Remote Binding error -14102

Question

Level 1

0 points

Remote Binding error -14102

I'm trying to bind to my Open Directory Server with Directory Utility and get the following error:

Unable to add server: An unexpected error of type -14102 (eDSAuthNoAuthServerFound) occured.

My client Mac is running 10.5.4 and the Open Directory Server is running 10.5.4 Mac OS X Server. I don't have the firewall services running on the client or server.

I have the server setup to require authentication for binding and I get prompted for the directory admin username and password so I'm able to click the Bind button to start the process. The last message I see before I get the error is "Attempting to bind..."

Any ideas what the cause is?

Thanks.

MacBook Pro, Mac OS X (10.5.4)

Posted on Sep 1, 2008 9:28 PM

Reply

Answer 1

Sep 2, 2008 5:35 AM in response to Macfreqk

Are you sure all of the Open Directory services are running? In Server Admin, select the Open Directory service and view the Overview tab. All all services listed as running? Under 10.5.4 I've seen some failures. If it is a critical failure (look in system log), then the easiest solution is to destroy the OD master and recreated it. Then perform consistent backups.

If they are all running, then start with the basics. Is DNS set up properly? Is time synchronized between client and server? Are the services reachable via telnet from the client.

Hope this helps

Reply

Answer 2

Macfreqk Author

Level 1

0 points

Sep 2, 2008 11:33 AM in response to Strontium90

All the services in the Overview tab show that they are running.
I think DNS is setup properly. The server is running DNS services and has entries for all internal machines defined, including the server itself. So when I do an nslookup forward and backward, the server resolves itself. Now this is the case when I'm on the intranet. But in this case I'm on the Internet and my server name which is the same as the realm resolves to an external (router) IP address. Is that going to matter?

The time is being synced with time.apple.com for the client and the server. And I used telent to test ports 389 and 636. Eventually I want to get this to work with SSH. Are there other ports I can test?

Thanks for the help.

Reply

Answer 3

Sep 2, 2008 11:45 AM in response to Macfreqk

Based on your reply it appears that everything is proper. So, I suggest the following two things:

1: On the client, navigate to /Library/Preferences/ and find the folder DirectoryService. Move the entire folder to the Trash and then reboot the machine. When the machine comes back up, run from Terminal the command dscacheutil -flushcache Now try binding again.

2: If this still fails, then quit all applications and open Terminal. In Terminal type: sudo killall -USR1 DirectoryService
This will restart DS with debug logging enabled. A new log file will be created in /Library/Logs/DirectoryService called DirectoryService.debug.log. With debug logging running, try binding again. Find the error entries in the log and post them. To get DS out of debug logging, simply repeat the sudo killall -USR1 DirectoryService command.

Hope this helps

Reply

Answer 4

Macfreqk Author

Level 1

0 points

Sep 2, 2008 2:04 PM in response to Strontium90

OK, I think we're making progress. I cleared the Preferences folder and when I tried to bind again I got the following pop ups asking for permission to connect to ports on the server:

192.168.1.250 port 3659 (apple-sasl)
192.168.1.250 port 106 (3com-tsmux)

I think the problem is that the binding process is looking for the internal IP address of the server, which is 92.168.1.250.

The debug log file is REALLY verbose!

I think this is the relevant part:

10186529210822202048226983917041673335794944068018975269832330474808331707 root@studio.sticky.tv:192.168.1.250
2008-09-02 13:43:24 PDT - T[0xB0103000] - CLDAPv3Plugin::DoPasswordServerAuth:
2008-09-02 13:43:24 PDT - T[0xB0103000] - CLDAPv3Plugin: Attempting use of authentication method dsAuthMethodStandard:dsAuthNodeNativeCannotUseClearText
2008-09-02 13:43:24 PDT - T[0xB0103000] - Internal Dispatch, API: dsOpenDirService(), Server Used : DAR : Dir Ref 16777663 : Result code = 0
2008-09-02 13:43:24 PDT - T[0xB0103000] - Client: Requesting dsOpenDirNode with PID = 0, UID = 0, and EUID = 0
2008-09-02 13:43:24 PDT - T[0xB0103000] - Internal Dispatch, API: dsOpenDirNode(), PasswordServer Used : DAC : Dir Ref = 16777663 : Node Name = /PasswordServer/192.168.1.250
2008-09-02 13:43:24 PDT - T[0xB0103000] - CPSPlugIn::OpenDirNode path = /PasswordServer/192.168.1.250
2008-09-02 13:43:24 PDT - T[0xB0103000] - Internal Dispatch, API: dsOpenDirNode(), PasswordServer Used : DAR : Dir Ref = 16777663 : Node Ref = 16777664 : Result code = 0
2008-09-02 13:43:24 PDT - T[0xB0103000] - Internal Dispatch, API: dsDoPlugInCustomCall(), PasswordServer Used : DAC : Node Ref = 16777664 : Request Code = 1
2008-09-02 13:43:24 PDT - T[0xB0103000] - CPSPlugIn::DoPlugInCustomCall
2008-09-02 13:43:24 PDT - T[0xB0103000] - Internal Dispatch, API: dsDoPlugInCustomCall(), PasswordServer Used : DAR : Node Ref = 16777664 : Request Code = 1 : Result code = 0
2008-09-02 13:43:24 PDT - T[0xB0103000] - Internal Dispatch, API: dsDoDirNodeAuth(), PasswordServer Used : DAC : Node Ref = 16777664 : User Name = 0x00000000000000000000000000000001,1024 35 1371481133196407172068157173707822691739946189504983817477149548372898290402964 73380436237113078883103286005374351249303628070014230620445900000710823333070734 43060327875609914446905357372656065802273546724199486727736059469517224468581018 6529210822202048226983917041673335794944068018975269832330474808331707 root@studio.sticky.tv : Auth Method = dsAuthMethodStandard:dsAuthNodeNativeCannotUseClearText : Auth Only Flag = 0 : Continue Data = 0
2008-09-02 13:43:24 PDT - T[0xB0103000] - PasswordServer PlugIn: Attempting use of authentication method dsAuthMethodStandard:dsAuthNodeNativeCannotUseClearText
2008-09-02 13:43:24 PDT - T[0xB0103000] - GetAuthMethodConstant siResult=0, uiAuthMethod=1229, mech=
2008-09-02 13:43:24 PDT - T[0xB0103000] - hexHash=3C0F86E0CB452847F4E8FDAE68A683D9
2008-09-02 13:43:24 PDT - T[0xB0103000] - CPSPlugIn::HandleFirstContact: trying LDAP Hint
2008-09-02 13:43:24 PDT - T[0xB0103000] - CPSPlugIn::HandleFirstContact: could not find entry for LDAP hint (ip = 216.210.230.35)
2008-09-02 13:43:24 PDT - T[0xB0103000] - CPSPlugIn::HandleFirstContact: trying .local file
2008-09-02 13:43:24 PDT - T[0xB0103000] - CPSPlugIn::HandleFirstContact: trying config record
2008-09-02 13:43:24 PDT - T[0xB0103000] - CPSPlugIn::HandleFirstContact: trying passwordserver's file
2008-09-02 13:43:24 PDT - T[0xB0103000] - CPSPlugIn::HandleFirstContact: trying bonjour
2008-09-02 13:43:24 PDT - T[0xB0103000] - CPSPlugIn::HandleFirstContact: trying node IP (192.168.1.250)
2008-09-02 13:43:25 PDT - T[0xB0103000] - CPSPlugIn::HandleFirstContact: trying localhost
2008-09-02 13:43:26 PDT - T[0xB0103000] - CPSPlugIn::DoAuthentication returning -14102
2008-09-02 13:43:26 PDT - T[0xB0103000] - Internal Dispatch, API: dsDoDirNodeAuth(), PasswordServer Used : DAR : Node Ref = 16777664 : Result code = -14102
2008-09-02 13:43:26 PDT - T[0xB0103000] - Plug-in call "dsDoDirNodeAuth()" failed with error = -14102.
2008-09-02 13:43:26 PDT - T[0xB0103000] - Port: 0 Call: dsDoDirNodeAuth() == -14102
2008-09-02 13:43:26 PDT - T[0xB0103000] - Internal Dispatch, API: dsDoDirNodeAuth(), LDAPv3 Used : DAR : Node Ref = 16777658 : Result code = -14102
2008-09-02 13:43:26 PDT - T[0xB0103000] - Plug-in call "dsDoDirNodeAuth()" failed with error = -14102.
2008-09-02 13:43:26 PDT - T[0xB0103000] - Port: 0 Call: dsDoDirNodeAuth() == -14102
2008-09-02 13:43:26 PDT - T[0xB0103000] - CLDAPv3Plugin: Bind Request - Unable to authenticate as provided user - diradmin
2008-09-02 13:43:26 PDT - T[0xB0103000] - Internal Dispatch, API: dsCloseDirNode(), PasswordServer Used : DAC : Node Ref = 16777664
2008-09-02 13:43:26 PDT - T[0xB0103000] - Internal Dispatch, API: dsCloseDirNode(), PasswordServer Used : DAR : Node Ref = 16777664 : Result code = 0
2008-09-02 13:43:26 PDT - T[0xB0103000] - Internal Dispatch, API: dsCloseDirService(), Server Used : DAC : Dir Ref 16777663
2008-09-02 13:43:26 PDT - T[0xB0103000] - Internal Dispatch, API: dsCloseDirService(), Server Used : DAR : Dir Ref 16777663 : Result code = 0
2008-09-02 13:43:26 PDT - T[0xB0103000] - Internal Dispatch, API: dsCloseDirNode(), LDAPv3 Used : DAC : Node Ref = 16777658
2008-09-02 13:43:26 PDT - T[0xB0103000] - Internal Dispatch, API: dsCloseDirNode(), LDAPv3 Used : DAR : Node Ref = 16777658 : Result code = 0
2008-09-02 13:43:26 PDT - T[0xB0103000] - Internal Dispatch, API: dsCloseDirService(), Server Used : DAC : Dir Ref 16777657
2008-09-02 13:43:26 PDT - T[0xB0103000] - Internal Dispatch, API: dsCloseDirService(), Server Used : DAR : Dir Ref 16777657 : Result code = 0
2008-09-02 13:43:26 PDT - T[0xB0103000] - CLDAPv3Configs::WriteXMLConfig - Have written the LDAP XML config file
2008-09-02 13:43:26 PDT - T[0xB0103000] - CCachePlugin::EmptyCacheEntryType - Request to empty all types - Flushing the cache
2008-09-02 13:43:26 PDT - T[0xB0103000] - Unregistered node /LDAPv3/studio.sticky.tv
2008-09-02 13:43:26 PDT - T[0xB0103000] - CLDAPv3Configs::InitializeWithXML - Removing config for node studio.sticky.tv - 1C2029E4-4BA8-4BFC-850A-131707314648
2008-09-02 13:43:26 PDT - T[0xB0103000] - CLDAPv3Configs::InitializeWithXML - Have successfully added or updated Node configurations
2008-09-02 13:43:26 PDT - T[0xB0103000] - LDAPv3::Initialize completed posting event to allow requests

There is mention of authentication attempt with ...CannotUseClearText method. I didn't disable clear text passwords in the Security section of the Policy/Binding section for Open Directory in Server Admin. I do have SSL enabled in the Secure Sockets Layer (SSL) item in the LDAP tab for the Open Directory service in Server Admin. But I did not select the checkbox to bind to the server with SSL. Could that cause the auth problem?

Reply

Answer 5

Sep 2, 2008 5:36 PM in response to Macfreqk

Ok. So I think I see the problem, or perhaps two.

You have a server that on the LAN is at 192.168.1.250.
This server appears to have the fully qualified domain name of studio.sticky.tv
You've also provided a public address of 216.210.230.35 which I assume is through a NAT, not on the second ethernet interface.
Your client workstation has the software firewall enabled.

First, you might want to simply disable the firewall on the client. I do not this it is that simple. The toggling of name resolution is likely the problem.

Based on this, my guess is that your client is resolving to an external DNS server and getting the public address. Thus, from the client, when performing nslookup studio.sticky.tv you are getting the public address.

You need to modify this and allow access to the internal DNS server so that resolution of the fully qualified domain will resolve to 192.168.1.250. Thus, a client on your LAN should be able to perform an nslookup studio.sticky.tv and get 192.168.1.250 and then an nslookup 192.168.1.250 and get 250.1.168.192.in-addr.arpa name = studio.sticky.tv.

Assuming that DNS is configured on the server, simply put the IP address of the server as the primary name resolver in the Network config of the client, or more efficiently, distribute it via DHCP to all clients.

Next, on the server, confirm that everything is correct by running the following command: sudo changeip -checkhostname. If the results return anything other than "The names match. There is nothing to change." than you have a problem on the server that needs to be resolved.

Ok, that was a little scattered but getting the resolution solid should be the trick. Oh, and you should not worry about the cleartext message. If I recall, that shows up in all bind attempts.

Again, hope this helps.

Reply

Answer 6

Macfreqk Author

Level 1

0 points

Sep 3, 2008 12:07 AM in response to Strontium90

The sudo changeip -checkhostname returned that the names matched, so it looks like the server's DNS is configured correctly. I tried adding the server to client's DNS resolution path by adding it as one of the DNS servers, but this didn't help because the internal IP address of the server is not reachable from the Internet.
I did try changing a setting in Server Admin though. I went to the Open Directory service, Policy, Binding section and disabled the "Require authenticated binding between directory and clients" but made sure the "Enable authenticated directory binding" was till checked.
When I tried to bind again, I didn't get the authentication prompt for the directory administrator username and password, but the binding was successful.

This is nice that the binding was successful, but I don't want anyone able to bind. How can I get the authentication to work. Is the cleartext password a problem after all?

Reply

Answer 7

davidh

Level 4

1,896 points

Sep 3, 2008 3:27 AM in response to Macfreqk

You're trying to bind clients that are outside your private network ? Well...

It's standard practice not to allow traffic from external addresses, in to a company (private) network except via VPN, in terms of security policy/-ies.

Hhave you given thought to network outages, and the likelihood of extremely high latency which will be beyond your means to control or do anything about.

You'd better get SSL setup to protect that traffic
http://www.afp548.com/article.php?story=20071203011158936

Reply

Answer 8

Macfreqk Author

Level 1

0 points

Sep 3, 2008 9:11 PM in response to davidh

I agree, I think a VPN is a better solutions here to allow access to the internal network directly. If I have a VPN do I need to setup SSL too, doesn't the VPN encrypt the traffic anyway?

Reply