I was able to put DirectoryService into debug and grab what it did right when the account was locked. I don’t know much about what most of it means, but I combed though it and couldn’t find anything that might indicate it would lock things. The system.log didn’t report anything at that time. I broke down and sent an email to our Apple Rep to forward to some engineers.
I did discover one thing though. The problem is somehow related to the computer name being the same as the users account! All of our Macs are bound with the AD username of the person who uses that computer. I accidentally left a completely rebuilt Mac (to replace one that had the problem) on last night sitting at the login window and once an hour, with a few minutes variance, I received account lockout notifications. So somehow, AD thinks it’s a user trying to log in and not a computer trying to register itself.
I know this is long, but it’s the most complete explanation I have. I sent this to Apple.
Here’s our setup:
We are a primarily Windows-centric infrastructure with a single Xserve G5 that is currently only a stand-alone server. Our Domain Controllers are Win2k3 servers with the latest patches and such and both the Macs and the PC’s log in via Active Directory. Our production department is composed of 12 17″ 1.8GHz iMac G5’s, first generation, and three PowerMac G5’s (one is a first generation single processor 1.8GHz and the other two are 2GHz dual processors that are the latest generation). The two G5’s are running Tiger, as are two iMac’s that I upgraded a couple days ago. Everyone else is running 10.3.9 with the latest patches. Our computer names are set to the users AD username. I haven’t touched any of the underlying configuration in SMB or Kerberos or anything else.
Here’s the background on our problems:
Our production department was originally having problems with files not being released properly from our Windows 2k3 file server. When a file was opened, it would show as being opened with Read/Write access and one lock on the file. However, there was another file (not an actual file that existed, from what I can tell) that was listed as being open. It had the same name, but with the prefix of ._. I originally thought these were resource forks, but I discovered that the files didn’t actually exist on the server, so I figured they were some sort of lock file. Unfortunately, when the user closed the file, it removed it from the list of Open Files on the server, but the ._ file stayed with Read/Write access. This had the effect of not letting any other users make changes to the file. Oddly enough, the problem didn’t exist with users running Tiger, only those with Panther. Essentially, I couldn’t find a fix for it quick enough, so they insisted on being upgraded to Tiger to solve the problem.
Everything was great, until we found a new problem. They could only copy one file at a time from their local computer to the share, and even then they got an error that their privileges were insufficient. The file still copied though. When attempting to copy multiple files at once, it would copy the first, then give the same error. This only occurred when a user (on Tiger) was logged in via Active Directory and using SMB to connect to the file server (AFP works fine, except for the obvious issues with Microsoft’s old version). The problem didn’t occur with everyone on Tiger, though. The two PowerMacs that came with Tiger preinstalled don’t have the issue. I found that the Mac’s that were upgraded had the problem, but with a fresh install, the problem disappeared. I proceeded to wipe the two Tiger boxes that I had upgraded (I have only upgraded two machines to Tiger, everyone else is still on Panther). At first, it seemed to work. But a few hours later, they got the problem again and it hasn’t gone away since.
But wait, there’s more! When bound to AD, three of the four Tiger machines cause their domain accounts to lock. I’ve been able to reproduce this with a test machine and account. If I unbind the Mac and disable the AD plug-in (I haven’t tried just unbinding and leaving the plug-in active) then the account won’t get locked out. I left one of the Macs that I had freshly rebuilt on over night, sitting at the login window. Every hour, give or take a few minutes, we would get a notification that that users account was locked out, even though she wasn’t logged in anywhere. It seems that the AD plug-in is attempting to communicate with our domain controller every hour, but instead of the computer account on the server, it’s doing something with the user account with the same name.
I’ve turned on debug logging for the DirectoryService process and am waiting for it lock again.
This is the event that’s logged on the server:
Event Type: Success Audit
Event Source: Security
Event Category: Account Management
Event ID: 644
Date: 3/8/2006
Time: 10:43:35 AM
User: NT AUTHORITY\SYSTEM
Computer: RUBY
Description:
User Account Locked Out:
Target Account Name: mac002
Target Account ID: DIC\mac002
Caller Machine Name:
Caller User Name: RUBY$
Caller Domain: DIC
Caller Logon ID: (0x0,0x3E7)
Coincidentally, and possibly unrelated, these fill our logs all day every day and come from every Mac that’s bound to Active Directory.
Event Type: Failure Audit
Event Source: Security
Event Category: Account Logon
Event ID: 675
Date: 3/8/2006
Time: 10:51:09 AM
User: NT AUTHORITY\SYSTEM
Computer: RUBY
Description:
Pre-authentication failed:
User Name: mac002
User ID: DIC\mac002
Service Name: krbtgt/DICENT.COM
Pre-Authentication Type: 0x0
Failure Code: 0x12
Client Address: 192.168.2.18
Two of the upgraded Macs are also creating these events on the server. They’re failures to open folders that they don’t have access to, but they’re not trying to access them. I haven’t been able to reproduce this, but it might be related.
Event Type: Failure Audit
Event Source: Security
Event Category: Object Access
Event ID: 560
Date: 3/8/2006
Time: 11:53:49 AM
User: DIC\ttrost
Computer: SUMO
Description:
Object Open:
Object Server: Security
Object Type: File
Object Name: D:\Production\[REDACTED]
Handle ID: –
Operation ID: {0,198109585}
Process ID: 4
Image File Name:
Primary User Name: SUMO$
Primary Domain: DIC
Primary Logon ID: (0x0,0x3E7)
Client User Name: ttrost
Client Domain: DIC
Client Logon ID: (0x0,0xBC97A63)
Accesses: READ_CONTROL
ReadAttributes
Privileges: –
Restricted Sid Count: 0
Access Mask: 0x20080
To sum up, we’ve got two problems plaguing us. The first is that users on Tiger (but not all!) get an error when trying to copy a file from their Mac to the server. The file will successfully copy, but then they’ll received the sufficient privileges error. When copying multiple files, only the first will copy. The second problem is Mac’s running Tiger (again, not all) are locking the user account once an hour, regardless if anyone is logged in. The computers are named the same as the user that uses the machine. Both problems have been reproduced on my test Mac.
I wrote that before I had the results of the debug mode. I’d include that here as well, but even just the relevant section of the log is huge. If you’re interested, I can email it or something.
.
Comments are closed