DSCL works to 127.0.0.1 but not to machine's IP

Question

DSCL works to 127.0.0.1 but not to machine's IP

I'm running into a weird problem. Running Mac OS 10.8.5 with Server.app version 2.2.2 (I have not yet managed to get anything newer to work at all) On my main server, call it MachineA, I can run the command:

/usr/bin/dscl /LDAPv3/ldap://127.0.0.1 list /Users GeneratedUID

And it works as expected, returning a list of users and their GeneratedUID. However, if I replace the 127.0.0.1 with the IP of the machine (or host name) - as would be needed to run this command from a remote machine - I get a "Data source is not valid" error. I get the same error when trying to run this command against this host from a remote machine as well. Using an LDAP browser, however, does work, so I know LDAP at least is listening properly. How can I fix this?

Posted on Sep 7, 2015 9:40 AM

Reply

Answer 1

UptimeJeff

Level 4

3,479 points

Sep 7, 2015 12:06 PM in response to Israel Brewster

You connect to the remote host/IP (10.5.5.5) then list the Path as it would be on that machine.

User and PW are required unless the node is local.

dscl -u diradmin -p 10.5.5.5 list /Search/Userså

dscl -u diradmin -p 10.5.5.5 list /LDAPv3/127.0.0.1/Users

man dscl

If the hostname or IP address form is used then the user must specify the -u option and either the -P of -p options to specify an administrative user and password on the remote host to authenticate with to the remote host. The exception to this is if "localhost" is specified.

In the case of specifying a host as a data source, the top level of paths correspond to Open Directory plug-ins and Search Paths. One can specify the plug-in to traverse to a node name, after which the paths are equivalent to the former usage. The following might be the equivalent paths as the above paths:

/NetInfo/root/Users/alice

/LDAPv3/10.0.1.42/Groups/admin

Hope that helps

Reply

Answer 2

Sep 7, 2015 12:18 PM in response to UptimeJeff

Thanks, but neither of those forms appears to work at all: after asking for my password, it just sits there for thirty seconds or so before saying "Cannot open remote host, error: DSOpenDirServiceErr".

Additionally, if I try on a different, identical (carbon-copy cloner identical, then rename and re-ip), machine (let's call this one MachineB), both of the following forms work as expected:

/usr/bin/dscl /LDAPv3/ldap://127.0.0.1 list /Users GeneratedUID

/usr/bin/dscl /LDAPv3/ldap://<MachineB> list /Users GeneratedUID

Also, if I am on MachineA, I can query MachineB just fine using the following:

/usr/bin/dscl /LDAPv3/ldap://<MachineB> list /Users GeneratedUID

Which would seem to refute what the man dscl page you have says (maybe that page is from a newer version of dscl?). But from MachineB, I CAN NOT query MachineA using "/usr/bin/dscl /LDAPv3/ldap://<MachineA> list /Users GeneratedUID": It just gives me the "Data source is not valid" error.

So given the behavior on MachineB, it seems that it *should* work, but something is messed up on MachineA that is preventing it from working.

Reply

Answer 3

MrHoffman

Level 10

146,407 points

Sep 7, 2015 2:07 PM in response to Israel Brewster

IP address 127.0.0.1 is the local host loopback address. Technically, anything from 127.0.0.1 to 127.255.255.254. It's the current host. Always. The loopback always works.

Specifying one of the many host IP addresses that might be assigned to the host — because of the way Ethernet works — only operates as expected if something detects and loops back outbound traffic for the IP address and does not try to send the packet onto the Ethernet, or some other controller. This because a typical Ethernet controller can either listen for a packet addressed for the local host, or can transmit data to another host, but cannot perform both tasks at the same time.

In short, if you try to specify the IP address of the local host and not the 127.0.0.1 loopback address, you'll find it won't work reliably.

DNS servers often see this particular case, if the DNS server is using itself to resolve DNS translations, too.

Reply

Answer 4

Sep 7, 2015 2:32 PM in response to MrHoffman

Thanks for that explanation. However, it doesn't address the evidence as presented. To reiterate:

- When I am on MachineB, I CAN access the directory by using the command "/usr/bin/dscl /LDAPv3/ldap://<MachineB> list /Users GeneratedUID".

- I can NOT access MachineA from MachineB by using the command "/usr/bin/dscl /LDAPv3/ldap://<MachineA> list /Users GeneratedUID" on MachineB.

- I CAN access MachineB from MachineA by using the command "/usr/bin/dscl /LDAPv3/ldap://<MachineB> list /Users GeneratedUID" on MachineA

So the evidence would suggest that, in general, you CAN reliably call the dscl command against the local machine by using the IP address of the machine (rather than 127.0.0.1) - just not on my MachineA. Experience (including with DNS servers) would support this as well - I have never been unable to access a machine by using its own IP address. Also, the evidence says that you should be able to access a remote system by putting in its IP address - again, as long as that remote system isn't my MachineA.

To put it another way, the problem is that I can get a response from MachineA on dscl only if I run it on MachineA using the loopback address - anything else, whether run on MachineA or some remote machine pointed at MachineA gives me the "Data source is not valid" error.

Reply

Answer 5

MrHoffman

Level 10

146,407 points

Sep 7, 2015 5:11 PM in response to Israel Brewster

Have you tested IP connectivity directly; not via dscl?

How many network interface controllers are present and active in the boxes, and is there anything complex here such as multiple NICs or NAT?

If you have multiple controllers present, are the connected networks using different subnets?

If neither of the above point to an answer, post the dscl commands that work and the commands that don't with the IP addresses that do and do not, for each server. I'm having some difficulty (obviously) following through all the A and B nomenclature and what works and what does not work.

Reply

Answer 6

Sep 8, 2015 9:17 AM in response to MrHoffman

Yeah, I've never been terribly good at phrasing questions like this. Thanks for bearing with me.

- Yes, IP connectivity is fine - I can ping, ssh, web, etc both ways just fine.

- Both boxes are Mac Minis, 2.0 GHz Core i7 running 10.8.5 and server 2.2.2. As such, they both have both Ethernet and WiFi interfaces, although only the ethernet is used.

- No NAT, but the boxes are in different subnets. That said, the behavior doesn't appear to be due to this.

- Both machines are running OpenDirectory with around 400 users. The directory was set up on MachineA, then archived and restored on MachineB

So, to lay out the problem, hopefully more succinctly:

MachineA:

- IP Address 10.9.1.92

MachineB:

- IP Address 192.168.10.92

Commands that work on MachineB:

- /usr/bin/dscl /LDAPv3/ldap://192.168.10.92 list /Users GeneratedUID (access self using interface IP, also works from any other machine I test on)

- /usr/bin/dscl /LDAPv3/ldap://127.0.0.1 list /Users GeneratedUID (access self using loopback)

- Ping/SSH/http/etc 10.9.1.92 (general IP connectivity to MachineA using interface IP)

Commands that work on MachineA:

- /usr/bin/dscl /LDAPv3/ldap://127.0.0.1 list /Users GeneratedUID (access self using loopback)

- /usr/bin/dscl /LDAPv3/ldap://192.168.10.92 list /Users GeneratedUID (access other machine using interface IP)

- Ping/SSH/http/etc 10.9.1.92 (general IP connectivity to self using interface IP)

Commands that do not work anywhere:

- /usr/bin/dscl /LDAPv3/ldap://10.9.1.92 list /Users GeneratedUID (access MachineA using interface IP)

So, basically, I can access MachineB via dscl (192.168.10.92) from anywhere (including itself) using the 192.168.10.92 IP address. MachineA, however, I can not access via dscl via anything other than the loopback address.

One more thing: I CAN connect a basic LDAP browser or use LDAP authentication against 10.9.1.92 (MachineA) from anywhere. It's just the Open-Directory specific things (like dscl) that fail.

Hopefully this helps clarify the situation. Thanks again for bearing with me!

Reply

Answer 7

MrHoffman

Level 10

146,407 points

Sep 8, 2015 2:19 PM in response to Israel Brewster

Okay, so IP subnet routing is in play here, in two different private blocks. That complicates things slightly.

Do the forward and reverse DNS translations associated with both IP addresses work from both hosts?

Are the IP network paths through the network open for either unencrypted or encrypted path via the IP router, and for whichever Open Directory ports you're using? (TCP 389 and TCP 636 for SSL/TLS, IIRC.)

Use the OpenSSL s_client tool to test the SSL/TLS path. (The unencrypted path is preferably not in use.)

(Given there are certificates in use with many LDAP configurations, access can be blocked when the certificates and the DNS mismatch. Access should be blocked, too.)

Reply

Answer 8

Sep 8, 2015 3:06 PM in response to MrHoffman

Looks like I got it figured out. In Directory Utility, Directory Editor, under the Config section of the directory, there is an entry for "ldapreplicas". That entry had some old IP addresses in it. Once I fixed the IP address in that record, all commands started working as expected. Thanks for the suggestions!

Reply