Multiple-Domain SSO Kerberos Authentication

[Former Member]

Currently we are set up for SAP SSO using MS Kerberos exactly as described in SAP's guide at: http://help.sap.com/saphelp_nw70/helpdata/EN/44/0ebf6c9b2b0d1ae10000000a114a6b/content.htm

Please think of the following scenario:

1) The SAP application server belongs to CORPORATE domain. The service account for SAP is also in the same domain such as CORPORATE\SAPService<SID>

2) In RZ10, the snc/identity/as parameter is set up like p:SAPService<SID>@CORPORATE for the SSO to work.

3) The SPNs are also defined in the CORPORATE domain controller such as SETSPN -A SAPService<SID>/dontcare CORPORATE\SAPService<SID>

4) Users install the appropriate gsskrb5.dll file into their system32 folder and then create a new SSO-enabled entry for the SAP server in their SAPGUI, by activating the SNC and entering the SNC Name: p:SAPService<SID>

The scenario above works very well for us for authenticating the CORPORATE domain users. My extended scenario (and hence the question) is as follows:

5) Let's assume we have SAP users from another domain called ADVISORS as well. There is a trust relationship between the CORPORATE and ADVISORS domains at the OS level, so the ADVISORS users can reach files/folders/servers/applications in CORPORATE domain and vice versa.

6) If we would like to set the ADVISORS users with Kerberos SSO authentication to our SAP server in CORPORATE domain, what should we do?

I have tried changing the user mapping on /SU01 for a user coming in from ADVISORS domain but it didn't work.

Is it possible to have multi-domain Kerberos SSO authentication to the same SAP server?

Thank you in advance for your reply.

[tim_alsop]

Hi,

Thankyou for giving a very good and detailed explanation. If the user at the workstation logs onto ADVISORS domain, their Kerberos principal name will be <user>@ADVISORS, so you would need to add p:<user>@ADVISORS in the SNC tab of SU01. If the trust is setup between the domains, then everything else should be transparent.

Effectively what happens is that the Kerberos library on the workstation requests a service ticket called SAPService@CORPORATE, and this ticket request is sent to the ADVISORS domain controller (this is because workstation user logged onto the ADVISORS domain). The ADVISORS domain controller will then respond with a special Kerberos TGT called a cross-realm TGT (created using its trust relationship with the CORPORATE domain) and the client will then use this cross-realm TGT to send another service ticket request to the domain controller for the CORPORATE domain, and everything fom this point on works same as if the user had logged onto CORPORATE domain using a user account in that domain, but instead the SAP server will recognise that the user has authenticated to the ADVISORS domain from their initial TGT obtained during workstation logon.

I hope the extra detail given above is useful to you.

I am not 100% sure if the SAP Kerberos library supports the cross-realm scenario described above, but I do know that it is supported with a SAP Kerberos library provided by a SAP partner company.

My suggestion is that you check that you have entered the correct SNC name in the su01 snc tab, and then check workstation credentials cache using kerbtray tool, and see if you can see the cross realm TGT in the cache - if you can then it suggests the cross realm TGT is being issued and used, which is good. Otherwise you need to ask SAP for help, and perhaps they have a way to enable a debug trace in their Kerberos library to allow you to find out why the authentication has not worked ? Or, perhaps there is some information on the server in the dev_w0 trace file ?

Thanks,

Tim

[former_member225654]

Hello Tim,

Do you know if the multiple domain authentication is supported with the DLL provided in SAP note 2115486? Or is this only supported with the new SAP Single-Sing-On product libraries?

Thanks,

Noe Hoyos

[Christian_Cohrs]

Hi Noe,

the old solution you mention does not support multiple Windows domains.

SAP Single Sign-On does indeed support this.

Best regards,

Christian

[tim_alsop]

It is also supported with third party SSO products available from SAP partners.

[Former Member]

Thank you for your very detailed and informative answer Mr. Alsop, I really appreciate it. I gave 2 points to your answer although it hasn't solved my problem (yet). Thanks again.

I already tried putting the p:User@ADVISOR entry in the SNC tab of SU01, but it did not work.

I think what I will do next is to get that "kerbtray" application and see what authentication(s) are passed to the SAP server when I log in from the ADVISOR domain.

Maybe it is a limitation of the MS-supplied Kerberos library itself and it cannot work with multiple domains, I am not sure...I couldn't find any documentation on this.

Your answer still helped me deciding on my next steps toward the resolution. Thanks!

[tim_alsop]

There is no limitation in the MS Kerberos library, but this might be a limitation of the SAP SNC library, which itself calls the MS Kerberos library.

No, you don't need to use setspn on ADVISOR domain, since the ADVISOR domain will just receive the service ticket request for a ticket in the CORPORATE domain, and this is enough for it to issue the cross realm ticket. This is known as Kerberos referrals.

I suggest you check the dev_w0 trace file on server, in case this has gss-api related messages that help diagnose the issue.

PS. Thankyou for the points given so far - lets see if we can work together to solve this so I can get more points

Thanks,

Tim

[Former Member]

> PS. Thankyou for the points given so far - lets see if we can work together to solve this so I can get more points

Kindly take note that joking about points is permitted, but asking for points and particularly offering points subject to conditions is ILLEGAL in most countries...

[Former Member]

Oh, I forgot to ask. Do I need to make the SETSPN entries in the ADVISOR domain as well? Although my SAPService<SID> user belongs to the CORPORATE domain, do I still need to create a dummy reference in ADVISOR domain's SPN for the cross-domain SSO to work?

What do you think?

[Former Member]

Hello again,

I checked the dev_w0 file and I couldn't see any error entries regarding gss-api there. However, I would like to mention that the logon process probably doesn't make it to the server yet when I log on with a user from the ADVISOR domain.

I open my SAP GUI and choose my SSO-enabled connection to my SAP server (as a user in the ADVISOR domain) and this is the SAPGUI error that I get:

GSS-API(maj): Miscellaneous Failure

GSS-API(min): SSPI::IniSctx#1()==Specified target is unknown or unreachable

target="p:SAPService<SID>@ADVISOR"

Error in SNC

Now, the above error message tells me that the SAPGUI is looking for the service user defined in the ADVISOR domain (either via SETSPN or via profile parameter snc/identity/as).

The SSO-enabled entry in the connections list of SAPGUI is configured to "Activate SNC" and use "p:SAPService<SID>" in the Network tab of the entry. Can it be that my user's domain (ADVISOR) get appended to the end of this "p:SAPService<SID>" entry and become "p:SAPService<SID>@ADVISOR" -- thus a corresponding entry can't be found in ADVISOR domain and SAPGUI fails?

-- While I was typing my last sentence above, I added the domain name to the "p:SAPService<SID>" entry in the Network tab of SAPGUI connection.....and it authenticated me just fine! Still I had to change my user mapping on /SU01 to allow p:User@ADVISOR but nonetheless it worked as you suggested!

-- If I can find a way to make multiple domain entries in the /SU01 - SNC tab for one user, that will be great! I couldn't make my SAP server accept two domain user mapping entries in the /SU01 - SNC tab.

Thank you again Mr. Alsop. You have been very very helpful.

[tim_alsop]

Hi,

I am pleased you solved it - the SAP GUI configuration which is stored in saplogon.ini needs to use the same SNC name that is configured in server in snc/identity/as statement, e.g. p:SAPService@CORPORATE. This is same name regardless of which domain the user has logged onto. I think you know this now, and you just had the wrong entry in SAP GUI configuration, which is why this was not working.

Take care,

Tim

[Former Member]

> -- If I can find a way to make multiple domain entries in the /SU01 - SNC tab for one user, that will be great! I couldn't make my SAP server accept two domain user mapping entries in the /SU01 - SNC tab.

You can't configure multiple SNC-names per user in transaction SU01, but [you can use transaction SM30, view USRACL, to directly enter the SNC names in the USRACL table|http://help.sap.com/saphelp_nwmobile71/helpdata/en/f3/fc53af92c5421891a31b7d1d525c5e/frameset.htm].

Regards,

Alexander

[WolfgangJanzen]

>

> You can't configure multiple SNC-names per user in transaction SU01, but [you can use transaction SM30, view USRACL, to directly enter the SNC names in the USRACL table|http://help.sap.com/saphelp_nwmobile71/helpdata/en/f3/fc53af92c5421891a31b7d1d525c5e/frameset.htm].

You seem to be in favor of direct table manipulations ...

(Hereby it's irregardless whether you use generic ABAP tools or external SQL tools).

Well, I'll give our support colleagues a hint ...

It might save them valuable time when analyzing weird problems (reported by you or other customers who might have applied this "trick").

Regards, Wolfgang

[Former Member]

Wolfgang,

I think as this activity is documented in the official SAP documentation (see link) it can't be such a "bad thing". And AFAIK there existis no way to maintain multiple SNC-Names per user in the User Management.

Regards,

Alexander

[tim_alsop]

>

> Wolfgang,
> 
> I think as this activity is documented in the official SAP documentation (see link) it can't be such a "bad thing". And AFAIK there existis no way to maintain multiple SNC-Names per user in the User Management.
> 
> Regards,
> Alexander

Yes, the SAP Help does mention that this is allowed, but perhaps the help needs to be udpated/corrected ? Personally, I discourage the direct editing of USRACL since some of our customers tried this and got problems. I think some problems can occur due to the hash which is part of the table entry. If you use t-code su01 to maintain USRACL instead of directly editing it, then the hash is correctly calculated.

Thanks,

Tim

[WolfgangJanzen]

>

> >

> > Wolfgang,
> > 
> > I think as this activity is documented in the official SAP documentation (see link) it can't be such a "bad thing". And AFAIK there existis no way to maintain multiple SNC-Names per user in the User Management.
> > 
> > Regards,
> > Alexander

>

> Yes, the SAP Help does mention that this is allowed, but perhaps the help needs to be udpated/corrected ? Personally, I discourage the direct editing of USRACL since some of our customers tried this and got problems. I think some problems can occur due to the hash which is part of the table entry. If you use t-code su01 to maintain USRACL instead of directly editing it, then the hash is correctly calculated.

>

> Thanks,

> Tim

Can you please post that link?

[tim_alsop]

Wolfgang,

Check http://help.sap.com/saphelp_nwmobile71/helpdata/en/f3/fc53af92c5421891a31b7d1d525c5e/frameset.htm

At bottom of the page it says:

"As an alternative, you can use transaction SM30, view USRACL, to directly enter the SNC names in the USRACL table."

Thanks,

Tim

Edited by: Tim Alsop on Nov 27, 2008 10:27 AM

[WolfgangJanzen]

>

> Wolfgang,
> 
> Check http://help.sap.com/saphelp_nwmobile71/helpdata/en/f3/fc53af92c5421891a31b7d1d525c5e/frameset.htm
> 
> At bottom of the page it says:
> 
> "As an alternative, you can use transaction SM30, view USRACL, to directly enter the SNC names in the USRACL table."
> 

Thanks, Tim.

Well, I've tried it out myself. But it works as expected:

I'm getting the error message "An entry already exists with the same key"

This prevents to assign multiple SNC names to one single ABAP user account.

Same as in SU01 or BAPI_USER_CHANGE.

[tim_alsop]

>

> Well, I've tried it out, myself. But it works as expected:
> I'm getting the error message "An entry already exists with the same key"
> 
> This prevents to assign multiple SNC names to one single ABAP user account.
> Same as in SU01 or BAPI_USER_CHANGE.

Yes, this is same as my findings, so I am not sure what Alexander is doing ?

As far as I am aware, only 1-->many mapping is possible with SNC authentication. I wish it was possible to do otherwise, but with current product releases, this is the way it works.

[WolfgangJanzen]

>

> As far as I am aware, only 1-->many mapping is possible with SNC authentication. I wish it was possible to do otherwise, but with current product releases, this is the way it works.

Well, for SNC it's only possible to assign one single SNC name to one ABAP user account.

For X.509 client certificates it's (currently still) possible to assign multiple client certificates to one ABAP user account. But using the new rule-based certificate mapping (available as of NW 7.11) the ABAP userID (or the ABAP user aliasname) needs to be contained in the certificate. This limits / restricts / contraints the capabilities of N:1 mappings (but for the sake of reduced TCO: you only have to define the mapping rule(s) - but no longer thousands of individual mapping entries).

[tim_alsop]

>

> Well, for SNC it's only possible to assign one single SNC name to one ABAP user account.

You can map the same SNC name to more than one ABAP user account, and when this is done the user is given a screen allowing them to decide whcih ABAP user account and client number to use for this session. This is what I meant by 1-->many. This is useful when the user has a logon in more than one client and sometimes wants to logon to client 100, and on other logons he might want to logon to client 200.

Thanks,

Tim

[WolfgangJanzen]

>

> You can map the same SNC name to more than one ABAP user account, and when this is done the user is given a screen allowing them to decide whcih ABAP user account and client number to use for this session. This is what I meant by 1-->many. This is useful when the user has a logon in more than one client and sometimes wants to logon to client 100, and on other logons he might want to logon to client 200.
> 
> Thanks,
> Tim

Now, I see what you are referring to.

Well, that's no in contradiction to my statements ...

Summary:

1 : N mapping for SNC Name <-> ABAP User Account (client-specific)

M : N mapping for X.509 client certitifcate <-> ABAP User Account (client-specific)

M : 1 mapping for rule-based mapping: X.509 client certificate <-> ABAP User Account (client-specific)

Side-remarks:

1. Only in the case of ambiguous SNC mappings and SAPGUI logon such a "select one of the following matching entries" dialog is presented.

2. When using rule-based certificate mapping the various certificates (which are all mapped to the same user) do need to contain the ABAP UserID (or the ABAP user aliasname). So, those certificates do have "something in common" - which refers to the user.

Edited by: Wolfgang Janzen on Nov 27, 2008 1:02 PM

[tim_alsop]

>

> 1 : N mapping    for   SNC Name <-> ABAP User Account (client-specific)
> M : N mapping   for   X.509 client certitifcate <-> ABAP User Account (client-specific)
> M : 1 mapping    for  rule-based mapping:  X.509 client certificate <-> ABAP User Account (client-specific)

From above supported mapping methods, are they all applicable to SAP GUI SNC-authentication, or are the x.509 certificate specific mapping methods you mentioned only applicable when logging onto ABAP AS using Web-browser ?

Thanks,

Tim

[WolfgangJanzen]

>

> >

> > 1 : N mapping    for   SNC Name <-> ABAP User Account (client-specific)
> > M : N mapping   for   X.509 client certitifcate <-> ABAP User Account (client-specific)
> > M : 1 mapping    for  rule-based mapping:  X.509 client certificate <-> ABAP User Account (client-specific)
> 

>

> From above supported mapping methods, are they all applicable to SAP GUI SNC-authentication, or are the x.509 certificate specific mapping methods you mentioned only applicable when logging onto ABAP AS using Web-browser ?

>

> Thanks,

> Tim

I'm impressed by your instant reply ...

Sorry, whenever I'm typing "X.509 client certificates" above, I was referring to "X.509 client certificates used in conjunction with SSL / https (mutual authentication" respectively "X.509 client certificates used by Web Service Security (message-based authentication based on X.509 Tokens)" - but not to "SNC" (where PKI-based solutions are just one of many options to implement a Generic Security Service provider).

[tim_alsop]

Wolfgang,

I delayed my reply this time to surprise you

So, in summary, when using Kerberos and SNC (as this is what this thread is referring to) it is only possible to implement 1-->many mapping using entries in USRACL. It is also not recommended to add entries to the USRACL table without using t-codes such as su01.

I assume that the reference discussed earlier from the SAP Help needs to be corrected/updated, or is it ok for direct table maintenance even though each entry in USRACL has a hash value which is checked during logon ?

Thanks,

Tim

[WolfgangJanzen]

>

> Wolfgang,
> 
> I delayed my reply this time to surprise you 
Indeed, you did.
> So, in summary, when using Kerberos and SNC (as this is what this thread is referring to) it is only possible to implement 1-->many mapping using entries in USRACL. It is also not recommended to add entries to the USRACL table without using t-codes such as su01. 
> 
> I assume that the reference discussed earlier from the SAP Help needs to be corrected/updated, or is it ok for direct table maintenance even though each entry in USRACL has a hash value which is checked during logon ?
> 
> Thanks,
> Tim

Sorry, I have digressed - I should have focussed on the topic originally reported.

Well, as both of us have seen: it's not possible to assign multiple SNC names to one ABAP user account - irregardless whether you use SU01, the BAPIs or SM30 to maintain USRACL. So, there's no need to revise the documentation.

Regards, Wolfgang

PS: SM30 uses a "hand-programmed" (not generated) table / view maintenance report for USRACL (and for USREXTID, by the way). This ensures that the hash calculation and canonicalization is performed, properly.

[tim_alsop]

Woflgang,

I wasn't aware of how sm30 works, but I guess that explains my findings. Thankyou.

The customer who had the issue with the hash, that I mentioned earlier was using their own ABAP code and we found that the entries their code put into USRACL didn't work. I assumed sm30 would be the same, but I didn't try.

Regards,

Tim

[Former Member]

> I wasn't aware of how sm30 works, but I guess that explains my findings. Thankyou.

I noticed this a few months while implementing SNC SSO on one of our lab systems and also some quite harsh authority-checks made sometimes to edit SNC related tables.

If I remember correctly, the details screen of the report in SM30 is exactly that of SU01 (try double-click on an entry or look in the menu for some option called "User Details") and the PAI module did the same validations, so I don't see how Alexander could have done this anyway.

Perhaps it was just a guess without clicking on "Save"

Cheers,

Julius

[Former Member]

HI Ugur

We have the same issue in our case? Did you make an user SAPServiceSID in the adviser domain as well.

We have done the configuration the same way you did and getting the error  message Specified target is unknown or unreachable?

Could you please suggest how you resolve it?

Thanks!!

Saurabh

[Former Member]

Hi,

We are facing the similar problem for multi domain SSO Kerberos Configuration. In our case, the SAP application system is running on linux. We are able to perfrom the single signon with one domain but not able to perfrom the same with another domain.

We have establish the forest (Trust) relationship between both the domain.

Can anybody help in this regards.