Kerberos SSO with Azure AD on one domain and SAP On-Premise on another domain

[aoleary]

Hello,

A client of ours has two active directories.

One OnPremise and another on Azure, and the goal is to migrate everything to the AD on Azure.

We are trying to implement Kerberos SSO with the Active Directory on Azure (domain = .COM), and the SAP Instance and users and their dektop computers on another domain (.NET).

SSO works on the OnPremise Active Directory, however, we need to prepare for the situation when we move everyone to the Azure AD.

Since the user migration is not going to be done all in one go, we need to plan for the situation where some users will be on the Azure AD and others on the local AD.

Our problem is how do we setup the trust between the Azure AD and the local AD, so that when we migrate the users, nobody gets their SSO cut off.

We have also tried creating service users on both domains with the same SPN, but when I test the connection via SPNEGO to the .COM domain, it cannot find the user.

Thanks very much in advance,

Kind regards,

Anthony

[AlfredoMurguía]

Hi! did you get the response from SAP support ticket?

[apaul]

I would propose to try following https://blogs.sap.com/2019/11/22/kerberos-spnego-for-sap-as-abap-in-a-multi-domain-environment/. You need to deploy Azure AD Domain Services which give Active Directory DC type of behavior. See the answer from Achmad Dimyati in the https://answers.sap.com/questions/13324098/does-sap-sso-support-simple-authentication-with-az.html thread.

[aoleary]

Hi apaul,

This is all in place already. As I mentioned above, I have opened a message to SAP, so I will wait on their reply..

Thanks for replying 🙂

[Colt]

Hi Anthony,

Tim already asked the key question. And quite often we got similar questions... Especially when customers are no longer using the Azure hybrid mode - where a client (according to my knowledge) is still "domain joined" - Kerberos is no longer possible. I asked some MSFT experts recently if this is really true and will update this post here as soon as I have clearance. In your scenario, you will have two AD forests (Domains) that must not trust each other.

With SAP SSO 3.0 in place, you can just implement a point-to-point trust on the SAP side (via technical user/keytab) and so users from both domains will be able to authenticate to the same SAP system that trusts both forests.

Cheers Carsten

[aoleary]

Hi colt,

I have created a service user on each domain, both with the same SPN (the SID of the SAP system).

Testing in SPNEGO, the connection to the local AD works, but not the Azure hosted AD.

I have opened a message to SAP, so they are going to investigate why the connection doesnt work.

I'll keep everyone updated here as to the results of the testing..

Thanks for your reply 🙂

[tim_alsop]

When you refer to Azure AD, are you actually referring to Azure AD or Microsoft Windows Server domain controllers installed on Azure virtual server environment? I am asking this because you are saying you have created service accounts in Azure AD which is not possible as Azure AD does not support Kerberos in same way as on premise domain controllers. My assumption therefore is that when you are saying "Azure AD" you are referring to a Windows Server with Active Directory installed on Azure ?

[aoleary]

Hi tim.alsop,

Its probably what you said, AD installed on a server in Azure.

I'm not the person managing that side, so I guess I'm not 100% clear in my explanation.

[tim_alsop]

In that case, the solution will depend on what you want to do. The fact that one domain is in Azure and one isn't is not that important, so I will consider the setup as if there are 2 AD domains and then the solution depends on whether these domains trust each other and whether the user workstation is joined to domain1 or domain2. If I had this information I would be be able to give you clear instructions to make Kerberos work the way you want it to.

[aoleary]

For the moment there is no trust between the two AD domains.

If we define the domains as follows:

Domain1 = Azure

Domain2 = On Premise

At this point in time, there is only the Azure AD in Domain1.
In Domain2, we have the local AD, the SAP instance and the workstations. SSO works here.

I have created two service users, one in each domain, both with the exact same SPN.

The service user created in Domain1 is not recognized within SPNEGO.

In the future, everything in Domain2 is going to be migrated to Domain1, but in a phased manner.

Our issue is that SSO will be broken for the workstations that will be migrated to Domain1 before the SAP instance is moved to Domain1.

[tim_alsop]

So, SSO works in domain2 so I assume that the user logs onto the workstation using domain2 credentials, and logs onto SAP system which has service principal in domain2. Is this correct ?

In future if you migrate to domain2, then users workstation will need to login to domain2 user account and then they can logon to SAP systems in domain2. This is only way it can work unless you have domain trust and then you will be able to have user logon to workstation using domain2 account and logon to SAP systems in domain1 and domain2.

Thanks

Tim

[aoleary]

Hi Tim,

SSO works in Domain2, as everything is in Domain2.

However, we would like to move everything to Domain1, and would like to have the possibility of having SSO working in both domains during the time of the transition..

What do you mean by this sentence. I think you may have miswrote something somewhere..

"In future if you migrate to domain2, then users workstation will need to login to domain2 user account and then they can logon to SAP systems in domain2. This is only way it can work unless you have domain trust and then you will be able to have user logon to workstation using domain2 account and logon to SAP systems in domain1 and domain2."

Kind regards,

Anthony

[tim_alsop]

Hi

Yes, that sentence was not written very well. Let me try again... "If domain2 is working and you want users to transition to using domain1, then you will need to join the workstation used by users to domain1 so user logs into their workstation using a domain1 account and password. If they then want to logon to SAP systems in domain1 this will be possible because there is no trust needed for this (user and SAP system are in same domain) but if they want to login to domain2 from their workstation, this won't be possible as there is no domain trust. My suggestion is that you move SAP systems and users workstation from domain2 to domain1 over a weekend so when the user starts work after the weekend they will be able to access the SAP systems on domain1 instead of domain2."

[aoleary]

Hi tim.alsop,

Ideally we would move them in one go, however, it is unlikely that that will be possible..

We did a test where we moved the dev SAP server to domain1, and we were able to connect via SSO with a user created in domain1 logged into the dev server OS, so we know it works if everything is on domain1 or if everything is on domain2.

Is it possible to activate a trust between the Azure hosted AD and the On Premise AD, so that SSO can work in parallel on both domains ?

Thanks for your time so far 🙂

[tim_alsop]

Yes, you can setup trust between domains so that a user logged onto a workstation in domain2 can logon to SAP systems in domain1. The domain1 needs to have one-way trust with domain2 for this to work. Ask your AD admin to setup the trust - once done everything should work as expected.