[RobertHammen]

Whoops I pasted the wrong link in…

http://docs.info.apple.com/article.html?path=ServerAdmin/10.4/en/c5od21.html are the directions I attempted to follow.

I know [b]for sure[/b] that I did [b]NOT[/b] click on the Disable NetInfo button. Wonder if someone else did before this?

I’m proceeding reverting this server (and the new one) to standalone servers. I just hope their mail server continues to work following a restart…

–Robert

[RobertHammen]

[QUOTE][u]Quote by: nicole[/u][p]There’s two possibilities here: either your users are failing authentication, which is a DS/winbindd problem, or they’re failing authoriziation, which is likely a memberd problem. As a test, when the problem happens, try authenticating with an AD user account using dirt with ntlm authentication:

dirt -a nt -u -p

If this fails, you have an authentication problem, and the steps I talked about at WWDC should be able to help you.

If it succeeds, your authentication is ok, but you’re being blocked by permissions. Assuming your permissions are set such that the user in question should have access, the culprit is probably memberd. Resetting the memberd cache on the fileserver ought to fix this: memberd -r. You can also fix this issue for a specific user by running id for that user on the fileserver, as this will refresh the memberd cache for that user. Once you “id” the user, they should be able to login again.

Hope that helps.

[/p][/QUOTE]

The exact same problem still occurs on our new bound-at-10.4.9 Intel Xserve. It’s getting pretty frustrating.

When the problem happens authentication fails. It seems there are two problems:

#1) The machine password authentication against WINS starts failing (resetting nmbd (SIGHUP) seems to fix the problem temporarily). We have WINS registration set to 4 weeks in the smb.conf, so this shouldn’t be happening.

#2) Once this happens, user authentication starts to fail. Only SIGHUP’ing DirectoryService seems to fix it temporarily.

Sometimes this problem occurs and it fixes itself. Otherwise it’s multiple times per day. Doesn’t seem to be consistent that it happens after x amount of uptime (the only consistent thing is to run both commands and the problem is gone, at least temporarily). It’s getting pretty frustrating.

Would love to get to the bottom of this issue, as it’s been occurring under 10.4.x for a couple of years across two different Xserves (G5 and Intel)…

[RobertHammen]

[QUOTE][u]Quote by: DSoderholm[/u][p]Incidentally, is there a written-down version of those guidelines Robert mentioned?[/p][/QUOTE]

Here are my notes. Sorry if anything is incorrect, I was trying to keep up:

Active Directory Plug-in troubleshooting
1) Binding fails at “Step 5” = enable DS debug logging sudo killall -USR1 DirectoryService

touch /Library/Preferences/DirectoryService/.DSLogAtStart

/Library/Logs/DirectoryService/DirectoryService.debug.log

kpasswd operates over UDP on Tiger (can do either in Leopard)
Windows clients can use TCP instead

Port 464 UDP blocked? Check firewall.
Too much Kerberos PAC data? Use different admin account
Non-routable DNS address for dc? disable checkbox
Network settings that interfere with UDP? fix network settings

2) Issues with authenticating SMB to DirectoryService

AD user authentication to SMB services fails
Non-AD users are able to authenticate via SMB
Authentication to other services (AFP, etc.) works

First – check which authentication is working
dirt -u username -p password
dirt -u username -p password -a nt (NTLM)

dsconfigad -sso (all services to auth against AD
check /etc/smb.conf
workgroup = NETBIOS name of AD
security = ADS (active directory server) – DON’T USE DOMAIN
netbios name = computer account that you use when you bound to AD in Directory Access
use spnego = yes – enables negotiation of authentication protocols
realm = Kerberos name of your AD domain – ALL CAPS (Kerberos = case-sensitive)

Verify that winbindd is running (2 instances) – if not, start it /usr/sbin/windbinddd -s /Library/Preferences/DirectoryService/winbindd.conf

Make sure both AD AND samba are using the same password

/Library/Preferences/DirectoryService/ActiveDirectory.plist

AD Computer Password q
base64 password – need to be root to access

Dump the secrets.tdb file (/var/db/samba

tdbdump
data = “”

If they don’t match – reset samba

net -f changesecretpw

(will prompt you for a password – use the base64-decoded AD plugin)

3)Mac OS X Server bound to AD
Home Directory path in AD pointing to share on OS X Server
Home Directory shares located on non-boot volume (i.e. xServe RAID)

Symptoms:
clients can’t automount home dirs
home dirs don’t automagically get created
home dirs get created in the wrong place
Virtual home shares don’t work
AFP logins fail

\\Server\Share\Username -> /Network/Servers/server.fqdn.com/share/username

if home dirs not on the boot drive

/Network/Servers/server.fqdn.com/Volumes/volumename/share/username

create a symbolic link:
ln -s /Volumes/Storage/Homes /Homes

[RobertHammen]

Just ran into this issue this morning. Found an apparent solution on the Apple Discussion forums. I say “apparent” because my NetBoot no longer errors out immediately, and it’s imaging a test Intel machine right now, so I don’t know for sure if it works until it’s done. It does appear to be working, though…

Mount a Universal 10.4.9 or 10.4.10 drive or machine (i.e. via FireWire – the drive you made the NetInstall image from).

Mount the image from your NetInstall set (i.e. /Library/NetBoot/NetBootSP0/ImageXXXXXXX.nbi/Install.dmg – it should come up as Read/Write.

Copy the /System/Library/Frameworks/CoreVideo.framework from the 10.4.9 or 10.4.10 drive to the mounted Install.dmg image (in the same location – it shouldn’t ask to replace the file, as the problem is the file’s not there/it’s missing from the image).

Now, eject the mounted Install.dmg image.

Try to NetInstall from a target machine (use Command-V verbose mode to debug). Does it work? It is apparently doing so for me…

[RobertHammen]

Just ran into this issue this morning. Found an apparent solution on the Apple Discussion forums. I say “apparent” because my NetBoot no longer errors out immediately, and it’s imaging a test Intel machine right now, so I don’t know for sure if it works until it’s done. It does appear to be working, though…

Mount a Universal 10.4.9 or 10.4.10 drive or machine (i.e. via FireWire – the drive you made the NetInstall image from).

Mount the image from your NetInstall set (i.e. /Library/NetBoot/NetBootSP0/ImageXXXXXXX.nbi/Install.dmg – it should come up as Read/Write.

Copy the /System/Library/Frameworks/CoreVideo.framework from the 10.4.9 or 10.4.10 drive to the mounted Install.dmg image (in the same location – it shouldn’t ask to replace the file, as the problem is the file’s not there/it’s missing from the image).

Now, eject the mounted Install.dmg image.

Try to NetInstall from a target machine (use Command-V verbose mode to debug). Does it work? It is apparently doing so for me…

[RobertHammen]

Yes, we have this same exact issue. It seems to be something Apple is aware of – there was a “Best Practices/check these three things if you have this problem” in a session at WWDC done by Nicole Jacque of Apple. (BTW, I checked her guidelines and everything’s fine on our xServe/OS X Server, and still have the same intermittent issue).

You don’t have to reboot the entire server – as you noted, just stopping and restarting the Windows service doesn’t fix the issue – the temporary workaround is to kill/restart all instances of the “DirectoryService” process – this will boot all of your Windows connections off, but not disrupt AFP, NetBoot, Software Update Server, et. al.. Here’s to hoping the rewrite of DirectoryService in Leopard is the eventual fix for this.

In researching this problem it seems like it was a samba issue. At what version of OS X Server was your computer joined to AD? We started with (gulp) 10.4. It’s been postulated that unbinding from AD, deleting the computer out of the AD domain, and then re-joining/re-binding might “fix” this issue. However, with a number of sharepoints with permissions set using ACL’s from the Windows side, this didn’t appeal to us. I’m just about done setting up a new Intel-based xServe/RAID (to replace the G5 one we leased almost 3 years ago), so I’m in hopes that this *might* address the issue.

By any chance do you have access to the AD side of the house, to debug what’s going on when authentication is failing? I do…

[Author]

Posts