[DSoderholm]

I’ve seen a couple of reports (not many, mind you) of 10.4.11 causing problems. Does anyone have a successful installation in an AD environment? Has 10.4.11 resolved problems for anyone? I was wondering what the fixes that Apple mentioned actually are.

[DSoderholm]

It’s still happening here, and all I can do at the moment is kill -9 DirectoryService whenever it pops up (or preemptively, once a week or so). I haven’t yet had a chance to try out some of the other ideas mentioned in this thread, but I hope to next week. I did idly wonder if it had to do with Kerberos ticket length or something like that, and checked through the Group Policies on the Windows domain to see if there was anything there, but nothing jumped out at me. It’s largely under control at the moment (and killing DirectoryService instead of rebooting means that for the first time in ages, I have a server uptime of more than two weeks). Still, it’s a problem I wish wasn’t there…

[DSoderholm]

We got the server around 10.4.3 time, tried to join it to AD, failed, left it for ages, finally succeeded at 10.4.9, and it’s now 10.4.10. I’m the administrator on the Windows machines too, so I have full access to the AD. Nothing ever shows up in standard Windows server event logs, but I haven’t got round to enabling super-verbose debugging output to dig deeper.

I’ve been reluctant to delete it from the AD and re-joining it (considering it took me six months to get it working in the first place and I’m still not sure how I did it). At least knowing which process is buggy helps, but avoiding it entirely would of course be best. Some people mumbled that it might be lookupd, so I set a cron job to restart that and smbd every few days, but that didn’t solve it. If I see it happen again I’ll try restarting DirectoryService, but at the moment I’m just rebooting it once a week before it starts going belly-up, just to keep users from complaining. I’m going away for a fortnight soon though >.< I'll look through memberd too, and see if I can figure out how that might be related - I'm more of a Windows guy so I'm not overly familiar with all the OS X Server processes. Thanks for the suggestions! Incidentally, is there a written-down version of those guidelines Robert mentioned?

[DSoderholm]

Thanks for the help – I’ve pretty much got it working solidly now. There is still one problem, though – it’s hard to troubleshoot, but hopefully someone here will have experience with it.

I now have an AD domain with Windows XP clients, and an XServe where the SMB server is set to be a domain member, using the AD domain for authentication/permissions. The XP clients have mapped network drives on the XServe. If I create a new user on a new computer, a login script automatically maps the drive for them without asking for a username/password or anything like that (which is exactly how it should be). Every now and again, though, someone will log in to Windows – either over our VPN or in the office – and the XServe drives will not work. The mappings are there, but access is denied – usually with a ‘user does not exist’ message. Running a simple script to delete network drives and remap them usually solves it, although sometimes the user needs to log off and back on again. I’ve had to restart the SMB service in more severe cases (everyone suddenly can’t get on). This doesn’t happen with network drives on a Windows server – only on the XServe. Before the AD integration, I’d have assumed that it was sending the wrong credentials. Now, though, the credentials should be the same as those that the user logs on with or that they use on the Windows fileservers. I’m pretty much at a loss what it could be. Nothing appears in the security logs on the XServe or the AD domain controller, but sometimes, if I try repeatedly remapping a failed drive, the AD will lock the account (following Group Policy rules).

Does anyone know why the drive mappings to the XServe would fail so frequently? Has anyone experienced this with an XServe and Windows clients?

[DSoderholm]

Thanks for the useful tip. Should have thought of that myself! I created a test user on the AD domain, and gave that AD user read permissions on a folder on the XServe. I did not set up a corresponding user on the XServe (as I have done in the past). I logged on to a fresh installation of Windows (using VMWare), as testuser. When I mapped the \\XServe\test folder it worked without requiring any additional authentication. Fantastic – that’s what I’ve been trying to do for over a year. If it works on a brand new user and a brand new Windows installation then we know that in theory, the setup is sound.

However, I have tried deleting conflicting users from the XServe, and I am still having trouble with the AD users. I think it has something to do with Windows caching or sending passwords in a funny way, though I can’t be sure (and of course, this is turning into a Windows problem). As an example:

1. I create a user on the XServe called ‘tempuser’, with no corresponding AD account
2. I give tempuser permissions on a file share
3. In Windows, I try to map a network drive. It pops up a password dialogue box and will not accept anything I enter and defaults back to ADDOMAIN\tempuser (which of course doesn’t exist)
4. If I specify the username and password in advance, using ‘connect using a different username’, it works

This suggests to me that by default, Windows’ password-sending mechanism doesn’t agree with either Kerberos or SMB on the XServe, but I’m having trouble figuring out which. The fact that I’ve now seen it working is very encouraging, though 🙂

[DSoderholm]

This is something I’m very interested in too, but I haven’t found any comprehensive guides. This is my scenario:

1x AD domain with Windows Server 2003 and a load of Windows XP clients
1x PowerPC XServe (10.4.9), operating as OD master/PDC on its own domain and sharing a load of files

The Windows computers on ADDOMAIN access shares on the XServe. Each user has an account on both services; when they authenticate to the XServe it’s just username/password when mapping network drives. After a reboot or two, especially for VPN workers, though Windows always tries to use ADDOMAIN\username, which is of course wrong. When this happens, they have to disconnect and remap network drives, which is a pain for the end user. I’ve tried tinkering with kerberos settings before but had no success. I *once* got a Windows PC to authenticate to the file share with its AD username/pw, after trying until 2am, but after an XServe reboot it was all gone again.

What I’d like is to set the permissions on the XServe’s file shares to accept users from the AD domain, so when a user logs in to Windows as ADDOMAIN\jsmith, those details are passed to the XServe when mapping file shares and accepted. To do this, though, I’m unsure what I need to do. I’ve got the AD bound in Directory Access, but I haven’t done anything with Kerberos yet. Do I need to set up a trust relationship? I looked at https://www.afp548.com/xrealm/, but I wasn’t sure if this was what I needed to do for my scenario. I want Windows clients to continue logging on as they are now to the Windows domain; all I need is for the XServe’s file sharing to accept the credentials from the AD domain. I’ve been trying to do this on and off for a year, so any help would be greatly appreciated!

Update:

Most recently I tried simply adding a user from the AD to the ACL for the relevant share in Workgroup Manager, which is probably totally wrong and way too easy. When I map the drive in Windows as ADDOMAIN\username, it actually accepts the mapping (it appears in My Computer without complaint), but when I try to open it I get ‘access denied’ errors. This appears in the SMB error log:

[2007/04/12 10:24:38, 1] /SourceCache/samba/samba-100.7/samba/source/smbd/service.c:make_connection_snum(648)
ibm033 (192.168.0.54) connect to service iris initially as user dsoderholm (uid=1025, gid=20) (pid 23475)
[2007/04/12 10:24:39, 0] /SourceCache/samba/samba-100.7/samba/source/smbd/service.c:set_current_service(51)
chdir (/Groups/shared) failed

[Author]

Posts