incoming Kerberos TGT not accepted by Tiger Server 10.4.2 — but it obtains TGT’s correctly for SSO

[s_groening]

I am having a real pain correcting this issue… Our setup is as follows:

Servers:
2x W2K3 servers hosting AD, DNS and printing services (incl. printer accounting)
1x XServe G5 dual 2GHz running Tiger server 10.4.2 w. all updates installed
hosting OD, DHCP (for now), SMB and AFP services

Clients:
30 W2K/XP clients
65 G4/G5 clients running 10.3.9/10.4.2 w. all respective updates installed

Our situation is this: I have installed and setup our Tiger Server following all possible guidances in respect to this matter.

Installed 10.4.0, updated to 10.4.2 Combo + all security updates
Setup OD Master with a sharepoint for home directories, removed the ‘/LDAPv3/127.0.0.1’ entry form the authentication list in ‘Directory Access’, bound or joined the server to AD with the AD plug-in (specifying the correct uid attribute, using the UNC pth for home directories mounted via smb) and placed the AD domain at the top of the authentication list in ‘Directory Access’, afterwards recreating the ‘/LDAPv3/127.0.0.1’ entry in the authentication list in ‘Directory Access’. I then rebooted the server and joined it to the Kerberos realm by typing ‘dsconfigad -enablesso’ from the terminal as root AND I have turned off the OD Kerberos Client autoconfiguration, to stop the OD server from attempting to overwrite Kerberos information in respect to clients.

I then checked the smb.conf file and confirmed that the appropriate realm information was included, added the ‘winbind separator = +’ entry to smb.conf and uncommented ‘auth methods = guest opendirectory’ entry for both smb.conf and smb.conf.template to prevent overwriting of this entry on service restart.

I created user groups in the OD for AD users and created home directories and created the symlinks for ‘My Documents’, ‘My Music’, ‘My Pictures’ and created the ‘Application Data’ and ‘Start Menu’ folders.

Rebooted and logged in from the AD domain controller and logged in to the OD server’s smb share, and it served my home directory correctly…. This scenario repeated itself after logging in to both a XP workstation an a Mac OS X 10.4.2 workstation.

After a while, though, it stopped working until I restarted the smb service once more….

Here is my take on the problem: It seems as though incoming Kerberos TGT’s are not being recognized as usable in respect to the Tiger smb server, even though the opposite scenario (Tiger server fetching a TGT for an AD user, that is distributed by the AD KDC) works like a charm…and every time, too… This means that SSO is only happening from the Tiger server to the AD servers, not the other way around, and not necessarily from a Mac OS X 10.3.9/10.4.2 client…

Is there a way to make the Mac OS X server Kerberos libs behave like v.5 instead of v.5.5? -I think I saw this posted somewhere, maybe http://macwindows.com, as a somewhat equivalent to the v.4 compatibility mode found in v.5… Maybe this could bring SSO to Windows AND Mac OS X clients as well as the respective servers…

BTW: All signing and encryption of smb shares have already been sturned off on W2K3 servers to ensure login, so the Mac OS X clients WILL indeed experince true SSO once this ‘glitch’ has been corrected…

Best regards,
Søren Grønning

[s_groening]

I do not have access to the samba log files at the moment, but I have seen the ‘failed to verify incoming ticket’ message, which led me to speculate about Kerberos…

I will return as soon as I am back at work. Thank you for your advice this far!

[s_groening]

This seems to be going on and on and on….in the samba log file on the xserve g5:

[2005/09/13 20:00:56, 0] /SourceCache/samba/samba-92.9/samba/source/tdb/tdbutil.c:tdb_log(725)
  tdb(/private/var/samba/sessionid.tdb): tdb_reopen: open failed (Too many open files in system)
[2005/09/13 20:00:56, 0] /SourceCache/samba/samba-92.9/samba/source/smbd/server.c:open_sockets_smbd(437)
  tdb_reopen_all failed.

[s_groening]

I tried this:

“Hi
I have a very similar setup 2wk3 DC’s and 2 Xserve G5’s and a PowerMac G5 2 AD and 1 OD and noticed this problem too. Its a matter of the order in which things are done. I fixed this on the AD bound Xserve and Powermac by doing the following.

Unbind it and remove it from the domain.
Confirm your time sync on the AD and its.
Use the windows services part of server admin to join it as a domain member.
Stop and start windows services
Use the AD plugin to rejoin the domain.
run dsconfigad -enablesso
See there’s now a realm at the bottom

After doing this both the Macs and PC’s were getting
access. I assume by Kerberos but I will verify that
when i get a chance. Only the macs were get kerb afp before this.

I was busy doing something else at the time.

Cheers
Phil”

and it seems to work okay… but Windows users do not get permission rights of their own files…

[s_groening]

Now, for some insane reason, it seems to work nicely….
Having followed the preveously mentioned advice for the setup sequence, PLUS adding ‘winbind separator = +’ in /etc/smb.conf, I now have true SSO working with Tiger Server 10.4.2 and W2K/XP clients!!

I swear this was originally added to /etc/smb.conf as well, but only this time did it kick in… -Restarted the smbd process and ‘wooomp there it is’…

Now all I need is to be sure that the setup is stable.

[Author]

Posts