WinAD Configuration Woes

[DellSC]

I'm setting up a 4.2 SP6 patch 2 system on Windows for a client. I have configured WinAD authentication (no SSO) based on the documentation from SAP - like I always do. Using the kinit test that's explained in the doc, everything is configured correctly. I can also get the list of groups and users in the WinAD authentication configuration screen.

The problem is that we're not able to log in to either the CMC or BI Launchpad using WinAD credentials. On the login screen I see this error message:

Account information not recognized: Active Directory Authentication failed to log you on. Please contact your system administrator to make sure you are a member of a valid mapped group and try again. If you are not a member of the default domain, enter your user name as UserName@DNS_DomainName, and then try again. (FWM 00006)

In the Tomcat log, I see the error "Cannot locate KDC".

I used the krb5.ini and bcslogin.conf from their 3.1 system that we're migrating to 4.2 SP6 - the only difference is that I added kdc lines in krb5.ini for all of the domain controllers as part troubleshooting this issue.

Since the kinit test works, I know that the krb5.ini file is configured correctly. I have also verified that I can telnet to all 5 domain controllers on port 88.

As part of troubleshooting, I've run Tomcat as both the Local Service account (default) and using the service account that the SIA is running on.

Any ideas for other things I can look at?

Thanks!

-Dell

[denis_konovalov]

I fixed your tags a bit, as this way ore chances AUT people will see it first.

[DellSC]

Thanks Denis!

[mgrackin]

Dell, I assume you eventually resolved this issue. What was the solution?

[DellSC]

IIRC, there was an issue with either the default AD domain or the Service Principal Name that were configured under authentication in the CMC. However, that was a couple of clients ago - I've done three installs/upgrades for clients since then - and I don't remember what the exact issue was.

-Dell

[BasicTek]

If the kinit is finding the KDC then there is no security policy that can affect tomcat that way, both requests are initiated via java using the krb5 only, it appears that your java may be using a different krb5 than the default (kinit should be in the same java directory that tomcat is pointing to in the configuration options)

I'd always keep the krb5 in C:\windows to avoid the different Krb5 issue (although it may have occurred here anyway). Try editing the c:\windows\krb5.ini and putting in only a bad KDC and then test kinit again, if it works then you need to find the actual krb5 the kinit is using. In that case I'd search the hard drive. There is a place in java where it can be hard coded but we never recommend doing that.

Something else that's weird is the error itself, it's usually "Cannot get kdc for realm" so there might be some sort of problem with tomcat so it's not actually using the krb5 and throwing a bogus error

One more thing. On kinit the REALM is taken from the krb5 default realm, but tomcat takes the realm from the CMC > authentication > windows AD > default domain. Is it possible the realm is wrong in the CMC? This usually results in a different error but since the error is not really correct we should check that as well.

-Tim

[BasicTek]

If you are receiving cannot locate KDC and it is not giving you that error for kinit then you somehow have a different krb5. If using the same krb5 you would receive the same error in kinit as that portion of the logon is the same (called an AS request). SPN's have nothing to do with that error it's very specific to the KDC value in the krb5. Just to make sure it's not generated by something else lets verify the tomcat kerberos tracing.

Ensure your bsclogin.conf ends in the debug=true on the 2nd line if not add it and restart tomcat

you can also add -Dsun.security.krb5.debug=true before restarting tomcat for additional logging as well

-Tim

[DellSC]

Hi Tim,

I re-verified that there is only one krb5.ini file on the server. It was in C:\Windows. Because they have some odd security policies that I've never seen before that might be affecting this, I move the krb5 and bscLogin files to a separate folder (D:\WinAD_Config), set the Java options for Tomcat to point to the correct folder, and tried again. Logging was already turned on in bscLogin.conf, but I turned it on for the krb5 using the java option that you specified. Here's what I now see in stdout.log:

Java config name: D:\WinAD_Config\krb5.ini
Loaded from Java config
>>> KdcAccessibility: reset
default etypes for default_tkt_enctypes: 23.
>>> KrbAsReq creating message
getKDCFromDNS using UDP
getKDCFromDNS using TCP
		[Krb5LoginModule] authentication failed 
Cannot locate KDC

So it seems to me that it is finding the correct krb5.ini file, but it's truly not finding the KDC. At this point I'm pretty sure that the issue is the odd, overly stringent security policies that they have in place or they are using a different type of encryption than rc4-hmac or aes128-cts-hmac-sha1-96. Does that make sense to you?

-Dell

[BasicTek]

It sounds like either a) a typo in the java options pointing to the krb5 that tomcat is using, or b) when you test kinit it uses c:\windows\krb5.ini by default, possibly your tomcat is pathed out to a different one with an invalid KDC

-Tim

[DellSC]

Thanks Tim, I'll check that out. I also discovered yesterday afternoon that not all of the SPNs I requested had been created and I had to get a security policy exception to be able to give the service account the "act as part of the operating system" right. All of that was completed overnight, so I'm going to work on it some more this morning.

-dell

[DellSC]

Hi Tim,

The SPNs are now good and the service account has the rights to act as part of the operating system on both the app server and the web server. I validated that there is only one krb5.ini file and that the java options are spelled correctly and are pointing to the correct place. I'm still seeing the same error message on screen and "Cannot locate KDC" in the stdout.log file.

Since the server is running Windows 2016, I also tried the following in the krb5.ini:

default_tgs_enctypes = aes128-cts-hmac-sha1-96
default_tkt_enctypes = aes128-cts-hmac-sha1-96

But that didn't resolve the issue either.

-Dell

[wobi]

Dear Dell,

I am a bit confused:

You configure AD - without SSO - right? - but you do the kninit stuff which is used for SSO - If I remember correctly simple WIN AD Config does not need krb.ini etc... that's used for SSO - so I assume you have a not finished SSO AD configuration...

from my humble point of view you have to remove all the SSO stuff or complete it, if you need it.

Wobi

[DellSC]

Section 5 of the "Configuring Active Directory Manual Authentication and SSO for BI4" pdf is called "Configuring Manual AD authentication to Java Application Servers". The first part of the section talks about configuring the bscLogin.conf and krb5.ini files and then it talks about using the kinit test to validate that everything is working before moving on to configure Tomcat. So, I believe you are incorrect in thinking that those files are only for SSO.