But if there is no servicePrincipalName attribute, TGS_REQ for
"[EMAIL PROTECTED]" fails. So my clients are
not able to get the appropriate Kerberos ticket. (KDC returns
PRINCIPAL_UNKNOWN)
Have I done something incorrectly? Here's my setup:
ldapsearch -Y gssapi -X u:administrator samaccountname=foobar$ \
altsecurityidentities serviceprincipalname
Output:
dn: CN=FOOBAR,CN=Computers,DC=windows2000,DC=spinnakernet,DC=com
altSecurityIdentities: Kerberos:
[EMAIL PROTECTED]
Regards,
Vijay
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On Behalf Of Luke Howard
Sent: Thursday, September 19, 2002 4:02 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: RE: unknown RPC opcodes during join+logon
>But here are the results I got with changes to Samba:
> Odd name: <credential><4-byte flags = 0x0007ffff>: Access Denied
> Even name: <credential>,0x6B,0,<flags=0x0007ffff>: Access Denied
> Odd name: <credential><flags = 0x000001ff>:
> Success but "servicePrincipalName" attribute in Active
> Directory disappears
> Even name: <credential>,0x6B,0,<flags=0x000001ff>:
> Success but "servicePrincipalName" attribute in Active
> Directory disappears
I'm ont sure about the 0x6B but I would think that servicePrincipalName
disappearing would have something to do with Active Directory presuming
that downlevel clients (which negotiate 0x1ff) do not support Kerberos,
and thus do not have a servicePrincipalName. You might try using the
altSecurityIdentities attribute instead, eg:
altSecurityIdentities: Kerberos:cifs/foobar.windows2000.spinnakernet.com
-- Luke
--
Luke Howard | PADL Software Pty Ltd | www.padl.com
