PasswordSync using Novell IDM 3.5 with NW7.0

[Former Member]

Hello,

We are using Novell IDM ( old DirXML) 3.5 to Sync our passwords in our landscape.

The procedure is like this.

1) When the user forced to change thier password in every 90 dys ( AD), they change the password successfully in the Windows active directoy

2) Novell IDM captures it and update all the SAP system ( updates individually)

Environment

Windows Active Directory

Novell IDM 3.5

Netweave 2004s (NW7.0 )

It updates the passwords most part ...but we are getting lots of paswords failure in the SAP side.

The AD password policy and SAP password policy are same. But it fails and getting an error message as follows

Status: Error

Message: <description>SUSR_USER_CHANGE_PASSWORD_RFC : com.novell.nds.dirxml.driver.sapusershim.BapiException: 'PASSWORD_NOT_ALLOWED' exception while setting password. Password violates Server security policy</description>

from the message it looks like the password is failing to match the Server password policy.

Our user population is growing so the password failure also. I have to tell you this problemis not there in one of out 640 system.

I m trying to resolve this problem for almost 2 months. I would appreciate if any lights into this problem.

[Bernhard_SAP]

Hello Sudhir,

have you ever thought about to analyze the problem from ABAP Server side? The login trace will give you the exact cause, why the password change failed....

Just to make sure: The activatio of the logon trace is described in SAP note #495911.

b.rgds, Bernhard

[Former Member]

The status message (Status: Error

Message: <description>SUSR_USER_CHANGE_PASSWORD_RFC : com.novell.nds.dirxml.driver.sapusershim.BapiException: 'PASSWORD_NOT_ALLOWED' exception while setting password. Password violates Server security policy</description>) exactly tells you what's wrong.

I'm assuming, that you are using the Novell IDM SAP User connector to synchronize the password from the IDM system into your SAP User stack.

Using this connector, you can implement additional logic to that connector to verify, if the passwords which shall be synced to SAP match your SAP password rules.

If this is not the case, you can implement additional logic for problem escalations into the IDM system.

- Holger

[Former Member]

Hello,

Can you please give me little more information on the following.

1) Using this connector, you can implement additional logic to that connector to verify, if the passwords which shall be synced to SAP match your SAP password rules.

How we have to do this...Do you blieve IDM should have this facility....!

2) If this is not the case, you can implement additional logic for problem escalations into the IDM system

Please give me little bit more information on the above

[WolfgangJanzen]

>

> Using this connector, you can implement additional logic to that connector to verify, if the passwords which shall be synced to SAP match your SAP password rules. 

No - that's wrong. When performing a password change (SUSR_USER_CHANGE_PASSWORD_RFC) not only the password rules (PASSWORD_FORMAL_CHECK) are checked but additional "password change rules" are checked:

1. whether the user is allowed to change the password (SUSR_USER_PASSWORD_STATUS_GET)

2. whether old and new password are sufficiently different (login/min_password_diff)

3. whether the new password is in the password history (user-specific)

Well, for point 2 and 3 there are no APIs - that's all handled internally (inside the kernel part which is invoked by SUSR_USER_CHANGE_PASSWORD_RFC). So, you cannot predict failure.

A commonly made mistake is to combine two different APIs which have been designed for two different (and mutually exclusive) scenarios, namely BAPI_USER_CHANGE (designed for administrative purposes) and SUSR_USER_CHANGE_PASSWORD_RFC (designed for user self-services), and to invoke them in one single scenario. ["Ex falso quodlibet"|http://en.wikipedia.org/wiki/Ex_falso_quodlibet] - or "garbage-in / garbage-out".

Again: password synchronization is subject of (intrinsic) failure - but anyway: it's the wrong approach to achieve Single Sign-On.

Edited by: Wolfgang Janzen on Mar 31, 2009 10:30 AM

[Former Member]

Hello,

>1) Using this connector, you can implement additional logic to that connector to verify, if the >passwords which shall be synced to SAP match your SAP password rules.

My approach was much simplier. If I know the password policy rule (let's say, 8 chars long, must contain at least 2 numbers and 1 special character, can't be reused for the last 100 days, etc.), I can either specify the same password policy in eDirectory (base of Novell IDM), or I can implement a password parser as part of the SAP User connector.

If SAP would have a APIs to check a password against its own password policies, it might be a possibility to implement this as well. This would be the best approach, to refelect policy changes.

>2) If this is not the case, you can implement additional logic for problem escalations into the IDM >system

If the new password does not match the expected SAP password policy, it could be noticed using SMTP mail or whatever you want. It could also be possible to reset the password in eDirectory, but this would require some more logic to make this happen.

The keypoint for any resulting action is to gather the rule violation.

Regards

Holger

[Former Member]

>

> >1) Using this connector, you can implement additional logic to that connector to verify, if the >passwords which shall be synced to SAP match your SAP password rules.

and

>

> My approach was much simplier. If I know the password policy rule (let's say, 8 chars long, must contain at least 2 numbers and 1 special character, can't be reused for the last 100 days, etc.), I can either specify the same password policy in eDirectory (base of Novell IDM), or I can implement a password parser as part of the SAP User connector.

Just so that it is clear, you are quoting yourself here and not Wolfgang, even although you state that it is much simpler than what you originally wrote.

Regarding the minimum difference and history length of the password, which is something which should be known to the user if they are changing their own password, I guess you could capture the password on the external side (the IDM) and check these without having to use an absent API, before calling the RFC.

But still, that is yet another place where the password can be found or misused - in addition to the fact that the users are deprived of using different stronger passwords for different systems / clients which could isolate potential abuse or password sharing.

Basically, it means that your passwords are only as good as the weakest link (and mechanism) in all the systems / clients, and then misuse is open for all of them and for all users who use the Novell IDM.

In addition to the real single-sign-on already mentioned, a "password vault" is another and in my opinion much better option than this synchronization attempt for special users.

I have implemented and used these before and - if it is for "basis folks" who have many systems and clients to access and dont want to use other even more insecure means than password synchronization - they are very happy with it and get used to it easily, without the challenge and risks of massive password memory but still without "workarounds" and wondering who is accessing the systems...

My 2 cents,

Julius

[Former Member]

Hi Julius,

>Just so that it is clear, you are quoting yourself here and not Wolfgang, even although you state that it >is much simpler than what you originally wrote.

You are right, that's a mistake to reply to Wolfgang. My response was a reply to Sudhir's followup questions.

>Regarding the minimum difference and history length of the password, which is something which >should be known to the user if they are changing their own password,

If it would be the case, both Single SignOn and Password Sync wouldn't be needed. Unfortunately for a 'normal' human it's hard to remember 10 different passwords for 10 different systems and even harder to remember the history of each of this systems.

From my experiences, both solutions (Single SignOn and Password Sync) do have there pro's and con's.

Which fits for one customer doesn't for an other.

>But still, that is yet another place where the password can be found or misused

>Basically, it means that your passwords are only as good as the weakest link

That's definitive the biggest issues with Password Sync. But what do customers reply? 'We don't care, as long as we only have to remember one password!'

A big hurdle in a more secure Single SignOn solution, are the costs for additional strong authentification methods, which are required to secure your primary logon.

My final 2 cents

Holger

[Former Member]

> But what do customers reply? 'We don't care, as long as we only have to remember one password!'

A real Single-Sign-On will fullfill that requirement as well - logon once to the workstation or a certificate store, and the authentication is transparent afterwards, without password being needed (i.e. deactivated) in the backend systems at all.

> A big hurdle in a more secure Single SignOn solution, are the costs for additional strong authentification methods, which are required to secure your primary logon.

I have done vendor evaluations of Single-Sign-On solutions, and while this is very true in isolated cases, it is not true for all solutions available and I know some customers who are very happy with the solutions they have.

I would go so far as to say that the costs of most certified SSO solutions would with reasonable certainty be less than the costs of consulting and supporting and trouble-shooting a Password Synchronization solution which SAP seems actively trying to stop.

Cheers,

Julius

[WolfgangJanzen]

>

> If it would be the case, both Single SignOn and Password Sync wouldn't be needed. Unfortunately for a 'normal' human it's hard to remember 10 different passwords for 10 different systems and even harder to remember the history of each of this systems.

Single Sign-On does not mean that you do not have to logon.

But it means: that you truly logon only once - that could also be a password-based authentication.

The important part is: the user has only one single password and it will be only validated once (centrally).

Subsequently other credentials are validated (the backend systems will not perform a password-based authentication).

In contrast to that: if every system performs a password-based authentication, the user actually has many passwords (which are more or less identical - if the password synchronization works reliably, which I doubt that this will be possible).

> From my experiences, both solutions (Single SignOn and Password Sync) do have there pro's and con's.

> Which fits for one customer doesn't for an other.

Sorry to disagree. Password Synchronization has only disadvantages - just that some people believe that it's less pricy than a SSO solution (ignoring the effort to handle problems which result from synchronization problems, efforts to equalize the password policies (if at all possible), etc.).

But I admit: not all systems might be capable of supporting SSO solutions.

In that niche password synchronization solutions might step in - as "poorman's SSO" solution.

> >But still, that is yet another place where the password can be found or misused

> >Basically, it means that your passwords are only as good as the weakest link

>

> That's definitive the biggest issues with Password Sync.

There's another big issue: in order to reduce problems you have to lower the password rules to the highest common subset - in the end you'll have a very unrestrictive password policy (i.e. tolerating very primitive and easy to guess passwords, thus making a dictionary attack very likely to succeeed).

To me that's the biggest issue - and a real threat (of which some customers might not be (made) aware of).

> But what do customers reply? 'We don't care, as long as we only have to remember one password!'

Depends on who you ask at the customer side.

Some customers have to ensure strong authentication - and condemn password authentication in general. Password authentication is weak - and it will get even weaker if you synchronize the password (resulting in many copies spread over multiple systems). Well, it's a matter of "Governance, Risk and Compliance" (GRC) - more and more customers realize that this is important for them. In some countries that's demanded (at least for certain industries, e.g. public sector and suppliers).

> A big hurdle in a more secure Single SignOn solution, are the costs for additional strong authentification methods, which are required to secure your primary logon.

That's a one-time investment.

More important is the Total Cost of Ownership (TCO).

Edited by: Wolfgang Janzen on Apr 1, 2009 10:35 AM

[Former Member]

Hello,

Our major issue is...in our companies other division have SAP systems, mostly they have 6.40 and less release systems. Novell IDM sync the password with out much issue. In our division our SRM is stll in 640...we do not have a single failure.

I beleive from 700 onwards..SAP tightened the policy...Which are the major area it improved from 640 to 700.

Also there is another suggestion from our team is . as the password policy is maintained from LDAP ...so on the SAP side we can have a lighter policy.

We have another project is about to happen in this area is to integrate AD/LDAP with SAP.

Thanks

sudhir

[Former Member]

> I beleive from 700 onwards..SAP tightened the policy...Which are the major area it improved from 640 to 700.

I would describe it as an improved design and more secure settings which can be made.

> Also there is another suggestion from our team is . as the password policy is maintained from LDAP ...so on the SAP side we can have a lighter policy.

How do you prevent the user from changing their password locally, against the weaker rules?

Particularly if they know that they can avoid the requirement to change their password and dodge the IdM rules (like the users who would be expected to be targets of misuse are...) then they will opt for a weaker password and faster logon. They tend to get used to this after a while...

> We have another project is about to happen in this area is to integrate AD/LDAP with SAP.

If you are refering to the password hook, then note that this offers the option to set an "initial" password. It will force you to use less secure config, and the user's will still make a mess of it when they change their passwords locally.

Also: If someone resets the password locally, uses the account, and then waits for the sync to follow -=> how would the user have a chance of noticing that someone used their account and "replaced" the password. This is no longer possible from release 7.00 onward.

To be honest with you, I think you are entertaining and paying for a lot of workarounds to achieve what you want - which is actually a single-sign-on - and is not as difficult as you think.

My recommendation would be to invest a bit of time in a vendor evaluation (try to cut through the marketing and powerpoint glamor as quick as possible) and then decide what is best for the long run.

Good luck,

Julius

[WolfgangJanzen]

>

>
> Environment
> 
> Windows Active Directory
> Novell IDM 3.5
> Netweave 2004s (NW7.0 )

Question 1: what kind of frontend components are you using?

- SAP GUI

- SAP Business Explorer (RFC-based client)

- browser

Question 2: what operation system is beneath your ABAP server?

- Microsoft Windows

- other

Notice: if you are using SAP GUI / RFC-based clients and if your ABAP server is running on Windows, you might consider to use the SNC (wrapper) libraries provided by SAP to enable SSO (based on Kerberos / NTLM) to your ABAP system.

[Former Member]

Hello,

Question 1: what kind of frontend components are you using?

- SAP GUI

-

Question 2: what operation system is beneath your ABAP server?

- AIX 5.3

thanks

Sudhir

[WolfgangJanzen]

>

>
> Question 1: what kind of frontend components are you using?
> - SAP GUI
> 
> Question 2: what operation system is beneath your ABAP server?
> - AIX 5.3

Unfortenately, you cannot use the (free of charge) SNC libraries provided by SAP in that case - because of your AIX server.

But there are 3rd party SNC products which support Kerberos on AIX.

[Tim Alsop|https://forums.sdn.sap.com/profile.jspa?userID=2090095] works for one of those vendors - but there are also others; see [SAP Note 66687|https://service.sap.com/sap/support/notes/66687].

[tim_alsop]

Sudhir,

The easiest and most secure way to authenticate users via SAP GUI onto SAP ABAP on AIX is to use SNC, instead of password sync. To use SNC you need an SNC library which you can install on each Windows workstation where SAP GUI is installed, and also a library which is installed and supported on AIX 5.x. You can attempt to use open source code and build this library yourself (some companies/people are brave enough to undertake this), or you can use a SAP certified and supported product which includes the libraries required. There are products available from SAP partners which use either Kerberos protocol (the authentication protocol used by Windows and Active Directory, so works well if you want to use AD credentials for SSO) or x.509 certificates (most of time will require additional infrastructure to be setup when using with Active Directory).

As Wolfgang has already mentioned, you should seriously consider this approach instead of password sync.

In addition to the links Wolfgang has provided, you can look on SAP EcoHub and search for SNC. To get to EcoHub you can click on the tab at the top of this page.

Thanks,

Tim

[Former Member]

You say that your AD and SAP password policies are same but for the error message it does not seem that way right ....seems in SAP you have some login parameters which is probably asking for a special character or a digit or upper case / lower case letter.

Please check the login parameters in your sap systems where this is failing and see if there is some change.

[Former Member]

> You say that your AD and SAP password policies are same but for the error message it does not seem that way right ....seems in SAP you have some login parameters which is probably asking for a special character or a digit or upper case / lower case letter.

It might not be all that easy to spot though. Specifically check the parameter login/password_downward_compatibility and login/compliance_to_current_policy. If compatible with the old and the new password mechanism, but if the current password (before the sync) is not compliant with the policy then the behaviour is different (the password change is forced). Perhaps the calling program is not handling this (sending the new password to the wrong screen?) in a correctly configured system.

Another possibility is that after the changes of SAP note 899614, the calling program was not corrected to handle the return messages. This note also changed the interface of the function module...

> Since the programs that use the function module SUSR_USER_CHANGE_PASSWORD_RFC also have to be adjusted accordingly, additional corrections (to other components) are necessary...

But I still think the wrong use-case for this function module is being applied here, and the solution brings more security risks with it than what it appears to (cosmetically) strengthen password rules...

Basically, synchronizing passwords is not an excuse for stronger password rules. I agree with Tim that looking beyond this problem for a better solution is the best way.

Cheers,

Julius

[WolfgangJanzen]

>

> Basically, synchronizing passwords is not an excuse for stronger password rules. I agree with Tim that looking beyond this problem for a better solution is the best way.

Well, unfortenately there is a correlation between "weak password rules" and "password synchronization": if you aim at having just one single password in many systems which however have their own (local) password policy, then you have to lower the password policy of all systems to the highest commonly accepted policy - which will be lower the more (heterogeneous) systems you want to integrate; and it might also fail to find such a common ground.

Let me tell you, again: password synchronization is a bad idea.

If you aim to have just one password, then using a domain controler approach is the way to go: you should only have one central place where passwords are validated.

In most cases "password synchronization" serves as "poor man's Single SignOn solution".

Well, it might be politically incorrect but it's a bitter fact: poor people become sick more often (and more severe) than richer ones.

So, if reliabilty is an important factor for you, you might better consider to implement a proper SSO solution, instead. It pays out - especially since you want to scale out (more users, more systems).

[Former Member]

Yes, I agree with you. If this is only a password sync solution and not a single-sign-on, then it weakens the security of all the systems to the level of the weakest chain and has limitations in scalability in increasing error margins as it gets bigger.

> Well, it might be politically incorrect but it's a bitter fact: poor people become sick more often (and more severe) than richer ones.

Try tell that to a spaced-out rockstar or a cowboy who just shot himself in the foot...

Cheers,

Julius

[Former Member]

Hello,

Yes we have difference in Policies between AD and SAP. those difference are

login/password_history_size 5 (SAP) 7 (AD)

This is the main difference between them.

We tried to Password Downward_compatibility paramter to 2 / 3 and 5 ( note 1145106)

but that practtically shrinked the password to max of 8 character....this raised lots of failure as users mostly uses more than 8 characters

We tried to have min 1 lower case also as per note 1023437. this also failed to give as a solution.

We will try to look into the other option as you suggested .

Edited by: Sudhir Pattalil on Feb 24, 2009 3:31 PM

[Former Member]

> This is the main difference between them.

What is the value of your parameter login/min_password_diff ?

[WolfgangJanzen]

>

>               Yes we have difference in Policies between AD and SAP. those difference are 
> 
>                                            
> 
> login/password_history_size      5 (SAP)                  7 (AD)      
> 
> This is the main difference between them.

In that case the SAP system is less strict than the Active Directory, so this could not explain the failure.

By the way: you can configure the ABAP system to use the same history size ...

Well, I assume some other error cause:

once you've run out of synch (e.g. because you have "missed" a password change event, e.g. during downtime of the system) you'll be in trouble. Such things can always happen - and that's why I keep repeating: password synchronization is subject of intrinsic failure - it simply CANNOT work (reliably and under all conditions). It MIGHT only work under CERTAIN conditions (that's why I call such an approach a "good-weather solution").

[WolfgangJanzen]

>

> > This is the main difference between them.
> What is the value of your parameter login/min_password_diff ?

Good point. They way how the password difference is calculated is quite SAP specific (see RZ11: documentation for that profile parameter).

[Former Member]

Hello,

login/min_password_diff is 1

[Former Member]

Okay, so we are on a wild goose chase....

It is niether the cycle (users do this...) nor the minimum difference within the cycle (which is more configurable within SAP).

You mentioned before that a 6.40 system is not having this problem. Please compare table USR40 of this system to the others. Are there differences?

This table defines patterns which are not permitted, and your Novell is perhaps "only" doing validations of characters which are not permitted against a set which are.

Unfortunately, this table was misinterpreted a long time ago...

If this is the difference, then I recommend rather setting a minimum 1 "digit" and minimum 1 "special" in the params to break the dictionary attacks and set the minimum difference (see above) to something which is compatable with the IdM.

My personal belief is that if users change their passwords often enough, and logon often enough, and use at least one digit, then they can protect themselves.

A secure single-sign-on (SSO) is in most cases a better option: to protect the user from their own errors should their password be leaked once, in one of the systems... and one of the clients...

Please keep us posted on both fronts (your password and SSO thoughts).

Cheers,

Julius

[Former Member]

Hello ,

We are wondering whether the login/password_history_size is interfearing with LDAP password as it keeps track of it

Is ther a way we can disble this in the ABAP profile.

Sudhir

[Former Member]

And I am wondering whether you have checked USR40 and considered ditching this idea?

May I ask how old this solution is and for how long it has been causing troubles?

Cheers,

Julius

[Former Member]

USR40 is empty. And this problem is there for a year now from the day of implementation. As recently it became visisble as the system user size increased.

[WolfgangJanzen]

Sorry, but I need to repeat myself:

password synchronization might fail due to the existance of (local) password policies.

That's a fact you have to face - you cannot change it.

And the likelihood of such failures will increase with the number of (heterogeneous) systems of which you want to synchronize the passwords - that's another intrinsic fact.

The conclusion of all that is:

if you want to ensure that a user has to memorize just one single password but is enabled to use multiple (different) systems, make sure that there is only one single place where passwords are checked (domain controler approach, Single Sign-On ). Or, and that might be even a better solution, forget about passwords and use other authentication mechanisms, e.g. X.509 client certificates (which also enable S/MIME and (digitally) signing documents, offline). Or, SecureID Tokens. Just to mention a few.

Yes, that requires some investment. But those mechanisms cause less trouble than the attempt to synchronize passwords. In the end, this is less costly (and might enable new usage scenarios, as stated above). Total cost of ownership is the keyword.

[WolfgangJanzen]

This message was moderated.

[tim_alsop]

Sudhir,

I know this is not directly answering your question, but I thought it might be useful for you to know about an alternative solution, just in case you decide you do not want to continue with this password sync approach. If you are not interested in any other solution, please accept my apology.

Often when companies want to use "common authentication" or "sso" for applications, they first consider synchronization of passwords, as this seems to be the simplest way to solve the problem. However, it is not the most secure approach, and has a few challenges, such as the ones you have observed with password policy differences. It can also mean that passwords can get out of sync if it is not properly setup. The alternative is to use the same authentication technology in SAP as you use for MS AD domain authentication (Kerberos). This is not as hard or as expensive as you might think, and will give you many added security benefits and completely remove the need to sync passwords.

Once again, I am sorry if you were not interested to hear about alternatives.

Thanks,

Tim

[Former Member]

> SUSR_USER_CHANGE_PASSWORD_RFC

This FM is used by external applications (Java Connectors, Portals, ITS, etc) to change the user's own password IF they supply their own correct "old" password. Depending on your release, it also does not provide much information to the external caller about the reason for the password being unsuccessfull. I don't see any intended compatability with synchronizing passwords from an adminsitration tool ...

But to answer your question: I would suspect UPPER CASE / lower case conversion (upward and downward compatibility of passwords) as being the first cause to investigate. You can do a more detailed analysis on the server side using the procedure described in SAP note 495911.

Cheers,

Julius