Active Directory issues

[DSoderholm]

Hi;

I’ve been trying on and off for about a year to get AD and my XServe integrated. Basically it’s just a CIFS file/web server (currently running as OD master, though it probably shouldn’t be). Windows users from my AD domain regularly use the file shares, and I thought it’d be terribly useful if they could use their Windows logons instead of setting up a separate account. As it is, they have duplicate accounts on the XServe and it’s a common problem, especially for VPN users, that it will simply forget their password and they will have to manually remap their network drives, which is a pain.

What I have at the moment is a shambolic state where I’m half-integrated into an AD – I’ll worry about cleaning it up in due course. The current problem I’m having, and would dearly like to solve, is this:

– I create a new file share on the XServe, for testing
– In Workgroup Manager, I pick a user from the Active Directory and give them ACE permissions
– Using my Windows laptop, which is *not* on the domain, I successfully map a network drive on the XServe: say I map X: to \\Xserve\testfolder, using the logon ADDOMAIN\testuser
– If I try to map it on a computer that *is* connected to the domain, it fails. It will not accept the username/password, and just pops up an error message again.
– If I log off the domain computer and log back on as a local user rather than a domain user, it succeeds.

I’ve tried looking all over Microsoft’s support pages but I can’t find anything (hard to figure out the keywords). A little lightbulb came on that suggested it was a group policy issue – the GPOs apply when the domain account is logged on, but not when I’m a local user. I am assuming that there is a GPO relating to authentication methods, or encrypted connections, or something of that order, which is causing my logons to be rejected when I am on a domain computer (of course, I may be way off).

Please please please, does anyone know what it could be?

[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]

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?

[Author]

Posts