OpenLDAP client unable to authenticate

I am running two machines with FreeBSD 11.0-RELEASE. Machine 1 is running OpenLDAP server and Machine 2 is configured as a client for OpenLDAP. I am trying to make the simplest LDAP server/client setup possible, just to get it working. There is no TLS or SSL required on the server.

My config files on the client macine


/usr/local/etc/openldap/ldap.conf


From here I can run ldapsearch and I get output

Code:
# Casey Smith, people, acme.com
dn: cn=Casey Smith,ou=people,dc=acme,dc=com
objectClass: inetOrgPerson
cn: Casey Smith
cn: Casey
sn: Smith
uid: csmith
mail: casey@acme.com
mail: c.smith@acme.com
ou: sales
userPassword:: e1NTSEF9U1htMXQwVkUwQUtsZklhRDVGdnY3SHFFZElHTi9ZaUw=

# search result
search: 2
result: 0 Success

# numResponses: 8
# numEntries: 7

Does this mean I am connecting just fine so far? My next goal is to use the id and getent tools to see if it's grabbing user stuff from LDAP.


I have openldap-client nss_ldap and pam_ldap installed on the client.

My /usr/local/etc/ldap.conf and /usr/local/etc/nss_ldap.conf are the same file with these settings

Code:
base                   dc=acme,dc=com
uri                   ldap://admin.acme.com

pam_login_attribute     uid

When I run id csmith and getent passwd csmith it returns is no such user. There seems to be no way to tell what is happening when id or getent are ran to see if they are even successfully connecting to LDAP.

What do I have to do to get the client to work?
 
  • Thanks
Reactions: Oko
Might be not relevant but after upgrade from 10.3 to 11 I had to rebuild db5 for openldap, then I saw that Jenkins and Hudson do not authenticate. To fix that I had to replace %20 from base_dn with spaces and use capital letters. A week ealier base_dn was with small letters and %20. Not sure if this was OS , db5 , openldap, jenkins or hudson change. This not affect apache.
 
  • Thanks
Reactions: Oko
SirDice, Yes correct all packages were rebuild, additional step was to make db5.recovery in my case.
 
What do I have to do to get the client to work?

Check binddn and bindpw in /usr/local/etc/ldap.conf or if you are using rootbinddn, check /usr/local/etc/ldap.secret.

On the server side, enable logging so you can see what's happening:

Code:
loglevel 256

Other things to check would be the "access to ..." settings in slapd.conf or in your cn=config.
 
One thing to note if you're searching for LDAP configurations on the internet is that a lot of Linux distributions use -Y EXTERNAL to authenticate with the root account. This doesn't work on FreeBSD without additional configuration. You'll need to enable GSSAPI (which pulls in sasl) for this to work.

Also note that the default config has a very open ACL, as can be witnessed by the LDAP output. Anyone (even unauthenticated users) can read the userPassword property. Good enough for testing but pretty bad for production systems.

After a lot of experimenting I've got something like this:
Code:
include         /usr/local/etc/openldap/schema/core.schema
include         /usr/local/etc/openldap/schema/cosine.schema
include         /usr/local/etc/openldap/schema/inetorgperson.schema
include         /usr/local/etc/openldap/schema/openldap.schema
include         /usr/local/etc/openldap/schema/nis.schema
#include         /root/ldap/kerberos.schema

pidfile         /var/run/openldap/slapd.pid
argsfile        /var/run/openldap/slapd.args

# Load dynamic backend modules:
modulepath      /usr/local/libexec/openldap
moduleload      back_mdb
# moduleload    back_ldap


access to attrs=userPassword,shadowLastChange,krbPrincipalKey 
        by dn.exact="cn=LDAPAdmin,dc=dicelan,dc=home" write
        by anonymous auth
        by self write
        by * none

access to dn.base=""
        by * read

# Providing access to realm container
#access to dn.subtree= "cn=DICELAN.HOME,cn=krbcontainer,dc=dicelan,dc=home"
    #by dn.exact="cn=kdc-service,dc=example,dc=com" read
    #by dn.exact="cn=adm-service,dc=example,dc=com" write
    #by * none

# Providing access to principals, if not underneath realm container
#access to dn.subtree= "ou=users,dc=example,dc=com"
    #by dn.exact="cn=kdc-service,dc=example,dc=com" read
    #by dn.exact="cn=adm-service,dc=example,dc=com" write
    #by * none

access to *
        by dn.exact="cn=LDAPAdmin,dc=dicelan,dc=home" write
        by * read
#######################################################################
# MDB database definitions
#######################################################################

database        config
rootdn          "cn=root,cn=config"
rootpw          secret

access to *
        by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth write
        by * read
        by anonymous none

database        mdb
maxsize         1073741824
suffix          "dc=dicelan,dc=home"
rootdn          "cn=LDAPAdmin,dc=dicelan,dc=home"
rootpw          secret
directory       /var/db/openldap-data

# Indices to maintain
index   objectClass             eq
index   cn                      pres,sub,eq
index   sn                      pres,sub,eq
index   uid                     pres,sub,eq
index   displayName             pres,sub,eq
index   default                 sub
index   uidNumber               eq
index   gidNumber               eq
index   mail,givenName          eq,subinitial
index   dc                      eq
index   krbPrincipalName        eq,pres,sub
As you can see I'm trying to set up Kerberos with an LDAP backend. It's by no means complete, I haven't gotten it to work as I want it yet, but it might provide some examples.

I configure it using slapd.conf as it's easier to do. I then delete everything and convert the config to the 'new' cn=config style:
slaptest -f /usr/local/etc/openldap/slapd.conf -F /usr/local/etc/openldap/slapd.d/
 
Check binddn and bindpw in /usr/local/etc/ldap.conf or if you are using rootbinddn, check /usr/local/etc/ldap.secret.

On the server side, enable logging so you can see what's happening:

Code:
loglevel 256

Other things to check would be the "access to ..." settings in slapd.conf or in your cn=config.

What is the difference in using binddn or rootbinddn? Is this choice based on what is in my slapd.conf on the server?

My slapd.conf is very basic and simple and I just added the loglevel 256 line.

Code:
database        mdb
maxsize         1073741824
suffix          "dc=acme,dc=com"
rootdn          "cn=admin,dc=acme,dc=com"
rootpw         secret
loglevel 256
 
As you can see I'm trying to set up Kerberos with an LDAP backend. It's by no means complete, I haven't gotten it to work as I want it yet, but it might provide some examples.

I configure it using slapd.conf as it's easier to do. I then delete everything and convert the config to the 'new' cn=config style:
slaptest -f /usr/local/etc/openldap/slapd.conf -F /usr/local/etc/openldap/slapd.d/

Do you have a working example of just a basic ldap server/client config without kerberos? I'm dying for just a basic set of config files on each side to see what the minimum needed is to make it working. I don't know what the client side ldap.confs need to auth.
 
Nothing workable yet, it's mostly just notes and things I tried.

I don't know what the client side ldap.confs need to auth.
That depends on how you set things up, the most basic configuration doesn't require any authentication to read from the LDAP server. So you don't need to set binddn. The idea behind binddn is that anonymous readers don't have access, for LDAP to work, getting the IDs for example, some level of read-access is required. This is where the binddn comes in. It's basically a simple account with read-access to the LDAP directory.
 
I have an awesome document and script for OpenLDAP Setup and Configuration with TSL Encrypted N-Way Multi-Master Replication Services, rfc2307bis.schema, MemberOf, Samba, PasswordPolicy, Profiles, etc... It's not simple and probably would not help if I just gave it to you or posted it here, that, and I'd have to support it! :eek: It's not ready for release anyway.

Have you dug deep into the Zytrax OpenLDAP for Rocket Scientists website? I think that is the best site to get started with OpenLDAP.
 
Back
Top