Cross Domain Authentication via SPNEGO

[Former Member]

Hello,

I have succesfully configured the Secure Login Server to authenticate users via Windows Login / SPNEGO. Unfortunatelly the enrollment does NOT work for users in different domains, but only one domain AT A TIME. So the Secure Login Server SPN sits within the Kerberos Realm that allows users in exactly this Realm to login via SPNEGO. (Of course all users from all domains are visible in dthe Secure Login Servers UME)

But we have 4 domains in a forrest..So, according to note 994791 that states:

• Domain Forest
  • Create and configure a J2EE service user in one of the domains part of  the forest # it doesn#t matter if this domain will be the root domain or any of the child domains
  • Configure UME to use multiple ADS data sources (for each domain in the forest)
  • In the #Kerberos Realm# step of the wizard you should provide  information only for the domain where you have created the service user for the J2EE Engine

..I have configured SPNEGO only for the realm that hosts the SPN.

Unfortunatelly it doesn't work. Please help me if you have experience with cross domain SPNEGO authentication via Secure Login Server.

Thank You,

Philippe

[Former Member · Accepted solution]

Dear Phillipe,

i already implemented Secure Login Server successfully within a multi-domain environment. Information you have is not correct. You need to create an corresponding service account (lets say "svc-jee-sso") in each domain. Then you need to register Service Principal Names (SPN) for each account and the http service. E.g. http/<IP> and/or http/<hostname of SLS>. The SPN must correspond the Enroll URL of the Secure Login Client registry information from customer.reg.

Check from each domain if the SPN can be retrieved correctly e. g. "setspn -L <service account>" Output must show the registred HTTP SPNs. Do the steps in all child domains and - if required - also in the forest root domain.

If you operate the SLS on a AS JAVA CE 7.3 - to use SPNego you need to have a at least SP3 or higher to have support for the required encryption algorithms (AES). For each Domain you have to create the REALM entry using SPNego Wizard, so in the list you will have - lets say - 5 entries. You will only need to setup one Secure Login Server instance, e.g. use the default server instance and choose the SPNegoLoginModule in the settings. Seems you already rocked this

Example: User from Domain A receives a Service Ticket from his DC (DC Domain A) and sends it to the SLS. This Kerberos ST is encrypted with the service accout password based on the keytab of the REALM entry for Domain A. SLS uses the keytab to decrypt the ST and can obtain information about the user (UPN) and some more information. Of course a user from Domain B will receive an ST from his DC (DC Domain B) and thus SLS needs to have multiple entries/REALMS with corresponding keytabs. OK, it may be possible to operate SLS within a multi-domain forest having only one service account, but never tested this out. Why? The other way works fine

Unfortunately after SPNego has successfully decrypted the ticket, the user there is another step required. The Kerberos Principal Name (KPN) retrieved by AS Java has to be mapped to an existing user in the User Management Engine (UME). And this often make no fun - I tell you why.

First this wiry UME stuff is much effort to configure. Then UME has some limits when it comes to support multiple AD domains or even forests, i am sure you already have seen the SAP notes 673824 and 762419 regarding multiple domain UME, using global catalog and all this funny things... and there is another big issue we often have. If the UME is configured to use the ABAP Stack as the default UME database (usage type ABAP) and the AD username and ABAP username do not match - uuups

Good news is, there is a solution available starting from Support Package Stack 07 for AS JAVA 7.2/7.3x

You choose the Principal@REALM mapping mode, with

virtual user as the data source!!

With SP07 there is a new source “virtual user” available for user mapping in the SPNego configuration of the JAVA system. Here is the documentation from 7.30 SP7 (scenario 4) -

http://help.sap.com/saphelp_nw73/helpdata/en/f4/1978c3a37a441b87a89d61c1a08689/frameset.htm.

By using this data source “virtual user” you do not need to configure/consider UME, it is not required.

I hope this information helps you to solve the problems you have. If you require additional support, feel free to contact.

Best regards,

Carsten

(SECUDE GmbH, Darmstadt)

[Former Member · Accepted solution]

Dear Carsten,

Thank You for your helpful answer. I was pretty sure that it was inevitable to configure SPN's in ALL the domains, even if they are in direct trust relationship. Still to mention the necessity to assign DNS alises for the Secure Login Server and assigning them to the service users SPN's. These DNS aliases correspond to the ENROLL URL in the client policy registry entry, uploaded in each domain seperately.. still check the UME of Login Server "sees" all users..This way it finally works..thanks!!

Perfect answer!! Thanks a lot!..

Regards,

Philippe

[tim_alsop · Accepted solution]

Phillippe,

I am not sure if you are interested or not, but if you are not, just ignore my response below.

The setup for your environment seems to be a lot more complicated than it needs to be. I have setup the same scenario for dozens of customers and did not need to create a principal in each domain, and didn't have to go through the complex setup steps that you have had to. I hope you will agree that using the domain and/or forest trust would both be simpler and easier to maintain ?

Thanks again,

Tim

[Former Member · Accepted solution]

Hello Tim,

That's why I was asking if it really necessary, as note 994791 states:

• Domain Forest
  • Create and configure a J2EE
    service user in one of the domains part of  the forest # it doesn#t
    matter if this domain will be the root domain or any of the child
    domains
  • Configure UME to use multiple ADS data sources (for each domain in the forest)
  • In
    the #Kerberos Realm# step of the wizard you should provide  information
    only for the domain where you have created the service user for the
    J2EE Engine

So we definitely have a domain forest. When adding a realm, The Kerberos wizards asks us to enter a service user EXACTLY in that realm that we create. So according to that note, this should actually then work also for users in other trusted domains. But Logon fails ("Credentials are not accepted by the server"). The Secure Login Client Log says subsequently that the Realm does not match to the service that was called.

As the service user must be in the realm and the realm defines the domain of the calling user, we found no other solution than to add service users in every realm and add every realm = domain of the calling user in the SPNEGO wizard.

Regards,

Philippe

[tim_alsop · Accepted solution]

Philippe,

I am sorry if I have confused you, but I have implemented this without using the SAP SPNEGO login module and without using any component of SAP NetWeaver Single Sign-On product. Instead, I use a third party product that is SAP certified.

Thanks,

Tim

[Former Member · Accepted solution]

Hi Tim,

i am sure you´re right, in theoretically it should work with one service account, for example located in the root domain. If client from any domain in the forest contacts his KDC and requests a ticket, the KDC uses global catalog to locate the correct SPN.

In the scenario with Secure Login Server it may work with one account but having multiple SPNs registred in each domain, with different names (EnrollURLs).

The reason behind I recommended this to Philippe is, that I know it works for sure. In other situations where the SLS is operated as xAAS (service provider solution) it may be required to integrate to mutiple independent AD forests - and this works the same way as described in my post. The offline kerberos implementation behind is a good thing, because it is not necessary to integrate the AS JAVA system to any REALM.

Philipp nice to hear, that i could help!

Regards,

Carsten

[former_member208943 · Accepted solution]

Implementing SPNEGO2 on EP 7.02

Our sapservers are in a sub-domain i.e. sape7psys.nvprod.acme.com and the Users/SapserviceAcounts are in root domain i.e SAPServiceE7P@acme.com.

There is a cname pointing sape7psys.acme.com to sape7psys.nvprod.acme.com

The realm is ACME.COM

• setspn -A HTTP/sape7psys.acme.com SAPServiceE7P
• ktpass /out e7p.keytab /princ SAPServiceE7P@ACME.COM /pass PASSW0RD

URL http://sape7psys.acme.com:50000/irj/portal gives blank white screen with this error in the security.log file

No key (etype: 23) for realm NVPROD.ACME.COM available.

C:\Temp\Support Tools>setspn -L sape7psys

Registered ServicePrincipalNames for CN=SAPE7PSYS,OU=VCS Cluster Objects,OU=SAP,OU=Santa Mar,OU=PROD,OU=Servers,DC=nvprod,DC=acme,D

VCSClusterVirtualServer/SAPE7PSYS.nvprod.acme.com

VCSClusterVirtualServer/SAPE7PSYS

HOST/SAPE7PSYS.nvprod.acme.com

HOST/SAPE7PSYS

Should my setspn include nvprod.acme.com or just acme.com as specified above..??

any help please..??

[former_member199849 · Accepted solution]

Try to register setspn including nvprod.acme.com and also add realm "nvprod.acme.com"

Tell me if you need something more.

Regards

Andy

[former_member208943 · Accepted solution]

Not true...Realm is always the domain where the users/server account exists...which is the parent domain in our case. (i.e ACME.COM)

Anyway we resolved the issue....this is waht we did

Realm= ACME.COM

setspn -A HTTP/sape7psys.acme.com SAPServiceE7P

setspn -A HTTP/sape7psys.nvprod.acme.com SAPServiceE7P

ktpass /out sape7pnvprod.keytab /princ HTTP/sape7psys.nvprod.acme.com@ACME.COM  /mapuser SAPServiceE7P /pass XXX -pType KRB5_NT_PRINCIPAL

Thanks,

Shivpal Reddy

[former_member291531]

Hi All,

I know this thread has been dormant for a while but I can't find any better thread to post my questions to.

And I think it is better to continue the previous thread than creating a new one, since the topic is similar.

Consider these 2 cases/scenarios.

Do you think both will work?

Case 1:

There are 2 domains (forests), Domain A and Domain B.

SAP users are located in Domain A, while AS-JAVA server is located in Domain B.

There isn’t any trust relationship between the 2 domains.

AS-JAVA is using Active Directory (Domain B) as the UME data source.

We run ‘setspn’ in Domain A for the AS-JAVA resource.

We create the Kerberos Realm in AS-JAVA for Domain A.

Would this SSO configuration work?

Case 2:

There are 2 domains (forests), Domain A and Domain B.

SAP users are located in Domain A, while AS-JAVA server is located in Domain B.

There is a One Way Forest Trust (OWFT) between Domain A and Domain B, in which Domain A is the trusted domain, while Domain B is the trusting domain.

AS-JAVA is using Active Directory (Domain B) as the UME data source.

We run ‘setspn’ in Domain B for the AS-JAVA resource.

We create the Kerberos Realm in AS-JAVA for Domain B.

Would this SSO configuration work?

On this scenario, what would be the KPN (principal@REALM)? Is it principal@DomainA or principal@DomainB?

Thanks in advance.

Best Regards.

[tim_alsop]

Deepak,

You have updated a thread that is already 'answered'

For best results, you should start a new thread and ask your question. Please feel free to make reference via URL to other threads if needed.

Thanks

Tim

[former_member291531]

Thanks for the advise, Tim.

I have created a new discussion on my question.

[former_member199849]

hi philipp,

can you share information about spnego configuration in portal 7.3?

I am new on Portal 7.3, and I have doubts

do you have an email? Mine is agmunoz87@gmail.com

thanks

andrea

[Former Member]

Hi Andrea,

Basically, the configuration for Portal 7.3 is done with the new SPNEGO configuration wizard. You might find this helpful:

http://help.sap.com/saphelp_nw73/helpdata/en/21/bff93c7dcd458e9d71539a6d50dbbe/frameset.htm

You can find my email adress inside my profile.

Please feel free to contact me..

Regards,

Philippe