Setting up Kerberos Authentication in Trusted Domain

[Former Member]

I am trying to set up Kerberos authentication to the java stack of a PI 7.1 EHP1 system in a trusted domain scenario, in which the SAP server domain (I will call this Domain A) has trusted a secondary domain (I will call this Domain B). This is a one way trust only, with Domain A as the "trusting" domain.

I have configured SPNego and verified that Kerberos authentication is working within Domain A. Now I am ready to try to get it working from Domain B. I have not run any setspn commands, or done any other configuration within Domain B at this point.

I have logged onto a Domain B workstation (with a Domain B userID) and adjusted the IE settings appropriately per the SAP documentation. then, if I trace a test connection from the Domain B workstation (using the Diagtool) it shows that an NTLM ticket is being passed instead of a Kerberos ticket. I have verified that the clocks are in sync between the DC's on both sides, the SAP servers, and the frontend workstations.

Below is the setspn command that I ran on Domain A:

setspn u2013A HTTP/<sap server FQN> <DOMAIN_A\service_user>

Do I need to run this exact command on Domain B as well? Can I use the Domain A service account in the setspn command, or does an identical service account need to be created on Domain B? Is there some other problem, or some other step that has to be performed on Domain B? Again, I have tested single sign on successfully within Domain A, so I am pretty sure that my spnego configuration is correct.

Other details:

Domain Controllers are Windows 2008 running Active Directory 2008.

[Former Member]

We got this working by changing the host principal to @<DOMAIN B>, and changing the login modules accordingly.

[Former Member]

Hi Kevin,

  We have the same problem what you have in this thread.

  Please send me the steps to change the host prinicipal to @DOMAIN B and adjusting the login modules.

I am not able to run the following command on our Active directory domain controllers.

setspn u2013A HTTP/<portal alias server FQDN> <DOMAIN_A\service_user>

I ran the below command instead , is that correct

setspn -a HTTP/<portal alias server FQDN> <DOMAIN_A\service_user>

Appreciate you help.

Thank you,

Sam

[Former Member]

Hi Kevin,

I don't know exactly where is the problem with your configuration but I think that it should be possible because I have a nearly similar setup.

We have an EP 7.0 Portal in a domain A with a Windows 2008 AD (also Kerberos KDC) and all our PC workstations and windows users accounts are in a 2nd domain B with a Windows 2003 AD.

There is a trusting relationship between the 2 domains.

SSO/IWA works fine but we had to use a third party Login module because the standard SAP module was only able to use the DES algorithm and so not able to use a Windows 2008 AD.

The only setspn needed command is

setspn u2013A HTTP/<portal alias server FQDN> <DOMAIN_A\service_user>

We did not do any specific configuration in domain B except the trusted relationship.

Regards,

Olivier

[Former Member]

So just to clarify, you did not run any setspn commands on Domain B correct?. We also have a Windows 2008 AD on the Domain A side and Windows 2003 on Domain B. Since I was able to get it to work within Domain A, I didn't think there was any problem with the DES encryption on Windows 2008 AD. Could this be my problem? Can you provide more details around the limitations of DES on Windows 2008 AD? For some reason I get NTLM tickets only, so I'm thinking now that this might be my issue.

One other question, did you have a one way trust or a full two way trust between domains?

Edited by: Kevin Biggs on Jul 2, 2010 11:38 PM

[Former Member]

Hi Kevin,

Correct, we did not run any setspn command on Domain B.

By default, DES is deactivated on windows 2008 AD. It can be activated but, as DES is deprecated and has been cracked, our security team forbids the use of DES.

DES is also obsolete on Windows 7 PC.

If you get NTLM tickets, this could be your problem.

You can use Wireshark to display the KRB5 protocol. With it you can display the encryption algorithms negotiation between the client PC and the AD.

We have a one way trust between the 2 domains.

Regards,

Olivier

[Former Member]

I have added the service account and run the setspn command on the Domain B side, and am now able to generate a kerberos ticket. However, I get the following error when trying to make the kerberos handshake:

Looking for credentials for realm <DOMAIN B>

No jGSSName found for realm <DOMAIN B>. jGSSNames are: host/hostname@<DOMAIN A>