SSO two domains, no trust, logon via logon group

[Mark17]

Hi guys,

we are migrating to separate active directory and using SSO (with Secure Login Client).
So in future there will be two active directories with NO trust to be useful in SAP for SSO.
Wh did add both AD service user (SPN) to SPNEGO and adjusted for the relevant user the SNC parameter in SU01 + SAPUILandscape.xml entries
(for users/client in the new domain, old users/clients will be untouched).
So far everything is working good.

Only one problem:
When using logon with logongroup (messageserver) the SNC parameter for SAP GUI are placed automatically (due to snc/identity/as I assume?).
Every user is getting the value for old domain: "p:CN=SAP/Kerberos<SID>@OLDDOMAIN.COM".
But of course the new domain users do need the new parameter "p:CN=SAP/Kerberos<SID>@NEWDOMAIN.COM".

[Christian_Cohrs1]

Hi,

OSS note https://me.sap.com/notes/2338952/E might help here. With the replacement parameters of the CommonCryptoLib you can adjust the name coming from the Kerberos token before the SNC name mapping takes place. 

Best regards,
Christian 

[Colt]

And i would not use snc/identity/as = p:CN=SAP/Kerberos<SID>@OLDDOMAIN.COM in any case. I recommend you change that to p:CN=Kerberos<SID> which means the domain part will be used from the current users domain and the SAP/ will always be used by default, so in this case your SPN SAP/Kerberos<SID> dont have to be changed at all. Check out this blog for some more details: https://xiting.com/en/sap-single-sign-on-insider-tips-volume-4/

[dyaryura · Accepted solution]

Hi

We had a similar scenario with two different domains, but we are not using the old kerberos naming in the snc/identity_as. We have users going via the load balancer as described in note https://me.sap.com/notes/3250948 and parameter configured as per https://me.sap.com/notes/1696905/E

So our identity_as looks like p:CN=<SID>, OU.... The system will pick the first part of the certificate and you need to use SPNs for your AD users with SAP/<SID>. This is much simpler to configure and will support certificates also. From a naming perspective the use of certificates in the SNC naming looks also nicer than Kerberos names, I like to see certificates in STRUST with real certificate names and not using @ and weird symbols just to make SSO work

Hope it helps.

Thanks