Project

General

Profile

Bug #3251

nsswitch.ldap should use DNS for hosts and ipnodes

Added by Piotr Jasiukajtis about 8 years ago. Updated about 8 years ago.

Status:
Closed
Priority:
Low
Assignee:
Category:
system data
Start date:
2012-10-02
Due date:
% Done:

0%

Estimated time:
Difficulty:
Bite-size
Tags:
Gerrit CR:

Description

Nsswitch.ldap should use DNS for hosts and ipnodes these days.
Without that 'ldapclient init/manual' in most cases just fails because it can't find the LDAP server.

#1

Updated by Milan Jurik about 8 years ago

  • Status changed from New to Feedback

Why should it fail? I am pretty sure it finds LDAP server if called correctly, I used it too many times in last years.

nsswitch.ldap is LDAP example. ldapclient does not deal with resolv.conf and it should not play with it.

#2

Updated by Paul Henson about 8 years ago

Who stores host info in ldap 8-/?

I agree with the original comment. ldapclient overwrites nsswitch.conf with nsswitch.ldap, which points hosts lookups to ldap, and then it can't find the IP of the ldap server you provided to the ldapclient command line :(.

Actually, better yet, ldapclient shouldn't muck around with nsswitch.conf at all... It's quite unintuitive. The whole ldapclient binary to set up a config is annoying too. I just copy in /var/ldap/ldap_client_file with the right config, give me a plain text file config over an opaque binary to run any day.

#3

Updated by Milan Jurik about 8 years ago

Some bigger are doing so, even these days. Usually they add DNS after LDAP backend.

It was very common to use IP address of LDAP server in ldapclient initialization. Yes, with SSL it can be chickend and egg problem and you need to prepare environment. But as you wrote, you are doing so anyway.

ldapclient is doing slightly more than just creating some file and moving files around. It is not ideal tool and it can be improved/replaced but I do not understand what's opaque on ldapclient in verbose mode.

The problem with adding DNS to nsswitch.ldap is that it does not solve the problem, because ldapclient will not setup DNS for you. You have to do it manually anyway.

And in real environment you need to review nsswitch.ldap/nsswitch.conf and set every line per your own setup to have it optimal.

#4

Updated by Piotr Jasiukajtis about 8 years ago

Milan Jurik wrote:

Why should it fail? I am pretty sure it finds LDAP server if called correctly, I used it too many times in last years.

nsswitch.ldap is LDAP example. ldapclient does not deal with resolv.conf and it should not play with it.

ldapclient replaces nsswitch.conf with nsswitch.ldap and it fails every time you use DNS name of LDAP server. I'm OK with ldap entries with nsswitch.ldap, but we should add DNS also.

#5

Updated by Milan Jurik about 8 years ago

Piotr Jasiukajtis wrote:

ldapclient replaces nsswitch.conf with nsswitch.ldap and it fails every time you use DNS name of LDAP server. I'm OK with ldap entries with nsswitch.ldap, but we should add DNS also.

No, it does not fail if you add the name to local hosts/ipnodes where it belongs. Or do you want to say that you depend on DNS server to be able to resolve your critical naming server?

No, we should not add DNS there by default.

#6

Updated by Paul Henson about 8 years ago

Actually, yes, I do depend on dns to resolve the IP of my ldap server. I would think most people do. The only service my boxes use a hardcoded IP to access is, well, dns.

You said "you need to review nsswitch.ldap/nsswitch.conf and set every line per your own setup", which I agree with. Then rather than copying over the sample nsswitch.ldap (which perhaps writes over the already customized nsswitch config), ldapclient should just leave it alone and let the user edit it themselves?

#7

Updated by Milan Jurik about 8 years ago

  • Status changed from Feedback to Closed
  • Assignee set to Milan Jurik
  • Tags deleted (needs-triage)

Paul Henson wrote:

Actually, yes, I do depend on dns to resolve the IP of my ldap server. I would think most people do. The only service my boxes use a hardcoded IP to access is, well, dns.

Then your system is misconfigured from security point of view. You are leaving your system depending on insecure DNS protocol and through this you give attacker chance to add naming data (e.g. passwd database) to the system. Fix your configuration.

You said "you need to review nsswitch.ldap/nsswitch.conf and set every line per your own setup", which I agree with. Then rather than copying over the sample nsswitch.ldap (which perhaps writes over the already customized nsswitch config), ldapclient should just leave it alone and let the user edit it themselves?

No, because after ldapclient the system is configured as Native LDAP client, with all services set for it. Read documentation before you shoot youself. You can modify nsswitch.ldap before ldapclient is executed, if you really need it.

ypinit and nisinit are doing the same thing here.

#8

Updated by Paul Henson about 8 years ago

It seems we will just have to agree to disagree regarding the design of the Solaris/illumos LDAP naming services integration.

However, I will point out that SSL is configured for access to the LDAP server, providing strong cryptographic authentication of the data coming from it. Which is considerably more secure than simply hardcoding an IP address. So no, my configuration is not broken.

#9

Updated by Milan Jurik about 8 years ago

Paul Henson wrote:

It seems we will just have to agree to disagree regarding the design of the Solaris/illumos LDAP naming services integration.

However, I will point out that SSL is configured for access to the LDAP server, providing strong cryptographic authentication of the data coming from it. Which is considerably more secure than simply hardcoding an IP address. So no, my configuration is not broken.

In case you are distributing server public certificate to your client system, then it should not be big deal to add even critical IP record to the local file, should it?

Keep it simple by default.

Also available in: Atom PDF