Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

Create User without password because SNC should be used

Former Member
0 Kudos

Hi all,

I got this requirement from a customer to create with FM BAPI_USER_CREATE1 users without password. From my experience I know that the inital password is mandatory (or a productive password with the SELF_REGISTER flag).

But the customer provided screenshots from SE37 showing that with setting SNC.PNAME (even a wrong name), LASTNAME, GLTGV,GLTGB etc. it worked in his environment. I was not able to reproduce this.

Does anyone know if this is a supported use case and how it works?

Thanks,

Jens

5 REPLIES 5

Former Member
0 Kudos

You could deactivate the password for the user. Set the password to a random generated one when creating the user, afterwards remove it by using parameter DELETE_PASSWORD of FM SUSR_USER_CHANGE.

Former Member
0 Kudos

The BAPI has an import parameter in the LOGONDATA structure which is not formally released, but works fine.

CODVN = 'X' sends the encryption algorithm into nirvana and deletes the supplied password hash.

Alternately you can set BCODE and PASSCODE to '0000...'s as well, but CODVN will do that for you so is a better weapon..  :-).

Cheers,

Julius

former_member283791
Participant
0 Kudos

Our solution was to always have the password of a new user set to a default one and by default disabling password logon.

We found this to be the solution which involved the least amount of overhead and was easiest to adapt to situations where a user did need a password for logon.

I know it isn't a direct answer to your question, but figured it might help

0 Kudos

That does still leave a little gap for those who know the default password and the fact that the status is initial.

Using SUSR_GENERATE_PASSWORD to create a cryptic one is one notch more secure, but in that case you might as well hardcode CODVN = 'X' in which case the password is destroyed completely.

A plan B for when SSO might be down should ideally be in place anyway (IMO a self-service is best for this, as only those needing a password during that time need to even know about the SSO being down, which typically is for a relatively short period of time such as forgetting about server certificates or a required "identity provider" service is not reachable).

Cheers,

Julius

0 Kudos

If you create a user with a default initial or random password, you can also set login/password_change_for_SSO to 3 which means that the password will be automatically deactivated when it expires. After the password is deactivated it cannot be used anymore, and only SNC (or logon ticket) can be used to logon until somebody with authority activates the password and sets it to a known value.

Thanks,

Tim