43k+ errors from Active Directory DC? Error 4776

[volvo64]

In November a user requested a new Mac for publishing purposes; after a long wait we finally got it last month. In addition to her 27" iMac, I was given a new 13" MBP since I'm familiar with OS X and we need someone to support her. Both Macs are running OS X 10.8.2.

After getting them, I naturally bound them to our domain using Directory Utility, which seemed to work like a charm. We could access network shares, network users can log in to them, Domain Admins have admin access on them, printers work, intranet works, etc. However, it turns out that each of these Macs are generating 43,000 plus errors on the Domain Controllers every week. We have a mixed 2003/R2/2008/R2 environment, with both DCs being 2008 R2. I'm really unsure of how these errors keep being generated, since both machines are functioning just fine; but my security admin is going nuts about them. Attached is a screenshot of the error, which is Windows ID 4776.

 

[satcomer]

First make sure the Macs on the Domain use the SAME Time Server as the Domian Server is using. This way the Kerberos will not mess up.

 

[volvo64]

First make sure the Macs on the Domain use the SAME Time Server as the Domian Server is using. This way the Kerberos will not mess up.

OK, changed the time server on my laptop. There was no difference between time.apple.com and our internal NTP server which the domain is syncing from.

That brings up another valid point, however: if I understand correctly, OS X, being a Unix-type system, holds a system time in UTC, whereas BIOS-based clocks hold local time. Therefore, even though I'm using a time server and setting the correct timezone, and my clock displays 11:38, the system time would be 16:38, the current UTC time. Any possibility of a conflict there?

 

[Ccrew]

The error is actually somewhat benign, it's because the Apple workstations are using NTLMv2 authentication to auth versus kerberos. You'll still work, but the servers complain by posting event messages.

Apple went away from MIT kerberos for Heimdahl in Lion, they've not gotten it quite right yet. Might want to take a look here:

http://kb.mit.edu/confluence/displa...+OS+X+10.7+(Lion)+or+OS+X+10.8+(Mountain+Lion)

Your Infosec guy needs something better to do, like upgrading the 2003 servers

 

[volvo64]

The error is actually somewhat benign, it's because the Apple workstations are using NTLMv2 authentication to auth versus kerberos. You'll still work, but the servers complain by posting event messages.

Apple went away from MIT kerberos for Heimdahl in Lion, they've not gotten it quite right yet. Might want to take a look here:

http://kb.mit.edu/confluence/displa...+OS+X+10.7+(Lion)+or+OS+X+10.8+(Mountain+Lion)

Your Infosec guy needs something better to do, like upgrading the 2003 servers

Was not able to download that file, it looks like because I'm not on MIT's network. The given error was 'The server 'downloads.mit.edu' did not accept the certificate.' Did a little more poking after that, found the Ticket Viewer app in /System/Library/Core Services and signed in on that.

We're watching the logs to see if that helps at all. Otherwise can someone whose certificate MIT trusts send me that DMG?

 

[volvo64]

Security admin has been out sick for a few days; will update Monday hopefully.

 

[throAU]

OK, changed the time server on my laptop. There was no difference between time.apple.com and our internal NTP server which the domain is syncing from.

That brings up another valid point, however: if I understand correctly, OS X, being a Unix-type system, holds a system time in UTC, whereas BIOS-based clocks hold local time. Therefore, even though I'm using a time server and setting the correct timezone, and my clock displays 11:38, the system time would be 16:38, the current UTC time. Any possibility of a conflict there?

AFAIK, this should not be an issue - as the internal method of keeping time should not be exposed over the network as far as time synch is concerned.

All that should be seen via network is time presented in either NTP format or Windows format when accessing Windows resources. I.e., it should be abstracted away from whatever OS X is doing internally.

 

[Ccrew]

AFAIK, this should not be an issue - as the internal method of keeping time should not be exposed over the network as far as time synch is concerned.

All that should be seen via network is time presented in either NTP format or Windows format when accessing Windows resources. I.e., it should be abstracted away from whatever OS X is doing internally.

Correct. Biggest thing is that the time skew is less than 5 minutes, or you can't get a valid Kerberos ticket.

In looking at the screenshot a bit closer since the last time I checked this thread though, I i wonder some of the issues is that the name of the mac ends in .local and the OP's internal domain does also. There are known issues with this, and it's not uncommon to see.

From Technet: http://technet.microsoft.com/en-us/library/cc626155(WS.10).aspx

"If you have a Macintosh computer with OS X 10.3 and higher on your network, you must specify an AD DS name extension for the internal domain other than .local. The Rendezvous Service on Macintosh computers with OS X 10.3 and higher use .local to discover other computers on the network. "

 

[volvo64]

This error quieted down and everything else at work drew more attention, so this hasn't been on my radar for quite some time.

Turned out to be errors against the proxy server that we use here at work. Not sure what the problem was, nor am I sure how it might be fixed, but since the proxy wasn't doing anything on the Macs except for prompting to log in every time a new app asked for internet access, we disabled the proxy. Works fine now on both Macs in the office.

Hope this helps somebody in the future, even though I can't tell you exactly what the issue was.

Correct. Biggest thing is that the time skew is less than 5 minutes, or you can't get a valid Kerberos ticket.

In looking at the screenshot a bit closer since the last time I checked this thread though, I i wonder some of the issues is that the name of the mac ends in .local and the OP's internal domain does also. There are known issues with this, and it's not uncommon to see.

From Technet: http://technet.microsoft.com/en-us/library/cc626155(WS.10).aspx

"If you have a Macintosh computer with OS X 10.3 and higher on your network, you must specify an AD DS name extension for the internal domain other than .local. The Rendezvous Service on Macintosh computers with OS X 10.3 and higher use .local to discover other computers on the network. "