Manual AD Authentication with subdomain

[dazsmithuk]

I am implementing BI 4.2 SP4 for a customer at the moment. They have a production system and a test system, both of which are Windows 2012 R2 Server.

I have got AD Authentication working on the production system, but things here are fairly standard; the users, server and Windows AD group are all in the same domain (let's call this "CUST").

I am having a problem with the test system, which is in a subdomain called "TEST". The Windows AD group and the service account which SPNs are created on are also in TEST, but the members are in "CUST". There is, I am told, two-way trust between the parent and subdomain.

On the test server, the Windows AD configuration settings are okay; I've mapped the Windows AD group in (TEST\Business Objects Test) and the users in this group have appeared in the Users and Groups part of the CMC. Also, Windows AD authentication works with the client tools. So that shows that the SPN configured for this is working.

However, I can't get manual AD authentication working using the CMC/BI Launch Pad. I have added the krb5.ini file with details as follows:

[libdefaults]
default_realm = CUST.CO.UK
dns_lookup_kdc=true
dns_lookup_realm=true
default_tgs_enctypes = rc4-hmac
default_tkt_enctypes = rc4-hmac
udp_preference_limit = 1
[realms]
TEST.CUST.CO.UK = {
kdc = LCCTST-DC-01.TEST.CUST.CO.UK
default_domain = TEST.CUST.CO.UK
}
CUST.CO.UK = {
kdc = LCC-DCP-001.CUST.CO.UK
default_domain = CUST.CO.UK
}

I can successfully use the kinit script in win64_x64/sapjvm/jre/bin to get a ticket for one of the users in the "CUST" domain that is a member of the mapped group.

When I try and use the CMC to log in with the same user, I get an error "Account information not recognized: The Active Directory Authentication plugin could not authenticate at this time...."

In the Windows AD Authentication page of the CMC, I have the following settings:

AD Administration Name: TEST\SVC-WEBTSTBO-01 (this user is also used to run the SIA)

Default AD Domain: CUST.CO.UK

Authentication Option: Use Kerberos Authentication

SPN: BI4TEST/SVC-WEBTSTBO-01.TEST.CUST.CO.UK

Please can anyone offer any advice?

Darren

[BasicTek]

A few questions or comments.

You said the test domain is a child of the customer domain, if this is correct the trust is automatic. If the test domain is actually another forest the the rules will change significantly. So I'll assume same forest, child domain.

When you login form the default domain, you can simply type in the AD username, if you login from client tools then it's domain\username. When you login from the child you must type in username@FQDNDOMAIN.COM by your example that is username@TEST.CUST.CO.UK. Typing the username or domain\username or even username@test.cust.co.uk will all fail.

Another point is no additional SPN's are required. If you only generated a unique SPN (as you mentioned BI4TEST/SVC-WEBTSTBO-01.TEST.CUST.CO.UK) that shouldn't hurt anything but if you created the same SPN in both domains that will be an issue for at least 1 domain. running setspn -x -f will verify any duplicates in either domain.

-Tim

[dazsmithuk]

Hi Tim, thanks for your advice, much appreciated.

I believe the child domain is in the same forest, I have asked the domain admin for confirmation. There is only one SPN created, on the child domain as you can tell from the name of it.

My users are in CUST.CO.UK. If I try and log on as username ~at~ TEST.CUST.CO.UK it tells me "Authentication failed to log you on." which I would expect as the user isn't a member of the test domain. If I try and log on as username ~at~ CUST.CO.UK it tells me "The Active Directory Authentication plugin could not authenticate at this time". (NB I replaced @ with ~at~ above)

So it sounds like authentication would only work with users who are in the TEST domain; for some reason it's not authenticating users from CUST when using the TEST domain controller. However it works for Client Tools, and in fact when I log on to the same server with Remote Desktop using the same account. So I assume there must be something wrong with my krb5.ini?

Thanks, Darren

[dazsmithuk]

Hi Tim,

You'll see in my krb5.ini that I had different domain controllers for the two realms. I've now tried using the same one (the test one) in both cases, but I'm now just getting "failed to log you on" in every case.

The SPN was created on the test domain; the service account is on the test domain. Do you think that this service account would be able to query AD on the CUST domain or could there be some kind of permission issue? And if so, how to tell?

Thanks, Darren

[BasicTek]

If you follow the krb5 KBA 1245178 that Chenghao gave you it explains the krb5.ini

It works like this: 1st java looks up your realm (what is after the @) If you don't enter an @ it will take the value from the CMC > authentication > windows AD > default domain (which also must be in all CAPS) This is why users in the default domain can login with username only.

Next java will locate the KDC for the REALM. The KDC's must be in the same realm they are listed or they will not find the user. If your kinit is working properly, then the you can log the krb5 by adding the debug=true parameter to the bsclogin.conf and see the results of that portion of the login (successful will show commit succeeded for the username@REALM.COM). I think that is where your failure is occurring.

Just to verify users from the default domain are able to login correct? If not check your java options 1st make sure they are pointing to the correct files in the windows directory. The full config can be found here

-Tim

[dazsmithuk]

Hi Tim, thanks so much for bearing with me. Just to say that I have set up the production server with everything on one domain and that worked fine. I've set the test system up in the same way, other than that the users are on the main domain, as is the default domain in CMC>Authentication>Windows AD and also krb5.ini - but the service account and server are on the TEST subdomain.

In summary, on the test server (single server installation):
1. Client Tools Windows AD Authentication - works
2. kinit on the server - works
3. CMC or BI Launchpad manual Windows AD Authentication - doesn't work for anyone.

I've noted that if I log in to the CMC and get the password wrong, I get a different error "Active Directory Authentication failed to log you on". If I get the password right, I get "The Active Directory Authentication plugin could not authenticate at this time".

This is borne out by the output from turning the different debug options on, which I'll paste in my reply to Chenghao.

Thanks, Darren

[BasicTek]

If no one is logging in via java (launchpad and CMC) then verify that the krb5 has the same info as the working production system. verify no typos or .txt extensions on the files, and verify the java options on your web/app

[dazsmithuk]

Hi Tim

No-one can log in via Java (Launchpad and CMC) as the errors are received as above; "failed to log you on" if the password is wrong and "could not authenticate at this time" if the password is right.

The krb5 is, by definition, different from the production system because it uses a different service account, and there is a different domain involved. My thoughts are that we need to use a service account in the same domain as the users, rather than in the TEST child domain.

Were you able to draw any conclusions from the output from turning the debug options on?

Thanks again, Darren

[BasicTek]

ok the service account has no relevance for the krb5, that is essentially replacing DNS function for AD requests going through java. However if you're users are in a different domain that does have relevance...

#1 is the default domain in the AD plugin an FGDN od the users domain in CAPS such as CUST.CO.UK?

#2 is that the same default domain in the krb5.ini

#3 you mention kinit works, kinit looks for the krb5.ini in the c:\windows directory, are your java options pointed to that directory? If kinit works that manual logon should also work if java is pointing to the same file. If it fails that is an indicator that either the bsclogin, or krb5 are not correctly defined in the java options. (This is for the default domain only!) other domains may require additional info in the krb5 but getting the default domain working if kinit works and client tools works can only fail in the java options....

-Tim

[dazsmithuk]

Hi Tim

#1 Yes, the default domain is fully qualified and in capitals in CMC > Authentication > Windows AD.
#2 Yes, the same default domain is in the krb5.ini
#3 Yes, kinit works fine. Yes, in Tomcat the java tab has exactly this (same as in the production system):

-Djava.security.auth.login.config=c:\windows\bscLogin.conf
-Djava.security.krb5.conf=c:\windows\krb5.ini

Although I have added the TEST realm in the krb5.ini, no users from TEST will be authenticating against this system. Only the service account is in TEST, all the users are in CUST. You can see the krb5.ini in my original post.

The debug output I posted in response to Chenghao shows that the ticket was created but not sent back, as far as I can tell?

Thanks, Darren

[BasicTek]

I didn't see the debug data before, so "Commit Succeeded" is the kinit portion of the logon so the java options are ok and the kinit is succeeding in launchpad. Now in launchpad there is a 2nd part of the process as it hands the user to the CMS. That portion can fail if there is an issue with encryption or trusts.

Encryption should be verified if your AD service account is using the same encryption specified in the krb5.ini the krb5 is using rc4 (is your service account set to use something else like AES)?

Now AD trust is ok if users can logon through client tools, but java requires a different way to map the trusts depending on the domain structure the KB 1245178 Chenghao mentioned explains how.

#1) Is the cust domain the default domain? If not can you change the both the AD plugin and krb5.ini to that domain.

#2) If the cust domain is not the default have you tested login with a user that is mapped into BI and in the default?

#3)The only other issue that could make this fail is if there are any account options selected on the user accounts themselves to modify kerberos. If you can verify any specific account options on the service account or failing user accounts.

-Tim

[dazsmithuk]

Hi Tim, thanks again for your replies.

I don't know how to tell what encryption the service account uses. I've no reason to suspect it will be any different from the encryption type the service account for the production system uses, and the production system is fully working with both manual AD Authentication and SSO.

#1) Yes, the CUST domain is the default domain in CMC > Authentication > Windows AD. This is also in the krb5.ini as the default. (See initial post for all the settings)

#2) N/A

#3) The same user accounts are mapped to both prod and test, and they can authenticate against the prod system with no issues. There are no specific account options on the service account other than, as recommended, setting "Trust this user for delegation to any service (Kerberos only)" on the Delegation tab as recommended.

Thanks, Darren

[BasicTek]

What's the rest of the error after it says AD authentication failed to log you on?

I'm not seeing any failures in your debug logs, if using the default domain then there shouldn't be a need for trusts, but encryption can still be an issue, your java config is trying to force RC4 which many AD's are using AES

[dazsmithuk]

Hi Tim

The full error, which appears in red after a login attempt, below the words "BI Launch Pad", is this.

Account information not recognized: The Active Directory Authentication plugin could not authenticate at this time. Please try again. If the problem persists, please contact your technical support department. (FWM 00005)

If I deliberately get the password wrong, the error is this:

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 ~at~ DNS_DomainName, and then try again. (FWM 00006)

[BasicTek]

this error "please contact your technical support department. (FWM 00005)" is rare. It's an indication that the java portion is working with kinit (which we saw with commit succeeded) but then the hand off to BI failed. The bulk of reasons a hand off would fail would also cause the user to fail to logon to client tools. For default domain the only failures I know of are if the user has something checked in their AD account properties, or encryption is not matching.

Try removing the RC4 entries from the krb5 and restarting tomcat

If that doesn't work have someone look at the AD account properties and verify nothing is checked

if still nothing we will need to run a wireshark on tomcat to scan the logon attempt and see if there are any kerberos errors

[dazsmithuk]

Hi Tim

I removed the RC4 entries and restarted but it made no difference. I've now put them back and restarted again.

The next thing will be to get someone to look at the AD account properties, I will do that now. Any particular parts that are possible issues? I assume you mean in Active Directory where there are lots of different tabs?

Thanks again
Darren

PS Just a note - when I log in to the CMC or Launch Pad from a client (on the CUST domain) I have to fully qualify the URL, e.g. lcctst-appbo-01.test.cust.co.uk/BOE/CMC . If I try lcctst-appbo-01/BOE/BI it doesn't work.

If I log on to client tools from the client, and I just enter a non-qualified system name, choose "Windows AD" and leave the user and password blank, I get the following error (this is from Designer):

[repo_proxy 13] SessionFacade::openSessionLogin with user info has failed (Unable to connect to CMS lcctst-appbo-01.test.cust.co.uk:6400. A wrong connection is made to @@LCCTST-APPBO-01.test.cust.co.uk:6400 (LCCTST-APPBO-01.test.cust.co.uk:6400). Logon cannot continue. (hr=#0x80042a79)

If I log on to client tools from the client, and I enter a fully qualified system name (lcctst-appbo-01.test.cust.co.uk), and again set the authentication to Windows AD and leave the username and password blank, it works! But it's strange that when it doesn't work, it quotes the correct fully qualified path in the error.

[BasicTek]

"account" is the tab where any specific settings such as encryption can cause issues. and the specific area is called "account options" not properties, my bad.

the URL should have nothing to do with login but the web/app does need to be in a domain location where the DNS on that server will resolve. Since the kinit works that seems to be ok.

now if you take the "cust" domain you can login to universe designer or webi rich client with cust\user or just user since cust = default. When you login to launchpad/CMC you should be typing just the same user, no domain is required.

It's really very difficult to make users in the default domain fail if the kinit and client login are both working. The only 2 reasons I've ever seen are specifying a non supported encryption in the krb5, or checking a box to not use kerberos preauthentication on the account. But DES and AES settings on the account can also theoretically cause issues since you are specifying RC4.

[BasicTek]

one other thing I just thought of, the groups that you mapped the users in with... are the groups also in the cust domain. If the groups were in another domain that could create a trust issue that isn't defined in the krb5

[dazsmithuk]

Hi Tim

As the group is in TEST and the users in that group are a member of the parent domain, it sounds like this is a good candidate for being the issue. I'm waiting on the system administrators to move the Windows AD group and then to test again. I will let you know either way what happens.

Thanks, Darren

[dazsmithuk]

Hi Tim, I got the group recreated in the CUST domain, but this made no difference I'm afraid.

What about the service account / SPNs? These are in the TEST child domain. Should these be moved to the CUST domain?

Thanks, Darren

[BasicTek]

ok I think you have identified the issue, the group has no bearing on what domain we are using to login, the domain is determined by where the users exist.

so to setup BI and java with a single domain you need to verify where the customer exists, create the group in the same domain. (i.e. customer@cust.domain.com) set the default in the CMC as CUST.DOMAIN.COM when logging into a client tool such as UDT or WRC use the customer username only (since domain is default it should not be needed) If the client tool login requires domain\username then something is not setup right.

In java define the default domain as the same as the CMC, define a KDC from that domain to choose which one go to DOS and run the comment set (enter) and the logonserver is usually a good choice. If your web/app tomcat is not in the same domain then keep using a KDC from the CUST.DOMAIN.COM, restart tomcat and try again

[dazsmithuk]

Hi Tim, I've done all that but it's still not working. The one thing you haven't mentioned in your latest response is the service account used for running the SIA and the SPNs that get created for it.

Do you think I should ask the System Administrators to recreate the service account in the parent CUST domain? Do you think the current issues are because the service account and SPN are against the TEST domain?

Thanks, Darren

[BasicTek]

The service account is verified good by the client tool login. It works the same way for java and client tools. The issue is coming from java (krb5.ini) and not reporting anything to the logs for some reason. Usually the -Dsun logging in the other post will reveal any errors but i didn't see any from your earlier post

[dazsmithuk]

Hi Tim

I followed my instincts... and I was right!

I asked the administrators to create a service account on the CUST domain (CUST\SVC-WEBTSTBO-01). They also created the BI4TEST/SVC-WEBTSTBO-01.cust.co.uk SPN.

I then did the following:

- Updated the information in the Authentication > Windows AD section to use both the new service account and SPN
- Stopped the SIA
- Added the new service account to the local administrators group
- Let the service account "act as part of the operating system" in Local Security Policy
- Restarted the SIA, running as the new service account

I then tried to log on using Manual AD Authentication and it worked!

The conclusion for this - could it be that it isn't possible to have the service account in a child domain when the users are in the parent domain? Or do you think the two-way trust between parent and child domain is maybe not completely all there?

Either way, I'm sure you can imagine how relieved I am!

Thanks for all your help
Darren

[BasicTek]

As the users could login to client tools (which uses the service account the same way as logging in from java) that shouldn't make any difference. Any child domain has a 2 way automatic trust. Now if it's not actually a child domain and has another relationship such as tree root, or forest then the java portion could be affected.But this should have been reported with the -Dsun logging.

There is also a java bug out there affecting certain versions and causing issues so it may have fallen into that catagory as well. Fortunately you had a fairly simple fix and we are quite a bit limited in our troubleshooting using a forum instead of actual contact in a remote session.

It sounds like that's the way you should keep it going forward, glad you finally got it working.

-Tim

[former_member79187]

Hi,

A helpful tool in troubleshooting is the -Dsun.security.krb5.debug=true added to tomcat java options (type the option and restart tomcat to take effect, info is in tomcat logs(stderr.log and stdout.log).

See the link in the references section to KB 1245178 for basic krb5.ini configuration tips please.

Sungho

[dazsmithuk]

Hi Sungho / Chenghao

Thanks for your suggestion. I have put this in place, and attempted to log on to the CMC. The user is in the default domain specified in both the krb5.ini and the Authentication options in the CMC. This is the output I got (I have changed the customer's domain to "CUST.CO.UK" to protect their anonymity. As you'll see, it says "succeeded" but then gives other issues. The error I see on screen is "The Active Directory Authentication plugin could not authenticate at this time".

Debug is true storeKey false useTicketCache false useKeyTab false doNotPrompt false ticketCache is null isInitiator true KeyTab is null refreshKrb5Config is false principal is null tryFirstPass is false useFirstPass is false storePass is false clearPass is false
[Krb5LoginModule] user entered username: csilimited@CUST.CO.UK

Java config name: c:\windows\krb5.ini
Loaded from Java config
>>> KdcAccessibility: reset
default etypes for default_tkt_enctypes: 23.
>>> KrbAsReq creating message
>>> KrbKdcReq send: kdc=LCC-DCP-001.CUST.CO.UK TCP:88, timeout=30000, number of retries =3, #bytes=155
>>> KDCCommunication: kdc=LCC-DCP-001.CUST.CO.UK TCP:88, timeout=30000,Attempt =1, #bytes=155
>>>DEBUG: TCPClient reading 195 bytes
>>> KrbKdcReq send: #bytes read=195
>>>Pre-Authentication Data:
PA-DATA type = 11
PA-ETYPE-INFO etype = 23, salt =

>>>Pre-Authentication Data:
PA-DATA type = 19
PA-ETYPE-INFO2 etype = 23, salt = null, s2kparams = null

>>>Pre-Authentication Data:
PA-DATA type = 2
PA-ENC-TIMESTAMP
>>>Pre-Authentication Data:
PA-DATA type = 16

>>>Pre-Authentication Data:
PA-DATA type = 15

>>> KdcAccessibility: remove LCC-DCP-001.CUST.CO.UK
>>> KDCRep: init() encoding tag is 126 req type is 11
>>>KRBError:
sTime is Sat Oct 07 00:11:47 BST 2017 1507331507000
suSec is 633624
error code is 25
error Message is Additional pre-authentication required
sname is krbtgt/CUST.CO.UK@CUST.CO.UK
eData provided.
msgType is 30
>>>Pre-Authentication Data:
PA-DATA type = 11
PA-ETYPE-INFO etype = 23, salt =

>>>Pre-Authentication Data:
PA-DATA type = 19
PA-ETYPE-INFO2 etype = 23, salt = null, s2kparams = null

>>>Pre-Authentication Data:
PA-DATA type = 2
PA-ENC-TIMESTAMP
>>>Pre-Authentication Data:
PA-DATA type = 16

>>>Pre-Authentication Data:
PA-DATA type = 15

KrbAsReqBuilder: PREAUTH FAILED/REQ, re-send AS-REQ
default etypes for default_tkt_enctypes: 23.
default etypes for default_tkt_enctypes: 23.
>>> EType: sun.security.krb5.internal.crypto.ArcFourHmacEType
>>> KrbAsReq creating message
>>> KrbKdcReq send: kdc=LCC-DCP-001.CUST.CO.UK TCP:88, timeout=30000, number of retries =3, #bytes=233
>>> KDCCommunication: kdc=LCC-DCP-001.CUST.CO.UK TCP:88, timeout=30000,Attempt =1, #bytes=233
>>>DEBUG: TCPClient reading 1524 bytes
>>> KrbKdcReq send: #bytes read=1524
>>> KdcAccessibility: remove LCC-DCP-001.CUST.CO.UK
>>> EType: sun.security.krb5.internal.crypto.ArcFourHmacEType
>>> KrbAsRep cons in KrbAsReq.getReply csilimited
principal is csilimited@CUST.CO.UK
Commit Succeeded

Found ticket for csilimited@CUST.CO.UK to go to krbtgt/CUST.CO.UK@CUST.CO.UK expiring on Sat Oct 07 10:11:47 BST 2017
Entered Krb5Context.initSecContext with state=STATE_NEW
Found ticket for csilimited@CUST.CO.UK to go to krbtgt/CUST.CO.UK@CUST.CO.UK expiring on Sat Oct 07 10:11:47 BST 2017
Service ticket not found in the subject
>>> Credentials acquireServiceCreds: same realm
default etypes for default_tgs_enctypes: 23.
>>> CksumType: sun.security.krb5.internal.crypto.RsaMd5CksumType
>>> EType: sun.security.krb5.internal.crypto.ArcFourHmacEType
>>> KrbKdcReq send: kdc=LCC-DCP-001.CUST.CO.UK TCP:88, timeout=30000, number of retries =3, #bytes=1546
>>> KDCCommunication: kdc=LCC-DCP-001.CUST.CO.UK TCP:88, timeout=30000,Attempt =1, #bytes=1546
>>>DEBUG: TCPClient reading 1512 bytes
>>> KrbKdcReq send: #bytes read=1512
>>> KdcAccessibility: remove LCC-DCP-001.CUST.CO.UK
>>> EType: sun.security.krb5.internal.crypto.ArcFourHmacEType