Password Replication Active Directory - ABAP Backend

[Former Member]

Dear board,

my potential scenario looks like the following. There is a Single-Sign-On environment in place using Kerberos in the Windows world and for authentication at the SAP Enterprise Portal. As our application servers are on Unix, SPNego/SAP Logon Tickets are used further on for SSO to the backend systems.

For situations like administrative access using SAP Gui or Active Directory / Enterprise Portal downtime direct access to the SAP backend systems may be needed. As I do really mind setting up /managing users locally, I'm looking for a way to replicate the users password stored in the Active Directory to the ABAP user store for that case. Is there a way to do that?

Kind regards and many thanks,

R.

[tim_alsop]

Richard,

You will find that Active Directory does not allow access to the users password which is used for Kerberos authentication, so you cannot obtain this to sync with an ABAP password. Any Kerberos server that has the ability for code to request the password for a user could be considered to be insecure. The Kerberos protocol uses symmetric key cryptography to authenticate a user instead of sending and comparing a password.

Instead of syncing passwords, you need to use Kerberos authentication when accessing apps in ABAP engine via SAP GUI, SAP RFC etc. This requires the SNC interface provided by SAP and since your app servers are on UNIX you will need a third party certified SNC/Kerberos library. When implemented your user authentication via SAP GUI will be using Kerberos like you are using for your existing Web logon method. I represent a company that provides a product, which we have developed specifically to sell to SAP customers so that this need can be met.

If you are interested, please email me using my email address in SDN business card, and/or feel free to check our website <a href="http://www.cybersafe.com/links/snc.htm">here.</a>

Thanks,

Tim

[Former Member]

Hi Tim,

thanks for your reply. I'll check the site, but currently 3rd party software is not the preferred option.

Did I understand you right? In my scenario outlined, any ADS and/or Portal downtime would lead to the inability to login to the SAP backend systems with the users maintained there. Correct?

I do have an additional question regarding my scenario: In case I do have two independent AD structures in place, I have learned that it is possible to configure seperate login modules which check for authentication a) Kerberos for user group A against ADS I b) Username and Password for user group B against ADS II.

- Is this possible and advisable?

- Can I also adjust the Enterprise Portal to use independent data sources for different user classes? How could I do the differentiation?

Any hints or links to documentation are highly appreaciated.

Kind regards and many thanks,

Richard

[tim_alsop]

Richard,

Unless I misunderstood what you were trying to do, I am afraid that in this scenario you have no other option. You need to use 3rd party software, or open source software which you would need to compile and support yourself.

Normally, when ADS is deployed, there are multiple domain controllers, so that one can be used if another is not available. You would have to have a serious failure, e.g. many systems failing at same time for ADS to be unavailable.

If you are using more than one ADS domain, then the domains need to have trust relationship with the domain the user at workstation uses when they logon.

I am having hard time to understand why you want to have more than one ADS domain, when Kerberos cross realm trust can be used and avoid any complex configurations.

Normally, the j2ee engine will be configured so that the ticket auth stack invokes the appropriate login modules, and this stack is used by many applications, including the portal. I am not sure if it is possible to configure SAP so that some users use one auth stack (e.g. a specific set of login modules) and another set of users to use another auth stack. In some cases it is possible to specify an auth stack which is different to ticket on a per application basis, but when a stack/login module is used for a particular app it is used for ALL users logging onto that application.

I hope this helps.

Thanks,

Tim

[Former Member]

Hi Tim,

thanks again for your reply. The reason for seperated ADS is simply corporate policy and you are rigth, an ADS and EP portal landscape will not be setup with single instances only. Nevertheless I do see a drawwback in here.

So, my additional questions to the board are:

- I found documentation saying that UME can use several user stores for reading information, only one data source can be used for storing the data. Is this really true?

- Is it possible to customize seperate login modules in the UME to authenticate users A with Kerberos and users B with Username and Password? How is the separation handled? I've seen remarks on SDN, that it is possible via seperate URLs for example

Kind regards and many thanks,

Richard

[tim_alsop]

Richard,

I hope you don't mind me answering again, but I can help you with your second question. Hopefully somebody else will answer and give you info regarding your first question.

When you configure the ticket auth stack to use your SPNEGO based logon module, you can configure a fallback login module in this stack. Let me know if you need an example configuration. When accessing the app using a valid hostname the SPNEGO Kerberos authentication will work as required, but if you use a different host name for the same server, or an ip address, the browser will not be able to get a Kerberos ticket, so the SPNEGO login module will fail, and the login module later in the ticket stack will be invoked instead. This approach is used a lot, to allow for normal access using SSO, but allowing you to logon using a userid+password in special cases.

Thanks,

Tim

[tim_alsop]

Richard,

The ticket stack can be configured something like :

EvaluateTicketLoginModule SUFFICIENT

<your spnego login module> OPTIONAL

CreateTicketLoginModule SUFFICIENT

BasicPasswordLoginModule REQUISITE

CreateTicketLoginModule OPTIONAL

In above stack, normally items 1,2 and 3 will be used, but if item 2 fails to authenticate due to wrong host name being specified in browser, the login module in item 4 will be invoked and when this is successful an SSO2 ticket issued (item 5).

I hope this helps you ?

Thanks,

Tim

[Former Member]

Edit

Message was edited by:

Richard H.

[Former Member]

Hi Tim,

of course I do not mind you answering, thanks a lot. Highly appreciated! If it is not too large you may post the sample configuration in here.

Many regards,

Richard