"Nikolaos Milas" <nmilas@xxxxxx> wrote in message
news:4E7C4A82.9030407@xxxxxx...
On 23/9/2011 10:25 Ãμ, Markus Moeller wrote:
This is an incomplete Active Directory setup (or Kerberos if you don't
use AD).
Thanks Markus,
As you may have seen from earlier posts, I am using MIT Kerberos on
CentOS. I don't have Active Directory but I am using OpenLDAP which
serves as Kerberos container and principals store.
DNS entries were (until now) considered unnecessary. I have created the
required entries and retried.
Now I am getting (in Wireshark) an LDAP search request from the client
and this fails:
CLDAP searchRequest(4) "<ROOT>" baseObject
with content:
baseObject:
scope: baseObject (0)
derefAliases: neverDerefAliases (0)
sizeLimit: 0
timeLimit: 0
typesOnly: False
Filter:
(&(&(DnsDomain=EXAMPLE.COM)(Host=CLIENTHOSTNAME))(NtVer=0x20000006))
attributes: 1 item
AttributeDescription: Netlogon
and the server responds:
ICMP Destination unreachable (Host administratively prohibited)
We don't allow anyone (except specific DNs) to access our LDAP server.
Additionally there are no such entries in there (these are obviously
Active Directory specific). Anyway, there is no client host entry in
Kerberos or in LDAP.
Now what?
This now goes more into how to setup Windows clients ( Do I understand right
taht you use IE on XP or Windows 7) with MIT Kerberos. Therer are several
guides for this like
https://help.ubuntu.com/community/LDAP-Samba_PDC_%28for_Linux_and_Windows%29
and http://technet.microsoft.com/en-us/library/bb742433.aspx Section "Using
an MIT KDC with a Standalone Windows 2000 Workstation" (although this is a
bit older).
What you should see is:
1) user logs in to XP/Windows 7 => DNS from Windows client to find kdc ( we
fixed this), AS-REQ from Windows client to kdc, AS REP from kdc to Windows
client
2) use kerbtray to list kerberos cache on XP,Windows 7 and you should see a
client principal user@xxxxxxxxxxx and possibly a TGT of krbtgt/EXAMPLE.COM
3) access web page via squid => TGS REQ from Windows client to kdc for
HTTP/<squid>, TGS REP from kdc to Windows client (You must have created a
HTTP principal in your Centos kdc using MIT tools like kadmin)
4) kerbtray should now list HTTP/<squid>
If you don't get that far (e.g. no TGS REP) check your kdc logfile.
5) Inside your HTTP communication on the proxy port you will see a Proxy
Authentication Negotiate header. Wireshark can decode this and you should
see the un encrypted details of the Kerberos ticket like user principal and
service principal HTTP/<squid>
6) If that works but you still get challanged, check the squid_kerb_auth
debug information (i.e. using -d) in cache.log.
Nick
