Home › Forums › OS X Server and Client Discussion › Active Directory › Active Directory Binding (PMMUC Error -14006)
- This topic has 16 replies, 6 voices, and was last updated 18 years, 4 months ago by
afp548contributor.
-
AuthorPosts
-
October 18, 2005 at 8:25 pm #363690
cobra
ParticipantI have successfully bound to my domain controller with no problem. Been running for 2 weeks now. All of a sudden when I go into WM to select the Active Directory I get this error:
Error of type eDSCannotAccessSession (-14006) on
line 3178 of /SourceCache/serverManagerApp/
ServerManagerApp-230.1.1/PMMUCGMainView.mmAnyone have any ideas, thanks Wayne.
December 14, 2005 at 12:01 am #364411Anonymous
GuestI just started getting the same error after I tried to set Open Directory as connected to a Directory System. It attempt failed and now all attempts to authenticate to A/D fail with the error you reported. I’ve restarted the server, repaired permissions, tried to authenticate from a different admin account on the same machine. Nothing changes.
January 19, 2006 at 12:07 am #364824Anonymous
GuestSame basic problem here. Can bind server to AD, but after a day or two it looses its mind. Afterwhich WGM can no longer see AD user or group list, windows users can no longer access smb shares due to failed authentication. Running 10.4.4 on XServe G5. This server has no OD, no direct logins, it is only a fileserver for smb and nfs shares.
When I put DirectoryService in debug mode and run dscl interactive, all is well until I get into my AD/domain/users/ directory and try to do an ls. At this point it reports “eDSCannotAccessSession” error and the debug log shows:
– Client: dscl, PID: 18895, API: dsFindDirNodes(), Server Used : DAR : 1 : Dir Ref = 16779721 : Requested nodename = /Active Directory/primarion.com/Users
– Client: dscl, PID: 18895, API: dsFindDirNodes(), Server Used : DAR : 2 : Dir Ref = 16779721 : Result code = -14008then
– ADPlugin: Calling GetRecordList
– ADPlugin: 16779863 – Calling GetRecordList Routine
– ADPlugin: Search Records called in ADSWrapper
– ADPlugin: Searching attribute: dsAttrTypeStandard:RecordName
– ADPlugin: Doing an Attribute = kDSRecordAll Search, setting cn=*
– ADPlugin: Did DC search with queryFilter = (&(objectCategory=cn=person,cn=schema,cn=configuration,dc=primarion,dc=com)(cn=*)), limit 0
– Client: servermgrd, PID: 49, API: dsOpenDirService(), Server Used : DAR : Dir Ref 16779869 : Result code = 0
– ADPlugin: Failed getting credentials at line 2687 in ADSEngine.mm
– ADPlugin: 16779863 – Put 0 records in Buffer for RecordList
– Client: dscl, PID: 18895, API: dsGetRecordList(), Active Directory Used : DAR : Node Ref = 16779863 : Number of Found Records = 0 : Continue Data = 0 : Result code = -14006
– Plug-in call “dsGetRecordList()” failed with error = -14006.kinit username, followed by password of a windows user produces no error.
Hope someone can help….
Rob
February 9, 2006 at 1:09 am #365233Anonymous
GuestI’ve encountered the same problem with my setup. Has anyone found a solution to it yet?
February 14, 2006 at 4:55 pm #365317pme
ParticipantThis seems like the same problem as we have. Two of our seven Xserve (10.4.3 and 10.4.4) occasionally gets kicked out from the AD. Only way to get them back in is to unbind+bind.
When we look in the error log of our AD servers we se the following:
[QUOTE]The session setup from computer ‘ServerName’ failed because the security database does not contain a trust account ‘ServerName$’ referenced by the specified computer. [/QUOTE]On the OSXS side the DirectoryService logs doesn’t show any abnormalities during the failure. (one of my old DS debug logs shows however the same error)
The AppleFileService log shows:
IP xx.xx.xx.xx - - [12/Feb/2006:04:56:13 0100] "Logout user" -5023 0 0 IP xx.xx.xx.xx - - [12/Feb/2006:04:56:21 0100] "Logout user" -5023 0 0 **** - - [12/Feb/2006:04:56:21 0100] "<D> user" 8719 13404 0 **** - - [12/Feb/2006:04:56:21 0100] "<D> user" 11831 13404 0 **** - - [12/Feb/2006:04:56:21 0100] "<D> user" 12039 13404 0 **** - - [12/Feb/2006:04:56:21 0100] "<D> user" 12701 13404 0 **** - - [12/Feb/2006:04:56:21 0100] "<D> user" 12807 13404 0 **** - - [12/Feb/2006:04:56:21 0100] "<D> user" 12841 13404 0 [snip] IP xx.xx.xx.xx - - [12/Feb/2006:04:56:21 0100] "Reconnected User: <Guest>" 13985 0 0 IP xx.xx.xx.xx - - [12/Feb/2006:04:56:21 0100] "Logout <Guest>" 0 0 0 IP xx.xx.xx.xx - - [12/Feb/2006:04:58:34 0100] "Login <Guest>" 0 0 0 IP xx.xx.xx.xx - - [12/Feb/2006:04:58:36 0100] "Logout <Guest>" 0 0 0 IP xx.xx.xx.xx - - [12/Feb/2006:04:58:36 0100] "Logout user" -5023 0 0 IP xx.xx.xx.xx - - [12/Feb/2006:04:59:00 0100] "Logout user" -5023 0 0 IP xx.xx.xx.xx - - [12/Feb/2006:05:00:00 0100] "Logout user" -5023 0 0 IP xx.xx.xx.xx - - [12/Feb/2006:05:03:47 0100] "Login <Guest>" 0 0 0 IP xx.xx.xx.xx - - [12/Feb/2006:05:03:49 0100] "Logout <Guest>" 0 0 0 IP xx.xx.xx.xx - - [12/Feb/2006:05:03:50 0100] "Logout user" -5023 0 0 IP xx.xx.xx.xx - - [12/Feb/2006:05:06:54 0100] "Login <Guest>" 0 0 0 IP xx.xx.xx.xx - - [12/Feb/2006:05:06:56 0100] "Logout <Guest>" 0 0 0 IP xx.xx.xx.xx - - [12/Feb/2006:05:06:56 0100] "Session Network Error Disconnect: " 0 0 0 IP xx.xx.xx.xx - - [12/Feb/2006:05:06:56 0100] "Logout user" -5023 0 0 IP xx.xx.xx.xx - - [12/Feb/2006:05:07:52 0100] "Logout user" 0 0 0 IP xx.xx.xx.xx - - [12/Feb/2006:05:14:53 0100] "Logout user" -5023 0 0 IP xx.xx.xx.xx - - [12/Feb/2006:05:20:02 0100] "Logout user" -5023 0 0 IP xx.xx.xx.xx - - [12/Feb/2006:05:40:03 0100] "Logout user" -5023 0 0 IP xx.xx.xx.xx - - [12/Feb/2006:06:00:04 0100] "Logout user" -5023 0 0 IP xx.xx.xx.xx - - [12/Feb/2006:06:20:05 0100] "Logout user" -5023 0 0
As I began, this only affects two out of seven equally installed and configured machines. Our OD is on separate machines (with Kerberos disabled).
The only differences between the failing servers and the working ones are that the failing servers are a little bit more used than the others (100 avarage users logged in, compared to 35 users). And… that the AD DC:s for the failing ones are in a separate “site” than the other AD DC:s. (we’ve contacted M$ to see if there’s a misconfiguration in the AD behind it)/P-M
February 14, 2006 at 5:15 pm #365319pme
Participant[QUOTE BY= macshome] Check the contents of /L/P/edu.mit.kerberos when you are having these auth errors.
Check to see if any ACLs were placed on the AD schema.
When you kinit as a user does it work?[/QUOTE]
I forgot to answer this…
There’s no problem using /S/L/C/Kerberos to get a tgt for an AD user. The only problem (in our case) is that the computer account stops working.
Also, if I only restart DirectoryService it states that it can’t find the closest domain controller for the AD./P-M
March 3, 2006 at 11:00 am #365529pme
ParticipantWe’ve done some more testing and come up to this: The thing that breaks our computer account is the Samba server.
On the troubeling server we’ve had problems getting the Samba server to authenticate using Kerberos. Therefore we’ve set it to use:
security : ntdomainThis setting seems to break the computer account since the AD forces the computer accounts to change password every 7 days (which Samba apparently can’t handle).
/P-M
March 9, 2006 at 5:02 am #365618Anonymous
GuestI had a server that bound. There was an authentication problem so I unbound the server and then it would not rebind.
I actually installed Server 10.4 again and tried same thing. makes it to step 5 and then spins and spins.April 10, 2006 at 7:04 pm #365955tramahound
ParticipantI’m getting the same error with 10.4.4 connected to our AD server. Unbinding and binding again fixes things, but it’s not the most elegant of solutions.
July 31, 2006 at 8:38 pm #366712Anonymous
GuestCheck the date and time of your domain and your server.. AD will only tolerate about +- 5 min
November 27, 2006 at 6:52 pm #367718engelby
ParticipantCan anybody explain this in a pretty simple way (for someone that is not the AD guy). They installed SecureID’s here over thanksgiving break and made changes to our AD schema I believe. We have had a lot of re-binding to do today. As an example, every Mac server had to be unbound/bound. All of our servers have never had the need to be unbound and rebound before until today, and we also had a few (10-15) clients that had to be rebound as well for them to work. We were getting the error -14006 on the servers.
I saw a few times in here, people mentioned using 10.4.4. We are using up to 10.4.7 right now, with some back at 10.4.5. Is this fixed in 10.4.8, or is this something that can always happen when whatever happened, happens.
So if computer accounts need their passwords changed by GPO, this is to be expected? Are there any other reason’s why all our Mac servers (all set as Connected to a Directory System) had to be rebound to AD. And while I know time will tell, but do you think this could just be a 1 time rebinding?
November 27, 2006 at 7:22 pm #367720engelby
ParticipantWell, I guess just as an add-on to above, instead of about 10-15 clients that need to be rebound, it is now looking more like every computer is going to need to be rebound. I know how to do it remotely, but hopefully this is something they could have messed up just one time, instead of it happening weekly or whatever.
-
AuthorPosts
- You must be logged in to reply to this topic.
Comments are closed