# Centralized user authentication with OpenLDAP and PAM

## Koon

-IMPORTANT NOTICE-

This howto was written for an old version of OpenLDAP, DirectoryAdministrator and else. It's awfully deprecated and does not work as is. You should use the (current and maintained) Gentoo Guide to OpenLDAP Authentication instead. If you need help, you should post to the Networking forum. If you find a problem in that (official) doc, please file a Documentation bug. For those that choose to ignore that warning and use this howto, you might find this post interesting, as it details what user weyhan did to have it working.

-IMPORTANT NOTICE-

-----------------------------------------------------------------------------

This setup is useful if you manage multiple systems and want all of them to share the same user/passwords.

Server setup

Install openldap :

```
# emerge openldap
```

Look at what the hostname command returns on your server, and generate a LDAP root password under MD5 form, you will need them later for config files :

```
# hostname

YourLdapServerHostname

# slappasswd -h {MD5}
```

Replace /etc/openldap/slapd.conf with :

```
include         /etc/openldap/schema/core.schema

include         /etc/openldap/schema/cosine.schema

include         /etc/openldap/schema/nis.schema

include         /etc/openldap/schema/inetorgperson.schema

pidfile         /var/run/openldap/slapd.pid

argsfile        /var/run/openldap/slapd.args

 

access to dn=".*,dc=yourcompany,dc=com" attr=userPassword

        by dn="cn=root,dc=yourcompany,dc=com" write

        by self write

        by * auth

access to dn=".*,dc=yourcompany,dc=com"

        by * read

 

TLSCertificateFile      /etc/openldap/ssl/ldap.pem

TLSCertificateKeyFile   /etc/openldap/ssl/ldap.pem

TLSCipherSuite HIGH:+MEDIUM:!LOW

TLSVerifyClient never

                                                                                

database        ldbm

suffix          "dc=yourcompany,dc=com"

rootdn          "cn=root,dc=yourcompany,dc=com"

rootpw          {MD5}PutSlapPasswdOutputHere

directory       /var/lib/openldap-ldbm

index           objectClass,uid,uidNumber,gidNumber   eq

index           cn,surname,givenname                  eq,subinitial
```

Start OpenLDAP and add it to default runlevel :

```
# /etc/init.d/slapd start

# rc-update add slapd default
```

Create the /root/base.ldif file with :

```
dn: dc=yourcompany,dc=com

dc: yourcompany

objectClass: top

objectClass: domain

dn: ou=People,dc=yourcompany,dc=com

ou: People

objectClass: top

objectClass: organizationalUnit

 

dn: ou=Group,dc=yourcompany,dc=com

ou: Group

objectClass: top

objectClass: organizationalUnit
```

Import the /root/base.ldif file in the LDAP server :

```
# ldapadd -x -D "cn=root,dc=yourcompany,dc=com" -W -f /root/base.ldif
```

That's it, your LDAP server is ready (but empty). We will now see how to populate the user base.

LDAP base setup

We will use directoryadministrator which provides an easy interface to create users and groups on the LDAP server. On the admin workstation (doesn't need to be the LDAP server or a client) :

```
# emerge directoryadministrator
```

As of this writing, version 1.5.1 is in ~x86, so to get it :

```
# ACCEPT_KEYWORDS=~x86 emerge directoryadministrator
```

Run directoryadministrator, and setup your profile :

- Check "Enable transport security"

- Search root : dc=yourcompany,dc=com

- DN/User ID : cn=root,dc=yourcompany,dc=com

Go to Preferences :

- Store passwords as an MD5 hash

- DO NOT check "Use the authPassword attribute"

Create a group called users with GID=100

Create users...

See the Notes chapter at the end of this post for advice on how to migrate an existing user base.

Client setup

Install the PAM-LDAP and NSS-LDAP files :

```
# emerge pam_ldap nss_ldap
```

Modify the following lines from /etc/nsswitch.conf to read :

```
passwd:      files ldap

shadow:      files ldap

group:       files ldap
```

Replace your /etc/ldap.conf by the following :

```
host YourLdapServerHostname

base dc=yourcompany,dc=com

scope 1

pam_filter objectclass=posixaccount

pam_login_attribute uid

pam_member_attribute gid

pam_password md5

ssl start_tls
```

Replace the /etc/pam.d/system-auth file by the following :

```
#%PAM-1.0

 

auth       required     /lib/security/pam_env.so

auth       sufficient   /lib/security/pam_unix.so likeauth nullok nodelay

auth       sufficient   /lib/security/pam_ldap.so use_first_pass

auth       required     /lib/security/pam_deny.so

 

account    required     /lib/security/pam_unix.so

account    sufficient   /lib/security/pam_ldap.so

 

password   required     /lib/security/pam_cracklib.so retry=3

password   sufficient   /lib/security/pam_unix.so nullok md5 shadow use_authtok

password   sufficient   /lib/security/pam_ldap.so use_authtok

password   required     /lib/security/pam_deny.so

session    required     /lib/security/pam_mkhomedir.so skel=/etc/skel/ umask=0022

session    required     /lib/security/pam_limits.so

session    required     /lib/security/pam_unix.so

session    optional     /lib/security/pam_ldap.so
```

If you don't want strong password checks, you can use these password lines instead :

```
password   sufficient   /lib/security/pam_unix.so nullok md5 shadow

password   sufficient   /lib/security/pam_ldap.so

password   required     /lib/security/pam_deny.so
```

You should remove the "users" group from /etc/group, since it is already in the LDAP server. You can then test that everything is working correctly by retrieving passwd and group :

```
# getent passwd

# getent group
```

You should see the users group and the LDAP users. If everything is OK, repeat these steps on each client machine, and you're all done.

Notes

Migration of an existing user base

If you don't have too many users, it's simpler to create new LDAP users with same UID and name and remove existing users from /etc/passwd and /etc/shadow on the client machines.

If you have a big user base, you should use PADL migration tools (emerge migrationtools) and the migrate_group.pl and migrate_passwd.pl scripts. You might have to abandon MD5 passwords for Crypt passwords if you want to migrate the passwords also.

The system accounts and groups

You should not migrate system accounts (including the root account) and system groups in the LDAP server. You should keep them in the files, so that you can log in as root if the LDAP server is not working. root password should be different on each machine, anyway  :Wink: 

Hope this helps, WorkedForMe(TM)

- K

History:

* corrected rootpw and base.ldif thanks to snafoo remarks

* corrected the incomplete system-auth file

* added a note on the official Gentoo guide

* removed defaultaccess directive (deprecated as of OpenLDAP 2.1)Last edited by Koon on Wed Jul 21, 2004 4:25 pm; edited 5 times in total

----------

## prophetx2

wow thanks for this, it's exactly what I'm looking for.  I'm going to try this maybe next week when I get my new box =)

----------

## snafoo

some notes: i think the rootpw entry is incorrect, should use output from slappasswd and the base.ldif should contain:

dn: dc=a2t,dc=com

dc: a2t

objectClass: top

objectClass: domain

for your domain obviously  :Smile: 

hope this helps the readers

-snafoo

----------

## Koon

 *snafoo wrote:*   

> some notes: i think the rootpw entry is incorrect, should use output from slappasswd and the base.ldif should contain...

 

Yes, the rootpw probably got caught in my "yourcompany" changes... and the base.ldif file was incomplete. Main post has been edited to correct this.

Thanks for your proofreading ! Yes, it will help  :Wink: 

-K

----------

## El_Presidente_Pufferfish

Hrm...would this  work on a laptop that leaves the network often?

or is this only for computers that are always on the same network?

----------

## Koon

 *El_Presidente_Pufferfish wrote:*   

> Hrm...would this  work on a laptop that leaves the network often?
> 
> or is this only for computers that are always on the same network?

 

It would not work properly... 

In fact, when you lose your network connnection to the LDAP server, the getent calls (which retrieve available users and groups) would no longer find the LDAP-defined users and groups, only the local ones (defined in the usual files). 

What you can do is have local users (defined in the files) and global users (defined in LDAP). Use local users when disconnected, global users when connected. They can even share the same uid/name... you should have "ldap files" rather than "files ldap" in nsswitch.conf so that it finds LDAP users first when connected.

Never tried it though. Centralized user repositories do not play to well with roaming users (password sync can be a problem, I think).

-K

----------

## Koon

The system-auth file in the original post was incomplete (missing the auth, session and account sections).

This has been corrected in the original post.

-K

----------

## StrCrssd

Can you please post an example ldif?  directoryadministrator keeps crashing on me, and I don't know exactly what fields to include in my user ldif files.

----------

## Koon

 *StrCrssd wrote:*   

> Can you please post an example ldif?  directoryadministrator keeps crashing on me, and I don't know exactly what fields to include in my user ldif files.

 

A user entry looks like this :

```
dn: uid=thehulk,ou=People,dc=yourcompany,dc=com

objectClass: organizationalPerson

objectClass: inetOrgPerson

objectClass: account

objectClass: top

objectClass: posixAccount

objectClass: shadowAccount

host: *

uid: thehulk

uidNumber: 1000

gidNumber: 100

givenName: The

sn: Hulk

cn: The Hulk

homeDirectory: /home/thehulk

loginShell: /bin/bash

gecos: The Hulk

userPassword: {MD5}HULKPASSWORD
```

while a group entry looks like this :

```
dn: cn=vmadmin,ou=Group,dc=yourcompany,dc=com

objectClass: top

objectClass: posixGroup

objectClass: groupOfNames

cn: vmadmin

gidNumber: 2002

memberUid: thehulk

member: uid=thehulk,ou=People,dc=yourcompany,dc=com
```

You can also look at the PADL migration tools results, they produce LDIF files from your existing system files.

Maybe there exists a better set of LDAP/PAM related tools out there, but DirectoryAdministrator works fine for me...

-K

----------

## StrCrssd

Wonderful.

I appreciate your help.

----------

## Sasun

The best guide to setup LDAP for user auth is on

http://www.mandrakesecure.net/en/docs/ldap-auth2.php

too bad that the site is down but the google cash is available:

http://216.239.53.104/search?q=cache:5jgAEQWmmaMJ:www.mandrakesecure.net/en/docs/ldap-auth2.php+&hl=en&ie=UTF-8

It is the only guide that is worth reading, and includes details how to migrate and stay compatible with md5 /etc/shadow passwords, how to increase security etc.

----------

## Shizatoga

First I'd like to thank Koon for this great, bumpable, howto. 

To consoladate this information I'll ask my question here. Does anyone know how to set up /etc/pam.d/passwd to change user's passwords in ldap? I've looked around and all the examples I've found don't work, all I get is some form of error complaining about tokens.

----------

## Shizatoga

Apparently upgrading to openldap 2.1 fixed this, go figure.

----------

## adamtheo

I'm reading in the  OpenLDAP config file docs that the following is an acceptable option, and supposedly means a Berkeley DB backend for storing the directory info:

```

database bdb

directory /usr/local/var/openldap-data

```

But the OpenLDAP 2.0.27 documentation only allows "ldbm", "shell", and "passwd" types. I've tried using the "bdb" option in my conf file, and slapd says it cannot find the bdb type. Was wondering if this is a deprecated type, and i should just use ldbm?

And also, why do you use the MD5 method for encrypting passwords rather than SHA or SSHA? Personal preference? Have any reasons for choosing that one?

Thanks.

----------

## adamtheo

Nevermind, I found out the solution to the below problem was to chown the database directory to the ldap user. Thanks anyway.

I have successfully installed and started OpenLDAP so far, but when I get to importing the "/root/base.ldif" file, I get this error:

```

theoretic root # ldapadd -x -D "cn=root,dc=theoretic,dc=com" -W -f /root/base.ldif

Enter LDAP Password: 

adding new entry "ou=users,dc=theoretic,dc=com"

ldap_add: Operations error

ldif_record() = 1

```

Here is an excerpt from my "/etc/openldap/slapd.conf" file:

```

include         /etc/openldap/schema/core.schema

include         /etc/openldap/schema/cosine.schema

include         /etc/openldap/schema/nis.schema

include         /etc/openldap/schema/inetorgperson.schema

pidfile         /var/run/openldap/slapd.pid

argsfile        /var/run/openldap/slapd.args

# Load dynamic backend modules:

# modulepath    /usr/lib/openldap/openldap

# moduleload    back_ldap.la

# moduleload    back_ldbm.la

# moduleload    back_passwd.la

# moduleload    back_shell.la

access to dn=".*,dc=yourcompany,dc=com" attr=userPassword

        by dn="cn=root,dc=yourcompany,dc=com" write

        by self write

        by * auth

access to dn=".*,dc=yourcompany,dc=com"

        by * read

defaultaccess none

#TLSCertificateFile      /etc/openldap/ssl/ldap.pem

#TLSCertificateKeyFile   /etc/openldap/ssl/ldap.pem

#TLSCipherSuite HIGH:+MEDIUM:!LOW

#TLSVerifyClient never

#########################################

# Theoretic Users in BerkleyDB format

# Is used by Apache, TWiki, and Jabberd.

#########################################

database        ldbm

suffix          "dc=theoretic,dc=com"

rootdn          "cn=root,dc=theoretic,dc=com"

rootpw          {MD5}*******************

directory       /var/lib/openldap-users

index           objectClass,uid,uidNumber,gidNumber   eq

index           cn,surname,givenname                  eq,subinitial

```

I have the TLS section commented out because my server is not yet using the FQDN that I am configuring the LDAP and SSL functionalities for (this server will replace one that is currently "theoretic.com"). I am not connecting remotely to the LDAP directory, I am performing all operations over a SSH connection.

And here is the "/root/base.ldif" file:

```

dn: dc=theoretic,dc=com

dc: theoretic

objectClass: top

objectClass: domain

dn: ou=users,dc=theoretic,dc=com

ou: users

objectClass: top

objectClass: organizationalUnit

description: Group for Users

dn: ou=members,dc=theoretic,dc=com

ou: members

objectClass: top

objectClass: organizationalUnit

description: Group for Members

dn: ou=admins,dc=theoretic,dc=com

ou: admins

objectClass: top

objectClass: organizationalUnit

description: Group for Administrators

```

Any help would be appreciated. Thanks.

----------

## Koon

 *adamtheo wrote:*   

> And also, why do you use the MD5 method for encrypting passwords rather than SHA or SSHA? Personal preference? Have any reasons for choosing that one?

 

Personal preference. SHA1 is better in terms of security (size of digest), but I have a few software that does only support MD5 or CRYPT  :Wink: 

-K

----------

## erebus

Hi ya... I've spent the last few hours trying to implement ldap on my new system and have found your guide very helpful..

But I've run into a few problems. I've created a user in ldap called andrew and a group called users and this seems to work fine. But when I try to modify this use using the standard linux commands, say usermod to add a group.. e.g.;

```
usermod -G users,wheel andrew
```

I get this error,

```
usermod: andrew not found in /etc/passwd
```

Am I missing something simple here?

And if I can't change users like this.. how can I go about adding a user to a group that exists in the group file rather than in the ldap database?

----------

## erebus

Ahh well I've managed to get things sorted regards the group front (you mearly add all the users you want in a particular group to the group data rather than adding the group to the user data)..

But if anyone else is having difficultly.. I can recommend emerging migrationtools.. its a set of perl scripts to automatically convert over you local file groups, passwd, hosts and a load of other things.. Worked like charm for me.

----------

## Koon

Yes, usermod is used to manipulate the standard Unix files (like useradd and others). You have to use an LDAP-specific solution to manage your LDAP-defined users & groups. I recommend directoryadminsitrator (it's not perfect, but better than nothing).

-K

----------

## adamtheo

RESOLVED: It seems I had an error in my /etc/hosts file, which was causing all local LDAP clients to hang when looking up the LDAP hostname. The error was having the wrong LAN IP address (192.168....) point to the domain name.

I had this setup working before, but decided to uninstall and try something different.

I have now set up my slapd.conf file as so:

```

include         /etc/openldap/schema/core.schema

include         /etc/openldap/schema/cosine.schema

include         /etc/openldap/schema/nis.schema

include         /etc/openldap/schema/inetorgperson.schema

pidfile         /var/run/openldap/slapd.pid

argsfile        /var/run/openldap/slapd.args

TLSCertificateFile      /opt/theoretic/ssl/key.pem

TLSCertificateKeyFile   /opt/theoretic/ssl/key.pem

TLSCipherSuite HIGH:+MEDIUM:!LOW

TLSVerifyClient never

database        ldbm

suffix          "dc=theoretic,dc=com"

rootdn          "cn=root,dc=theoretic,dc=com"

rootpw          {SSHA}FJJDcr+fOQjnLkwaMxWhzMzI8yBqUGVD

directory       /opt/theoretic/ldap

index           objectClass,uid,uidNumber,gidNumber   eq

index           cn,surname,givenname                  eq,subinitial

access to dn=".*,dc=theoretic,dc=com" attr=userPassword

        by dn="cn=root,dc=theoretic,dc=com" write

        by self write

        by * auth

access to dn=".*,dc=theoretic,dc=com" attr=mail

        by dn="cn=root,dc=theoretic,dc=com" write

        by self write

        by * read

access to dn=".*,ou=Users,dc=theoretic,dc=com"

        by * read

access to dn=".*,dc=theoretic,dc=com"

        by self write

        by * read

```

And I had added a user under a group in the directory, using GQ. I have given thios user a SSHA password. But when I try to log into the server, hoping to authenticate against LDAP, my password is continually refused. It seems that the server is not checking against the LDAP directory for users. How do I verify and debug this? Thanks

EDIT/UPDATE: I just did a "getent passwd" and "getent group", and do not see the users or groups that are in the LDAP directory.[/b]

----------

## adamtheo

Hello, again. It seems that getting past that last hurdle only got me into another one. Now I have the local LDAP clients accessing the LDAP directory. I have put slapd in debug mode, and watch as I try to log in with a regular user, or run the getent command. I see activity, but in the case of logging in, the password is rejected. And in the case of getent, the users and groups in the LDAP directory are not displayed.

----------

## Koon

 *adamtheo wrote:*   

> I have put slapd in debug mode, and watch as I try to log in with a regular user, or run the getent command. I see activity, but in the case of logging in, the password is rejected. And in the case of getent, the users and groups in the LDAP directory are not displayed.

 

Something must be wrong in the LDAP query. Could you post what the slapd debug traces show (debug level 768 might help) to see where it's stopped at ?

-K

----------

## bueno

hello,

i've a prbl

i've emerge openldap and i've tupe hostname...I obtain "sqall.maryblue.homeip.net"

I've type this to create the root pass :

```
# slappasswd -h {MD5}
```

so I put this in my /etc/oenldap/slapd.conf

```

include         /etc/openldap/schema/core.schema

include         /etc/openldap/schema/cosine.schema

include         /etc/openldap/schema/nis.schema

include         /etc/openldap/schema/inetorgperson.schema

pidfile         /var/run/openldap/slapd.pid

argsfile        /var/run/openldap/slapd.args

access to dn=".*,dc=maryblue.homeip,dc=net" attr=userPassword

        by dn="cn=root,dc=maryblue.homeip,dc=net" write

        by self write

        by * auth

access to dn=".*,dc=maryblue.homeip,dc=net"

        by * read

defaultaccess none

TLSCertificateFile      /etc/openldap/ssl/ldap.pem

TLSCertificateKeyFile   /etc/openldap/ssl/ldap.pem

TLSCipherSuite HIGH:+MEDIUM:!LOW

TLSVerifyClient never

database        ldbm

suffix          "dc=maryblue.homeip,dc=net"

suffix          "o=SPACEONE,c=FR"

rootdn          "cn=root,dc=maryblue.homeip,dc=net"

rootpw          {MD5}ZKZ99fgVxoVG5CznpIa7fA==

directory       /var/lib/openldap-ldbm

index           objectClass,uid,uidNumber,gidNumber   eq

index           cn,surname,givenname                  eq,subinitial

```

and when I type this I've a prbl (I'm in root)

```

/etc/init.d/slapd start

 * Starting ldap-server...

/etc/openldap/slapd.conf: Permission denied                                  [ !! ]

```

Can you help me please ?

bueno  :Sad: 

----------

## Carlo

bueno: Comment out the TLS lines, to ensure that  this isn't your problem.

Carlo

----------

## adamtheo

RESOLVED!!! See next post by me. Thanks Koon and all for the help!

Koon:

Hereis the output of slapd when started in debug mode 768 and running "getent passwd":

 *Quote:*   

> 
> 
> daemon: conn=5 fd=10 connection from IP=66.13.154.254:32959 (IP=:: 389) accepted.
> 
> ber_flush: 14 bytes to sd 10
> ...

 

Here is the output when running "getent group":

 *Quote:*   

> 
> 
> daemon: conn=6 fd=10 connection from IP=66.13.154.254:32960 (IP=:: 389) accepted.
> 
> ber_flush: 14 bytes to sd 10
> ...

 

And here is the output when trying to log into a user account that is listed in LDAP:

 *Quote:*   

> 
> 
> daemon: conn=7 fd=10 connection from IP=66.13.154.254:32961 (IP=:: 389) accepted.
> 
> ber_flush: 14 bytes to sd 10
> ...

 

And here is the output when I try to "su" into the user account:

 *Quote:*   

> 
> 
> daemon: conn=12 fd=10 connection from IP=66.13.154.254:32966 (IP=:: 389) accepted.
> 
> ber_flush: 14 bytes to sd 10
> ...

 

Also, when I try to do an "ldapsearch -LL -ZZ -H ldap://new.theoretic.com -b "dc=theoretic,dc=com" -x "(uid=adamtheo)"" command from the same server, I get the following:

 *Quote:*   

> 
> 
> daemon: conn=7 fd=9 connection from IP=66.13.154.254:32996 (IP=:: 389) accepted.
> 
> ber_flush: 14 bytes to sd 9
> ...

 

Also, what's funny is that I have installed GQ on my desktop at home, and I can run it, and get the proper information queried from the LDAP directory. I can see and modify the users, their passwords, groups, etc. Here is the slapd debug from when I access a particular user's account:

 *Quote:*   

> 
> 
> conn=8 op=18 SRCH base="uid=reatmon,ou=Users,dc=theoretic,dc=com" scope=0 filter="(objectClass=*)"
> 
> ber_flush: 340 bytes to sd 9
> ...

 

To my untrained eye it is now looking like the GQ queries are succeeding where the PAM/NSS queries are not is because GQ is looking in "ou=Users,dc=theoretic,dc=com", whereas PAM/NSS is just looking in "dc=theoretic,dc=com" for the posixAccount user. If this is the case, how do I get PAM/NSS to query the right 'ou'? Is that in '/etc/ldap.conf'?

Thanks.

----------

## adamtheo

Hi all. It seems I found the problem and fixed it after trying many different things. I eventually figured that the main problem had to be that PAM/NSS wasn't looking in 'ou=Users,dc=theoretic,dc=com' as it should for the posixAccount user, so I started poking around that. Turns out I had to uncomment the nss_base_passwd, nss_base_shadow, and nss_base_group          lines and change the values to fit my LDAP directory. Now PAM/NSS looks in the proper 'ou' categories and I can successfully log in as a regular user over SSH.

Might be something to put into the original HOWTO doc above.

----------

## bueno

no it's not this... :Sad:  another solution?

bueno

----------

## bueno

ok my first prbl is resolv, it was the password...he understand a clear pass but nor the MD5

but now I ve prbl to create the database...look

```

 ldapadd -x -D "cn=root,dc=maryblue.homeip,dc=net" -W -f /root/base.ldif

Enter LDAP Password: 

adding new entry "dc=maryblue.homeip,dc=net"

adding new entry "ou=People,dc=maryblue.homip,dc=net"

ldap_add: No such object

ldif_record() = 32

```

when I try to add th first grp he tell me there is nothing in the directory and and shoul try to use the migration tools

any idea please ?

thx

bueno

----------

## Koon

 *bueno wrote:*   

> but now I ve prbl to create the database...look
> 
> ```
> 
>  ldapadd -x -D "cn=root,dc=maryblue.homeip,dc=net" -W -f /root/base.ldif
> ...

 

The ldapadd is stopped at the first error, so the database is not created. The problem may come from your Base DN : I think it should read "dc=maryblue,dc=homeip,dc=net".

-EDIT- rereading your post, it appears there is a typo in the ldapadd script : you try to add "ou=People,dc=maryblue.homip,dc=net" to "dc=maryblue.homeip,dc=net". Check that it's called homeip everywhere in the base.ldif file. The problem surely comes from there.

-K

----------

## Koon

 *adamtheo wrote:*   

> Turns out I had to uncomment the nss_base_passwd, nss_base_shadow, and nss_base_group          lines and change the values to fit my LDAP directory. Now PAM/NSS looks in the proper 'ou' categories and I can successfully log in as a regular user over SSH.
> 
> Might be something to put into the original HOWTO doc above.

 

Could you please post the values you had to enter for these parameters to get it to work ? I will add a warning in the HOWTO. I don't understand why I didn't need these...

-K

----------

## tecknojunky

I find this LDAP thing very abstract, difficult and complicated.  I tought maybe doing the default recommendations found here and there would get me started and I could then understand later.  For now, I just keep bumping on hurdles for the last 3 days.

I think the LDAP server is working since doing  ldapsearch on the console gives results.  It seems that whatever GUI client I use, either directory_administrator or gq, I always get "Couldnt enable TLS on the LDAP connection: Can't contact LDAP server".  I have no clue what's wrong.

Any pointers would be greathly appreciated.

----------

## Koon

 *tecknojunky wrote:*   

> I think the LDAP server is working since doing  ldapsearch on the console gives results.  It seems that whatever GUI client I use, either directory_administrator or gq, I always get "Couldnt enable TLS on the LDAP connection: Can't contact LDAP server".  I have no clue what's wrong.

 

Did you try to comment the TLS* lines in slapd.conf to connect without TLS from LDAP client to server ? You can also run slapd using a debug flag (-d 768) and see if it receives something when GQ is connecting.

-K

----------

## eikketk

I cannot get this to work  :Sad:  Changed everything, imported everything using migrationtools (all info is in my directory, I can browse it using phpldapadmin)

I even filled in a binddn and password in /etc/ldap.conf, but this didnt solve the problem

Here's a part of the output of slapd -d 768:

```

slapd starting

daemon: conn=0 fd=9 connection from IP=127.0.0.1:4113 (IP=0.0.0.0:389) accepted.

conn=0 op=0 BIND dn="CN=MANAGER,DC=TRANGEZ,DC=INT" method=128

ber_flush: 14 bytes to sd 9

conn=0 op=0 RESULT tag=97 err=0 text=

conn=0 op=1 SRCH base="ou=People,dc=trangez,dc=int" scope=1 filter="(&(objectClass=posixAccount)(uid=mathieu))"

ber_flush: 314 bytes to sd 9

conn=0 op=1 ENTRY dn="uid=mathieu,ou=People,dc=trangez,dc=int"

ber_flush: 14 bytes to sd 9

conn=0 op=1 SEARCH RESULT tag=101 err=0 text=

conn=0 op=2 SRCH base="ou=People,dc=trangez,dc=int" scope=1 filter="(&(objectClass=posixAccount)(uid=mathieu))"

ber_flush: 314 bytes to sd 9

conn=0 op=2 ENTRY dn="uid=mathieu,ou=People,dc=trangez,dc=int"

ber_flush: 14 bytes to sd 9

conn=0 op=2 SEARCH RESULT tag=101 err=0 text=

conn=0 op=3 SRCH base="ou=People,dc=trangez,dc=int" scope=1 filter="(&(objectClass=posixAccount)(uid=mathieu))"

ber_flush: 314 bytes to sd 9

conn=0 op=3 ENTRY dn="uid=mathieu,ou=People,dc=trangez,dc=int"

ber_flush: 14 bytes to sd 9

conn=0 op=3 SEARCH RESULT tag=101 err=0 text=

daemon: conn=1 fd=14 connection from IP=127.0.0.1:2177 (IP=0.0.0.0:389) accepted.

conn=1 op=0 BIND dn="CN=MANAGER,DC=TRANGEZ,DC=INT" method=128

ber_flush: 14 bytes to sd 14

conn=1 op=0 RESULT tag=97 err=0 text=

conn=1 op=1 SRCH base="ou=People,dc=trangez,dc=int" scope=2 filter="(&(objectClass=posixAccount)(uid=mathieu))"

ber_flush: 387 bytes to sd 14

conn=1 op=1 ENTRY dn="uid=mathieu,ou=People,dc=trangez,dc=int"

ber_flush: 14 bytes to sd 14

conn=1 op=2 BIND dn="UID=MATHIEU,OU=PEOPLE,DC=TRANGEZ,DC=INT" method=128

conn=1 op=1 SEARCH RESULT tag=101 err=0 text=

ber_flush: 14 bytes to sd 14

conn=1 op=2 RESULT tag=97 err=0 text=

conn=1 op=3 BIND dn="CN=MANAGER,DC=TRANGEZ,DC=INT" method=128

ber_flush: 14 bytes to sd 14

conn=1 op=3 RESULT tag=97 err=0 text=

conn=0 op=4 SRCH base="ou=People,dc=trangez,dc=int" scope=1 filter="(&(objectClass=posixAccount)(uid=mathieu))"

ber_flush: 314 bytes to sd 9

conn=0 op=4 ENTRY dn="uid=mathieu,ou=People,dc=trangez,dc=int"

ber_flush: 14 bytes to sd 9

conn=0 op=4 SEARCH RESULT tag=101 err=0 text=

```

the entry mathieu seems to be found   :Confused:   Altough not when using 

```
getent passwd | grep mat
```

I try to login (on a tty, not ssh) with login id=mathieu, password doesn't matters  :Wink:  but is right.

If I try to login using ssh, uid=NOUSER or something alike is passed to slapd ?!?   :Shocked: 

If anyone ever got LDAP authentication working on Gentoo, please help me out...  :Crying or Very sad: 

Thanks, Ikke

----------

## tecknojunky

 *Koon wrote:*   

>  *tecknojunky wrote:*   I think the LDAP server is working since doing  ldapsearch on the console gives results.  It seems that whatever GUI client I use, either directory_administrator or gq, I always get "Couldnt enable TLS on the LDAP connection: Can't contact LDAP server".  I have no clue what's wrong. 
> 
> Did you try to comment the TLS* lines in slapd.conf to connect without TLS from LDAP client to server ? You can also run slapd using a debug flag (-d 768) and see if it receives something when GQ is connecting.
> 
> -K

 But then I would need to remove all those ldaps:// and 636 references and all.  Isnt there a simpler way to know why SSL does not work?!?  I've seen a couple of posts of people simply disabling that features, but none are specifying why it did not work or how to set it properly.

All in all, I'm starting to dislike very much LDAP.

----------

## tecknojunky

ok, so i did comment all TLS lines in the slapd.conf.  Like I said, it does implies also removing all references to post 636 and ldpas:// in all the files where such references exists.

Also, I noticed that the init.d script did not start no more for an unknown reason.  Calling slapd from the command line worked but not the script.  I have debug this to being the ldap user/group used to start the ldap service.  Since ldap already messes up with users and group validities, it creates some kind of chicken and egg issue, so I removed the -u and -g options from the start-stop-daemon in the init.d/slapd script.  

The service now starts and I can browse the content of the directory with gq.  Still, the remote clients can't no more reach the ldap server, my local su does not work no more, and I have all the groups and users in the directory, including the root, which is bound to create problems if the ldap is down.

Bottom line is, all the howtos I have found on ldap in the Gentoo sites seem to be a mess.  I may be at fault since I never played with this before (not even NIS) and in no way do I want to take down the ones who contributed the docs, I salute their attempts, but it's still foggy sh!t.

One thing is sure, I now begin to understand a bit better the arguments on comparing the costs of OSS compared  to proprietary, especially when it is said that cost is not only the acquiering of softwares.  Softwares are implemented and maintained by people and that's what cost the most.  So far, I have spent 4 full days on this LDAP thing and, in a business environment, it would have surely outwage the cost of installing something  with some basic wizzards and concise docs and howtos.  It may not apply to all OSS softs, but this is one clear example.  In my book, LDAP is to Qmail what Chess id to Tic-Tac-Toe, really not as easy to get going.

I have now turn to the official OpenLDAP site's docs and I will stay away from the doc provided by Gentoo as it's clearly inadequate (at least, for me).  More on my successes and woes to come.

----------

## tecknojunky

So far, I had one misconfiguration on the client (pam_login_attribute was set to memberuid instead of uid in /etc/ldap.conf).

With TLS i could not browse the directory with GQ, that feature removed (lots of files to fudge), I could browse but not modify.  I have put "uid=root,ou=People,dc=fiston,dc=inet" in the DN feild of the server, and also statically entered the password.  Now I can modify entries in the directory.  I have yet to test if I can gain Manager access from any users.

When I login on a client terminal with a user only existing in the LDAP, I get pam_login's authentification failures printing on the screen, but I end up logged in anyway.  At least something is working.  In fact, it's pam_unix that is complaining and I think it only has to do with verbosity.  Maybe it's supposed to be sent to stderr but it ends up on the console, or maybe it's set to be verbose like that... even standard user login issues echos from pam_login.

I have removed the "session    required     /lib/security/pam_mkhomedir.so skel=/etc/skel/ umask=0022" in the  /etc/pam.d/system-auth file as I intend to nfs mount the whole user's home tree on each machines at boot (I also deleted the /etc/skel since I don't have use for it).

su is now borked.  I can't su to root on the server.

I can't ssh to the client with a LDAP user that does not exist on that machine.

Probably a lot of other stuffs broken too that have yet to be discovered.  Any help to any of the mentionned issues would be greatly appreciated.

----------

## tecknojunky

couple of other howtos I've found:

http://www.direct-to-linux.com/TUTORIALS/LinuxTutorialLDAP.html

http://www.cerritoslug.org/tutorials/ldap/

http://www.bayour.com/LDAPv3-HOWTO.html

----------

## Koon

 *eikketk wrote:*   

> I cannot get this to work  Changed everything, imported everything using migrationtools (all info is in my directory, I can browse it using phpldapadmin)

 

Don't forget to leave system accounts and groups in the classic Unix files.

 *Quote:*   

> I try to login (on a tty, not ssh) with login id=mathieu, password doesn't matters  but is right.
> 
> If I try to login using ssh, uid=NOUSER or something alike is passed to slapd ?!?

 

Send the log (-d 768) for that query, if you have it.

-K

----------

## Koon

 *tecknojunky wrote:*   

> Also, I noticed that the init.d script did not start no more for an unknown reason.  Calling slapd from the command line worked but not the script.  I have debug this to being the ldap user/group used to start the ldap service.  Since ldap already messes up with users and group validities, it creates some kind of chicken and egg issue, so I removed the -u and -g options from the start-stop-daemon in the init.d/slapd script.

 

Did you leave the system groups and accounts in the classic Unix files ? Having root in the LDAP directory is a bad idea (see Howto) for all kind of reasons.

 *tecknojunky wrote:*   

> One thing is sure, I now begin to understand a bit better the arguments on comparing the costs of OSS compared  to proprietary, especially when it is said that cost is not only the acquiering of softwares.  Softwares are implemented and maintained by people and that's what cost the most.  So far, I have spent 4 full days on this LDAP thing and, in a business environment, it would have surely outwage the cost of installing something  with some basic wizzards and concise docs and howtos.  It may not apply to all OSS softs, but this is one clear example.  In my book, LDAP is to Qmail what Chess id to Tic-Tac-Toe, really not as easy to get going.

 

Yes, OSS is a lot more complicated to put in place the first time, so it can be more costly than a polished commercial alternative. The BIG difference is that once you understand the issue correctly, the next time it does cost you next to nothing. I have to spend 2 days to get the LDAP auth server to work here, but I did it on another site and it took me half an hour (following this very howto I wrote during my first attempts). Using commercial software will cost you the same over and over. 

 *Quote:*   

> I have now turn to the official OpenLDAP site's docs and I will stay away from the doc provided by Gentoo as it's clearly inadequate (at least, for me).  More on my successes and woes to come.

 

PAM and LDAP are complex issues, and one false step may spell the end at any time (as PAM controls a lot of things on your system). I surely hope you will manage to have it working in the end, and if your problems were related to errors or omissions in this howto, please let me know so that I can correct it.

-K

----------

## tecknojunky

 *Koon wrote:*   

>  *tecknojunky wrote:*   Also, I noticed that the init.d script did not start no more for an unknown reason.  Calling slapd from the command line worked but not the script.  I have debug this to being the ldap user/group used to start the ldap service.  Since ldap already messes up with users and group validities, it creates some kind of chicken and egg issue, so I removed the -u and -g options from the start-stop-daemon in the init.d/slapd script. 
> 
> Did you leave the system groups and accounts in the classic Unix files ? Having root in the LDAP directory is a bad idea (see Howto) for all kind of reasons.

 

Yes, I have left the Unix files intacts.  Just that, following Gentoo's howto, I ended up with a perfect mirror of those in the ldap directory.  I have cleaned up the users (even root), but I have not played with the groups because some contains users that will be in the LDAP directory, so I have yet to figure that out.

 *Koon wrote:*   

>  *tecknojunky wrote:*   One thing is sure, I now begin to understand a bit better the arguments on comparing the costs of OSS compared  to proprietary, especially when it is said that cost is not only the acquiering of softwares.  Softwares are implemented and maintained by people and that's what cost the most.  So far, I have spent 4 full days on this LDAP thing and, in a business environment, it would have surely outwage the cost of installing something  with some basic wizzards and concise docs and howtos.  It may not apply to all OSS softs, but this is one clear example.  In my book, LDAP is to Qmail what Chess id to Tic-Tac-Toe, really not as easy to get going. 
> 
> Yes, OSS is a lot more complicated to put in place the first time, so it can be more costly than a polished commercial alternative. The BIG difference is that once you understand the issue correctly, the next time it does cost you next to nothing. I have to spend 2 days to get the LDAP auth server to work here, but I did it on another site and it took me half an hour (following this very howto I wrote during my first attempts). Using commercial software will cost you the same over and over. 

 

It makes sense.  Steep learning curve at first.  Just like a new qmail setup takes me now just about 5% of my initial attempt.

 *Koon wrote:*   

>  *Quote:*   I have now turn to the official OpenLDAP site's docs and I will stay away from the doc provided by Gentoo as it's clearly inadequate (at least, for me).  More on my successes and woes to come. 
> 
> PAM and LDAP are complex issues, and one false step may spell the end at any time (as PAM controls a lot of things on your system). I surely hope you will manage to have it working in the end, and if your problems were related to errors or omissions in this howto, please let me know so that I can correct it.

 

I'm doing this in a test environment.  Before my reboot, I had /usr mounted from the server via nfs.  This was working, but unmounted forced me to reinstall [pam|nss]_ldap + openldap on the client.  I did not have a system logger either, metalog pointed me to the missing ldap libs.  Those are resolv but still can't connect from client.

The current issue is that pam claims the underlying modules does not know my user, regardless to the fact that the user show when I do "genent passwd" (and, no, the user is not in the Unix files).  I have all the files exactly like mentionned in the "setup client" of your first post.  Do I need to configure and start slapd on the client too?!?  I think not.

----------

## Koon

 *tecknojunky wrote:*   

> Just that, following Gentoo's howto, I ended up with a perfect mirror of those in the ldap directory.

 

It's not Gentoo's howto, it's just an howto written by me  :Wink:  But Mandrake's one in no better. The problem is that it's very difficult to troubleshoot because (1) OpenLDAP logs are obscure and (2) Everything falls apart as soon as there is the slightest error.

 *Quote:*   

> I'm doing this in a test environment.  Before my reboot, I had /usr mounted from the server via nfs.  This was working, but unmounted forced me to reinstall [pam|nss]_ldap + openldap on the client.  I did not have a system logger either, metalog pointed me to the missing ldap libs.  Those are resolv but still can't connect from client.

 

I must admit the howto was written for a from scratch machine with no existing users, so mitigating factors like unusual installation and migration of user base are not very well covered.

 *Quote:*   

> The current issue is that pam claims the underlying modules does not know my user, regardless to the fact that the user show when I do "genent passwd" (and, no, the user is not in the Unix files).  I have all the files exactly like mentionned in the "setup client" of your first post.  Do I need to configure and start slapd on the client too?!?  I think not.

 

If getent works but not login, it means the NSS_LDAP part is working (and therefore the server setup must be OK). The problem must be located in PAM_LDAP configuration on the client (the /etc/pam.d files and some parameters of ldap.conf). One thing you can try (if you have still energy left to spend on this problem) is comparing OpenLDAP logs output for the client's "getent passwd" and the client login and look for differences. It's possible that there is a glitch in the migrationtools-generated files (I didn't use these), and that you must adjust values in ldap.conf accordingly...

Hope this helps.

-K

----------

## tecknojunky

 *Koon wrote:*   

>  *tecknojunky wrote:*   Just that, following Gentoo's howto, I ended up with a perfect mirror of those in the ldap directory. 
> 
> It's not Gentoo's howto, it's just an howto written by me  But Mandrake's one in no better. The problem is that it's very difficult to troubleshoot because (1) OpenLDAP logs are obscure and (2) Everything falls apart as soon as there is the slightest error.

 

Noted.  Like I said, I salute the effort.  The biggest problem I'm finding out is that there is not much documentation on the concept as a whole, so everything must be done thrue guessing, trials and (mostly) errors.

 *Koon wrote:*   

>  *Quote:*   I'm doing this in a test environment.  Before my reboot, I had /usr mounted from the server via nfs.  This was working, but unmounted forced me to reinstall [pam|nss]_ldap + openldap on the client.  I did not have a system logger either, metalog pointed me to the missing ldap libs.  Those are resolv but still can't connect from client. 
> 
> I must admit the howto was written for a from scratch machine with no existing users, so mitigating factors like unusual installation and migration of user base are not very well covered.

 

In fact, I only have one user on the server and none on the client.  Well, that is, appart from all those default users that comes bundled with Gentoo and for which the vast majority I don't use.  I'm not a big fan of adding all those users by default in a system and it's on my todo list to remove the ones I don't use.  When creating the ldif file, I edited it to remove all the non relevant users from it before importing it to the directory.  Still, I have all sorts of issues now.  I can't su root no more (really annoying) and when sshing to the client with the sole server's user, I can login but the prompt show "I dont know who i am@mybox".  But these can be resolved after.

 *Koon wrote:*   

>  *Quote:*   The current issue is that pam claims the underlying modules does not know my user, regardless to the fact that the user show when I do "genent passwd" (and, no, the user is not in the Unix files).  I have all the files exactly like mentionned in the "setup client" of your first post.  Do I need to configure and start slapd on the client too?!?  I think not. 
> 
> If getent works but not login, it means the NSS_LDAP part is working (and therefore the server setup must be OK). The problem must be located in PAM_LDAP configuration on the client (the /etc/pam.d files and some parameters of ldap.conf). One thing you can try (if you have still energy left to spend on this problem) is comparing OpenLDAP logs output for the client's "getent passwd" and the client login and look for differences. It's possible that there is a glitch in the migrationtools-generated files (I didn't use these), and that you must adjust values in ldap.conf accordingly...

 

I'm beginning to grasp the concepts a bit.  I noticed that my group "shema"(?) does not have a "gid" feild per say, but rather a memberuid, so I tried playing with that without any success.  I think I would be better off emptying the directory and start from scratch with an empty list instead.  Is deleting the openldap-libm enough?

I will try the log thing you said, altough it's all chinese to me.  I will get this thing going, I have just abbandonned the idea of getting this going real soon.  It's all cool to learn from your mistake, but there's a point where enough is enough and you wish it would just work.  I have never felt this noob apart since I used Linux for the first time, figuring out how to list a folder's content (ls  :Wink:  ).

----------

## Koon

 *tecknojunky wrote:*   

> Still, I have all sorts of issues now.  I can't su root no more (really annoying)

 

Looks like a 'wheel' group problem. As you probably know, your user needs to be in the wheel group to be able to su. Maybe the wheel group was migrated to LDAP but the user wasn't added to it or something like that... (just guessing)

 *Quote:*   

> I think I would be better off emptying the directory and start from scratch with an empty list instead.  Is deleting the openldap-libm enough?

 

You can also create an LDAP database in some other directory (see the "directory" parameter in slapd.conf).

 *Quote:*   

> I will try the log thing you said, altough it's all chinese to me.  I will get this thing going, I have just abbandonned the idea of getting this going real soon.  It's all cool to learn from your mistake, but there's a point where enough is enough and you wish it would just work.  I have never felt this noob apart since I used Linux for the first time, figuring out how to list a folder's content (ls  ).

 

Maybe you should start by trying to find some docs on LDAP and PAM first, to get a good understanding of everything that's involved in this (complicated) process. The PAM docs not (at all) newbie-oriented, so the learning curve is quite steep. But from there, implementation should not be a problem... Good luck anyway.

-K

----------

## daha

if something went wrong, booting with "single" argument (grub) is easy way to fix things .-]

just regonized that, when i typoed emerge -C pam, when tried to emerge -C pan :]

----------

## tecknojunky

Finally went with my initial idea.  I deleted the directory folder in /var/lib, followed the instruction in the initial post in this thread by creating an empty directory, used directory_administrator instead of gq, created group users with gid 100, then created users with same uid as in the passwd, went on client and BINGO!, it worked.

So, at least, this is now working like expected and I can build on that.  :Smile: 

----------

## tecknojunky

lastest news:

I fixed the su issue by editing /etc/pam.d/su file and commenting the following line:

 *Quote:*   

> #auth       required     /lib/security/pam_wheel.so use_uid

 

which simply disable the need to be in the wheel group to access root thrue su.

I could ssh to the client using a user in from the ldap, but I could not do the same from the client to server using that same user, altough both ssh and ldap settings were wirtiualy identical.  Roaming the ssh config files in /etc/ssh, I noticed that /etc/ssh/sshd_config had a Use_PAM switch that was commented (on both the client and server).  Removing that comment and restarting the sshd server allowed me to connect to any box from anybox with users from the ldap directory.

The only thing remaining would be to re-enable ssl and try to make slapd run as the ldap user:group.

Hope those infos help someone... somewhere.

----------

## Koon

Glad you made it. 

The Use_PAM trick is strange, since I don't have any Use_PAM parameter in my SSH config files. Maybe you don't use the same version as me.

-K

----------

## thomasando

using this method, can you automatically mount nfs home drives for each user when they login and unmount it when they logout? at the moment i have the home drives mounted all the time... would be nice to have them coming up/down automatically... and it might solve some of the problems i have with the nfs shares when the system shuts down uncleanly...

----------

## tecknojunky

 *thomasando wrote:*   

> using this method, can you automatically mount nfs home drives for each user when they login and unmount it when they logout? at the moment i have the home drives mounted all the time... would be nice to have them coming up/down automatically... and it might solve some of the problems i have with the nfs shares when the system shuts down uncleanly...

 

I also hame the whole /home mounted nfs since all the users (two  :Very Happy:  ) are roaming, we don't have local accounts.

But if I would, I would try to put the mount command in the /etc/profile.  Maybe something like this:

mount <ip.address.of.nfs>:$HOME $HOME

Of course, this way, you must be sure each ldap users with a home folder to be nfs mounted have an equivalent empty folder on each box.  Unless you create the folder on the fly and delete it when the user logs out, but that needs thinking a little bit harder.

----------

## thomasando

i dont care if there's empty folders, as long as it automounts/unmounts when i log in/out of the box  :Very Happy:  like you, i only have 2 users... but several pc's that we could use and it's a bit of a pain to have to setup accounts on each machine (considering one of them is for testing and gets rebuilt weekly or even more frequently sometimes)... since i have a dedicated server there, it might as well be a bit more useful than it already is  :Very Happy: 

----------

## tecknojunky

I don't have a solution for the auto-unmounting.

For us, we prefer having the /home mounted with all the accounts on all the boxes.  This way, if we want to exchange files in the other user's home folder, it's available and visible, regardless of the boxe we are presently logged on to.

----------

## shira

would a setup like this work over a WAN or would one want to use something like vpns and such to make sure data stays secure

----------

## Koon

 *shira wrote:*   

> would a setup like this work over a WAN or would one want to use something like vpns and such to make sure data stays secure

 

I see two potential problems :

First, in my setup, I don't have strong client/server authentication (the client is not sure it is communicating with the server and the server is not sure it is communicating with a genuine client). Even if the authentication data is encrypted, you could fell prey to a MiM attack. So for WAN deployment you should either add strong high-level client/server authentication (using PKI on OpenLDAP), or deploy a VPN to have strong low-level machine-to-machine authentication.

Furthermore, with PAM and NSS using LDAP, you will have a lot of requests for LDAP data by your clients, and if the LDAP server is far away, this may slow down everything. LDAP data is by essence a local resource, so you should better have a local LDAP server for queries and replicated/distributed LDAP servers on your WAN.

-K

----------

## negativecreep

 *tecknojunky wrote:*   

> lastest news:
> 
> I fixed the su issue by editing /etc/pam.d/su file and commenting the following line:
> 
>  *Quote:*   #auth       required     /lib/security/pam_wheel.so use_uid 
> ...

 

If you still want to require users to be in wheel to be able to su you can manually add the ldap usernames to the wheel line in /etc/group. I've done it this way on my setup since i don't want any system groups in my ldap directory.

----------

## ThomasL

You can use LDAP even on laptops. Follow the Replication-Guide (http://www.openldap.org/doc/admin20/replication.html).

So you have full access if the ldap-server is reachable and read-only acces if not.

Works great.

Thomas

----------

## digital diesel

i followed everything to a T.  now i get this when i try to ssh to the client

```

seattle root # ssh -2 10.0.0.20

root@10.0.0.20's password:

Permission denied, please try again.

root@10.0.0.20's password:

Permission denied, please try again.

root@10.0.0.20's password:

Permission denied (publickey,password,keyboard-interactive).

```

what should i do?

----------

## Koon

 *digital diesel wrote:*   

> i followed everything to a T.  now i get this when i try to ssh to the client...

 

Is eveything else working properly, i.e. do you manage to do "getent passwd" on the client itself to show all the accounts ? Do you manage to log in the client from the console ? If everything but ssh login works, it might mean that ssh has a specific configuration (UsePAM set to false in SSH server, specific PAM filesto manage the SSH-login...)

-K

----------

## DArtagnan

I have followed the first post and I get this error!

Can any 1 help me please?

```

mslinux-dev liviu # /etc/init.d/slapd start

 * Starting ldap-server...

@(#) $OpenLDAP: slapd 2.0.27-Release (Thu Oct 23 10:08:29 IST 2003) $

        portage@mslinux-dev:/var/tmp/portage/openldap-2.0.27-r4/work/openldap-2.0.27/servers/slapd

daemon_init: listen on ldaps://

daemon_init: listen on ldap://

daemon_init: listen on ldapi://%2fvar%2frun%2fopenldap%2fslapd.sock

daemon_init: 3 listeners to open...

ldap_url_parse_ext(ldaps://)

daemon: initialized ldaps://

ldap_url_parse_ext(ldap://)

daemon: initialized ldap://

ldap_url_parse_ext(ldapi://%2fvar%2frun%2fopenldap%2fslapd.sock)

daemon: initialized ldapi://%2fvar%2frun%2fopenldap%2fslapd.sock

daemon_init: 3 listeners opened

ldap_create

ldap_extended_operation_s

ldap_extended_operation

ldap_send_initial_request

ldap_new_connection

ldap_int_open_connection

ldap_connect_to_host: mslinux-dev.mscc.huji.ac.il

ldap_connect_to_host: getaddrinfo failed: Name or service not known

ldap_unbind

slapd init: initiated server.

==>backsql_initialize()

<==backsql_initialize()

TLS: could not use certificate `/etc/openldap/ssl/ldap.pem'.

TLS: error:0906D06C:PEM routines:PEM_read_bio:no start line pem_lib.c:666

TLS: error:140AD009:SSL routines:SSL_CTX_use_certificate_file:missing asn1 eos ssl_rsa.c:534

main: TLS init def ctx failed: 0

slapd shutdown: freeing system resources.

slapd stopped.

connections_destroy: nothing to destroy.                                                         [ !! ]

mslinux-dev liviu #

```

----------

## digital diesel

 *Koon wrote:*   

>  *digital diesel wrote:*   i followed everything to a T.  now i get this when i try to ssh to the client... 
> 
> Is eveything else working properly, i.e. do you manage to do "getent passwd" on the client itself to show all the accounts ? Do you manage to log in the client from the console ? If everything but ssh login works, it might mean that ssh has a specific configuration (UsePAM set to false in SSH server, specific PAM filesto manage the SSH-login...)
> 
> -K

 

I think it's possible i screwed up the name of the the /etc/pam.d/syst-auth file.  what is it's absolute path including file name becaue i think that's what's screwing me up

----------

## Koon

 *digital diesel wrote:*   

> I think it's possible i screwed up the name of the the /etc/pam.d/syst-auth file.  what is it's absolute path including file name becaue i think that's what's screwing me up

 

You have to look at what the /etc/pam.d/sshd file contains. Normally it contains links to /etc/pam.d/system-auth, which shoould contain what this guide requires.

HTH

-K

----------

## sj7trunks

I wrote the document on openldap for gentoo. Just a few pointers... You can always delete the root account from the ldap database. Most systems use sudo to gain root privledges and it's good practice. The password for root shouldn't be passed out to anyone in the first place. A person can login from console with root/password and no way to identify who accessed the machine which is VERY bad... So that is why you need to show which users are using root  Best to luck for those people with problems. I'll try following this thread in the future to help people with their problems.

----------

## Carlo

 *sj7trunks wrote:*   

> I'll try following this thread in the future to help people with their problems.

 

Hehe - take me by the hand, then!  :Wink: 

```
TLS trace: SSL_accept:error in SSLv2/v3 read client hello A

TLS: can't accept.

TLS: error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol s23_srvr.c:641

connection_read(9): TLS accept error error=-1 id=0, closing
```

Since enabling TLS, I can't acces the directory regardless which client I use. I triple checked the configuration, but cannot find the problem.

Carlo

----------

## Superfly

Anyone have any luck getting host based authentication to work?

I've gotten it to work by changing "account sufficient" to "account required" for pam_ldap.so... but that doesn't allow any system accounts to login.

Supposedly pam_filter is supposed to solve that problem according to this page:

http://linsec.ca/bin/view/Main/OpenLDAPAuth#Host_based_Authentication

But I can not get it to work... :(  I've even tried using pam_ldap 165 instead of the 156 that's "stable" for Gentoo right now.

----------

## Superfly

Holy wow.  It took me all friggin' day, but I got it to work how I want it.

The two ebuilds shipped with Gentoo don't support all the features I needed, so I had to make my own 165 ebuild.  To do this, just copy the /usr/portage/net-libs/pam_ldap/pam_ldap-156.ebuild to pam_ldap-165.ebuild.  Then change the "SRC_URI" to:

```
SRC_URI="http://www.padl.com/download/${P}.tar.gz"
```

Then, from that directory just run:

```
emerge ./pam_ldap-165.ebuild
```

My requirements were that I wanted host based authentication to be _required_ for ldap users.  But obviously for system users, it shouldn't be checked.  So, I added this line to me /etc/ldap.conf:

```
pam_check_host_attr yes
```

And I commented out all pam_filter lines.  Then I set my account lines in my /etc/pam.d/system-auth to:

```
account    required     /lib/security/pam_ldap.so ignore_unknown_user ignore_authinfo_unavail

account    required     /lib/security/pam_unix.so
```

ignore_unknown_user makes it so that system accounts can login when the ldap server is running.

ignore_authinfo_unavail makes it so that system accounts can login when the ldap server is not running.

Then I just used directoryadministrator to add hosts to my users.  Supposedly wild cards are supposed to work... haven't tried them yet.

Hope that saves someone a days worth of hair pulling.

----------

## eliemedeiros

 *Superfly wrote:*   

> 
> 
> Hope that saves someone a days worth of hair pulling.

 

well - i spent quite a while not figuring out how it worked (more than a day), but those ignore_* lines seem to have done the trick - couldn't figure out why the system accounts (including root) did not seem to work on the ldap server, but they do now...

ta

Elie

----------

## eliemedeiros

For some reason, when I connect to LDAP using TLS i get the following error:

```

ldap_bind: Can't contact LDAP server (81)

additional info: (..) SSL3_GET_SERVER_CERTIFICATE:certificate verify failed

```

when i do ldap searc -H ldaps://FDQN -d7, I get something along the lines of:

```

TLS certificate verification: Error, self signed certificate in certificate chain

(..)

TLS trace: SSL3 alert write: fatal: unknown CA

```

it seems someone is not playing nice with self-signed certificates (which is what I am using). I have 

```

TLSClientVerify never

```

in the slapd.conf file, but this doesn't seem to do anything. I could use 

```
TLS_REQCERT allow
```

, but I wanted to use PHP's ldap functions and they don't seem to work with TLS whether that option is set or not - ibid for PAM.

any ideas?

Elie

----------

## tank

Ok I have an LDAP auth server setup and running.

Everything seems to work fine, as long as I do not have ANY ACL defined.

No matter what I ACL I use I can not AUTH with the server.

I can do an ldap search with the server with the ACL in place, however PAM gives me an authenitcation failed anytime I try to log in via console or ssh when an ACL is definec (no ACL defined I can log in fine).

this is the ACL I am trying to use.

```

access to *

  by self write

  by users read

  by anonymous auth

```

Pretty simple, not sure why it will not work.

----------

## eliemedeiros

i'm not sure "anonymous" is a valid ACL entry - is it?

you might want to try:

```

access to *

  by self write

  by users read

  by * auth 

```

see if that works any better...

----------

## tank

I tried 

by * auth

also, it turns out that I had to create a proxy users and bind PAM to that proxy user  :Sad: 

----------

## xphyr

OK, so I have decided to setup LDAP as well for authentication and what not.  (Overkill since I am the only user, but I want to learn anyway).  I have my main server running ldaps and pam ldap perfectly.  No issues.  So I move to my workstation, and configure pam_ldap and try "getent passwd".  It only returns the local files info.  Now my guess is that this has something to do with the ssl certs.  I can't figure out what file to put in what place to make this work.  I can query the ldap server with ldapsearch (after having put "TLSReqCert allow" into the /etc/openldap/ldap.conf file ... ) but it seems like pam doesnt follow the same thing.  Does anyone here know if there is a way I can verify this is the problem?  Has anyone got this working with multiple machines and did you need to play with the ssl certs?  Thanks.

----------

## xphyr

Right, so I was bored at work .. and still very much interested in why I cant get this to work.  So I logged into home and started playing around a little.  I put slapd into debug mode and then tried to use the pam_ldap module from another machine.  In watching the debug output i found the following:

daemon: activity on 1 descriptors

daemon: new connection on 15

daemon: added 15r

daemon: activity on:

daemon: select: listen=6 active_threads=0 tvp=NULL

daemon: select: listen=7 active_threads=0 tvp=NULL

daemon: activity on 1 descriptors

daemon: activity on: 15r

daemon: read activity on 15

connection_get(15)

connection_get(15): got connid=1

connection_read(15): checking for input on id=1

ber_get_next

ldap_read: want=1, got=1

  0000:  80                                                 .

ldap_read: want=1, got=1

  0000:  92                                                 .

ber_get_next on fd 15 failed errno=34 (Numerical result out of range)

connection_read(15): input error=-2 id=1, closing.

connection_closing: readying conn=1 sd=15 for close

connection_close: conn=1 sd=15

daemon: removing 15

daemon: select: listen=6 active_threads=0 tvp=NULL

daemon: select: listen=7 active_threads=0 tvp=NULL

daemon: activity on 1 descriptors

daemon: select: listen=6 active_threads=0 tvp=NULL

daemon: select: listen=7 active_threads=0 tvp=NULL

I think the important part is the "ber_get_next on fd 15 failed errno=34" I only see this when pam queries the ldap directory.  Anyone here know or understand what this means?  I am off to google for an answer...

----------

## shomer

 *digital diesel wrote:*   

> i followed everything to a T.  now i get this when i try to ssh to the client
> 
> ```
> 
> seattle root # ssh -2 10.0.0.20
> ...

 

I have exactly this problem. I can login on any machine from the console but not via ssh. I can also login as a local user and su to the ldap user.

My /etc/pam.d/sshd file and sys-auth are as quoted in the HOWTO.

I've googled but everything *seems* to be correct. Does anyone have any idea how to debug this?

Many thanks in advance.

----------

## Koon

 *tank wrote:*   

> this is the ACL I am trying to use.
> 
> ```
> 
> access to *
> ...

 

For AUTH purpose I think you need to let anonymous users read most of the parameters. Try the ACL specified in this howto and see if it works better.

-K

----------

## Koon

 *shomer wrote:*   

> I have exactly this problem. I can login on any machine from the console but not via ssh. I can also login as a local user and su to the ldap user.
> 
> My /etc/pam.d/sshd file and sys-auth are as quoted in the HOWTO.
> 
> I've googled but everything *seems* to be correct. Does anyone have any idea how to debug this?
> ...

 

Does the SSH server have UsePAM enabled ?

Is there any LDAP activity when you try to log in ?

-K

----------

## Koon

 *xphyr wrote:*   

> OK, so I have decided to setup LDAP as well for authentication and what not.  (Overkill since I am the only user, but I want to learn anyway).  I have my main server running ldaps and pam ldap perfectly.  No issues.  So I move to my workstation, and configure pam_ldap and try "getent passwd".  It only returns the local files info.  Now my guess is that this has something to do with the ssl certs...

 

Does it work if you only use LDAP and not LDAPS ?

-K

----------

## tank

 *Koon wrote:*   

>  *tank wrote:*   this is the ACL I am trying to use.
> 
> ```
> 
> access to *
> ...

 

Well wouldn't that kinda defeat the purpose of having an ACL?  I do not want just anyone having read access to my directory.  Maybe I am missing something

----------

## zhenlin

If you can get PAM to authenticate as a non-POSIX user, then you can grant that user access to all non-password fields of all the users, and auth access to the password fields.

But don't forget: LDAP is also a directory service. You can look up the phone numbers, email addresses - whatever they've put into their LDAP user entry if you allow all users to have read access.

----------

## ozric100

I think you need to let * read the uid and gid the get ldap_pam to work. maybe more..  any user on your system can read the /etc/passwd file anyway.  I had a bear of a time with ACL's too.   BTW the example in the the HOWTO never worked for me.   If you alread have a stack of acls you might try the break to see where things are hanging up.

----------

## shomer

 *Koon wrote:*   

>  *shomer wrote:*   I have exactly this problem. I can login on any machine from the console but not via ssh. I can also login as a local user and su to the ldap user.
> 
> My /etc/pam.d/sshd file and sys-auth are as quoted in the HOWTO.
> 
> I've googled but everything *seems* to be correct. Does anyone have any idea how to debug this?
> ...

 

It didn't have UsePAM enabled but it does now (and the servers have been started).

The following ldap activity is recorded on an attempted login.

```

slapd starting

daemon: conn=0 fd=9 connection from IP=127.0.0.1:36224 (IP=0.0.0.0:389) accepted.

ber_flush: 14 bytes to sd 9

conn=0 op=1 BIND dn="" method=128

ber_flush: 14 bytes to sd 9

conn=0 op=1 RESULT tag=97 err=0 text=

conn=0 op=2 SRCH base="dc=idoru,dc=org" scope=2 filter="(&(objectClass=posixAccount)(uid=thomer))"

ber_flush: 307 bytes to sd 9

conn=0 op=2 ENTRY dn="uid=thomer,ou=People,dc=idoru,dc=org"

ber_flush: 14 bytes to sd 9

conn=0 op=2 SEARCH RESULT tag=101 err=0 text=

conn=0 op=3 SRCH base="dc=idoru,dc=org" scope=2 filter="(&(objectClass=shadowAccount)(uid=thomer))"

ber_flush: 93 bytes to sd 9

conn=0 op=3 ENTRY dn="uid=thomer,ou=People,dc=idoru,dc=org"

ber_flush: 14 bytes to sd 9

conn=0 op=3 SEARCH RESULT tag=101 err=0 text=

conn=0 op=4 SRCH base="dc=idoru,dc=org" scope=2 filter="(&(objectClass=shadowAccount)(uid=thomer))"

ber_flush: 93 bytes to sd 9

conn=0 op=4 ENTRY dn="uid=thomer,ou=People,dc=idoru,dc=org"

ber_flush: 14 bytes to sd 9

conn=0 op=4 SEARCH RESULT tag=101 err=0 text=

daemon: conn=1 fd=15 connection from IP=127.0.0.1:36225 (IP=0.0.0.0:389) accepted.

ber_flush: 14 bytes to sd 15

conn=1 op=1 BIND dn="" method=128

ber_flush: 14 bytes to sd 15

conn=1 op=1 RESULT tag=97 err=0 text=

conn=1 op=2 SRCH base="dc=idoru,dc=org" scope=2 filter="(&(objectClass=shadowAccount)(uid=thomer))"

ber_flush: 93 bytes to sd 15

conn=1 op=2 ENTRY dn="uid=thomer,ou=People,dc=idoru,dc=org"

ber_flush: 14 bytes to sd 15

conn=1 op=2 SEARCH RESULT tag=101 err=0 text=

conn=-1 fd=15 closed

```

Thanks again.

----------

## Stalione

Hello Koon,

     Thanks for the great how-to.  I followed the direction very carefuly and I have attempted this on two different machines and I have ended up with the exact same results.  Here's the trouble:

[1] Can not get Transport Layer Security to work.  I have to uncheck that option in DirectoryAdministrator to get it to connect.  Also in your guide you did no mention how to generate the ldap.pem keys (perhaps you wanted the readers to use the default one that come with the ebuild)

[2] Once I have made the connection with directoryadministrator, I was able to create a users group and also add a user and assign the user to that group.  But when I tried to shell into the box over ssh and on console, I could not get it.  It said permission denied.

 *Quote:*   

> 
> 
> Received disconnect from 192.168.1.101: 2: Too many authentication failures for vavarachen
> 
> 

 

[3] I am very unclear on what exactly does getent do.  I did not find any man pages on it.  From my understanding it should show you all the entries in the database (passwd or group) from the respective files and the ldap. But this was not the case with me cause doing

 *Quote:*   

> 
> 
> mirage root # getent group | grep 100
> 
> mirage root # getent passwd | grep vavarachen
> ...

 

did not get me any results.  

[4]  <added this question after getting user authentication working (see next post)>

I don't understand why when I attempt to change the root password, it prompts me for password 4 times?  I thought maybe this was because the root user is the master user listed in slapd.conf (hence in ldap) and ofcouse root user is also in the passwd file.  So I decided to change the password of the games user.  It prompted me 4 times  :Sad: 

 *Quote:*   

> 
> 
> mirage home # passwd games
> 
> New UNIX password: 
> ...

 

I will be happy to post any of my config files, I assure  you that I have gone over it multiple times and not found anything suspicious...but then again there is always a chance I missed something obvious.Last edited by Stalione on Sat Nov 15, 2003 8:34 am; edited 1 time in total

----------

## Stalione

I started to think about how the whole TLS dealy wasn't really working out, then it suddenly hit me, in my /etc/ldap.conf file I have ssl start_tls line.  I commented it out and sure enough I was able to log in as vavarachen.

----------

## Koon

 *shomer wrote:*   

> The following ldap activity is recorded on an attempted login.

 

OK, so there is LDAP activity when you try to log in, at least the SSH->PAM->LDAP connection seems to be OK. Now, two possibilities : (1) LDAP returns everything is OK ans PAM has a problem and considers it shouldn't let the user in anyway, and (2) LDAP has a problem and returns the user is not OK. We should be able to tell between the two problems from the LDAP trace.

I don't have my LDAP setup here at home so I can't compare your trace to mine yet. Maybe you should try to get more trace information (for example the detailed entries returned, I don't remember the exact debug level needed  :Wink:  )

-K

----------

## Koon

 *Stalione wrote:*   

> [1] Can not get Transport Layer Security to work.

 

Given the number of persons having problems with this one, I begin to suspect there have been changes since the ebuilds I used and the default values don't suffice anymore. I will try this again from the beginning when I have time.

 *Stalione wrote:*   

> Also in your guide you did no mention how to generate the ldap.pem keys (perhaps you wanted the readers to use the default one that come with the ebuild)

 

From what I remember, they are generated during first start or something like that.

 *Stalione wrote:*   

> [3] I am very unclear on what exactly does getent do.

 

getent does a libC system call and returns corresponding admin DB information. The system call uses the nsswitch.conf file to see where it should look for information (in our case : "files ldap") and returns all information found. It serves to test that both standard Unix files and LDAP data are taken into account in system calls.

See an old Unix Getent man page

 *Quote:*   

> But this was not the case with me cause doing
> 
>  *Quote:*   
> 
> mirage root # getent group | grep 100
> ...

 

Does it work now that SSH is working ?

 *Quote:*   

> [4] I don't understand why when I attempt to change the root password, it prompts me for password 4 times?  I thought maybe this was because the root user is the master user listed in slapd.conf (hence in ldap) and ofcouse root user is also in the passwd file.  So I decided to change the password of the games user.  It prompted me 4 times 

 

It's probably a problem in the passwd PAM configuration. For example, you "required" (rather than "sufficient") pam_unix and pam_ldap to do the change, so it does them two times. Check (or post here) your system-auth PAM file.

-K

----------

## Stalione

Koon,

     Before I go on to try the things you have suggested, I want to resolve a really strange issue I am having.  No boxes can ssh to the ldap server. (I normally do not allow root to ssh in but this is a test box)

 *Quote:*   

> 
> 
> ssh: connect to host 192.168.1.101 port 22: Connection refused
> 
> bash-2.05b$ ssh root@192.168.1.101
> ...

 

I can ping the box just fine but I can't ssh into it.  Also from the console on the ldap server I am able to ssh to localhost.  What could be causing this?  I noticed that in sshd_conf file i have PAM=yes option set, but I don't even get a login prompt, so it can't be PAM or LDAP.  I have a strong suspicion that its something to do with the nsswitch.conf file.  All I did was change the passwd, shadow and group entry to reflect files ldap.  Rest was left untouched.  Please help.

----------

## Stalione

As oddly as the ssh problem came about, oddly enough it also went away after a reboot.  Koon thank you for the getent man pages link.  Here are the contents of my system_auth file:

 *Quote:*   

> 
> 
> #%PAM-1.0
> 
> auth       required     /lib/security/pam_env.so
> ...

 

Where do I need to change required to sufficient.  Other than only getting one password change prompt, what other side effects can I expect?

UPDATE

It turns out that I accidently selected the same IP for this ldap dev box as I had assigned to one of the workstations.  The whole ssh fiasco happened due to IP conflict.

----------

## Lightspeed

I don't suppose anyone can help me out with getting my gentoo machines to auth using LDAP with a Windows Server 2003 based Active Directory? I have installed windows services for unix 3 on the domain controller to update the AD schema so that it can theoretically support this, but beyond that I don't seem to be having much success. Pretty much the only other thing that did work was I managed to use Samba from the linux boxes to add a computer account for them into the AD.

----------

## Koon

 *Lightspeed wrote:*   

> I don't suppose anyone can help me out with getting my gentoo machines to auth using LDAP with a Windows Server 2003 based Active Directory?

 

It's already difficult to help from a distance when it's full Gentoo and theorically fully supported and working, I won't try to help in mixed, half-supported and half-working environments. You should seek help from someone who already did the same thing. Maybe on the OpenLDAP forum ?

PS : Stalione : glad you made it  :Wink:  The "I rebooted and it worked" is a good explanation on Windows, but on Linux there is always a reason : I guess two machines on the same IP is a good one  :Wink: 

-K

----------

## Stalione

Koon,

     LDAP is working great (except TLS)!  I am actually setting this up  for a small project and plan to tie in a lot of other services to ldap for authentication.

[1] subversion

[2] Mail, Calendar, Address book etc. (groupware)

[3] Apache (instead of using htaccess, ill use mod_ldap)

[4] Jabber (possibly)

[5] FTP (ProFTPD using pam support)

One of my current concerns is how can users change their passwords (and other organizational info like phone, name etc) without bothering me, without me giving write access to ldap for each user etc.  Would I need to give each user shell access for them to change password (I hope not)?  Also does anyone have any experience setting up any of the above mentioned services to authenticate against ldap, if so please share the info.

----------

## Koon

 *Stalione wrote:*   

> One of my current concerns is how can users change their passwords (and other organizational info like phone, name etc) without bothering me, without me giving write access to ldap for each user etc.  Would I need to give each user shell access for them to change password (I hope not)?

 

I see two ways of doing it : the classic way is to have an ACL allowing "self write" and use LDAP scripts to bind and modify attributes (as this particular user). The other way is to use a generic admin LDAP account and check user credentials before doing modifications (as the generic admin LDAP user). The two can be implemented as CGI scripts accessible with a web server. You don't need the shell access !

 *Quote:*   

> Also does anyone have any experience setting up any of the above mentioned services to authenticate against ldap, if so please share the info.

 

I did a exim/courier-imap LDAP bind and I heavily hacked webcalendar to get it to authenticate/auto-create accounts against LDAP. Address book : Mozilla can use anonymous access to get LDAP information. No experience in mod_ldap, Jabber or ProFTPD.

-K

----------

## eliemedeiros

hi,

I have setup everytihing as detailed in the tutorial, and PAM + LDAP authentication works ine when I am logged into the machine. In fact it works fine when I log in via SSH too - however I have a problem when trying to su from within the shell opened via SSH. so for instance if I try:

```
su root
```

I get:

```

zcrar70@brassai zcrar70 $ su root

Password:

su: unbind.c:40: ldap_unbind_ext: Assertion `( (ld)->ld_options.ldo_valid == 0x2 )' failed.

```

when I try to su to another user, i get:

```

zcrar70@brassai zcrar70 $ su tung

Password:

Segmentation fault

```

in both cases the passwords are correct. I can ssh into the box with user tung but i can't su to him if i am logged in via ssh. I can't login as root via ssh as this is disabled.

my setup is as follows:

/etc/pam.d/su:

```

auth       sufficient   /lib/security/pam_rootok.so

auth       required     /lib/security/pam_wheel.so use_uid

auth       required     /lib/security/pam_stack.so service=system-auth

account    required     /lib/security/pam_stack.so service=system-auth

password   required     /lib/security/pam_stack.so service=system-auth

session    required     /lib/security/pam_stack.so service=system-auth

session    optional     /lib/security/pam_xauth.so

```

/etc/pam.d/system-auth:

```

auth       required     /lib/security/pam_env.so

auth       sufficient   /lib/security/pam_unix.so likeauth nullok nodelay

auth       sufficient   /lib/security/pam_ldap.so use_first_pass

auth       required     /lib/security/pam_deny.so

#account    required    /lib/security/pam_ldap.so ignore_unknown_user ignore_authinfo_unavail

#account    required    /lib/security/pam_unix.so

account    required     /lib/security/pam_unix.so

account sufficient      /lib/security/pam_ldap.so       use_first_pass

password   required     /lib/security/pam_cracklib.so retry=3

password   sufficient   /lib/security/pam_unix.so nullok md5 shadow use_authtok

password   sufficient   /lib/security/pam_ldap.so use_authtok

password   required     /lib/security/pam_deny

session    required     /lib/security/pam_limits.so

session    required     /lib/security/pam_unix.so

session    optional     /lib/security/pam_ldap.so

```

I use openssh 3.7.1_p2, openssl 0.9.7c, openldap 2.1.22-r1, nssldap 211, pamldap 161. Any ideas why this is happening?

thanks,

Nick

----------

## Koon

 *eliemedeiros wrote:*   

> I have a problem when trying to su from within the shell opened via SSH.

 

It works if you're connected locally and do an su and it borks when you do the same while on ssh ? Weird... The segfault and assert tend to incriminate pam_ldap code (or pam_ldap compilation), maybe it's a bug triggered by special terminal configs (that would explain the difference in behaviour between console access and ssh access)...

It would be interesting to look at what the unbind.c contains around line 40 in the sources used to compile pam_ldap on the client machine... although my little C and pam knowledge might not be enough to understand what's going on here. Maybe the Portage & Programming forum would be more appropriate...

-K

----------

## eliemedeiros

apologies - I made a mistake in the post above: I was quite sure I had tested this at home in front of the box as well as from the office via ssh, but apparently I hadn't.  :Embarassed: 

So to correct my previous post, the seg fault and errors on su appear both from the console and from within ssh.

Will try to find unbind.c this evening when i get back home - I think I read something about someone else having a similar problem due to compiling with a different verson of openssl than what the pam_ldap author had compiled with (now where was that????  :Crying or Very sad:  )- will post back here if i find out more

thanks Koon - 

Nick

//Added later:

here's some stuff I found:

http://www.openldap.org/lists/openldap-general/200001/msg00058.html:

 *Quote:*   

> 
> 
> I saw smtg like that with applications like su, who fork. The problem was not
> 
> in pam_ldap
> ...

 

http://lists.debian.org/debian-devel-announce/2001/debian-devel-announce-200110/msg00012.html:

 *Quote:*   

> Package: libpam-ldap (debian/main)
> 
> Maintainer: Sami Haahtinen <ressu@debian.org>
> 
>   107707 makes su and others segfault
> ...

 

http://www.netsys.com/pamldap/2002/10/msg00025.html

 *Quote:*   

> 
> 
> I found this same situation and fixed it by adding "-B group" to the LDFLAGS
> 
> to force the pam_ldap module to resolve its symbols against the specified
> ...

 

(not quite sure what the equivalent to LDFLAGS is in Gentoo...)

these are all a bit old though (2001) - the problems listed there might have been sorted out since....

any feedback/insight/suggestions appreciated.

----------

## adamtheo

eliemedeiros: I am having the exact same problem with my setup over SSH (can't try locally). Unfortunately, I'm intending this to be a very stable, secure production server, so can't afford to go messing around with all those options and files without running the risk of breaking something later. I really hope a simple fix can be found, hopefully by just emerging some updated ebuilds to certain packages. I'll be watching for any updates to this, thanks.

BTW, I have the following packages:

nss_ldap 211

pam_ldap 161

openldap 2.1.22-r1

note that there are the only ~x86 (unstable) packages I have installed on my system, the rest of the system is stable (x86) (with the exeption of db4 for berkeleydb support in openldap)

Koon: thanks again for this guide, it helped me early on  :Smile: 

----------

## eliemedeiros

following Koon's suggestion, I have posted a thread concerning the pam_ldap + su segfault to 

https://forums.gentoo.org/viewtopic.php?t=108015 in the Portage & Programming forum

Nick

----------

## numerodix

One question.. ldap is just for authentication, right? Are the user accounts moved to the server as well then?

----------

## tank

 *numerodix wrote:*   

> One question.. ldap is just for authentication, right? Are the user accounts moved to the server as well then?

 

Oh no, LDAP is for many things Auh is just one of them.  It can be used for a address book, like what large companies use.  It can be used for any type of data that is read heavy, and write light.  Also good for data that can be structured in a tree type format.

As for Auth the user accounts stay on the LDAP, they are never "moved" to the server.  They appear as part of the servers user accounts, however if the LDAP goes down those accounts cease to exist.

----------

## unstable_geek

hello all.

i have disabled TLS for now, so my slapd.conf file is:

```

include         /etc/openldap/schema/core.schema

include         /etc/openldap/schema/cosine.schema

include         /etc/openldap/schema/nis.schema

include         /etc/openldap/schema/inetorgperson.schema

pidfile         /var/state/openldap/slapd.pid

argsfile        /var/state/openldap/slapd.args

access to dn=".*,dc=infinitylimited,dc=net" attr=userPassword

         by dn="cn=root,dc=infinitylimited,dc=net" write

         by self write

         by * auth

access to dn=".*,dc=infinitylimited,dc=net"

         by * read

defaultaccess none

database        ldbm

suffix          "dc=infinitylimited,dc=net"

rootdn          "cn=root,dc=infinitylimited,dc=net"

rootpw          {MD5}6E/0sWh7/8lBmKUThDluQg==

directory       /var/state/openldap/openldap-ldbm

index           cn,surname,givenname                  eq,subinitial

```

I start slapd (after editing the init.d/slapd file)

```

/usr/lib/openldap/slapd -s 7

```

which presents this:

```

Dec 27 15:07:16 coal slapd[24001]: daemon_init: <null>

Dec 27 15:07:16 coal slapd[24001]: daemon_init: listen on ldap:///

Dec 27 15:07:16 coal slapd[24001]: daemon_init: 1 listeners to open...

Dec 27 15:07:16 coal slapd[24001]: daemon: initialized ldap:///

Dec 27 15:07:16 coal slapd[24001]: daemon_init: 1 listeners opened

Dec 27 15:07:16 coal slapd[24001]: slapd init: initiated server.

Dec 27 15:07:16 coal slapd[24002]: slapd startup: initiated.

Dec 27 15:07:16 coal slapd[24002]: slapd starting

```

getent works fine, I get all the users defined in my /etc/passwd file.

I had problems with the base.ldif file, but it must have been weird characters or something.  I split the file into 3 files and it went fine.

Since my goal is a shared address book only at this stage, I configured KDE to use ldap, by adding a resource into the address book section of KDE config.

Resource Settings:

User: root

Password: ******  :Smile: 

Host: localhost

Port: 389

Dn: cn=root,dc=infinitylimited,dc=net

Filter: <blank>

when I fire up Kaddressbook, I see this in the server log:

```

Dec 27 15:47:32 coal slapd[24008]: connection_get(9): got connid=11

Dec 27 15:47:32 coal slapd[24008]: connection_read(9): checking for input on id=11

Dec 27 15:47:32 coal slapd[24008]: ber_get_next on fd 9 failed errno=11 (Resource temporarily unavailable)

Dec 27 15:47:32 coal slapd[24014]: do_bind

Dec 27 15:47:32 coal slapd[24014]: bind: invalid dn (root)

Dec 27 15:47:32 coal slapd[24014]: send_ldap_result: conn=11 op=0 p=2

Dec 27 15:47:32 coal slapd[24014]: send_ldap_result: 34::invalid DN

Dec 27 15:47:32 coal slapd[24014]: send_ldap_response: msgid=1 tag=97 err=34

```

help?  :Confused: 

----------

## Koon

Looks like a bug in Kaddressbook : it uses the user (root) instead of the DN (cn=root,dc=infinitylimited,dc=net) to bind...

-K

----------

## unstable_geek

are you sure it uses root? I run KDE as me not root.....

----------

## Koon

 *unstable_geek wrote:*   

> are you sure it uses root? I run KDE as me not root.....

 

I take it from your logs :

```
Dec 27 15:47:32 coal slapd[24014]: bind: invalid dn (root)
```

It should try to bind with DN="cn=root,dc=infinitylimited,dc=net", not DN="root".

-K

----------

## Gushy

I'm having trouble getting su to work for ldap users.  I know I can comment out the auth line /etc/pam.d/su so that users don't have to be in the wheel group, but I *want* them in the wheel group.  I also know I can add the ldap users to the wheel line in /etc/group but I don't want to have to do that either.

I've got a wheel group in my directory and it even has the same gid as the normal wheel group (I used the migration tool) and I've added a user I created to the wheel group; but I just get 'Permission denied' when I try to su.

Anyone got a surefire way of getting su to work for ldap users?

----------

## Gushy

Just came across another two problems that I can't see or find the answer to.

How can I change the permissions for an ldap users home when it's created?  it's currently set as 644, which is not good cos it's world readable and the group can read - not good when all my users are members of the users group.

One solution to the group permissions problem is to add a group first with the name of the user and make that group the primary user. A bit long winded and not ideal cos it doesn't solve the world readable bit.  One thing I noticed with this method is that when doing an ls -la the group ownership is shown as the gid and not the group name.  How can I fix that?

UPDATE - SOLVED

ok so I found the umask setting, it was in /etc/pam.d/system-auth on the line:

```
session    required     /lib/security/pam_mkhomedir.so skel=/etc/skel/ umask=0022
```

----------

## Koon

 *Gushy wrote:*   

> I'm having trouble getting su to work for ldap users.  I know I can comment out the auth line /etc/pam.d/su so that users don't have to be in the wheel group, but I *want* them in the wheel group.  I also know I can add the ldap users to the wheel line in /etc/group but I don't want to have to do that either.
> 
> I've got a wheel group in my directory and it even has the same gid as the normal wheel group (I used the migration tool) and I've added a user I created to the wheel group; but I just get 'Permission denied' when I try to su.

 

I suppose you somewhat have to stack an LDAP module in the su pam configuration in the right order, but I don't have the exact syntax at hand.

Personally I use a per-machine wheel group (people allowed to su are not the same from machine to machine) so I keep them in the static file.

-K

----------

## Gushy

 *Koon wrote:*   

> 
> 
> I suppose you somewhat have to stack an LDAP module in the su pam configuration in the right order, but I don't have the exact syntax at hand.
> 
> 

 

Yeah that's what I figured, but I'm buggered if I can find the changes I need to make.  :Sad: 

 *Koon wrote:*   

> 
> 
> Personally I use a per-machine wheel group (people allowed to su are not the same from machine to machine) so I keep them in the static file.
> 
> 

 

Ah, on my network the only people allowed to su are the same on every machine so a working ldap solution is definitely the best method.

----------

## Tarball

I recently set up a second machine which I have networked, I fancied centralised user auth so I'm giving openldap a go.

Unfortunately I didn't get very far!

I edited the config files as specified at the top of this thread.  This raises my first question, there seems to be a /etc/ldap.conf and /etc/openldap/ldap.conf what is the deal with this? Are they both used?  What goes in which file?

Skipping over that I followed the guide made my changes to /etc/openldap/ldap.conf, I started the service but when I try to access the LDAP service I get the following debug info:

```

chaos openldap # ldapsearch -D "cn=Manager,dc=natty,dc=org.uk" -W -d 255

ldap_create

Enter LDAP Password:

ldap_bind_s

ldap_simple_bind_s

ldap_sasl_bind_s

ldap_sasl_bind

ldap_send_initial_request

ldap_new_connection

ldap_int_open_connection

ldap_connect_to_host: localhost

ldap_new_socket: 3

ldap_prepare_socket: 3

ldap_connect_to_host: Trying 127.0.0.1:389

ldap_connect_timeout: fd: 3 tm: -1 async: 0

ldap_ndelay_on: 3

ldap_is_sock_ready: 3

ldap_is_socket_ready: error on socket 3: errno: 111 (Connection refused)

ldap_close_socket: 3

ldap_perror

ldap_bind: Can't contact LDAP server
```

As you can see from the debug it is failing to connect to the socket, this isn't really suprising as netstat -atn reveals:

```

Active Internet connections (servers and established)

Proto Recv-Q Send-Q Local Address           Foreign Address         State

tcp        0      0 0.0.0.0:1026            0.0.0.0:*               LISTEN

tcp        0      0 0.0.0.0:111             0.0.0.0:*               LISTEN

tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN

tcp        0      0 0.0.0.0:636             0.0.0.0:*               LISTEN

tcp        0      0 192.168.0.5:22          192.168.0.2:53205       ESTABLISHED

tcp        0      0 192.168.0.5:22          192.168.0.2:58252       ESTABLISHED

tcp        0      0 192.168.0.5:22          192.168.0.2:58267       ESTABLISHED

tcp        0      0 192.168.0.5:22          192.168.0.2:58393       ESTABLISHED
```

or netstat -at:

```

Active Internet connections (servers and established)

Proto Recv-Q Send-Q Local Address           Foreign Address         State

tcp        0      0 *:1026                  *:*                     LISTEN

tcp        0      0 *:sunrpc                *:*                     LISTEN

tcp        0      0 *:ssh                   *:*                     LISTEN

tcp        0      0 *:ldaps                 *:*                     LISTEN

tcp        0      0 chaos.natty.org.uk:ssh  ecco.natty.org.uk:53205 ESTABLISHED

tcp        0      0 chaos.natty.org.uk:ssh  ecco.natty.org.uk:58252 ESTABLISHED

tcp        0      0 chaos.natty.org.uk:ssh  ecco.natty.org.uk:58267 ESTABLISHED

tcp        0      0 chaos.natty.org.uk:ssh  ecco.natty.org.uk:58393 ESTABLISHED
```

So I guess the question is should there be a server listening on port 389???

Cheers

----------

## Koon

 *Tarball wrote:*   

> there seems to be a /etc/ldap.conf and /etc/openldap/ldap.conf what is the deal with this? Are they both used?  What goes in which file?

 

/etc/openldap/ldap.conf is part of the openldap package. It contains system-wide defaults to be applied when running ldap clients (see man ldap.conf).

/etc/ldap.conf is part of the nss_ldap package and contains the configuration to use with NSS to retrieve its information (passwd, groups...) from LDAP.

 *Quote:*   

> 
> 
> ```
> tcp        0      0 *:ldaps                 *:*                     LISTEN
> ```
> ...

 

You have an LDAPS server but no LDAP server. Which servers get started depend on your /etc/conf.d/slapd contents... But you should be able to test access to the LDAPS server using ldapsearch, maybe using the -H option ?

-K

----------

## Stalione

Hi Koon,

         Its been a while since I worked on my ldap server.  For some reason (i can't remember why) I ended up restoring all the changed i had made to slapd.conf, pam.d/* and ldap.con...now I am trying to redo the ldap server.  I have it up and running but once again I cannot get TLS to work.  Also I noticed that even though I have the TLS lines specified in the config file, and the slapd daemon starts up without errrors, I do not see slapd listening on 686 port, only 389.  Any clues why?

 from slapd.conf 

```

TLSCertificateFile      /etc/openldap/ssl/ldap.pem

TLSCertificateKeyFile   /etc/openldap/ssl/ldap.pem

TLSCipherSuite HIGH:+MEDIUM:+SSLv2

```

Also as a side note, the permissions on ldap.pem should be 440, with ldap as owner and group.

[b] netstat output [b]

```

Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name

tcp        0      0 0.0.0.0:389             0.0.0.0:*               LISTEN      32421/slapd

tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      28765/apache2

tcp        0      0 0.0.0.0:21              0.0.0.0:*               LISTEN      1141/proftpd: (acce

tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      1025/sshd

tcp        0      0 0.0.0.0:443             0.0.0.0:*               LISTEN      28765/apache2

```

----------

## drdabbles

Hello all,

  I am trying to implement LDAP authentication on a test system I am building.  Of course, I am having no luck because I am not following the directions to a "T".    :Confused: 

  Anyway, the trouble I am having is that I would like to use ".local" instead of ".com/.net/.whatever".  I saw a note somewhere that I should be using a real TLD, but I wanted to know how true this really is.  I know I have to play with my internal DNS here to get things right with the TLS, and that is causing some errors right now.  So, basically, should I expect breakage if I decide to use .local?

----------

## Koon

 *Stalione wrote:*   

> I have it up and running but once again I cannot get TLS to work.  Also I noticed that even though I have the TLS lines specified in the config file, and the slapd daemon starts up without errrors, I do not see slapd listening on 686 port, only 389.  Any clues why?

 

There are two ways of doing encryption with LDAP : TLS over LDAP (port 389) and LDAPS port 686. In the first case the client asks for TLS and establishes an encrypted tunnel. In the second it's always encrypted.

In your case maybe TLS is working but only the LDAP server (port 389) was started.

You have to use the -h option in slapd to start on port 389 and/or port 686 (something like slapd -h "ldap:// ldaps://").

-K

----------

## Koon

 *drdabbles wrote:*   

> So, basically, should I expect breakage if I decide to use .local?

 

I don't think so. You can name your LDAP domain whatever you wish. The only problem I see would be the TLS certificate domain, which should probably match the name of your machine.

-K

----------

## Stalione

Koon,

   You are correct.  I had TLS enabled but did not start it.  All I had to do was merely edit /etc/conf.d/slapd.conf and uncomment the line that enabled it.  Also I'd like to share a great document I came across on the openldap.org site.   OpenLDAP TLS/SSL howto 

I just got done make the changes and I see that i have ldap listening on 636.  I'll post the results of my tests, which is to get diradmin tool to connected over tls/ssl.

 UPDATE (some info changed to protect the innocent)

 *Quote:*   

> 
> 
> mirage ssl # ldapsearch -x -b 'dc=mydomain,dc=com' -D "cn=root,dc=mydomain,dc=com" '(objectclass=*)' -H ldaps://localhost -W
> 
> Enter LDAP Password:
> ...

 

So I guess it still did not work.

----------

## drdabbles

 *Stalione wrote:*   

> Koon,
> 
> <--SNIPPED-->
> 
>  *Quote:*   
> ...

 

Try adding "-d 255" to that command line, so you can see where and why it is failing.  I was having quite a time trying to get TLS/SSL working properly, so definately be careful there.  Really, you want to pay the most attention to your hostname / domain name / FQDN, certificate / keyfiles, etc.

Just thought I'd throw that in there to see if it helps.    :Confused: 

----------

## Stalione

drdabbles you rock dude!  that was it.  adding that -d 255 really helped.  It clearly told me what the issues was.  In my command I was using ldaps://locahost , well it didn't like that and wanted the FQDN.  After adding the right FQDN, the command spewed out loads of output, mostly all the members (ou's) in the ldap.  

However, it still did not work for me when I treid to use directory administrtor.  In my profile I had specified just the first part of the hostname since it was in my /etc/hosts file.  I replaced it with the FQDN and it still did not work.  Any clues?

----------

## drdabbles

Stalione,

Are you running the admin. program on the same physical system that the LDAP server is on?  Also, are you trying to use the TLS encryption in directory_administrator?  I had a bit of trouble with that one, so I decided to turn off the TLS bits.  Of course, that wasn't in a production environment.

The biggest issues I found that caused trouble had to do with host / domain names.  This, of course, is due to the SSL components, because things have to be just right for it to work again   :Razz: 

----------

## axxackall

in my case lda=ssh problem was solved in two steps.

1st, this option in /etc/ssh/sshd_config forced ssh to use PAM:

```

UsePAM yes

```

Then directly pointing  in /etc/pam.d/sshd to ldap finished the job:

```

#%PAM-1.0

auth       required     /lib/security/pam_nologin.so

auth       sufficient   /lib/security/pam_ldap.so

auth       required     /lib/security/pam_unix_auth.so try_first_pass

account    sufficient   /lib/security/pam_ldap.so

account    required     /lib/security/pam_unix_acct.so

password   required     /lib/security/pam_cracklib.so

password   sufficient   /lib/security/pam_ldap.so

password   required     /lib/security/pam_pwdb.so use_first_pass

session    required     /lib/security/pam_unix_session.so

```

that means that if you follow the Gentoo OpenLDAP Authentication doc then you will have /etc/pam.d/sshd pointing to system-auth, which is not working for sshd. I don't know why, but /etc/pam.d/sshd must be configured to use ldap directly, not through system-auth.

----------

## drdabbles

 *axxackall wrote:*   

> in my case lda=ssh problem was solved in two steps.
> 
> that means that if you follow the Gentoo OpenLDAP Authentication doc then you will have /etc/pam.d/sshd pointing to system-auth, which is not working for sshd. I don't know why, but /etc/pam.d/sshd must be configured to use ldap directly, not through system-auth.

 

Wow, this would have been SO helpful two days ago.  I just got tired of researching everything along the way...so I unmerged LDAP.  I admin the stations via SSH, so when I couldn't log back in...I got a bit pissy.  Anyway, good tip!  Thanks a bunch!

----------

## Meleni

I have found a partial fix for the su/wheel problem.

A look around the net told me that when you have a group in both a file and the LDAP directory, only the first is checked.  Because LDAP users are not in your group file, it returns a fail.  The "fix" is to remove your wheel group from the group file.

On my machine, this is tested to, well, a point of failure.  But I have also read that you need a root user in your LDAP directory to get it to work correctly.

Without the root user, you will get a segmentation fault.

I don't have a root user, and I get a segmentation fault.  This seems encouraging to me, and at least it's not a permission denied message.

Unfortunately, I'm at work right now and unable to add/test it with a root user.

----------

## Stalione

WARNING:

I upgraded openldap to openldap-2.1.26 and everything fell apart.  I kept getting protocol error when using directory administrator.  I rolled my install back to openldap-2.0.27-r4 and everything is fine now.

I am not sure if this has been mentioned in the last 5 pages on this topic, but if this is a repeat I apologize. Has anyone tried openldap-2.0.27-r5?

----------

## Koon

I found this bug in the SourceForge directoryadministrator project, I think it's related. Looks like OpenLDAP 2.1 requires only one STRUCTURAL objectClass and DA uses more. Not too sure about the workaround though. If anyone tries and succeeds please post...

-K

----------

## ozric100

not sure if this will help but you can turn off the scema checking in 2.1.  I tested out 2.1 a long time ago with Samba 3.0 and all of my conversion scritps were failing.

----------

## utabintarbo

Has this been resolved, or should we stick with openldap-2.0.27-r4 for now?  :Question: 

Bob

----------

## ozric100

I upgraded with no problems.  I use GQ tho so I have no clue about other software.   I have pam, nis and samba3 all working fine. on 2.1

----------

## kitana_ann

Hi all, thanx Koon for starting this thread and writing the howto. 

I have followed the howto on setting up directoryadmin. but when I was going to test connection I get an error: 

```
Connection failed: Protocol error
```

I really dont know what I am doing wrong I have tryed sevaral ways to write in my dn user namn and search base. Nothing helps.

Does anybody know the problem?

----------

## Koon

 *kitana_ann wrote:*   

> I have followed the howto on setting up directoryadmin. but when I was going to test connection I get an error: 
> 
> ```
> Connection failed: Protocol error
> ```
> ...

 

Did you try to disable TLS transport security ? You can have a look at the messages log and see what happens on the server side. Does it receive something ? Do you get an error ?

-K

----------

## weyhan

Hi,

****EDIT****

Never mind, right after I have posted,  I was looking at the ldif file again and find that the empty lines between the sections contain a space from the cnp!!! That's annoying. *grumble* Why can't openldap ignore space only lines and treat other lines starting with space as continuation?!?! *grumble*

Now I was able to initialize the database in one go. However, my question still remains. If I were to add the section in one by one, would it still give me a valid db? and also please explain the statement about the official guide. I don't like to throw out anything without knowing why.

****EDIT****

I have run into a few problem trying out your guide (btw, thanks for this great guide).

When I try to ldapadd for the first time I get this error:

```

# ldapadd -x -D "cn=root,dc=thesource,dc=net" -W -f /root/base.ldif

Enter LDAP Password: 

adding new entry "dc=thesource,dc=net"

adding new entry "ou=People,dc=thesource,dc=net"

ldapadd: update failed: ou=People,dc=thesource,dc=net

ldap_add: Undefined attribute type (17)

        additional info: dn: attribute type undefined

#

```

Then I use a new base.ldif file with only the People section and re-run the ldapadd command and it worked. Following a new base.ldif file with only the Group section and re-run the same ldapadd command and it also worked. (It did not work if I run the ldapadd command the second time with both People and Group section. Strange!)

```

# ldapadd -x -D "cn=root,dc=thesource,dc=net" -W -f /root/base.ldif

Enter LDAP Password: 

adding new entry "ou=People,dc=thesource,dc=net"

# ldapadd -x -D "cn=root,dc=thesource,dc=net" -W -f /root/base.ldif

Enter LDAP Password: 

adding new entry "ou=Group,dc=thesource,dc=net"

```

So, my question is, does that mean I did in fact got the empty ldbm database setup correctly?

Also, I don't understand the comment about the official guide.

 *Quote:*   

> 
> 
> ...(all accounts are migrated, something I advise everyone against)...
> 
> 

 

Why is it bad?

Regards,

----------

## Koon

 *weyhan wrote:*   

> So, my question is, does that mean I did in fact got the empty ldbm database setup correctly?

 

I think it's setup correctly. You can double-check by dumping the LDAP directory content to an LDIF file and checking everything was created OK (using the slapdump -- or is it ldapdump ? -- command).

 *Quote:*   

> Also, I don't understand the comment about the official guide.
> 
>  *Quote:*   
> 
> ...(all accounts are migrated, something I advise everyone against)...
> ...

 

If you migrate system accounts and your network connectivity goes down, nothing will work, you won't be able to log in as root, etc. I prefer to migrate user accounts (so that passwords get replicated from machine to machine) and keep passwordless system accounts in the files. I also prefer to keep the root account in the files as it allows to connect even when the network is down. YMMV...

-K

----------

## weyhan

 *Quote:*   

> I think it's setup correctly. You can double-check by dumping the LDAP directory content to an LDIF file and checking everything was created OK (using the slapdump -- or is it ldapdump ? -- command). 

 

I think you are talking about slapcat, right?

Well, I have compare both and of course the createdTimestamp is different. Apart from that the entryUUID and the entryCSN is also different. not sure if they should. Anyway, I will go ahead with the corrected ldif file.

 *Quote:*   

> If you migrate system accounts and your network connectivity goes down, nothing will work, you won't be able to log in as root, etc. I prefer to migrate user accounts (so that passwords get replicated from machine to machine) and keep passwordless system accounts in the files. I also prefer to keep the root account in the files as it allows to connect even when the network is down. YMMV... 

 

Ah. I see. Thanks for explaining and I think it make more sense in what you suggest.

Regards,

----------

## weyhan

Hi, find this entry in my log file:

```

May 15 01:41:08 theone slapd[2360]: /etc/openldap/slapd.conf: line 59: unknown directive "defaultaccess" outside backend info and database definitions (ignored)

```

Seem to be cause by this line:

```

defaultaccess none

```

I'm using openldap-2.1.26. I wonder if the version support this option? Have anyone seen this problem in their logs?

Also, I am having problem getting directory_administrator to connect via TLS (can't even create the user goup). Having a bad headache now so can't think. I'll try to find the problem maybe tomorrow but if anyone have an idea, please post.

Regards,

----------

## Koon

Apparently the defaultaccess directive is deprecated as of OpenLDAP 2.1.

If any "access" is defined, "defaultaccess none" is implied. If no "access" is defined, "access to * by * read" is implied.

I will correct the first post to reflect this change.

-K

----------

## stormer

Just as information, using LDAP on laptop is possible, but not usefull since you have to create local account to use it offline.  Try using this /etc/system-auth.

auth       required     /lib/security/pam_env.so

auth       sufficient   /lib/security/pam_unix.so likeauth nullok

auth       sufficient   /lib/security/pam_ldap.so use_first_pass

auth       required     /lib/security/pam_deny.so

account    sufficient   /lib/security/pam_unix.so

account    sufficient   /lib/security/pam_ldap.so

account    required     /lib/security/pam_deny.so

password   required     /lib/security/pam_cracklib.so retry=3

password   sufficient   /lib/security/pam_unix.so nullok ssha shadow use_authtok

password   sufficient   /lib/security/pam_ldap.so use_authtok

password   required     /lib/security/pam_deny.so

session    required     /lib/security/pam_mkhomedir.so skel=/etc/skel/ umask=027

session    required     /lib/security/pam_limits.so

session    sufficient   /lib/security/pam_unix.so

session    sufficient   /lib/security/pam_ldap.so

session    required     /lib/security/pam_deny.so

----------

## weyhan

 *Quote:*   

> Also, I am having problem getting directory_administrator to connect via TLS (can't even create the user goup). Having a bad headache now so can't think. I'll try to find the problem maybe tomorrow but if anyone have an idea, please post. 

 

I have found the problem with the connection.  According to the message shown after emerging openldap:

```
 * If you are upgrading from OpenLDAP 2.0, major changes have occured:

[...]

 * - Self-signed SSL certificates are treated harshly by OpenLDAP 2.1

 *   add 'TLS_REQCERT never' if you want to use them.

```

And so I did and the connection went through (though I have to google to find out exactly where I need to add... maybe I should open a bug against the ebuild). However, I don't understand the implication though of adding this line in the /etc/openldap/ldap.conf. Maybe someone who knows ldap better can clearify.

----------

## weyhan

Well, so much for solving a connection problem and then bumping into another immediately... I now can't seem to add a user with directory_administrator. After some investigation, I find that some of the attribute set by directory_administrator is not allowed. Attributes like sn, givenName, mail, and etc.

I suspect that the attribute that failed to add into ldap should not cause too much problem for our purpose. But, I can't even get directory_administrator to continue without setting a givenName. Have anyone seen this problem? Is it related to the following?

 *Koon wrote:*   

> I found this bug in the SourceForge directoryadministrator project, I think it's related. Looks like OpenLDAP 2.1 requires only one STRUCTURAL objectClass and DA uses more. Not too sure about the workaround though. If anyone tries and succeeds please post...
> 
> -K

 

----------

## bruor

has anyone here used phpldapadmin at all? 

i have installed it and gotten it to connect. 

but im having problems adding users

when reading this tutorial it says to create new goups etc,  in phpldap admin it gives an option ot create a new posix group,  is this what i want? 

reguardless when i try to create and groups or users i get the gollowing back. 

 *Quote:*   

> Error
> 
> Could not add the object to the LDAP server.
> 
> LDAP said: Undefined attribute type
> ...

 

but i dont knwo if its referring to the atribute type being the "posix group" or the "user account" 

i have installed the other 2 programs,   i cant get directory administrator to run at all,  gq runs but there doesnt seem to be an intuitive way to add users. 

when i try to run the migration tools i get another error altogether.   when i have another few minutes ill get the error back and post that as well.  maybe ill just try this whole deal over from scratch again..

----------

## Ian

I hate LDAP, causes me so much pain...

Trying to setup a LDAP server for my school's 10 or so Macs, I get everything working, and ready to start adding users, and I get this...

```

photo migrationtools # ldapadd -D "cn=Manager,dc=smithtown,dc=k12,dc=ny,dc=us" -W -f /tmp/base.ldif

Enter LDAP Password:

adding new entry "dc=ny,dc=us"

ldapadd: update failed: dc=ny,dc=us

ldap_add: Server is unwilling to perform (53)

        additional info: referral missing

```

I got this same problem when trying with Debian.

Why am I so stupid that I can't get around this problem?  I have less than a week left of school, and I'd like to finish this, so any help is appreciated.

----------

## atac

i'm trying to migrate the user accounts, everything works fine

except the /etc/passwd file:

```

marvin migrationtools # ./migrate_passwd.pl /etc/passwd /tmp/passwd.ldif

marvin migrationtools # ldapadd -D "cn=Manager,dc=hgttg,dc=net" -W -f /tmp/passwd.ldif

Enter LDAP Password:

adding new entry "uid=root,ou=People,dc=hgttg,dc=net"

ldapadd: update failed: uid=root,ou=People,dc=hgttg,dc=net

ldap_add: Object class violation (65)

        additional info: invalid structural object class chain (inetOrgPerson/account)

```

any ideas?

----------

## jayjay

Atac wrote:

 *Quote:*   

> adding new entry "uid=root,ou=People,dc=hgttg,dc=net" 
> 
> ldapadd: update failed: uid=root,ou=People,dc=hgttg,dc=net 
> 
> ldap_add: Object class violation (65) 
> ...

 

A dirty workaround, that I used myself.

Add to slapd.conf

```

schemacheck off

```

The Reason may be discusses in that message:

http://www.openldap.org/lists/openldap-software/200306/msg00293.html

http://www.netsys.com/openldap-software/2004/02/msg00431.html

----------

## runge

Hi, I have tried to install ldap using this howto but I have got the same problem as a couple of ppl before.

When I try to connect using directoryadministrator (not using TLS) I get 

```
Protocol error
```

The server log says

```
ldap slapd[19819]: conn=4 op=0 RESULT tag=97 err=2 text=requested protocol version not allowed
```

ldap version is 2.1.26 

directoryadministrator version 1.5.1

any ideas?

*************************SOLVED****************

That problem is solved by adding

allow bind_v2

in the slapd.conf file

I hope that helps

************************************************

----------

## Diezel

Has anyone solved the issue with using 

```
'TLS_REQCERT never'
```

with OpenLDAP?

I want to use my own certificate and key and I can't get the server started with them.

The problem is, I don't know where to add the

```
'TLS_REQCERT never'
```

part.

Anyone with info on this, please post to this thread.

----------

## thompsonmike

I am considuring this for my 8 Gentoo servers and user accounts. 

The only thing that is holding me back is the mail server, would this impact on the mailserver, or would Postfix witht the correct settings be happy? I have no need for virtual domains or anything else. Usres have accounts on the mail server. 

I had alook at the Postfix howtos for LDAP and all they mention is Virtual domains. 

Any ideas on weather Postfix could cope without having any major impact?

----------

## runge

I might be totaly mistaken, but maybe you should try something simpler like qmail.

Though its just what I have heard. I myself have only tried postfix and failed (the official virtual mail howto). For me there were to many components involved..

----------

## irondog

Fucking nothing works in this howto. I do exactly as said:

ldapadd -x -D "cn=root,dc=example,dc=com" -W -f /root/base.ldif

Enter LDAP Password:

ldapadd: no attributes to change or add (entry="dc=example,dc=com dc: yourcompany objectClass: top objectClass: domain dn: ou=People,dc=example,dc=com ou: People objectClass: top objectClass: organizationalUnit   dn: ou=Group,dc=example,dc=com ou: Group objectClass: top objectClass: organizationalUnit")

Directory_administrator never works: always a protocol error. Am I too stupid or do I forget something?

----------

## weyhan

Hey Koon,

I have finally got openldap to work with pam. Thanks for the howto, though it did not work right for me, it was a good starting point. So, since I have learn a great deal, it's time to share and maybe fix some problem with your howto.

1. Before starting slapd, I believe a step is missing. The /etc/conf.d/slapd file should be configure with (by default, nothing is set in this file):

```
OPTS="-h 'ldaps:// ldapi://%2fvar%2frun%2fopenldap%2fslapd.sock'"
```

I have found it necessary to remove the "ldap://" from the suggested line in the file because I use TLS to connect to the server. With the "ldap://" included in the line, clients will try to by pass ssl to connect to the server, therefore it will fail.

2. There is no mention of configuring the /etc/openldap/ldap.conf file in your guide. Not to be confused with /etc/ldap.conf (this file is used by pam_ldap and nss_ldap). Without configuring the /etc/openldap/ldap.conf, the command ldapadd will fail. So this file should look like:

```
BASE         dc=yourdomain, dc=com

URI          ldaps://yourldaphost.yourdomain.com:636/

TLS_REQCERT  allow
```

3. The /etc/ldap.conf file presented needs a few changes:

```
uri ldaps://yourldaphost.yourdomain.com  # I have some problem with "host" and "base" configuration.

ldap_version 3

port 636   #not sure if this is really necessary but what the hack.

scope sub   #not sure what is the difference with scope 1. Anyone?

pam_filter objectclass=posixaccount

pam_login_attribute uid

pam_member_attribute memberuid   #works the same with gid, I think.

pam_password exop      #seem to work for my md5 passwords. not sure what's the diff.

#According to the my research, speed things up and lighten the load for the ldap server

nss_base_passwd      ou=People,dc=yourdomain,dc=com?one

nss_base_shadow      ou=People,dc=yourdomain,dc=com?one

nss_base_group      ou=Group,dc=yourdomain,dc=com?one

ssl start_tls

ssl on    #this needs to be on
```

4. directoryadministrator really don't work well with newer version of the schema. Then again, neither does the migration tools. The base and groups are not the one giving the problem. So, using either of these tools to setup the base as well as create the group(s) are just fine. The problem is the users entries. Both directoryadministrator and the migration tools assumes the old schema. The way I over come the problem is to use the migration tools to generate the ldif files and removing parts of it I don't want to migrate. Then edit the password.ldif till it works. Here is a working copy of (though I am not sure it's 100% correct) user.ldif you can use as a template:

```
dn: uid=testuser,ou=People,dc=yourdomain,dc=com

uid: testuser

cn: testuser             #change this to the first name of your user

sn: testuser              #change this to the last name of your user

mail: testuser@yourdomain.com

mailRoutingAddress: testuser@yourdomain.com    #remove this line

mailHost: yourdomain.com                         #remove this line

objectClass: mailRecipient                      #remove this line

objectClass: person

objectClass: organizationalPerson

objectClass: inetOrgPerson

objectClass: account                           #remove this line

objectClass: posixAccount

objectClass: top

objectClass: kerberosSecurityObject

objectClass: shadowAccount

userPassword: {crypt}(...crypt hash)          #change this to md5 hash. use slappasswd -h {MD5}

shadowLastChange: 12609

shadowMax: 99999

shadowWarning: 7

krbName: testuser@YOURDOMAIN.COM

loginShell: /bin/bash

uidNumber: 1003

gidNumber: 100                     #should be the same gid as your "users" group

homeDirectory: /home/testuser
```

Note that you will need to place the following file as /etc/openldap/schema/kerberosobject.schema:

```
# Depends upon core.schema and cosine.schema

# OID Base is 1.3.6.1.4.1.2312.4

#

# Attribute types are under 1.3.6.1.4.1.2312.4.1

# Object classes are under 1.3.6.1.4.1.2312.4.2

# Syntaxes are under 1.3.6.1.4.1.2312.4.3

# Attribute Type Definitions

attributetype ( 1.3.6.1.4.1.250.1.32

        NAME ( 'krbName' 'kerberosName' )

        DESC 'Kerberos Name'

        EQUALITY caseIgnoreIA5Match

        SYNTAX 1.3.6.1.4.1.1466.115.121.1.26

        SINGLE-VALUE )

objectclass ( 1.3.6.1.4.1.2312.4.2.4 NAME 'kerberosSecurityObject' SUP top AUXILIARY 

   DESC 'A uid with an associated Kerberos principal'

   MUST ( krbName ) )

```

And also add the following line in your /etc/openldap/slapd.conf:

```
include      /etc/openldap/schema/inetorgperson.schema

include         /etc/openldap/schema/kerberosobject.schema    #this line

include      /etc/openldap/schema/nis.schema
```

So that openldap will not complain that "krbName" and "kerberosSecurityObject" are invalid and as well as to use kerberos later. If you don't intend to use kerberos you can remove the offending line in the ldif file and ignore the fact that I have mentioin the keberos schema.

Because I use migration tools to generate my ldif files, they are also different. So here is the base.ldif I've used:

```
dn: dc=yourdomain,dc=com

dc: yourdomain

objectClass: top

objectClass: domain

objectClass: domainRelatedObject

associatedDomain: yourdomain.com

dn: ou=People,dc=yourdomain,dc=com

ou: People

objectClass: top

objectClass: organizationalUnit

objectClass: domainRelatedObject

associatedDomain: yourdomain.com

dn: ou=Group,dc=yourdomain,dc=com

ou: Group

objectClass: top

objectClass: organizationalUnit

objectClass: domainRelatedObject

associatedDomain: yourdomain.com
```

And here is a group.ldif I've used:

```
dn: cn=users,ou=Group,dc=yourdomain,dc=com

objectClass: posixGroup

objectClass: top

cn: users

gidNumber: 100

memberUid: games
```

Use the following command to add it to the directory:

```
ldapadd -D "cn=root,dc=genfic,dc=com" -W -f  <ldif file>
```

5. Finally (hope I have not left out any details), with the base and at least one user setup, I find that the following gui tool is quite good: http://www.iit.edu/~gawojar/ldap/

Though I find it a pain to use without at least one user because it does not comes with a template suitable for adding a user. However when you have at least one user in your directory, you can use that user's entry to create a template (there is a command to do that with this tool).

So here you go. Hope this is going to be helpful.

----------

## Koon

 *irondog wrote:*   

> Fucking nothing works in this howto.

 

The problem is that this howto was written for old versions of openldap, directory_administrator and else. It worked as-is for me with these old versions. Unfortunately, I don't maintain it up to date with new versions (OpenLDAP 2.1.x migration was rather painful). I will reference the latest hints by weyhan in the first post when I will have more time to read them. In all cases, you should rather use the howto in the official Gentoo docs. If there is an error there, post a documentation bug. It will be much better to improve that version rather than mine.

-K

----------

## nextgen

Gee! It's too bad your walking away from this. I CAN get ldap working, but I CANNOT figure out a way to get ldaps:// or TLS over ldap://  working. What's the point if the LDAP server authenticate in clear text? What config or package on earth is necessary for ldaps or tls over ldap? I've been on this problem for a month (now using 2.6.7-gentoo-r :Cool: . I've been searching for so long and can't figure this out. If anyone knows, please, give a hint.

----------

## Koon

 *nextgen wrote:*   

> What config or package on earth is necessary for ldaps or tls over ldap?

 

The only thing I can think of is the ssl USE flag. You need it enabled for openldap to support TLS.

Hope this helps.

-K

----------

## striscio

For those who are experiencig problems with ssh authentication in an LDAP system.

I had all auth working except for ssh. I found out that deleting this line 

```

ChallengeResponseAuthentication no

```

in /etc/ssh/sshd_config and restarting the sshd server fixed my problems.

----------

## c0ns0le

I have a working ldap directory that i have imported my users to using this howto and some other ideas found on the web. simply install openldap make the modifications to the /etc/openldap/slapd.conf file start the ldap server add your Manager then download the http://download.fedora.redhat.com/pub/fedora/linux/core/3/i386/os/Fedora/RPMS/openldap-servers-2.2.13-2.i386.rpm rpm2targz it then tar -zxvf openldap-servers-2.2.13-2.i386.tar.gz -C / usr/share/openldap/migration cd to /usr/share/openldap/migration. edit the file migrate_common.pl < i think > remove all but the Users and Group portion. this will import all your users w/ pass's and group id's. sorry this isn't put together all nice and such buh it's 00:42 CST i'm a little tired. if you have any questions please post here.

----------

## kootie

Hi,

i've just finished reading the whole thread and didn't find answers to my problem.

I am trying to setup an LDAP server as in : http://www.gentoo.org/doc/en/ldap-howto.xml

The LDAP server works and system was successfully migrated.

I'm having trouble with the NSS part :

```
localhost root # getent passwd|grep 0:0
```

says

```
root:x:0:0:root:/root:/bin/bash
```

instead of 2 entries.

tail /var/log/messages says :

```
Mar 19 16:26:13 localhost slapd[13028]: conn=1 fd=10 ACCEPT from IP=127.0.0.1:32827 (IP=0.0.0.0:389)

Mar 19 16:26:13 localhost slapd[13031]: conn=1 op=0 BIND dn="" method=128

Mar 19 16:26:13 localhost slapd[13031]: conn=1 op=0 RESULT tag=97 err=0 text=

Mar 19 16:26:13 localhost slapd[13031]: conn=1 op=1 SRCH base="ou=People,dc=pastis,dc=ath.cx" scope=1 filter="(objectClass=posixAccount)"

Mar 19 16:26:13 localhost slapd[13031]: conn=1 op=1 SRCH attr=uid userPassword uidNumber gidNumber cn homeDirectory loginShell gecos description objectClass

Mar 19 16:26:13 localhost slapd[13031]: conn=1 op=1 SEARCH RESULT tag=101 err=0 nentries=0 text=

Mar 19 16:26:13 localhost slapd[13028]: conn=1 fd=10 closed

Mar 19 16:26:13 localhost slapd[13028]: conn=1 fd=10 ACCEPT from IP=127.0.0.1:32827 (IP=0.0.0.0:389)

Mar 19 16:26:13 localhost slapd[13031]: conn=1 op=0 BIND dn="" method=128

Mar 19 16:26:13 localhost slapd[13031]: conn=1 op=0 RESULT tag=97 err=0 text=

Mar 19 16:26:13 localhost slapd[13031]: conn=1 op=1 SRCH base="ou=People,dc=pastis,dc=ath.cx" scope=1 filter="(objectClass=posixAccount)"

Mar 19 16:26:13 localhost slapd[13031]: conn=1 op=1 SRCH attr=uid userPassword uidNumber gidNumber cn homeDirectory loginShell gecos description objectClass

Mar 19 16:26:13 localhost slapd[13031]: conn=1 op=1 SEARCH RESULT tag=101 err=0 nentries=0 text=

Mar 19 16:26:13 localhost slapd[13028]: conn=1 fd=10 closed

```

I'm thinking that the problemes comes from 

```
BIND dn=""
```

 wich sould be 

```
BIND dn="root" 
```

 I'm may be wrong...

Thanks in advance for your help.

Related configuration files :

/etc/openldap/slapd.conf

```

include         /etc/openldap/schema/core.schema

include         /etc/openldap/schema/cosine.schema

include         /etc/openldap/schema/inetorgperson.schema

include         /etc/openldap/schema/nis.schema

# Define global ACLs to disable default read access.

# Do not enable referrals until AFTER you have a working directory

# service AND an understanding of referrals.

#referral       ldap://root.openldap.org

pidfile         /var/run/openldap/slapd.pid

argsfile        /var/run/openldap/slapd.args

# Use crypt to encore passwords

password-hash {crypt}

# Define SSL and TLS properties (optional)

#TLSCertificateFile /etc/ssl/ldap.pem

#TLSCertificateKeyFile /etc/openldap/ssl/ldap.pem

#TLSCACertificateFile /etc/ssl/ldap.pem

#######################################################################

# ldbm database definitions

#######################################################################

database        ldbm

suffix          "dc=pastis,dc=ath.cx"

rootdn          "uid=root,ou=People,dc=pastis,dc=ath.cx"

rootpw          r

directory       /var/lib/openldap-ldbm

# Indices to maintain

index   objectClass     eq

########## Permissions

# -- Bertier

# -- http://www.gentoo.org/doc/en/ldap-howto.xml

access to *

  by dn="uid=root,ou=People,dc=pastis,dc=ath.cx" write

  by users read

  by anonymous auth

access to attrs=userPassword,gecos,description,loginShell

  by self write

```

/etc/openldap/ldap.conf

```

BASE    dc=pastis, dc=ath.cx

URI     ldap://127.0.0.1

TLS_REQCERT     allow

```

/etc/ldap.conf

```

#host 127.0.0.1

#base dc=padl,dc=com

#ssl start_tls

#ssl on

suffix          "dc=pastis,dc=ath.cx"

#rootbinddn uid=root,ou=People,dc=pastis,dc=ath.cx

uri ldap://127.0.0.1/

pam_password exop

ldap_version 3

pam_filter objectclass=posixAccount

pam_login_attribute uid

pam_member_attribute memberuid

nss_base_passwd ou=People,dc=pastis,dc=ath.cx

nss_base_shadow ou=People,dc=pastis,dc=ath.cx

nss_base_group  ou=Group,dc=pastis,dc=ath.cx

nss_base_hosts  ou=Hosts,dc=pastis,dc=ath.cx

scope one

```

/etc/conf.d/slapd

```
OPTS="-h 'ldap:// ldapi://%2fvar%2frun%2fopenldap%2fslapd.sock'"
```

/etc/nsswitch.conf

```

# Bertier

# http://www.gentoo.org/doc/en/ldap-howto.xml

passwd:         files ldap

group:          files ldap

shadow:         files ldap

# passwd:    db files nis

# shadow:    db files nis

# group:     db files nis

hosts:       files dns

networks:    files dns

services:    db files

protocols:   db files

rpc:         db files

ethers:      db files

netmasks:    files

netgroup:    files

bootparams:  files

automount:   files

aliases:     files

```

Last edited by kootie on Sun Mar 20, 2005 2:33 pm; edited 1 time in total

----------

## kootie

Some more info :

```
su - <user>
```

make this show up in the log

```
Mar 19 19:37:03 localhost slapd[21683]: conn=11 op=1 SRCH base="ou=People,dc=pastis,dc=ath.cx" scope=2 filter="(&(objectClass=posixAccount)(uid=<user>))"
```

But it still returns 0 search results..

----------

## weyhan

 *kootie wrote:*   

> Some more info :
> 
> ```
> su - <user>
> ```
> ...

 

I think your base should be

```
"ou=People,dc=pastis,dc=ath,dc=cx"
```

----------

## kootie

I don't think so because this :

```
ldapsearch -D "uid=root,ou=people,dc=pastis,dc=ath.cx" -W -Hldap://127.0.0.1
```

returns results. Excerpt :

```

# mbertier, People, pastis.ath.cx

dn: uid=mbertier,ou=People,dc=pastis,dc=ath.cx

uid: mbertier

cn: mbertier

sn: mbertier

objectClass: person

objectClass: organizationalPerson

objectClass: inetOrgPerson

objectClass: posixAccount

objectClass: top

objectClass: shadowAccount

userPassword:: e2NyeXB0fSQxJEoudTU2czBZJElhaGpqZDdiZnA2WmxmNUh0YzNGSy8=

shadowLastChange: 12837

shadowMax: 99999

shadowWarning: 7

loginShell: /bin/bash

uidNumber: 1000

gidNumber: 407

homeDirectory: /home/mbertier

```

----------

## weyhan

 *kootie wrote:*   

> I don't think so because this :
> 
> ```
> ldapsearch -D "uid=root,ou=people,dc=pastis,dc=ath.cx" -W -Hldap://127.0.0.1
> ```
> ...

 

I know you have setup it up as such. I'm saying you should set it as:

```
"ou=people,dc=pastis,dc=ath,dc=cx"
```

----------

## kootie

Found the problem in the other (french) thread i opened : 

It was an ACL issue, the first ACL example didn't work The second one does :

```
access to attribute="userPassword"

  by dn="uid=root,ou=people,dc=pastis,dc=ath.cx" write

  by anonymous auth

  by self write

  by * none

 

access to *

  by dn="uid=root,ou=People,dc=pastis,dc=ath.cx" write

  by * read

```

wouhou !

Is this an error in the howto, or does this come from something wrong in my setup ?

----------

## outspoken

i followed the howto and it ended up not working. =/

but i did find two other howtos on the net which helped me out:

http://linsec.ca/bin/view/Main/OpenLDAPAuth

http://wiki.debian.net/?LDAPMigrationTools

so it took a total of 3 howtos to get my system rolling, as always YMMV.  :Wink: 

----------

## weyhan

You could have use the following guide  :Wink: :

http://gentoo-wiki.com/HOWTO_LDAPv3

The HOWTO you follow is incredibaly old and outdated.

----------

## outspoken

 *weyhan wrote:*   

> You could have use the following guide :
> 
> http://gentoo-wiki.com/HOWTO_LDAPv3
> 
> The HOWTO you follow is incredibaly old and outdated.

 

well like i said, i used 3, so i only took the bits and pieces that i needed from those mentioned guides - i didn't follow them form top to bottom.

also, the ldap howto on that wiki page does not cover many of the issues that i ran into. whats even better is the fact that the wiki link you pasted has a link at the bottom that is one of the links i pasted!  :Wink: 

after im fully satisfied with things and have it running smooth ill come back and help edit that gentoo wiki page.

next time don't be in such a rush to correct someone.

----------

## weyhan

 *outspoken wrote:*   

> well like i said, i used 3, so i only took the bits and pieces that i needed from those mentioned guides - i didn't follow them form top to bottom.
> 
> also, the ldap howto on that wiki page does not cover many of the issues that i ran into. whats even better is the fact that the wiki link you pasted has a link at the bottom that is one of the links i pasted! 

 

Humm... I've just re-read the HOWTO I have posted and a new section I have not read before that points to the gentoo official HOWTO http://www.gentoo.org/doc/en/ldap-howto.xml. 

 *outspoken wrote:*   

> after im fully satisfied with things and have it running smooth ill come back and help edit that gentoo wiki page.

 

Great. Unless, of course, it is the same thing in the gentoo official HOWTO, and in that case I would like to know. So I could point people there if necessary. Please post your findings here. Thanks.

 *outspoken wrote:*   

> next time don't be in such a rush to correct someone.

 

Not correcting. I'm trying to tell you and others who come to this HOWTO for help that it is really old and dated and to point them to other alternative (maybe I should have worded it better). I know you are trying to do the same as well. I'm merely trying to suggest an alternative. No need to take offense.  :Wink: 

----------

