Thanks, Dean. Ok, so... looks like most of of our settings line up. I did mean to mention this, though... when I said kinit, etc, were working from the command line I might have been going off half-cocked. Doing:
klist -k ...shows my krb5.conf is getting picked up, it sees the keytab file I created using ktpass.exe on my AD box and copied over, and it lists the HTTP/[email protected] principal (and a kvno matching what ktpass.exe output when the keytab was generated). When I said 'kinit' works, I wasn't using the SPN account -- I was using my domain user and entering my domain password. Doing 'klist' after that shows a cached ticket for 'krbtgt/[email protected]'... my assumption is (was) that this still uses the SPN keytab to handle communication / delegated authentication. Maybe I was misunderstanding there... digging a little deeper: when I do: kinit [email protected] ...and enter the password for that account, I get "kinit(v5): Preauthentication failed while getting initial credentials". If I do: kinit -k -t /path/to/my.keytab [email protected] ...I get a different message: "kinit(v5): Key table entry not found while getting initial credentials". If I do: kinit -k -t /path/to/my.keytab HTTP/[email protected] ...I get another error: "kinit(v5): Client not found in Kerberos database while getting initial credentials". If I do: kinit [email protected] ...and put in my password, like I said -- no complaints and 'klist' shows a cached krbtgt ticket. Anyone have thoughts on the best way to test this? I suspect that I should be able to kinit with the SPN account, but that's not happening for some reason. Suggested next step? Start snooping the kerberos traffic going to AD? Thanks! - Bill On Wed, Apr 28, 2010 at 1:01 PM, Dean Heisey <[email protected]>wrote: > Bill, > > > > The userPrincipalName should be HTTP/[email protected] and the > servicePrincipalName should be HTTP/server.my.domain. > > > > Here are the settings on my AD Domain server for the user account: > > > > When you open the ActiveDirectory Users and Computers admin console and > click on your user: > > > > On the Account Tab: > > > > User logon name à HTTP/server.my.domain @MY.DOMAIN > > User logon name pre windows 2000 à your actual user name in my case the > user name is _*CAS*_SERVICE > > > > Account options: be sure the following two are checked and no others…User > cannot change password, Password never expires. > > > > On the Delegation Tab: > > Be sure that the Trust this user for delegation to any service(Kerberos > only) is selected. > > > > To enable the delegation tab, you need to run the ktpass command for that > user. If you don’t run ktpass on the AD box..SPNEGO never seems to hook up. > > > > Your klist and kinit are working that means that from your Sun box you can > talk Kerberos. It is not kerberos that is the problem it’s the integration > with AD. > > > > Just to be sure, you have run the ktpass on the AD user, correct? > > > > Hope this helps. > > > > Dean > > > > > > *From:* William Markmann [mailto:[email protected]] > *Sent:* Tuesday, April 27, 2010 1:49 PM > *To:* [email protected] > *Subject:* Re: [cas-user] Problem with SPNEGO (Getting NTLM token instead > of Kerberos) > > > > Dean, > > I am just returning to this now; I'm still seeing the same issues as when > you originally sent this message. I haven't tried with Firefox (can't > install it on my workstation, since I am in a fairly locked-down > environment), but I have enabled integrated Windows authentication in IE, as > the manual indicates. > > I did see in a previous message on the mailing list that the > 'servicePrincipalName' attribute of the SPN in AD should be > 'HTTP/[email protected]'. When I use an LDAP browser to look at > the SPN's entry in my AD, I see two attributes: > > userPrincipalName -> HTTP/[email protected] > servicePrincipalName -> HTTP/server.my.domain > > So, assuming Arnaud's comment in that regard is correct, I seem to have the > wrong values there. Is there any way you could confirm that matches up with > what you have set for your AD SPN user? I might be grasping at straws... > 'klist' and 'kinit' seem to be working fine from the command line; I guess > I'm still a little foggy on what the communication flow is between the three > participating parties (the KDC, my app server running CAS, and the end user) > that determines whether CAS gets a kerberos token or an NTLM token from the > user's browser... where else might I have screwed this up? > > Much appreciated! - Bill > > On Mon, Mar 22, 2010 at 11:18 AM, Dean Heisey <[email protected]> > wrote: > > It is the browser that is sending the token. Have you tried spnego with > Firefox? > > > > There are three things that are different in your setup: > > > > 1) You are running on Solaris, I am on RedHat Enterprise Linux v5 > > 2) Your encryption is DES, I am RC4-HMAC…have you checked the AD logs > to see if any errors are being generated? > > 3) I am not using a keytab file. > > > > Every time I ran into these types of issues, it was the AD user. Once you > have that communication path working don’t touch it unless you absolutely > have to. The AD portion seems to be the most unstable when it comes to > changing users/SPN combinations. > > > > · What version of AD are you running? > > · Also, you only have one SPN associated with this user, correct. > I noticed that if you add SPNs to the user, only the primary SPN is used. > By primary, I mean the SPN that shows up in the AD admin console as the > users login i.e. HTTP/<your host here> > > > > > > *From:* William Markmann [via Jasig] [mailto:[hidden > email]<http://n4.nabble.com/user/SendEmail.jtp?type=node&node=1677769&i=0>] > > *Sent:* Monday, March 22, 2010 7:49 AM > *To:* Dean Heisey > *Subject:* Re: Problem with SPNEGO (Getting NTLM token instead of > Kerberos) > > > > Dean, > > > > Thanks for the guidance. I talked to the AD admins and they did generate > the keytab from domain controller (the same machine that is listed as the > KDC in my kerberos config). So, still no luck there. Also, if delegation > weren't working properly, I wouldn't even be able to authenticate using > 'kinit', right? In my (possibly flawed) mental model of how this all works, > once I have 'kinit' working, everything is good from the Kerberos / AD side > of the equation, and we just need to focus on getting the app server -> > browser communication working properly. Am I thinking about this wrong? > > What factors actually affect whether the SPNEGO login action gets NTLM vs > Kerberos data? I've read through the source of SpnegoCredentialsAction, and > it looks like it gets one or the other -- what's actually determining which > is sent? > > > > Thanks, - Bill > > On Fri, Mar 19, 2010 at 7:53 PM, Dean Heisey <[hidden > email]<http://n4.nabble.com/user/SendEmail.jtp?type=node&node=1677730&i=0>> > wrote: > > > I ran into something like this where the kerberos was not working with my > AD, > When you regenerated your keytab for the new AD user/spn did you run the > ktpass on your Active Directory DOmain server? That gives you access to > the > Delegation tab on the AD user and computer administrator tab. Go check the > CAS User manual SPNEGO section. I updated it recently to include my > experiences. > > Dean > -- > View this message in context: > http://n4.nabble.com/Problem-with-SPNEGO-Getting-NTLM-token-instead-of-Kerberos-tp1598650p1629470.html > Sent from the CAS Users mailing list archive at Nabble.com. > > > -- > You are currently subscribed to [hidden > email]<http://n4.nabble.com/user/SendEmail.jtp?type=node&node=1677730&i=1>as: > [hidden > email]<http://n4.nabble.com/user/SendEmail.jtp?type=node&node=1677730&i=2> > > > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-user > > > > > -- > Bill Markmann > > Counterpoint Consulting, Inc. > (p) 571-338-2455 > (f) 202-403-3425 > > (e) [hidden > email]<http://n4.nabble.com/user/SendEmail.jtp?type=node&node=1677730&i=3> > > > (w) http://www.counterpointconsulting.com/ > > -- > > You are currently subscribed to [hidden email] > <http://n4.nabble.com/user/SendEmail.jtp?type=node&node=1677730&i=4> as: > [hidden email] > <http://n4.nabble.com/user/SendEmail.jtp?type=node&node=1677730&i=5> > > > > > > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-user > > > ------------------------------ > > View message @ > http://n4.nabble.com/Problem-with-SPNEGO-Getting-NTLM-token-instead-of-Kerberos-tp1598650p1677730.html > To unsubscribe from Re: Problem with SPNEGO (Getting NTLM token instead of > Kerberos), click here. > > > > > ------------------------------ > > View this message in context: RE: Problem with SPNEGO (Getting NTLM token > instead of > Kerberos)<http://n4.nabble.com/Problem-with-SPNEGO-Getting-NTLM-token-instead-of-Kerberos-tp1598650p1677769.html> > > > Sent from the CAS Users mailing list > archive<http://n4.nabble.com/CAS-Users-f255676.html>at Nabble.com. > > -- > > You are currently subscribed to [email protected] as: > [email protected] > > > > > > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-user > > > > > -- > Bill Markmann > > Counterpoint Consulting, Inc. > (p) 571-338-2455 > (f) 202-403-3425 > (e) [email protected] > (w) http://www.counterpointconsulting.com/ > > -- > > You are currently subscribed to [email protected] as: > [email protected] > > > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-user > > -- Bill Markmann Counterpoint Consulting, Inc. (p) 571-338-2455 (f) 202-403-3425 (e) [email protected] (w) http://www.counterpointconsulting.com/ -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
