Disabling password history

Question

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

Answer 1

>
Russ Brooks wrote:
> 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