3 Answers
-
Best Answer
Former MemberPosted on Oct 19, 2006 at 09:20 PMI am not aware of any known methods to do this, but there are some work-arounds worth trying:
1) Educate the users who do this by running a little script which logs on as the user ID with same password and then contact those for whom the authentication passed.
2) There is a parameter for enforcing special characters into passwords (only applies (default) when the password is next changed! So if the users are already running little scripts themselves then it will not work necessarily). It is a login/* param but I cant remember the name off hand. User IDs would typically not have special characters in the ID name, so a 1:1 match can be excluded.
3) There is table USR40 into which you can enter all the user IDs as a value. They will not be able to use their own or another users ID as a password (but a user with strong authorization will bypass this - more critical than an end user in my view...).
4) There might be a user exit for transaction SU3 into which you can code this, but it should not work anymore.
So as an affective mechanism, I would say that you cannot cure this problem and its prodigal offspring, you can only treat the symptoms.
Add a comment
-
Former MemberPosted on Oct 19, 2006 at 10:22 PM
If Your organisation is following any kind of pattern on Usernames for example all userID's start with 'c' or some other letter then You can enter 'C*' as pattern in USR40.
The Profile parameters Julius was talking about are
login/min_password_specials
login/min_password_letters
login/min_password_digits
I guess these parameters are interlinked with other parameters. Please check.
Add a comment
-
Posted on Oct 20, 2006 at 09:19 AM
Well, previously (prior to ABAP release 6.x) there was a password rule on "the first 3 characters of the password must not occur in the username".
Unfortenately, as of 4.6C the "aliasname" was introduced - which can be used alternatively to the userID for logon (not on the SAPGUI logon screen but when using RFC or programmatic logon).
The "aliasname" was introduced to allow a migration from the previous "SU05 users" (aka "internet users") to "SU01 users". Typically, the userID (for the "internet users") is generated by the system (and not known/visible to the user). In that case the password rule mentioned above does not make any sense - and consequently was dropped. To compensate the loss a set of additional password rules was introduced (=> ability to enforce the usage of digits, special characters, etc.).
This ambiguity (userID / aliasname) is preventing us from establishing a password rule which rejects passwords that are "too close" to the username (userID / aliasname). Otherwise we could introduce such a rule, e.g. allowing to reject passwords that contain more than # characters (=> substring) that also in the username.
Maybe one day we can get rid of the userID and only use the aliasname as "logon name". The userID would then only be an internal identifier / handle (e.g. used as database key field - in thousands of tables and millions of records, that's why it can never be changed).
But currently, an "aliasname" is optional.
Not all users do have an aliasname assigned (but all of them have an userID, of course).
Well, it's not that easy. There are a lot of implications (which need to be taken into consideration). Otherwise it would have been implemented, already ...
Cheers, Wolfgang
Add a comment
Add a comment