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:

Code: Select all

# 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:

Code: Select all

# 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

Code: Select all

# $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

Code: Select all

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

Code: Select all

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

Code: Select all

# 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

Code: Select all

# /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

Code: Select all

#%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 )

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

Code: Select all

$ 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...

Sorry I'm too lazy to check your config files

I absolutely understand

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

Code: Select all

# 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?

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

I'm proud it does

So, I just changed some stuff about the ACLs:

Code: Select all

# 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?

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

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

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

Code: Select all

 # 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
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.

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
Code:
#%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

Code: Select all

#%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.

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:

Code: Select all

# emerge -p pam_ldap    

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

Calculating dependencies ...done!
[ebuild   R   ] net-libs/pam_ldap-156  

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.

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:

Code: Select all

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?

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:

Code: Select all

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

Code: Select all

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]

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.

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:

Code: Select all

zaiyon@zion ~ $ ls -ld /home/p2p
drwxr-x---  4 p2p p2p 136 Sep 17 14:37 /home/p2p
zaiyon@zion ~ $ ls -l /home/p2p
ls: /home/p2p: Permission denied

what the (excuse me) HECK is that?
getent group/passwd look as they should, "groups zaiyon" too, everything says that I'm in the "p2p" group, but I just cannot access that folder on the client (it works on the server) so I'm desilusionated....

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.

Code: Select all

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?

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....

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"

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....

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:
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.

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 thx!

ganbatte! (work hard / good luck)

domo

[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

Code: Select all

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]

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 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.

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:
ldapsearch uid=zaiyon
and see if that gives you anything back (it should).

this equals on client/server:

Code: Select all

# 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.

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....

Code: Select all

# 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

here's the output:

Code: Select all

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 Do you by any chance know what this could mean?

interesting is this:

Code: Select all

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

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...

[Petyr]

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

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

Code: Select all

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:

Code: Select all

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

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?

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.

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:

Code: Select all

# /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

Code: Select all

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)

Code: Select all

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

Code: Select all

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