Chained AdvancedLdapLoginModule against Server 2008 R2

[jar349]

Hello!

Here is the short summary: using the AdvancedLdapLoginModule chained after SPNEGO against Win2008 R2 always fails with: "000004DC: LdapErr: DSID-0C0906DC, comment: In order to perform this operation a successful bind must be completed on the conneciton., data 0, v1db0"

Here are the much longer details:

Domain: example.com

Functional level: Windows Server 2008 R2

Single Controller is: dc.example.com

JBoss platform: RHEL 5.4

Server name: linux.example.com

Joined to domain: Yes

Account running JBoss: [e-mail]

Account does not require preauthentication: Checked in AD

SPN assigned to service account: HTTP/[e-mail]

Keytab exported and referenced in login-conf.xml: Yes

Client Machine: Windows XP SP 3

machine name: client.example.com

Joined to domain: Yes

Logged in account: [e-mail]

With this setup, I am successfully able to execute all three of the jboss-negotiation-toolkit tests.  However, when I swapped out the UsersRolesLoginModule for AdvancedLdapLoginModule, I receive the error referenced above.

Looking at the Windows Event log, I see a bind warning (Event ID 2889) about a client that either performed a SASL bind that didn't request signing or performed a simple bind over cleartext.  Of note, the Identity that the client attempted to authenticate as is: NT AUTHORITY\ANONYMOUS LOGIN.  So it seems that something with the GSSAPI is failing to pass credentials and is falling back to anonymous.  The very next event in the event log is event id 1535, which is the error that I reference above.  The text "in order to perform this operation" is also in the server.log on the jboss server.

A wireshark capture on the domain controller shows linux.example.com contacting dc.example.com for a AS-REQ and then a TGS-REQ.  Both seem to receive the expected response.  The SPNs being passed around all look correct.  After the KRB5 traffic, here is the LDAP conversation I see:

• C: "bindRequest(1) <ROOT> sasl".  The mechanism is set to GSSAPI and includes credentials as well as the krb AP-REQ.
  
• S: "bindResponse(1) saslBindInProgress".
  
• C: "bindRequest(2) <ROOT> [Malformed Packet]".  The mechanism is set to GSSAPI but the credentials are <MISSING> this time.
  
• S: "bindResponse(2) saslBindInProgress".  The server's sasl creds are set and there's krb5_blob data.
  
• C: "bindRequest(3) <ROOT> sasl".  The mechanism is set to GSSAPI and there are creds and a krb5_blob.
  
• S: "bindResponse(3) success".  The resultCode is success (0).
  
• C: "searchRequest(4) DC=example,DC=com wholeSubtree".  The filter is (userPrincipalName=[e-mail])
  
• S: "searchResponse(4) operations error (the error referenced above is here)"
  
• C: "unbindRequest(5)"
  

Can anyone think of a reason why this might occur?  Or any idea how to fix it?

[jar349]

Are there no ideas for this issue? 

If not, is there anybody who has successfully gotten the AdvancedLdapLoginModule to work against a single Windows Server 2008 R2 domain controller?  If you have, could you please tell me if your wireshark capture is similar to my wireshark capture?  Would you mind posting your login-config.xml?  Would you mind posting your server.log?

Since I know that others have gotten their AdvancedLdapLoginModule to work, I want to test if the problem is something with Server 2008 R2 or something with my own environment setup.

Thanks for any information anyone can provide.

[jar349]

I have finally gotten my chained AdvancedLdapLoginModule to work.  What I did to make it work: delete my service account and recreate it WITHOUT setting the "Do not require Kerberos preauthentication".  For me to get this to work, that setting should be UNCHECKED.  Then use ktpass to map the SPN to your service account and export the keytab. I will not say that this is the "right answer", but all three of my jboss-negotiation-toolkit tests work AND the /Secured test is integrated with my AD/LDAP.

Step-by-step, here is what I did to get everything to work.  This is just for creation of the service account and the keytab.  I assume you've done everything else in the jboss negotiation user guide.

1. Create a new domain user (I called mine jbossService).  I set the "First Name" and "User logon name" to jbossService and click Next.  I enter the account password (let's pretend its password123) twice, clear the "User must change password at next logon" checkbox and check "User cannot change password" and "Password never expires".  I finish creating the user by clicking Next.
   
2. I now must map a SPN for the HTTP service on linux.example.com to the service account (jbossService) I just created.  From the Windows start menu, find Command Prompt and right-click on it and select "Run as Administrator" and accept the UAC dialog if it pops up.  At the command prompt, type the following and substitute your values.  When prompted for the password, use your original password (password123) both times.
   

ktpass.exe /out C:\linux.http.keytab /princ HTTP/[e-mail]
  /pass * /mapuser jbossService /ptype KRB5_NT_PRINCIPAL

Now you have a valid keytab on your C:\ drive that needs to be copied over to someplace on linux.example.com.  I first logged in as EXMAPLE\jbossService so that a home directory is created for the service account.  Then I put the keytab into the home directory of the jbossService account (/home/EXAMPLE/jbossService).  I can do this because I have previously joined my RHEL machine to the EXAMPLE.COM domain.  If you can't or haven't, just put it somewhere safe.  Then I changed ownership to EXAMPLE\jbossService:root and set permissions to 440.

sudo chown EXAMPLE(two backslashes go here)jbossService:root linux.http.keytab
sudo chmod 440 linux.http.keytab

Next, I made sure that my "host" security domain in jboss/server/xxx/conf/login-conf.xml referenced the keytab and the principal HTTP/[e-mail].  Also make sure that the rest of your LDAP settings for your AdvancedLdapLoginModule are correct.

This is all I had to do to get the chained AdvancedLdapLoginModule to work.  Again, I want to mention to future readers that I already had the 3 jboss-negotiation-toolkit tests working, so this posts assumes that you do too.

Finally, note that the unexploded jboss-negotiation-toolkit.war will not let you into the 3rd test (/Secured) unless the client account (the person who is logged in to the client machine browsing to the linux.example.com server) is a member of a group called "Users".  All I did was add my client account to the domain controller's BUILTIN\Users group and that was enough to make the 3rd test (/Secured) work for me, showing me my client account principal, etc.

[klindberg]

I ran into the exact same problem today, and thanks to your post it was easily solved by unchecking "Do not require kerberos preauthentication"

Thanks,  Kerstin

[sridhar18]

This worked for me too. Thanks John.

[ceedigh]

Thanks a lot for this information John. I had been trying to setup the JBoss Negotiation Toolkit for EAP 5.1.1 and Windows Server 2008 R2 and had everything working except the AdvancedLdapLoginModule. This was the final missing piece that was needed and like Kerstin I only needed to UNCHECK the "Do not require kerberos preauthentication" box for the Server User to make the Secured test work.

Since I am using JBoss EAP I had opened an official support case with Red Hat and they pointed me to the JBoss Negotiation User Guide which clearly was misleading as it said the checkbox should be checked.