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: 

Communication user is not requested change password

Former Member
0 Kudos

Hi

We have set a general rule, that users must change password every 90 days (login/password_expiration_time). We have now had a communication user in the system for more than 5 months, and the password is still not expired.

How can this be? Shouldn't communication users be forced to change the password?

In table USR02 I can see a field XUPWDSTATE - "Password Change Mandatory / Optional (See Domain XUPWDSTATE)", but I can't find any documentation on this field. The values are 0,1,254,255. Does anybody know what these values mean and how/when they are set.

Thank you for your help.

Regards, Morten

12 REPLIES 12

Former Member
0 Kudos

Take a look at [SAP Note 161146|https://service.sap.com/sap/support/notes/161146].

If you do not want the password changed (more specifically, that the user cannot change it's own password) then change the user type to 'SYSTEM'.

The documentation is in the data element XUPWDSTATE, not a domain range:

>DE XUPWDSTATE

>____________________________________________________

>Short Text

>Status of User Password (Value: -2/-1/0/1/2/3, see docu.)

>

>Definition

>Status of the user password (relating to whether it can or must be changed)

>

>Value Meaning

>-2 Password cannot (generally) be changed

>-1 Password cannot be changed today (only allowed once a day)

>0 Password can be changed, but does not have to be changed

>1 Password is initial and must be changed

>2 Password has expired and must be changed

>3 Password must be changed because it no longer meets the new rules

I would not recommend updating the password state to solve the problem. Rather reject the password based login, or change the user type (either SYSTEM or SERVICE if GUI capability is required).

Cheers,

Julius

0 Kudos

just one small additional information....

>

>

>

> >DE XUPWDSTATE

> >____________________________________________________

> >Short Text

> >Status of User Password (Value: -2/-1/0/1/2/3, see docu.)

> >

> >Definition

> >Status of the user password (relating to whether it can or must be changed)

> >

> >Value Meaning

> >-2 Password cannot (generally) be changed

> >-1 Password cannot be changed today (only allowed once a day)

> >0 Password can be changed, but does not have to be changed

> >1 Password is initial and must be changed

> >2 Password has expired and must be changed

> >3 Password must be changed because it no longer meets the new rules

>

-2 can be found in USR02 displayed as 254 and -1 as 255 (meaning cannot be changed before expired)

b.rgds,

Bernhard

Former Member
0 Kudos

Thank you for your response.

But I still do not understand why the communications user doesn't get locked after 3 months.

The documentation says, that general password rules apply to communication users, and our general setting is 90 days. Why is it then still possible to log in (not via GUI) with the communication user after 5 months?

Regards

Morten Ellgaard

0 Kudos

See the last sentence of the note I mentioned (default = 0 = not rejected, and the RFC interface does not provide the ability to change the password).

Also see the related notes.

Cheers,

Julius

Former Member
0 Kudos

Hi

As the title of the note was "RFC logon with the initial password" I didn't think that it was relevant, as this user has a productive password. As I read it now, a communication user is never locked unless you set the rfc/reject_expired_passwd setting. Is that correct understood?

I don't think this makes sence. A communication user must change password according to general password rules, but at the same time the system does not check if the password is expired?!?

Regards

Morten Ellgaard

0 Kudos

Hi Morten,

sounds strange, but is so.

Otherwise an rfc connection would never work!

Create a user of type comuncation. At this time the user has an initial password.

At the next (dialog) login the user must change this password. Well this is not possible, as the comuncaiton user is not able to interact. But an RFC-conneciton with this comuncation user with initial password will work....

So depending on the login procedure the verification is done or not and furthermore the status in usr02 is updated or not.

b.rgds,

Bernhard

0 Kudos

> As the title of the note was "RFC logon with the initial password" I didn't think that it was relevant, as this user has a productive password. As I read it now, a communication user is never locked unless you set the rfc/reject_expired_passwd setting. Is that correct understood?

Yes.

> I don't think this makes sence. A communication user must change password according to general password rules, but at the same time the system does not check if the password is expired?!?

"At the same time" is not the case, it's either one or the other which depends on rfc/reject_expired_passwd being 0 or 1.

A use of this is that you can create an RFC connection which WILL expire (if neglected, like a Dialog user might be neglected by it's "owner") when the password validity has passed.

Another use of it (rejecting the expired password of a Communication type user) is that it teaches folks to use SYSTEM and SERVICE type users for RFC and web-services - they learn the hard way...

Hope it is clear now. Please read the related notes as well, as there are some other aspects (and solutions).

Cheers,

Julius

Former Member
0 Kudos

Thank you for your response.

I think it is strange that the rfc/reject_expired_password=1 isn't default because the communication user is not acting as expected from the documentation.

Why document that the user must change its password when it is not possible?

Well, maybe I just have to accept this strange combination: The user must change the password but can't so the system just bypasses all normal security setup.

Regards

Morten Ellgaard

0 Kudos

There are a number of concepts which are introduced in this way, first with "enabler switches" and later with changed defaults as well.

In very old systems, you might even find a type 'D' user still. If you save once in SU01 when changing anything, it is converted to a type 'B' user.

The type 'C' user is being replaced by the type 'B' now as well and most scenarios will use (by default) the user type SYSTEM already to phase the conversion in.

You can use the above discussed parameter to force it, once you have finished the clean-up of already existing connections (the documented ones...)

Cheers,

Julius

Former Member
0 Kudos

Thank you for your help. I will try to avoid using communication users and use system users instead.

Regards

Morten Ellgaard

WolfgangJanzen
Product and Topic Expert
Product and Topic Expert
0 Kudos

>

> Hi

>

> We have set a general rule, that users must change password every 90 days (login/password_expiration_time). We have now had a communication user in the system for more than 5 months, and the password is still not expired.

>

> How can this be? Shouldn't communication users be forced to change the password?

>

> In table USR02 I can see a field XUPWDSTATE - "Password Change Mandatory / Optional (See Domain XUPWDSTATE)", but I can't find any documentation on this field. The values are 0,1,254,255. Does anybody know what these values mean and how/when they are set.

>

> Thank you for your help.

>

> Regards, Morten

Well, that's a common misunderstanding:

accounts of type "COMMUNICATION user" are subject of password expiration - however the password change requirement is not enforced (since the server cannot interact with the user). Actually that's not mainly caused by the user type but by the communication protocol being used: RFC and HTTP allow both, interactive and non-interactive system usage. Only the DIAG protocol (used by SAPGUI) ensures that an interaction with the user is possible - and in this case the system is enforcing a password change (when required).

Note 622464 provides an overview on the user types and the ability / requirement to change passwords (and other impacts).

Side-remark: modifying the USR02 field would not have any impact on the password change handling (beside the fact that such direct table manipulations are risky and strongly discouraged).

As reported by other SDN community members (and stated in note 320991, quite at the end) there are some profile parameters that will cause RFC and HTTP based logon to fail for passwords which are expired / initial. Setting those profile parameters will result in a downwards-incompatible system behavior - for this reason the default setting is "off".

Indeed, if you intend to use "technical accounts" for (automated) system-to-system communication, then kindly use the user type "SYSTEM". In that case, the password is neither "expired" nor "initial" - no password change is required nor can it be performed by the SYSTEM user itself. Only an user administrator can set a new password (in systems as of NWAS 7.0: even a downwards-compatible one - despite the password policy, see notes referenced by note 622464).

0 Kudos

>

> Indeed, if you intend to use "technical accounts" for (automated) system-to-system communication, then kindly use the user type "SYSTEM". In that case, the password is neither "expired" nor "initial" - no password change is required nor can it be performed by the SYSTEM user itself. Only an user administrator can set a new password (in systems as of NWAS 7.0: even a downwards-compatible one - despite the password policy, see notes referenced by note 622464).

An exception to this is if the SYSTEM user is itself authorized to administrate the passwords of user groups to which it itself belongs (object S_USER_GRP actvt '05' class 'what-ever-class-it-is-protected-by-in-USR02-CLASS-of-its-own-record')

In this case it is not changing it's own password. It is administrating itself.

=> it makes sense to limit the authority of SYSTEM users to only the documented use cases, or at the least to exclude some critical objects.

Cheers,

Julius