Disabling password history

[Former Member]

Hi,

We have 4.6C, ECC 6.0, and NW 2004s. Our company has purchased a 3rd party product, Avatier, to control passwords corporate wide. The security team is asking about the feasability of disabling password history in our SAP environments and removing SAP's password expiration (it would be controlled by Avatier). We can set the password expiration to 0, but I see no mechanism to stop storing password history in SAP.

Is there a technique for stopping SAP in 4.6C, ECC 6.0, and NW 2004s from storing and tracking the last 5 passwords?

Best regards,

Russ

[Former Member]

Did the 3rd party product tell you that they can control system specific SAP passwords?

I think there is a big misunderstanding here....

If you are not using the SAP password at all (e.g. SSO) then just deactivate it completely.

Cheers,

Julius

[Former Member]

They can synchronize passwords across all of our applications, as well as provide a self service feature to change user's passwords when they log into the network. It's my understanding that they are storing the new password both in Active Directory and directly in SAP, so totally disabling SAP passwords in not an option.

Cheers,

Russ

[Former Member]

But you cannot stop a Dialog user from changing their own password vuluntarily...

That is within the SAP system...

[WolfgangJanzen]

>

> They can synchronize passwords across all of our applications, as well as provide a self service feature to change user's passwords when they log into the network.  It's my understanding that they are storing the new password both in Active Directory and directly in SAP, so totally disabling SAP passwords in not an option.
> 
> Cheers,
> Russ

Well, this topic has been discussed many times in SDN before.

But the truth still remains unchanged: password synchronization does not work (in general).

In almost all cases the real intention is: Single Sign-On.

So, if a user should have only one password then this password must not be replicated / synchronized but there should be a central place where the password is validated. Take UNIX or Microsoft Windows as an example: no-one would try to synchronize local accounts across multiple servers using a file copy approach. Instead, a domain controler approach is used.

For the ABAP system this means: you have to use a proper SSO mechanism - then you can even delete / disable the password in the ABAP system.

Notice: ABAP systems are not the only systems with a (local) password policy. There are many different password policy implementations - and it might not be possible to define a common policy for all systems which are supposed to participate in a "password synchronization federation". That's a fact.

I'm really estonished to see how many people still only think of passwords when talking of authentication.

And consequently they believe that passwords need to be used (and consequently also synchronized) if a user should be able to logon to multiple systems without being forced to proof his identity to each and every of those systems (that's what is commonly referred to as "Single Sign-On"). That's really a kind of stupid conclusion: "logon = password authentication" -> "SSO = automated password authentication, based on password synchronization".

Well, you cannot derive a solution from a wrong assumption (ex falso quodlibet).

Instead, the assumption needs to be revised.

Regards, Wolfgang