# I just don't get ldap

## zaiyon

I'm sorry for this stupid topic, I don't intend to bother anyone, it's just that I'm going to lose my belief in the "never give up - attitude" I usually have.

I've been trying ldap for months now, and yesterday, I thought, finally got it working. 

I tried several Howtos floating around in this forum and some on the web, of course the official gentoo howto too. 

This time, I think, I made it because getent passwd finally showed me double-entrys

(On this point: some howtos said if I don't like the double-output of getent passwd (wich is the case), I should escape the doubled entrys in /etc/passwd (same with the groups)... but is there no... "more elegant" way?), on ldap server and client, so I thought everything is fine.

But I  don't get ldap OR there's still something wrong with it, trying to passwd, I get the following:

```

# passwd

passwd: Authentication token manipulation error

```

ok, could be normal, I'm not used to ldap yet and I tried directoryadministrator. It's a pity there where a protocol error. gq and phpldapadmin weren't able to found the ldap server neither, 

suing takes a unusual long time... 

I tried to get samba to work too, using this howto:

http://www.monkeybox.org.uk/docs/gentoo/samba3.html

but at "Creating essential group mappings", I can't go further because... see it yourself:

```

# smbldap-groupadd smbdomadmins

Could not find base dn, to get next gidNumber at /usr/share/samba/scripts//smbldap_tools.pm line 909, <DATA> line 283.

```

main thing: I don't get ldap and I just don't understand why my admin guis wont connect....

this is what I entered in directory_administrator:

Server Adress: paron-02.zaiyon.ath.cx

Search root: dc=zaiyon,dc=ath,dc=cx

DN/User ID: cn=Manager,dc=zaiyon,dc=ath,dc=cx

TLS not activated (because it causes another error on establishing connection)

my domain is zaiyon.ath.cx , my ldap servers name is paron-02, my ldap user is Manager

you may think that my problem is not really a "problem", but I obviously can't solve this myself, and I really tried hard.

If you would like to see any output, log or config file, I would be pleased to show it, I thank everyone trying to help me understand ldap in advance.

/etc/openldap/sladp.conf

```

# $OpenLDAP:pkg/ldap/servers/slapd/slapd.conf,v 1.8.8.7 2001/09/27 20:00:31

# kurtExp$

#

# See slapd.conf(5) for details on configuration options.

# This file should NOT be world readable.

#

# Schema and objectClass definitions

include    /etc/openldap/schema/core.schema

include    /etc/openldap/schema/cosine.schema

include    /etc/openldap/schema/nis.schema

include    /etc/openldap/schema/inetorgperson.schema

include    /etc/openldap/schema/samba.schema

# Schema check allows for forcing entries to

# match schemas for their objectClasses's

schemacheck   on 

# 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 

# Possible Loglevel values:

# Log levels are additive, and available levels are:

#    1 trace function calls

#    2 debug packet handling

#    4 heavy trace debugging

#    8 connection management

#    16 print out packets sent and received

#    32 search filter processing

#    64 configuration file processing

#    128 access control list processing

#    256 stats log connections/operations/results

#    512 stats log entries sent

#    1024 print communication with shell backends

#    2048 entry parsing

Loglevel   0

# 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

# Password Hash

password-hash  {crypt}

# TLS stuff

# Keep the following commented until everything else is working

#

#TLSCertificateFile     /etc/ssl/certs/slapdcert.pem

#TLSCertificateKeyFile  /etc/ssl/certs/slapdkey.pem

#TLSCACertificateFile   /etc/ssl/certs/slapdcert.pem

#

# Sample Access Control

# Allow read access of root DSE

# Allow self write access

# Allow authenticated users read access

# Allow anonymous users to authenticate

#

access to dn="" by * read

access to *

        by self write

        by users read

        by anonymous auth

# if no access controls are present, the default is:

# Allow read by all

#

# rootdn can always write! 

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

# ldbm database definitions

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

database ldbm 

suffix "dc=zaiyon,dc=ath,dc=cx"

#suffix "o=My Organization Name,c=US" 

rootdn "cn=Manager,dc=zaiyon,dc=ath,dc=cx"

#rootdn "cn=Manager,o=My Organization Name,c=US"

# Cleartext passwords, especially for the rootdn, should

# be avoid. See slappasswd(8) and slapd.conf(5) for details. 

# Use of strong authentication encouraged.

rootpw {MD5}QtxtrIcFS5aCvmKOccZxyw==

# The database directory MUST exist prior to running slapd AND

# should only be accessible by the slapd/tools. Mode 700 recommended.

directory /var/lib/openldap-ldbm

# Indices to maintain

index   objectClass   eq

index   cn            pres,sub,eq

index   sn            pres,sub,eq

## required to support pdb_getsampwnam

#index   uid           pres,sub,eq

## required to support pdb_getsambapwrid()

#index   displayName   pres,sub,eq

## uncomment these if you are storing posixAccount and

## posixGroup entries in the directory as well

index   uidNumber            eq

index   gidNumber            eq

index   memberUid            eq

index   sambaSID             eq

index   sambaPrimaryGroupSID eq

index   sambaDomainName      eq

index   default              sub

# Save the time that the entry gets modified, for database #1

lastmod    on

# Where to store the replica logs for database #1

# replogfile /var/lib/openldap-slurp/replog

# The userPassword by default can be changed

# by the entry owning it if they are authenticated.

# Others should not be able to see it, except the

# admin entry below

# These access lines apply to this database only

access to *

        by dn=''uid=root,ou=People,dc=zaiyon,dc=ath,dc=cx'' write

        by dn="cn=Manager,dc=zaiyon,dc=ath,dc=cx" write

        by users read

        by anonymous auth

        by * search 

access to attribute=userPassword,gecos,description,sambaLMPassword,sambaNTPassword

        by dn=''cn=Manager,dc=zaiyon.ath.cx'' write

        by dn=''uid=root,ou=People,dc=zaiyon,dc=ath,dc=cx'' write

        by self write

        by anonymous auth

        by * none

access to *

   by dn="cn=Manager,dc=zaiyon,dc=ath,dc=cx" write

   by * read

```

/etc/openldap/ldap.conf

```

host                 127.0.0.1  

base                 dc=zaiyon,dc=ath,dc=cx

scope                one

pam_filter           objectclass=posixaccount  

pam_login_attrubute  uid  

pam_member_attribute memberuid

nss_base_passwd      ou=People,dc=zaiyon,dc=ath,dc=cx?one

nss_base_shadow      ou=People,dc=zaiyon,dc=ath,dc=cx?one

nss_base_group       ou=Group,dc=zaiyon,dc=ath,dc=cx?one

nss_hosts        ou=Hosts,dc=zaiyon,dc=ath,dc=cx?one

pam_password         exop  

# if this is the /etc/ldap.conf that is local to the server,

# i.e not a client machine then

# the following can stay commented, else uncomment

# ssl start_tls

# ssl on

```

/etc/ldap.conf

```

host                 127.0.0.1  

base                 dc=zaiyon,dc=ath,dc=cx

scope                one

pam_filter           objectclass=posixaccount  

pam_login_attrubute  uid  

pam_member_attribute memberuid

nss_base_passwd      ou=People,dc=zaiyon,dc=ath,dc=cx?one

nss_base_shadow      ou=People,dc=zaiyon,dc=ath,dc=cx?one

nss_base_group       ou=Group,dc=zaiyon,dc=ath,dc=cx?one

nss_hosts        ou=Hosts,dc=zaiyon,dc=ath,dc=cx?one

pam_password         exop  

# if this is the /etc/ldap.conf that is local to the server,

# i.e not a client machine then

# the following can stay commented, else uncomment

# ssl start_tls

# ssl on

```

/etc/conf.d/sladp

```

# conf.d file for the openldap-2.1 series

#

# To enable both the standard unciphered server and the ssl encrypted

# one uncomment this line or set any other server starting options

# you may desire.

#

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

```

/etc/nsswitch.conf

```

# /etc/nsswitch.conf:

# $Header: /home/cvsroot/gentoo-src/rc-scripts/etc/nsswitch.conf,v 1.4 2002/11/18 19:39:22 azarah Exp $

# passwd:      files ldap

# shadow:      files ldap

# group:       files ldap

passwd: compat files ldap

shadow: compat files ldap

group: compat files ldap

# passwd:    db files nis

# shadow:    db files nis

# group:     db files nis

hosts:       files dns ldap wins

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

```

----------

## Skywacker

Sorry I'm too lazy to check your config files, but I've been messing with LDAP for the last week and finally got everything working today so I'll give you some advice:

1) Get LDAP working on the server first before you even think about SAMBA integration. 

2) Check your USE flags. I'm building a cluster and the Gentoo clustering howto has horrible use flags if you want to run ldap. I only put ldap and pam in mine. And definitely DON"T put a -* in the USE definition. LDAP has untold number of dependencies.

3) There's only a few relevant configuration files to bother with:

/etc/openldap/slapd.conf  --This is your most likely source of problems.

/etc/openldap/ldap.conf  --this is what ldapsearch uses to connect to your ldap server

/etc/ldap.conf --This is what getent uses to connect to your ldap server

/etc/pam.d/system-auth  --not much to screw up here, but this tells pam to use ldap

/etc/conf.d/slapd --not much to screw up here either

so basically if /etc/init.d/slapd starts, you at least have a slapd.conf that will load (though definitely could still have bugs)

if the ldapsearch command in the howto's returns data, /etc/openldap/ldap.conf at least knows how to connect to your server and pulls data

if getent passwd | grep 0:0 shows two roots, your /etc/ldap.conf is probably fine.

That in my opinion is the easy part. It's slap.d that is hard. Remove all ACL's untill you have things working. The default ACL's (that work without being defined at all) will allow a user to login. 

You might want to delete out all the comments until you get things working. Helped me see what was actually needed code.

Good luck. I'll email your my config files if you want to compare. Several times everything looked completely correct but little things didn't work. I had to just keep blowing my config files away and starting over and finally got things working. 

Oh, and /var/log/messages is your friend. 

-Skywacker

----------

## Petyr

Okay so having just dealt with this myself I hope I can offer some insight into whatall is going crazy for you.

Assuming I've read this right, your problem is that passwd is barfing a cryptic error message back at you.  Check the following

in /etc/pam.d/system-auth, did you add the lines with pam_ldap in it? Your system-auth file should probably look like this

```
#%PAM-1.0

auth       required  /lib/security/pam_env.so

auth       sufficient    /lib/security/pam_ldap.so 

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

auth       required  /lib/security/pam_deny.so

account    sufficient    /lib/security/pam_ldap.so

account    required  /lib/security/pam_unix.so

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

password   sufficient    /lib/security/pam_ldap.so use_authtok

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

password   required  /lib/security/pam_deny.so

session    required  /lib/security/pam_limits.so

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

session    optional      /lib/security/pam_ldap.so

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

Next if that's all setup correctly, check to make sure you've got the pam_ldap plugin installed. Do an emerge pam_ldap -p and see if it want's to compile it as a New package or Replace it. If it wants it as a new package, then life is mostly good. Once that's installed check it out again and see if it works.

Both of those don't do the trick?

Check out the /etc/ldap.conf file. Make certain that you have the entires to your ldap server in there correct (trust me this was a huge pitefall for me when I was setting this up).

Logins take too long? Try enabling NSCD (Name Service Cache Daemon). Basically it will cache all the lookups to ldap for a short period of time, this should help things significantly overall though (not to mention remove a huge load from your server and put it where it should be, at the client station   :Twisted Evil:  )

First line of trouble shooting this is to have a root consel open. When something doesn't work, switch to it and tail /var/log/messages

See what it tells you. This can usually help you find 95% of all problems with this kind of setup.

hth,

Petyr Rahl

----------

## zaiyon

thx to you for fast replying, Petyr and Skywacker,

I just found out something really strange:

on the client and the server, this is returned by the "groups" command

```

$ groups zaiyon

tty wheel cron audio video games users www burning p2p ftprw sshlogin tty wheel cron audio video games users www burning p2p ftprw sshlogin

```

if I do an usermod -G $group1,$group2 etc, nothing changes about this...

 *Skywacker wrote:*   

> Sorry I'm too lazy to check your config files

 

I absolutely understand  :Wink: 

my use flags should be okay, ldap and pam is inside.

I was not yet able to really understand ldapsearch, this is a command that, as far as I understand the manpage, should work for me and return at least... something

```

# ldapsearch -h localhost -b "cn=zaiyon,cn=ath,cn=cx" "(&(cn=*))"

# extended LDIF

#

# LDAPv3

# base <cn=zaiyon,cn=ath,cn=cx> with scope sub

# filter: (objectclass=*)

# requesting:  

#

# search result

search: 2

result: 32 No such object

# numResponses: 1

```

but that doesn't look good.. configuration problem or am I too stupid for the ldapsearch manpage?

 *Skywacker wrote:*   

> if getent passwd | grep 0:0 shows two roots, your /etc/ldap.conf is probably fine. 

 

I'm proud it does  :Wink: 

So, I just changed some stuff about the ACLs:

```

# These access lines apply to this database only

#access to *

#        by dn=''uid=root,ou=People,dc=zaiyon,dc=ath,dc=cx'' write

#        by dn="cn=Manager,dc=zaiyon,dc=ath,dc=cx" write

#        by users read

#        by anonymous auth

#        by * search 

#access to attribute=userPassword,gecos,description,sambaLMPassword,sambaNTPassword

#        by dn=''cn=Manager,dc=zaiyon.ath.cx'' write

#        by dn=''uid=root,ou=People,dc=zaiyon,dc=ath,dc=cx'' write

#        by self write

#        by anonymous auth

#        by * none

#access to *

#       by dn="cn=Manager,dc=zaiyon,dc=ath,dc=cx" write

#       by * read

```

everything commented out... I don't really know anything about ACLs except what they're meant to be, emerging acl right now...

I fooled around with the comments at the acl part, but phpldapadmin was never able to connect... is it enough to just restart /etc/init.d/sladp for this to take changes?

 *Skywacker wrote:*   

> 
> 
> I'll email your my config files if you want to compare.
> 
> 

 

that would be great, can you send it to zaiyon@gmx.net?

 *Skywacker wrote:*   

> Oh, and /var/log/messages is your friend. 

 

```

 # tail /var/log/messages

Sep 16 08:36:12 paron-02 sshd(pam_unix)[14441]: session closed for user jenny

Sep 16 08:37:53 paron-02 slapd[14517]: bdb_initialize: Sleepycat Software: Berkeley DB 4.1.25: (December 19, 2002)

Sep 16 08:40:00 paron-02 CRON[15711]: (root) CMD (test -x /usr/sbin/run-crons && /usr/sbin/run-crons )

Sep 16 08:42:03 paron-02 su(pam_unix)[17696]: session opened for user postgres by zaiyon(uid=0)

Sep 16 08:42:06 paron-02 su(pam_unix)[17696]: session closed for user postgres

Sep 16 08:46:33 paron-02 slapd[25155]: bdb_initialize: Sleepycat Software: Berkeley DB 4.1.25: (December 19, 2002)

Sep 16 08:47:57 paron-02 slapd[27077]: bdb_initialize: Sleepycat Software: Berkeley DB 4.1.25: (December 19, 2002)

Sep 16 08:50:00 paron-02 CRON[27087]: (root) CMD (test -x /usr/sbin/run-crons && /usr/sbin/run-crons )

Sep 16 08:51:11 paron-02 smbd[21253]: nss_ldap: reconnecting to LDAP server...

Sep 16 08:51:16 paron-02 smbd[21253]: nss_ldap: reconnected to LDAP server after 1 attempt(s)

```

I think this looks good, am I right?

at 08:36, my girlfriend disconnected, could be true  :Razz: 

all the connection stuff looks working, pam stuff too... do you see any problems there? I can post more of /var/log/messages if you're interested.

 *Petyr wrote:*   

> 
> 
> Assuming I've read this right, your problem is that passwd is barfing a cryptic error message back at you. Check the following
> 
> in /etc/pam.d/system-auth, did you add the lines with pam_ldap in it? Your system-auth file should probably look like this
> ...

 

```

#%PAM-1.0

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

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

password   sufficient   /lib/security/pam_ldap.so use_authtok

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

password   required     /lib/security/pam_deny.so

session    required     /lib/security/pam_limits.so

session    optional     /lib/security/pam_ldap.so

session    required     /lib/security/pam_unix.so

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

```

looks equal to me.

 *Petyr wrote:*   

> 
> 
> Do an emerge pam_ldap -p and see if it want's to compile it as a New package or Replace it.
> 
> 

 

not sure what you mean, but plz see it yourself:

```

# emerge -p pam_ldap    

These are the packages that I would merge, in order:

Calculating dependencies ...done!

[ebuild   R   ] net-libs/pam_ldap-156  

```

 *Petyr wrote:*   

> 
> 
> Check out the /etc/ldap.conf file. Make certain that you have the entires to your ldap server in there correct (trust me this was a huge pitefall for me when I was setting this up). 
> 
> 

 

Seem to be, but I'm of course not sure, I'll compare it to the stuff Skywacker will send me.

 *Petyr wrote:*   

> 
> 
> Logins take too long? Try enabling NSCD (Name Service Cache Daemon). Basically it will cache all the lookups to ldap for a short period of time, this should help things significantly overall though (not to mention remove a huge load from your server and put it where it should be, at the client station Twisted Evil ) 
> 
> 

 

I don't know how to enable NSCD, even if it sounds useful, I don't think thats the problem, because logins on the SERVER take long, not on the clients....

passwd works on the clients a lot longer than on the server, watch out:

```

zaiyon@zion ~ $ passwd zaiyon

Changing password for zaiyon

(current) UNIX password: 

New UNIX password: 

Retype new UNIX password: 

passwd: password updated successfully

zaiyon@zion ~ $ ssh paron-02

Password: 

Password: 

Last login: Thu Sep 16 08:57:29 2004 from zion.zaiyon.ath.cx

zaiyon@paron-02 zaiyon $ passwd zaiyon

passwd: Authentication token manipulation error

zaiyon@paron-02 zaiyon $ ssh zion

Password: 

Last login: Thu Sep 16 09:11:59 2004 from paron-02.zaiyon.ath.cx

zaiyon@zion ~ $ 

```

what happened is easy said, I changed my password on the client using passwd, then ssht to my server trying to log in with my new password, wich did not work, then I used the old password and it worked. Then I tried to change my password on t he server - did not work. After that I ssht back to my workstation with my new password, and it worked.

So I now have different passwords on each machine, how can this be?

 *Petyr wrote:*   

> 
> 
> First line of trouble shooting this is to have a root consel open. When something doesn't work, switch to it and tail /var/log/messages
> 
> See what it tells you. This can usually help you find 95% of all problems with this kind of setup. 
> ...

 

I connect to phpldapadmin now, and after that print out my tail /var/log/messages:

```

Sep 16 08:57:29 paron-02 sshd(pam_unix)[27123]: session opened for user zaiyon by (uid=0)

Sep 16 09:00:00 paron-02 CRON[27136]: (root) CMD (rm -f /var/spool/cron/lastrun/cron.hourly)

Sep 16 09:00:00 paron-02 CRON[27137]: (root) CMD (test -x /usr/sbin/run-crons && /usr/sbin/run-crons )

Sep 16 09:05:58 paron-02 su(pam_unix)[14332]: session closed for user root

Sep 16 09:06:13 paron-02 su(pam_unix)[27153]: session opened for user root by zaiyon(uid=1000)

Sep 16 09:10:00 paron-02 CRON[27177]: (root) CMD (test -x /usr/sbin/run-crons && /usr/sbin/run-crons )

Sep 16 09:13:03 paron-02 sshd(pam_unix)[27194]: authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=zion.zaiyon.ath.cx  user=zaiyon

Sep 16 09:13:11 paron-02 sshd[27192]: error: PAM: Authentication failure for zaiyon from zion.zaiyon.ath.cx

Sep 16 09:13:16 paron-02 sshd[27192]: Accepted keyboard-interactive/pam for zaiyon from 192.168.0.2 port 33469 ssh2

Sep 16 09:13:23 paron-02 sshd(pam_unix)[27196]: session opened for user zaiyon by (uid=0)

```

does not look for me as if there is anything about my tried phpldapadmin login, so it really does not even connect to the server - thats just strange...

thx again to you guys, I have some new red threads to follow now, I'll fool around some more...

----------

## Petyr

Whee long posts ^^

Okay I'll try to go in order for what I know...

The groups command lists things twice: Good, it's suppose to. Just like your user accounts are listed twice, the groups should be listing twice as well.

ldapsearch and wierd results: Try just doing ldapsearch. Just that, nothing else. Basically that would be saying to the computer "Checkout my ldap.conf file, use all that as the defaults, and give me everything you see back to me." If you STILL get no results back, then your ldap.conf is messed up somewhere and you need to get that resolved before anything else can work.

ACL's: Okay so they're all commented out. For now since you're still in the testing phase that's a good thing. Afterwords when you're getting ready to roll it out, put them back! THen test again ^_~ You really want those in ther eto prevent people from seeing things they shouldn't (i.e. other peoples passwords...). As for applying them, yes restarting slapd is sufficient.

phpldapadmin never able to connect: You did edit the config.php file yes? Just to make sure, becuase it's default settings are kinda stupid. It pretends that it's going to work, then fails. That and there's no "online" config utility *shrug* ohwell. If it is configured and you still can get it to connect, hrmmm... That could be a myrid of things really.

PAM stuff: Take a close look at my config file and your's. You'll notice that the ordering is different. I know this might be kinda a long shot and all, but as far as I remember ordering in the pam config files IS important.

emerge -p pam_ldap: Cool that looks good. Just wanted to make sure the pam module for ldap actually was installed (which it is)

NSCD: Oh side note, don't enable that until AFTER everything else is working. Because it caches things, if you change a password on the server, it can take a little bit before it propigates out to the client stations ^^;;; Sorry I shoulda mentioned that earlier.

Password on client diff than server: First off, on the client machine, does that user account have a LOCAL account? i.e. if you to a getent password | grep `whoami` does it list your user account twice? If it does then that's probably your problem. My guess is this is a two part problem. First part is that LOCAL entries override server entries. Usually. nsswitch.conf controls that ultimately, so if you say 

```
passwd: files ldap

shadow: files ldap
```

 then local entries are authoritative. If you reverse the files and ldap then SERVER entries are authoritative. The second part of the problem is probably your pam config. Make sure you get the ordering right. It should have asked your first for your LDAP password. The token manipulation error kinda sounds like that to me anyways.

phpldapadmin log: Hrmm I don't see anything in there about phpldapadmin, but that doesn't really suprise me. Log entries for that are going to be in apache's log files. Check out /var/log/apache/access_log and errors_log. That might give you a bit more insight into what's going on with phpldapadmin.

It's a long fight to be sure, but once it's working if you've got like 5 or more computers it is SO worth all the effort when you're done.

ganbatte! (work hard / good luck)

Petyr Rahl

----------

## zaiyon

[quote="Petyr"]The groups command lists things twice: Good, it's suppose to. Just like your user accounts are listed twice, the groups should be listing twice as well.  *Quote:*   

> 
> 
> Sorry, I've been too stupid to look at it right, I thought the output is not the same, because I expected a LF at the end of groups by the groups commando... the rows did not look equal to me so I thought thats the problem... I came to this, because I cannot access a folder I have access to on the ldap client, watch out:
> 
> ```
> ...

 

```

paron-02 zaiyon # ldapsearch

# extended LDIF

#

# LDAPv3

# base <> with scope sub

# filter: (objectclass=*)

# requesting: ALL

#

# search result

search: 2

result: 0 Success

# numResponses: 1

```

is this a success?

 *Petyr wrote:*   

> 
> 
> PAM stuff: Take a close look at my config file and your's. You'll notice that the ordering is different. I know this might be kinda a long shot and all, but as far as I remember ordering in the pam config files IS important. 
> 
> 

 

My system-auth now looks exactly like yours on client/server, and I restartet slapd on the server... no new results....

 *Petyr wrote:*   

> 
> 
> phpldapadmin never able to connect: You did edit the config.php file yes? Just to make sure, becuase it's default settings are kinda stupid. It pretends that it's going to work, then fails. That and there's no "online" config utility *shrug* ohwell. If it is configured and you still can get it to connect, hrmmm... That could be a myrid of things really. 
> 
> 

 

It now works, I've been too stupid to set auth_type to "session"  :Wink: 

ok, EVERYTHING changed, ldap seems to work! But there's a problem with my password I think... I would love to use TLS, you know any howto about that? directory_administrator and gq cannot connect, but at least ldap_admin seems to work, now I have to get used to ldap and next find a nice curses ldap admin software, I don't like X that much....

 *Petyr wrote:*   

> 
> 
> Password on client diff than server: First off, on the client machine, does that user account have a LOCAL account? i.e. if you to a getent password | grep `whoami` does it list your user account twice? If it does then that's probably your problem. My guess is this is a two part problem. First part is that LOCAL entries override server entries. Usually. nsswitch.conf controls that ultimately, so if you say
> 
> Code:
> ...

 

yes, I do have the user as a local account, at this position: Is this the reason why all the entrys are shown double on "getent group" or "getent passwd"? How can I get rid of this? Showing every entry twice is not nice...

but not the time to get pathetic, thanks to you I got phpldapadmin working  :Razz:  thx!

 *Petyr wrote:*   

> 
> 
> ganbatte! (work hard / good luck)
> 
> 

 

domo  :Wink: 

----------

## Petyr

Okay so for testing on the client box, you might want to ditch off the local accounts. That way we can rule out the possibilty of it working just because we have it setup as a local account on that machine.

Basically if you remove the local account then things will not show up twice int he getent (passwd | group)

Your ldap results however do not look correct to me. Id' say check out your ldap.conf files and make sure the base search path is correct. Once you've got that verified try it again. All else fails try doing a 

```
ldapsearch uid=zaiyon
```

 and see if that gives you anything back (it should).

as for the directory access thing, my *guess* is that because you've got a local group called p2p and a LDAP group called p2p, maybe their GID's are not the same (i.e. local gid=100 server gid=500), that could explain what's going on with it at least.

All I can say is first get it so everything works picture perfect on the server. Then get oen client to do that and just copy those config files to everyone else.

Petyr

----------

## zaiyon

 *Petyr wrote:*   

> 
> 
> Okay so for testing on the client box, you might want to ditch off the local accounts. That way we can rule out the possibilty of it working just because we have it setup as a local account on that machine.
> 
> Basically if you remove the local account then things will not show up twice int he getent (passwd | group) 
> ...

 

hm... commenting out the whole /etc/passwd was a REAL stupid idea of mine  :Wink:  should I only comment out some of the users (for example NOT root...) or do I really have to userdel all of them?

Should I do that on ldap server and on the client? I just tried around with this on my client.

 *Petyr wrote:*   

> 
> 
> Your ldap results however do not look correct to me. Id' say check out your ldap.conf files and make sure the base search path is correct. Once you've got that verified try it again. All else fails try doing a
> 
> Code:
> ...

 

this equals on client/server:

```

# ldapsearch uid=zaiyon

# extended LDIF

#

# LDAPv3

# base <> with scope sub

# filter: uid=zaiyon

# requesting: ALL

#

# search result

search: 2

result: 0 Success

# numResponses: 1

```

for me it looks good.... but I'm sure ldapsearch works, because searching in phpldapadmin or gq (I'm still not able to get rid of that directory_administrator - protocol error, everything else seems to connect just fine) works and returns me the right user.

 *Petyr wrote:*   

> 
> 
> as for the directory access thing, my *guess* is that because you've got a local group called p2p and a LDAP group called p2p, maybe their GID's are not the same (i.e. local gid=100 server gid=500), that could explain what's going on with it at least. 
> 
> 

 

I don't think thats the problem, output equals on server and client, the problem is only that I cannot access this diretory on the client by beeing in this group....

```

# getent groups | grep p2p

p2p:x:441:zaiyon,jenny

p2p:x:441:zaiyon,jenny

```

Another strange thing:

On my Server, authencication always needs my password twice, looks like a real stupid trojan to me  :Wink: 

here's the output:

```

zaiyon@zion ~ $ ssh paron-02

Password: 

Password: 

Last login: Sat Sep 18 15:33:41 2004 from zion.zaiyon.ath.cx

zaiyon@paron-02 zaiyon $ su

Password: 

Password: 

paron-02 zaiyon # 

```

My guess would be that ldap is trying to authenciciate with both local AND ldap account/password, but this can be nonsense too, just what I would guess  :Very Happy:  Do you by any chance know what this could mean?

interesting is this:

```

paron-02 zaiyon # /etc/init.d/slapd stop

 * Stopping ldap-server...                                                [ ok ]

paron-02 zaiyon # exit

zaiyon@paron-02 zaiyon $ su

Password: 

Password: 

paron-02 zaiyon # 

```

I have to type in my password twice, even if ldap is stopped.... just don't get it  :Wink: 

 *Petyr wrote:*   

> 
> 
> All I can say is first get it so everything works picture perfect on the server. Then get oen client to do that and just copy those config files to everyone else. 
> 
> 

 

thx for all your help, I sometimes thought about using nis instead and throwing ldap aside, but I'm not the type using qmail instead of postfix if you know what I mean...  :Wink: 

----------

## Petyr

 *Quote:*   

> Should I do that on ldap server and on the client?

  Just on the client. You can leave the "local" accounts on the server since that's not going to affect anything on the client end.

Your ldap results still seem...wrong to me. Ideally it should return a bunch of things, namely if you just say ldapsearch, it should give you back a list of every account in the database. More importantly, since you've disabled the ACL's it should also tell you what the shadowpassword for every account is...

As for the group permissions thing, hrmmm. All I can say is, crap, I was hoping it'd be the easier solution   :Wink: 

As far as your server asking for the password twice, that could be a pam configuration thing as well. Might want to verify the system-auth on the server and on the client again just to be sure.

As for nis *shudder* Might as well setup samba to do authentication against a WinNT4 domain.

hth,

Petyr Rahl

----------

## zaiyon

I've been fooling around with ldap for days now... ok ,some of them, I was in the mood to kill everybody saying an abbreviation beginning with "l". But on the other days, I tried hard to read trough some other howtos and try to understand ldap by fooling around with gq.

Ok, the password-asked-twice-issue is strange, but not that bad til now, what I enter at the first prompt doesn't matter, so I can just skip that one, _really_ looks like some dumb backdoor like 

```
alias su='echo -n "Password: "; read -s pw && echo $pw > ~/.pw 2>&1;echo; sleep 3;  su $@'
```

that's how I would write that code.. but thats OT. Next, after getting used to gq, I tried to add a testuser, wich worked just fine; except the fact, that this user doesn't exist outside of gq or phpldapadmin, I can search for it just fine, ldapsearch on the commandline always returns the same thing, no matter what I'm searching for so I think you're right, there's still something deeply wrong.... 

I know, it's much I want, but can you (or someone else) probably have a short look at my config files?

If not or additionally, it would be great if someone could email or post me his or something like that. 

I just wanna see a working ldap config, some other results would be really great like a example ldapsearch or even a example sladppasswd, becaue I not yet get how a user himself can change his password if he doesn't have the ldap password... I still have to get ldap, thx in advance

----------

## Petyr

okay so I took a look at your config files that you posted originally. They look good as far as I can see. That doesn't mean that I havn't missed something but *shrug* on my initial read I think they look right. 

One thing I recenetly rediscovered is this. Check to see if you have an /etc/ldap.conf AND an /etc/openldap/ldap.conf.

Delete one of them and symlink it to the other (whichever is the one you edited)

Thaty MAY fix the ldapsearch crap we've been getting. After that then maybe we can start to tackle the rest of these problems.

As for the password twice stuff. It *may* be a backdoor, but I'd be iffy about saying it is one. I dunno, go read around a bit and see ifyou can grab some of the testers for various rootkits. See if they turn up anything. If they DO, get your data and format the box. Don't even try to clean the system without doing that. If you're going to try to investigate the deal, then image the drive somewhere, MD5 the image, and then work from a copy of that image. After that then format the server and get it back up and working again ^_~

hth,

Petyr Rahl

----------

## zaiyon

I'm sorry for not answering for a long time, I had a lot to do with preparing myself for an important certificate, and ldap had to stand in the background for some time.

Now I'm encouraged to try it again.

First thing I did: Reactivating the ACL's in sladp.conf, now the group stuff finally works again on the client (yeah), but gq now starts to trouble.. as it should, I think, because ldapsearch and directory_administrator both don't work properly, so if gq works its kind of.. wrong.

I now have a problem wich sounds something like"invalid incredentials" or anything, but I'll start over with such tools when ldapsearch and so on work.

Is the ldapsearch problem perhaps related to my ACLs? Here's the part from my sladp.conf again:

```

access to *

        by dn=''uid=root,ou=People,dc=zaiyon,dc=ath,dc=cx'' write

        by dn="cn=Manager,dc=zaiyon,dc=ath,dc=cx" write

        by users read

        by anonymous auth

        by * search 

access to attribute=userPassword,gecos,description,sambaLMPassword,sambaNTPassword

        by dn=''cn=Manager,dc=zaiyon.ath.cx'' write

        by dn=''uid=root,ou=People,dc=zaiyon,dc=ath,dc=cx'' write

        by self write

        by anonymous auth

        by * none

access to *

        by dn="cn=Manager,dc=zaiyon,dc=ath,dc=cx" write

        by * read

```

 *Petyr wrote:*   

> okay so I took a look at your config files that you posted originally. They look good as far as I can see. That doesn't mean that I havn't missed something but *shrug* on my initial read I think they look right. 
> 
> 

 

thx, can you perhaps show me yours or something like that? I'm not quite sure if everything is right understood by me, all that pam stuff and so on, I am nearly certain that the password-twice-issue is related to that stuff because it cannot have anything to do with sladp.

I don't think it's a backdoor either, because for putting in something like that, somebody should have been capable of changing my system auth configuration, wich is just possible to be done by root on my system if I'm not damned wrong. So why should somebody with the root account sniff for user passwords? Am I schizophrenic?

 *Petyr wrote:*   

> 
> 
> One thing I recenetly rediscovered is this. Check to see if you have an /etc/ldap.conf AND an /etc/openldap/ldap.conf.
> 
> Delete one of them and symlink it to the other (whichever is the one you edited)
> ...

 

You were right, there's totally different stuff in both of them... so I simlinked one to the other and tried three configurations:

1.the ldap.conf in openldap

2.the one in /etc

3.and both of them concatenated

all those efforts didn't work... I don't even know if I have to restart sladp after changing this configuration, but I did it to be sure...

this is my /etc/{openldap/,}ldap.conf now:

```

# /etc/openldap/ldap.conf

BASE dc=zaiyon,dc=ath,dc=cx

TLS_REQCERT allow

URI ldap://paron-02.zaiyon.ath.cx

# /etc/ldap.conf

host                 127.0.0.1  

base                 dc=zaiyon,dc=ath,dc=cx

scope                one

pam_filter           objectclass=posixaccount  

pam_login_attrubute  uid  

pam_member_attribute memberuid

nss_base_passwd      ou=People,dc=zaiyon,dc=ath,dc=cx?one

nss_base_shadow      ou=People,dc=zaiyon,dc=ath,dc=cx?one

nss_base_group       ou=Group,dc=zaiyon,dc=ath,dc=cx?one

nss_hosts            ou=Hosts,dc=zaiyon,dc=ath,dc=cx?one

pam_password         exop  

```

----------

## Petyr

Okay so here goes

I have the same password twice thing on my server (and only my server)

The first one turns out to be the ldap password prompt (which I hit enter on and don't type anything) and the second one turns out to be the local system login. I'm not exactly sure WHY it's doing that, but I also don't really care too much about it so I think I'm going to leave it as it is since it's working right now ^_~

Next you asked to see the config files I have setup. Here goes, (note, I stripped my comments from the files to save space)

/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

include         /etc/openldap/schema/samba.schema

include         /etc/openldap/schema/redhat/autofs.schema

include         /etc/openldap/schema/redhat/kerberosobject.schema

security ssf=1 update_ssf=112 tls=112

TLSCertificateFile /usr/share/ssl/certs/slapd.pem

TLSCertificateKeyFile /usr/share/ssl/certs/slapd.pem

TLSCACertificateFile /usr/share/ssl/demoCA/cacert.pem

access to * attr="userPassword,sambaLMPassword,sambaNTPassword"

        by dn="uid=root,ou=People,dc=active-sight,dc=com" write

        by self write

        by anonymous auth

        by * search

access to * 

        by * read

database        ldbm

suffix          "dc=my-company,dc=com"

rootdn          "cn=Manager,dc=my-company,dc=com"

rootpw          [left out on purpose, you can set this one up yourself]

directory       /var/lib/ldap

index   objectClass             eq

index   cn                      pres,sub,eq

index   sn                      pres,sub,eq

index   uid                     pres,sub,eq

index   displayName             pres,sub,eq

index   uidNumber               eq

index   gidNumber               eq

index   memberUid               eq

index   sambaSID                eq

index   sambaPrimaryGroupSID    eq

index   sambaDomainName         eq

index   default                 eq

index   mail                    eq

index   givenname               eq,subinitial
```

next is /etc/ldap.conf (which is the only one I have, /etc/openldap/ldap.conf is a symlink to /etc/ldap.conf)

```
host 127.0.0.1:636

uri ldaps://127.0.0.1/   

base dc=my-company,dc=com

scope one

pam_filter objectclass=posixAccount

pam_login_attribute uid

pam_member_attribute memberUid

pam_password md5

nss_base_passwd         ou=People,dc=my-company,dc=com?one

nss_base_shadow         ou=People,dc=my-company,dc=com?one

nss_base_group          ou=Group,dc=my-company,dc=com?one

nss_base_hosts          ou=Hosts,dc=my-company,dc=com?one

ssl start_tls

ssl on
```

Finally is my /etc/pam.d/system-auth

```
auth        required      /lib/security/$ISA/pam_env.so

auth        sufficient    /lib/security/$ISA/pam_ldap.so 

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

auth        required      /lib/security/$ISA/pam_deny.so

account     sufficient    /lib/security/$ISA/pam_ldap.so

account     required      /lib/security/$ISA/pam_unix.so

password    required      /lib/security/$ISA/pam_cracklib.so retry=3 type=

password    sufficient    /lib/security/$ISA/pam_ldap.so use_authtok

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

password    required      /lib/security/$ISA/pam_deny.so

session     required      /lib/security/$ISA/pam_limits.so

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

session     optional      /lib/security/$ISA/pam_ldap.so

session     required      /lib/security/$ISA/pam_unix.so
```

 I hope all these are able to help you out a bit. Keep in mind, these files are pulled from a RedHat server. There isn't much difference between what RH and Gentoo are going to look like in this case (my laptop runs gentoo, and I got it to talk nicely to the RH server when I was testing my setup). Also, keep in mind there are some things that are in there specifically for Samba. I'm using a Samba domain controller that has an LDAP backend. Mainly I setup it up as a proof on concept so that hopefully company wide, they can roll it out. Otherwise it was a learning experience for myself so at least I didn't waste my time ^_~

Regards,

Petyr Rahl

----------

