Been already 2 days busy with this.
I am configuring ldap on yast and now I have an issue regarding the authentication.
My password is not being accepted even though I fill the correct password.
I have setup ldap using yast and here are some errors:
ldapwhoami
SASL/DIGEST-MD5 authentication started
Please enter your password:
ldap_sasl_interactive_bind_s: Invalid credentials (49)
additional info: SASL(-13): user not found: no secret in database
/var/log/messages:
:[rw] authid: “uid=root,cn=digest-md5,cn=auth” → “uid=root,cn=digest-md5,cn=auth”
: slap_parseURI: parsing uid=root,cn=digest-md5,cn=auth
: >>> dnNormalize: <uid=root,cn=digest-md5,cn=auth>
: <<< dnNormalize: <uid=root,cn=digest-md5,cn=auth>
: <==slap_sasl2dn: Converted SASL name to uid=root,cn=digest-md5,cn=auth
: slap_sasl_getdn: dn:id converted to uid=root,cn=digest-md5,cn=auth
: SASL Canonicalize [conn=1006]: slapAuthcDN=“uid=root,cn=digest-md5,cn=auth”
: SASL Canonicalize [conn=1006]: authzid=“root”
: SASL [conn=1006] Failure: no secret in database
: send_ldap_result: conn=1006 op=2 p=3
: send_ldap_result: err=49 matched="" text=“SASL(-13): user not found: no secret in database”
: send_ldap_response: msgid=3 tag=97 err=49
: conn=1006 op=2 RESULT tag=97 err=49 text=SASL(-13): user not found: no secret in database
LEt me know if you need more info, because of this issue I can’t create users or any other tasks in openldap
cat /etc/openldap/slapd.conf
Note: The OpenLDAP configuration has been created by YaST. YaST does not
use /etc/openldap/slapd.conf to store the OpenLDAP configuration anymore.
YaST uses OpenLDAP’s dynamic configuration database (back-config) to
store the LDAP server’s configuration.
For details about the dynamic configuration backend please see the
slapd-config(5) manpage or the OpenLDAP Software 2.4 Administrator’s Guide
located at /usr/share/doc/packages/openldap2/guide/admin/guide.html
SASL/DIGEST-MD5 authentication started
Please enter your password:
ldap_sasl_interactive_bind_s: Invalid credentials (49)
additional info: SASL(-13): user not found: no secret in database
ldapwhoami -x
anonymous
this is interesting, but still I have the problem in the yast userinterface
is there an option within the yast - ldap server to change the authentication mode ?
I am going to guess you are new-ish to LDAP on the command line. Please
confirm one way or another, so we can help with appropriate levels of
verbosity.
What does the following show:
ldapsearch -x
Which users have you defined in yast? Perhaps post the output from this:
getent passwd
Have you ever setup the LDAP client on a Linux box? On SLED specifically?
Do you see the slapd (as I recall) process running, which would be the
LDAP service itself?
ps aux | grep -i slapd
–
Good luck.
If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below…
I haven’t setup any LDAP clients on Linux and this is the first time.
Instead of manually configuration/installation , I used the Yast ldap interface.
And I can’t create any users, because of authentication errors
let me know if you need more info
[QUOTE=ecanmaster;24388]I haven’t setup any LDAP clients on Linux and this is the first time.
Instead of manually configuration/installation , I used the Yast ldap interface.
And I can’t create any users, because of authentication errors
let me know if you need more info[/QUOTE]
haven’t done this on SLED yet (just SLES), but that shouldn’t make much of a difference: During LDAP client setup, you’re asked for admin credentials to be used to bind to the LDAP backend. Have you entered anything there (i.e. “uid=root,cn=digest-md5,cn=auth”), or did you select “anonymous mode” instead?
When you set up the openLDAP server, you create some way to get write access to the server. Let’s call that the “LDAP root account”, and you’ll have set up a password to go with that.
When you use YaST, configured as an LDAP client, you’ll have to have write access to the LDAP tree, which is why you’d need to specify the “dn” to use to bind to the LDAP server. You’ll probably use the above “LDAP root account” for that (since I doubt you have created some different account in LDAP with the required permissions). Had you only wanted to use that SLED client to validate accounts, not to add them, you’d might configure to bind to the LDAP server anonymously in general (and for account password verification, the client would bind to the LDAP server using the current user’s credentials).
So what you probably are asked for, with your “ldapwhoami” invocation, is the password of the “LDAP root user”, with hopefully a different password than your Linux root user.
On the other hand, having had separately managed LDAP servers for ages, and only adding SLES client systems with anonymous bind since then, my above statements may be all nonsense.
I don’t think your statement could be nonsense, you probably/definitely know more then me.
First I installed OpenLDAP manually and I could configure all the settings in slapd.conf, but that system got corrupted, so I have a new machine.
I didn’t want to make any mistakes so I used the yast installation (Ldap - server).
Followed all the settings correctly and yes even put the password in.
I didn’t select anonymous mode.
Just to be sure I even changed the ldap password with slappasswd.
I only want to install ldap server and once it’s setup , I need it to use for authentication with openvpn.
here is a printscreen of my configuration.
Thx
that’s the server side of the game (the OpenLDAP server), how about the LDAP client configuration? (And it’s that LDAP client setup where you may configure to contact the server anonymously, or will have to provide the “Administrator DN” from your screen shot and the password you set.)
On SLES and OpenSUSE, YaST offers me “Network Services” - “LDAP Client” (right next to “LDAP Server”). I hope it’s the same on SLED, or at least sufficiently similar.
Excuse me for my ignorance, but do I need ldap client also?[/QUOTE]
yes, you do. Basically that YaST module takes care of the configuration of your SLE* system, pointing it at your LDAP server to fetch user/group information, and downloads any additionally required modules.
You need at least one running LDAP server, somewhere in your network.
You can point any SLE* host at that LDAP server, using the LDAP client configuration.
[QUOTE=ecanmaster;24414]I just checked and (Yast) ldap client is already enabled with correct information.
What do I need to do to get debug logs for this issue?[/QUOTE]
First of all, you should see messages in syslog about failed login attempts - including error messages if LDAP access failed during those checks.
Then I’d recommend to “manually” try to access the LDAP server: use "ldapsearch -Wx -b ‘dc=server-world,dc=com’ -D ‘cn=Administrator’ " and the password you set as the LDAP admin pw. You should see the proper entries then.
What’s in /etc/ldap.conf (strip all comments, please), in /etc/pam.d/common-auth and /etc/nsswitch.conf? ldap.conf contains the configuration used by the “LDAP Client” components - and those components are set up in the other files I asked for.
When I look at one of my test machines (no SLED, sorry), I see
> grep -v "^#" /etc/ldap.conf
uri ldap://firstLDAPserver.company.de ldap://secondLDAPserver.company.de
base ou=ourfolks,o=company,c=de
nss_map_attribute uniqueMember member
ssl no
pam_password exop
pam_filter objectClass=posixAccount
which tells the LDAP client to use the mentioned servers (two for redundancy), to search below “ou=ourfolks,o=company,c=d” (which is where we placed user accounts), to use no ssl (because we often do network traces for debugging) and to only look at account entries that have at least the “posixAccount” objectClass.
In common-auth you might find reference to a “pam_ldap” module, or maybe “pam_sss” (I don’t know if SLED uses this - “ab”, are you willing to jump in here with details?) and in nsswitch.conf this should reflect by either referencing ldap or sss for passwd and group.
Does your ldap.conf reflect the way you set up your LDAP server?
I don’t have syslog file on my system (syslog service is running though)
manually access to the server: # ldapsearch -Wx -b ‘dc=server-world,dc=com’ -D ‘cn=Administrator’
Enter LDAP Password:
ldap_bind: Invalid credentials (49)
here is my output: # grep -vE ‘^#|^;|^$’ /etc/ldap.conf
base dc=server-world,dc=com
bind_policy soft
pam_lookup_policy yes
pam_password exop
nss_initgroups_ignoreusers root,ldap
nss_schema rfc2307bis
nss_map_attribute uniqueMember member
ssl no
uri ldap://127.0.0.1
ldap_version 3
pam_filter objectClass=posixAccount
The ldap.conf file looks fine and I think the problem lies in SASL.
This is what the lof giles say:
[conn=1012]: slapAuthcDN=“uid=root,cn=digest-md5,cn=auth”
slapd[1006]: SASL Canonicalize [conn=1012]: authzid=“root”
slapd[1006]: SASL [conn=1012] Failure: no secret in database
slapd[1006]: send_ldap_result: conn=1012 op=2 p=3 slapd[1006]: send_ldap_result: err=49 matched="" text=“SASL(-13): user not found: no secret in database”
slapd[1006]: send_ldap_response: msgid=3 tag=97 err=49
slapd[1006]: conn=1012 op=2 RESULT tag=97 err=49 text=SASL(-13): user not found: no secret in database
maybe I should start from scratch.
Is there a way to start over again, but without YAST openldap.
I want to configure it manually this time, so I can edit the files like slapd.conf etc.
With yast that’s not possible.
I don’t want to remove the software, because of dependencies and it will definitely break the system.
I have disabled the yast ldap configuration and now doing it manually, but again have the same problem.
I don’t have syslog file on my suse 11 sp2 (64 bit)
# ldapsearch
SASL/DIGEST-MD5 authentication started
Please enter your password:
ldap_sasl_interactive_bind_s: Invalid credentials (49)
additional info: SASL(-13): user not found: no secret in database
# ldapsearch -x
extended LDIF
LDAPv3
base <dc=server-world,dc=com> (default) with scope subtree
I’m unsure how much impact the selected DNs have - your database uses a base DN of “dc=server-world,dc=com”, while the entry is on “dc=hwidc,dc=com”. I’d have expected the entry’s DN to have a suffix of “dc=server-world,dc=com”…
Any specific reason you created it that way? If not, I’d suggest to keep the LDAP entries in the same tree you created the database for.
Another issue that is still present is the login failure on ldapsearch - I read it that you created the slapd (openldap server) configuration using slapd.conf. When you look there, in the database section, are there rootdn and rootpw entries and are those the values you tried to use for your ldapsearch invocation?
Fixing the access to your LDAP database is the first issue… only then you should commence to the system authentication setup.