how to 'overrule' password policy for one user ?

[Former Member]

hi,

i am system administrator on our ECC 6.0.

we have 4 clients, test and production.

so i have 8 users, not everyone has the same password (for some reasons).

when i want to change the password i get the message that the passwortd cannot be on of the

last 5 passwords.

well, i want to set the password the same for ALL of my 8 users.

how can i 'overrule' the message, so that i can change the password ? any ideas ?

best regards, Martin

Edited by: Julius Bussche on Mar 28, 2011 6:46 PM

[Former Member]

Hi!

you have to delete in table usr02

fields:

OCOD1

BCDA1

CODV1

OCOD2

BCDA2

CODV2

OCOD3

BCDA3

CODV3

OCOD4

BCDA4

CODV4

OCOD5

BCDA5

CODV5

then go to SU01 and create a new initial password for each user...

afterwards make a new login and set the same password for every user...

ATTENTION - you have to change the entries in USR02 using a "hard" update in the database...

please be careful what you are doing and try it first with just one userid.

have fun

Flo

[Former Member]

uh uh uh, thats the very dirty way. i think i will have a problem with the audit when someone

detects what i have done there

isn't there a clean way for it ?;)

[Former Member]

Hi!

the normal way:

change it today to 123456

tomorrow to 234567

wednesday 345678

tuhrsday 456789

FRIDAY to your "real" password.

so you will have no rpoblems with the audit....

on the other hand, making dirty updates - who takes care and who will find out

[Former Member]

...

and if you create a rough and dirty update program, it will not be stored in SLG1

I guess if the right persons are reading my entries they will lock my userid

[Former Member]

Flo,

thats quite a good idea, but you should i do this day by day ???? isn't this possible on ONE day ???

best regards, Martin

[Former Member]

I think Flo was referring to parameter - login/password_change_waittime which has value of 1day so a user has to wait for 1 day to change his or her password again.

But as I said before User Administrator using SU01 can change password as many times as he want and then user can set it.

[Former Member]

This "hack" is completely useless if usr02-codvn NE 'A' or 'B' or 'D' as the fields are not used anymore since release 6.40...

The only thing it will achieve is a big mess.

Cheers,

Julius

[Former Member]

Hi!

Sure this does not work with CODVN = G. But in the request of Martin I could not see the Rel.

But should we really publish such illegal things like USRPWDHISTORY?

@Martin yes you have to change it for five days (depending on the system parameter maybe more often) manually...

have fun

Flo

[Former Member]

ECC 6.0. has code version 'G' as default, and unless he has a downwardly compatible requirement from a CUA somewhere in the landscape the usr02 fields will be empty.

What would make them "nicer" than usrpwdhistory to manipulate?

2 things which jump to mind are that the change documents are now in CDHDR and have a unique sequential number. The other thing is that random salted hashes might have a user specific attribute to them and you might delete that data.

Anyway... if the new common password is completely different from the most recent 5 (default and historic setting) then this whole discussion would have been unnecessary...

Cheers,

Julius

[martin_voros]

>

> But should we really publish such illegal things like USRPWDHISTORY? 

What is illegal about table USRPWDHISTORY. It's a regular table so to think that if you don't mention it on public forum then nobody will find it is a bit naive.

There are usually 3 reasons why you have to do some dirty trick: you want to do something wrong, there is a technical limitation in solution or there is something serious wrong with the solution. In my experience the first option is the most common and this case looks to me like the first option. It's not clear from your message what is the purpose of those users but as it was mentioned you can change their type or maybe you can use a different authentication method for them (certificates or SSO) to avoid password issues.

Cheers

[Former Member]

beside your discussion about "illegal things" i have chosen the following solution:

i set initial password for some times (2-5 times) in all clients in SU01. so then i was able to set the same password

for ALL Users in ALL clients on the same value.

thanks for your hints

best regards,

Martin

[Bernhard_SAP]

Hi,

change your user type to 'Service', reset your pwd in SU01 to the one you like. You won't be asked anymore at login to change your pwd. Verify with your admins about licensing for your user, if you use that type.

b.rgds, Bernhard

[Former Member]

I would basically just reset it from SU01 and then set it again and again till I get to the password I need. This means resetting the password at max 4 times for one user id. Believe me I have done this but I had only few users