Home › Forums › OS X Server and Client Discussion › Active Directory › GSSAPI FAILED doing gss_unwrap: No error
- This topic has 4 replies, 3 voices, and was last updated 17 years, 8 months ago by
jaharmi.
-
AuthorPosts
-
August 20, 2007 at 8:10 pm #369796
jaharmi
ParticipantI’m getting the following “errors” in my DirectoryService.debug.log on several Macs in my university domain.
[quote]GSSAPI FAILED doing gss_unwrap: No error
Secure BIND Session FAILED with server [server name]:389[/quote]We just added some domain controllers and I’m seeing the errors for two of their host names; I haven’t yet been able to find out if they are different from the old DCs in any substantial way (such as policy). Both are listed in the ActiveDirectory.plist for this domain on the local systems. I have unbound and rebound one of the computers and the error persists, so that would seem to rule out a computer object password problem.
I have inconsistent results logging in. Well over half of the time, I can’t log in with my account on one of these computers, and other users have similar results. If I [i]can[/i] log in, other things go haywire … I can’t use `sudo` because it can’t find my UID (rather than my username) in the passwd file, `id` returns only numeric values, authenticating at the screen saver fails, or whatever. The inability to authenticate in these ways is unsurprising to me if I can’t get through loginwindow most of the time.
I haven’t seen this error after some Googling.
I can, however, kinit as a user fine, so Kerberos appears to be working. Lookups via ldapsearch (as per the WWDC 2006 Advanced Troubleshooting session slides) fail with a binding error, `dscl read` of my username fails, and I can’t simulate a successful login with `dirt,` either.
Both forward and reverse DNS results seem to check out fine for all known domain controllers, not just the two listed in ActiveDirectory.plist. I’m going to try to specify one of the old DCs to see if that makes a difference.
Any ideas? To me, this sounds as if there is some sort of new policy on the new domain controllers, but I no longer have a reliably working client system to see what how secure binding used to work (if it did).
August 21, 2007 at 9:41 pm #369806jndesign22
Participantjaharami,
2000 server AD Domain w/ 2003 schema.
OS 10.4 ClientsI am having the same or a very similar issue. We recently applied new security policies (recomended from MS) on two of our 4 domain controllers. After doing this we are receiving the same gss_unwrap error. We are able to get kerberos ticket.
GSSAPI FAILED doing gss_unwrap:
Secure BIND Session FAILED with server …We may pull back the security updates. If this works I will let you know.
Jasen
August 22, 2007 at 2:53 pm #369812jaharmi
ParticipantWe had rolled out the AD 2003 R2 schema extensions prior to this, and are using Windows Server 2003 R2.
I was only specifically seeing the “error” (quotes because it says “no error” in the text!) when connecting to one of our newer domain controllers. I didn’t see it when I forced a connection (using the preferred DC option in the AD plugin) to one of the older domain controllers.
All of our domain controllers were rolled back to the same security policies as the older ones in the meantime, and that seems to have cleared quite a bit up. I’d like to know what specific policy or set of policies might have been the cause.
August 23, 2007 at 12:25 pm #369830jaharmi
ParticipantYes, we’ve had the R2 schema extensions for a while, so I don’t anticipate it was due to simply having the extended schema. The changes may have been due to further restrictions from the Security Configuration Wizard or another factor; we have yet to determine this in our post-mortem. There were also some problems with the DNS SRV records, which weren’t readily apparent to me but which have been fixed in the interim.
Since we rolled back policies to match the existing domain controllers, things have settled down for Tiger clients. I’ll just drop a number for something else I’ve uncovered: 5429392.
-
AuthorPosts
- You must be logged in to reply to this topic.
Comments are closed