Re: openldap proxy to kerberos
On 01/07/19 16:18 -0500, vad...@gmail.com wrote: I am using openldap proxy today with ldap backend. Any suggestions on how to use kerberos as the backend? Here is my config (sanitized) $ cat slapd.conf ### Database definition (Proxy to AD) # databaseldap readonlyyes protocol-version3 rebind-as-user yes uri "ldaps://ldap.example.com:1636" suffix "ou=People,dc=example,dc=net" I'm not clear on where kerberos authentication fits scenario, but the two pieces of documentation to start with would be the slapo-ldap manpage, and the OpenLDAP Software 2.4 Administrator's Guide, section 14.5, and chapter 15. If that doesn't adress your question, please provide more detail, including how your clients authenticate with the proxy server.
Re: How to make ldap evaluate clear text password vs DES stored password
On 09/21/18 12:04 +0900, yokoy...@jacic.or.jp wrote: I can't find 'Pass-Through authentication (section 14.5)' in slapd-config(5) man page. Could you send me its URL? http://www.openldap.org/doc/admin24/
Re: How to make ldap evaluate clear text password vs DES stored password
in message "Re: How to make ldap evaluate clear text password vs DES stored password", Dan White wrote: On 09/20/18?08:43?+0900, yokoy...@jacic.or.jp wrote: >LDAP’s userPassowrd stored in the RDB has been already DES hashed by >original app. On the other hand, input password from ldapseach command >line is CREARTEXT. If the hashed/encrypted password is supported by your local crypt(3) library, you can prepend the userPassword value with {CRYPT} as specified in slapd-config(5) and section 14.4.2 of the Admin Guide. Else, if you have a pam module which supports authentication of your hash, take a look at Pass-Through authentication (section 14.5). On 09/20/18 23:27 +0900, yokoy...@jacic.or.jp wrote: My CentOS can make cleartext into DES . hete is a part of my previous slapd.conf olcPasswordHash: {CRYPT} olcSizeLimit: 5000 olcPasswordCryptSaltFormat: "_%s" unfortunately,it didn't work for my issue. i think my slapd uses DES when i try to store new userPasword. slapd will not really be concerned about the format of your hash, as long as your underlyding crypt(3) supports it. slapd will pass the cleartext password received from the client to crypt. You will need to consult your cyrpt(3) manpage for what is supported, and for what format it expects to receive ($id$rounds=yyy$salt$encrypts). i think unless i fetch userPasdword from RDB through slapd, i will not be able to find SALT in userPassword. If your RDB has a pam authentication module, then that may be a more appropriate route. In that case you would not need to make any of your RDB password hashes directly available to slapd. slapd would pass the cleartext password, from the client, down to the pam module by way of pass-through authentication and saslauthd. Also, you should be taking appropriate security measures to protect the cleartext password over the wire (ldaps/STARTTLS).
Re: How to make ldap evaluate clear text password vs DES stored password
On 09/20/18 08:43 +0900, yokoy...@jacic.or.jp wrote: LDAP’s userPassowrd stored in the RDB has been already DES hashed by original app. On the other hand, input password from ldapseach command line is CREARTEXT. I’d like to change certification process of LDAP source file to make input password into DES hashed by using 2 characters of userPassword as its SALT. I've already known that 2 characters at the beginning of userPasswordwas used as its SALT when it was hashed. So the fact is ,my slapd can read userPassword from the RDB. I think I'll be able to find out what will be SALT to make input password into DES hashed text. If the hashed/encrypted password is supported by your local crypt(3) library, you can prepend the userPassword value with {CRYPT} as specified in slapd-config(5) and section 14.4.2 of the Admin Guide. Else, if you have a pam module which supports authentication of your hash, take a look at Pass-Through authentication (section 14.5).
Re: new attribute
On 03/13/18 12:40 +0100, Alexander Schwarz wrote: I tried to create a new objectclass and a new attribute to develop scripts to use against an ActiveDirectory. objectlass=user attribute=sAMAccountName attributetype ( 1.2.840.113556.1.4.221 NAME 'sAMAccountName' EQUALITY caseIgnoreMatch SYNTAX '1.3.6.1.4.1.1466.115.121.1.15' SINGLE-VALUE ) objectclass ( 1.2.840.113556.1.5.9 NAME 'user' DESC 'a user' SUP inetOrgPerson STRUCTURAL MUST ( cn ) MAY ( sAMAccountName ) ) This is included in slapd.conf: include ./schema/test.schema modify.ldif: dn: cn=test test,ou=Benutzer,ou=Netzwerk,dc=network,dc=de changetype: modify add: sAMAccountName sAMAccountName: test I used the ldapmodify tool: ldapmodify -a -x -D "cn=admin,dc=network,dc=de" -w passwd -H ldap:// -f d:\modify.ldif Eintrag cn=test test,ou=Benutzer,ou=Netzwerk,dc=network,dc=de wird geändert ldap_modify: Objektklassenverletzung ldap_modify: Zusätzliche Info: attribute 'sAMAccountName' not allowed Have you added the 'user' object class to the 'cn=test test' entry? -- Dan White
Re: Antw: Re: OpenLDAP / Active directory cohabitation
On 05/30/17 08:10 +0200, Ulrich Windl wrote: Clément OUDOT schrieb am 29.05.2017 um 20:43 in Nachricht : 2017-05-29 19:00 GMT+02:00 Dan White : On 05/29/17 23:36 +0900, Alexandre Rosenberg wrote: I am in a environment where we use both OpenLDAP and Active Directory. All Linux servers authenticate against OpenLDAP where we have user group, unix group (...) Pass-through authentication should work if you're performing simple binds. Chapter 14 of the admin guide has a good example. You can also find a tutorial here: https://ltb-project.org/documentation/general/sasl_delegation I have one question: Why is hte AD admin accound needed to authenticate? I see a problem with the AD admin password being stored in cleartext in the saslauthd configuration... Here's a simpler approach that does not require storing a password: https://www.openldap.org/lists/openldap-technical/201106/msg00198.html This was tested against AD 2003. You may need to use ldaps with newer versions. -- Dan White
Re: OpenLDAP / Active directory cohabitation
On 05/29/17 23:36 +0900, Alexandre Rosenberg wrote: I am in a environment where we use both OpenLDAP and Active Directory. All Linux servers authenticate against OpenLDAP where we have user group, unix group (...) This means that if perform a BIND and a search, the BIND should be performed against the AD but the search result should from OpenLDAP. (anonymous search is fine) The short username are used in in OpenLDAP like this: uid=john01,ou=People,dc=example,dc=com While the AD uses the long username. From my test when binding to AD, only the "DN" is simply set to the username. john.sm...@example.com Pass-through authentication should work if you're performing simple binds. Chapter 14 of the admin guide has a good example. If you're doing sasl binds, use gssapi to authenticate against the AD server directly. -- Dan White
Re: Search for primary group
On 05/23/17 09:17 -0400, Bernard Fay wrote: Is there a way to find the primary group of a user with ldapsesarch or other command? I run OpenLDAP version 2.4.40 on CentOS 7.2 if that matters. I assume you're asking about unix groups. Commonly the primary unix group id is stored within the gidNumber attribute of the user's corresponding DN. You can retrieve the primary group id with 'getent passwd ', or by searching for that attribute. Refer to your nss documentation (libnss-ldap, nss-pam-ldapd, nssov) for how to resolve the gidNumber to a group name, or use 'getent group '. The first group printed using 'groups ' should be the primary group, but the man page makes no claims of that being true. -- Dan White
Re: Filtered proxy to Active Directory
On 04/21/17 21:23 +, Kamenko Pajic wrote: We have Panasonic KX-UTG300B phones (SIP phone) which has LDAP Phonebook option. Settings on the phone to make this work are simple: LDAP Server Address: LDAP Server Port: LDAP Authentication ID: LDAP Authentication Password: LDAP Search Base: When I go to LDAP address book on the phone I get thousands of entries listing not only users with their phone number but also all other entries like resources, empty lines(???), N/A, Distribution lists .. Etc. in short probably everything. Try creating a group with your desired users and use that as your base.
Re: Dovecot can't connect to openldap over starttls
On 03/20/17 16:06 +0100, i...@gwarband.de wrote: I don't have any idea how to set a higher debug level to dovecot. In my opinion I have the highest. So I can't deliver a greater log. I recommend consulting Dovecot's advice on how to run a debugger, or dig into the code which calls libldap.
Re: Dovecot can't connect to openldap over starttls
On 03/19/17 09:07 +0100, i...@gwarband.de wrote: Am 2017-03-19 01:09, schrieb Dan White: On 03/17/2017 04:27 PM, i...@gwarband.de wrote: https://gwarband.de/openldap/dovecot.log Mar 11 11:18:26 s1 dovecot: auth: Debug: Read auth token secret from /var/run/dovecot/auth-token-secret.dat Mar 11 11:18:26 s1 dovecot: auth: Error: LDAP: ldap_start_tls_s() failed: Connect error Mar 11 11:18:26 s1 dovecot: auth: Error: LDAP: ldap_start_tls_s() failed: Connect error Mar 11 11:18:26 s1 dovecot: auth: Debug: auth client connected (pid=27177) Mar 11 11:18:33 s1 dovecot: imap-login: Disconnected (no auth attempts in 7 secs): user=<>, rip=149.172.171.148, lip=188.68.37.50, session= https://gwarband.de/openldap/dovecot-ldap.conf uris = ldap://ldap.gwarband.de dn = cn=T2,ou=tech,dc=gwarband,dc=de dnpass = secret tls = yes tls_ca_cert_file = /etc/ssl/certs/LetsEncrypt.pem auth_bind = yes ldap_version = 3 base = dc=gwarband,dc=de scope = subtree user_attrs = mail=maildir:/var/vmail/%{ldap:mailbox},uid=vmail,gid=vmail user_filter = (&(email=%u)(memberOf=cn=mailbox,ou=application,ou=groups,dc=gwarband,dc=de)) pass_attrs = email=user pass_filter = (&(email=%u)(memberOf=cn=mailbox,ou=application,ou=groups,dc=gwarband,dc=de)) https://gwarband.de/openldap/openldap.conf # Certificate TLSCACertificateFile/etc/ssl/certs/LetsEncrypt.pem TLSCertificateFile /etc/ssl/certs/gwarbandDE_LDAP.pem TLSCertificateKeyFile /etc/ssl/certs/gwarbandDE_LDAP.key TLSCipherSuite SECURE128:-ARCFOUR-128:-CAMELLIA-128-CBC:-3DES-CBC:-CAMELLIA-128-GCM TLSProtocolMin 3.1 TLSVerifyClient never # Read slapd.conf(5) for possible values loglevel256 There are more verbose options. # Include ACLs include /etc/ldap/acl.conf What are the contents of /etc/ldap/ldap.conf? The ldap.conf has no difference to the dovecot-ldap.conf. See: https://gwarband.de/openldap/ldap.conf The point "TLS_REQCERT" is in both confs "demand". I've changed it after that. The ldapsearch command works also under the user "dovecot" See: https://gwarband.de/openldap/ldapsearch-dovecot.log ~$ ldapsearch -x -ZZ -D "cn=admin,dc=gwarband,dc=de" -W "cn=mailbox" There is a difference in your binding DN. Debug Dovecot's implementation of ldap_start_tls_s(). -- Dan White
Re: Dovecot can't connect to openldap over starttls
Reformatted: On 03/17/2017 04:27 PM, i...@gwarband.de wrote: Hello guys, actually I'm trying to configure dovecot to access openldap for passwordcheck. All datalinks: https://gwarband.de/openldap/dovecot.log Mar 11 11:18:26 s1 dovecot: auth: Debug: Read auth token secret from /var/run/dovecot/auth-token-secret.dat Mar 11 11:18:26 s1 dovecot: auth: Error: LDAP: ldap_start_tls_s() failed: Connect error Mar 11 11:18:26 s1 dovecot: auth: Error: LDAP: ldap_start_tls_s() failed: Connect error Mar 11 11:18:26 s1 dovecot: auth: Debug: auth client connected (pid=27177) Mar 11 11:18:33 s1 dovecot: imap-login: Disconnected (no auth attempts in 7 secs): user=<>, rip=149.172.171.148, lip=188.68.37.50, session= https://gwarband.de/openldap/dovecot-ldap.conf uris = ldap://ldap.gwarband.de dn = cn=T2,ou=tech,dc=gwarband,dc=de dnpass = secret tls = yes tls_ca_cert_file = /etc/ssl/certs/LetsEncrypt.pem auth_bind = yes ldap_version = 3 base = dc=gwarband,dc=de scope = subtree user_attrs = mail=maildir:/var/vmail/%{ldap:mailbox},uid=vmail,gid=vmail user_filter = (&(email=%u)(memberOf=cn=mailbox,ou=application,ou=groups,dc=gwarband,dc=de)) pass_attrs = email=user pass_filter = (&(email=%u)(memberOf=cn=mailbox,ou=application,ou=groups,dc=gwarband,dc=de)) https://gwarband.de/openldap/openldap.log Mar 11 10:48:38 s1 slapd[26962]: conn=1001 fd=14 ACCEPT from IP=188.68.37.50:60814 (IP=188.68.37.50:389) Mar 11 10:48:38 s1 slapd[26962]: conn=1001 op=0 STARTTLS Mar 11 10:48:38 s1 slapd[26962]: conn=1002 fd=15 ACCEPT from IP=188.68.37.50:60815 (IP=188.68.37.50:389) Mar 11 10:48:38 s1 slapd[26962]: conn=1002 op=0 STARTTLS Mar 11 10:49:42 s1 slapd[26962]: connection_get(14): got connid=1001 Mar 11 10:49:42 s1 slapd[26962]: connection_read(14): checking for input on id=1001 Mar 11 10:49:42 s1 slapd[26962]: connection_read(14): TLS accept failure error=-1 id=1001, closing Mar 11 10:49:42 s1 slapd[26962]: connection_get(15): got connid=1002 Mar 11 10:49:42 s1 slapd[26962]: connection_read(15): checking for input on id=1002 Mar 11 10:49:42 s1 slapd[26962]: connection_read(15): TLS accept failure error=-1 id=1002, closing Mar 11 10:49:42 s1 slapd[26962]: conn=1001 fd=14 closed (TLS negotiation failure) Mar 11 10:49:42 s1 slapd[26962]: conn=1002 fd=15 closed (TLS negotiation failure) https://gwarband.de/openldap/trace.dump It appears that the client is sending an unbind request after the server sends a successful starttls response. The bugreportinglink from openldap: http://www.openldap.org/its/index.cgi/Incoming?id=8615 Am 2017-03-17 22:48, schrieb Tomas Habarta: been running Dovecot 2.2.27 against OpenLDAP 2.4.40 normally over the unix socket on the same machine, but tried over inet with STARTTLS and it's working ok... I would suggest double-checking key/certs setup on OpenLDAP side; for the test I have used LE certs, utilizing following cn=config attributes: olcTLSCertificateKeyFile contains private key olcTLSCertificateFilecontains certificate olcTLSCACertificateFile contains both certs (DST Root CA X3 and Let's Encrypt Authority X3) and used the same CA file in Dovecot's tls_ca_cert_file Is ldapsearch working ok (-ZZ) and only Dovecot has troubles or ... ? On 03/18/2017 09:41 AM, i...@gwarband.de wrote: I have also installed LE certs. But nothing helps, I have double-checking all certs. ldapsearch with -ZZ works see: https://gwarband.de/openldap/ldapsearch.log ldapsearch -x -ZZ -D "cn=admin,dc=gwarband,dc=de" -W "cn=mailbox" I have also uploaded the TLSCACertificateFile, maybe I have a failure in the merge of the two fiels: https://gwarband.de/openldap/LetsEncrypt.crt And also I have uploaded my complete openldap configuration: https://gwarband.de/openldap/openldap.conf # Certificate TLSCACertificateFile/etc/ssl/certs/LetsEncrypt.pem TLSCertificateFile /etc/ssl/certs/gwarbandDE_LDAP.pem TLSCertificateKeyFile /etc/ssl/certs/gwarbandDE_LDAP.key TLSCipherSuite SECURE128:-ARCFOUR-128:-CAMELLIA-128-CBC:-3DES-CBC:-CAMELLIA-128-GCM TLSProtocolMin 3.1 TLSVerifyClient never All other components can work and communicate with my openldap server. The components are postfix, openxchange, apache (phpldapadmin). My installated software is: Debian 8 OpenLDAP 2.4.40 Dovecot 2.2.13 Am 2017-03-18 12:30, schrieb Tomas Habarta: Well, if ldapsearch works, try to replicate its settings for dovecot client. It's not obvious what settings ldapsearch uses, have a look at default client settings in /etc/openldap/ldap.conf, there may be something set a slightly different way. Also double check permissions for files used by dovecot, I mean mainly the file listed for tls_ca_cert_file as dovecot may not have an access for reading... I cannot see anything downright bad, just posted CA cert (which is ok, tested) is *.crt and your config mentions *.pem but I consider it's the same file. Finally, I would recommend to enable debug option
Re: user removed from ldap group but Linux groups command still shows user as member of the group
On 02/24/17 08:55 -0500, Bernard Fay wrote: I removed a user from an LDAP group about a week ago. Today, this user still shows as member of the group with the Linux command groups. Also, the group (Administrators) appears twice in the output of the command id: uid=1(username) gid=1(Administrators) groups=10001(users),10005(devel),10011(video),10015(ansible),1(Administrators) The command getent though shows the proper group assignation: getent group | grep username | cut -d: -f1 users devel video ansible All of those groups are LDAP group. Is this from a long running shell? If so, start a new shell or run newgrp. Otherwise, verify that it is not cached (such as with nscd), and trouble shoot as an nss ldap problem. -- Dan White
Re: cant create child entrys
On 12/22/16 14:07 +, robert k Wild wrote: i cant create child entrys apart from OU and OR, why is this? i have installed openldap on a centos 7 vm and also phpldapadmin to manage the ldap server i imagine this is an openldap issue and not a php ldap admin issue https://s28.postimg.org/l5zb58h4t/Capture.png What error are you getting on the failed create? Is your new entry properly formatted? I'd suggest creating the entry using ldapadd, which would be easier to trouble shoot on failure.
Re: LDAP User can't login can su to with root account
On 12/22/16 17:39 +0800, Frank Yu wrote: I can see this log from audit.log when try to login type=USER_AUTH msg=audit(1482399412.928:11840): pid=23099 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=pubkey acct="luo.lu" exe="/usr/sbin/sshd" hostname=? addr=10.31.0.113 terminal=ssh res=failed' I presume you are using selinux? If so I can't offer much help here other than to suggest disabling it in a lab environment to see if that's what's tripping you up. Can you get better logging from sshd?
Re: LDAP User can't login can su to with root account
On 12/18/16 18:40 +0800, Frank Yu wrote: I have setup a LDAP service on host A, and configure ldap client on host B. when I tried to login host B with user which already added in LDAP server, it report error even through I enter right passwd shanzhi.yu@10.10.10.101's password: debug3: send packet: type 50 debug2: we sent a password packet, wait for reply debug3: receive packet: type 51 debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password Permission denied, please try again. shanzhi.yu@10.10.10.101's password: debug3: send packet: type 50 debug2: we sent a password packet, wait for reply debug3: receive packet: type 51 debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password Permission denied, please try again. shanzhi.yu@10.10.10.101's password:" and, I can su to user shanzhi.yu on host B [root@ host B ~]# su shanzhi.yu [shanzhi.yu@ host B root]$ cd [shanzhi.yu@ host B ~]$ There are too many missing variables to give you specific advice. General trouble shooting steps would include: 1) Enable server side (ssh) debugging to glean additional insight into the problem. 2) Verify your ssh server config has pam enabled (assuming you're using an ldap based pam module). 3) And if you are depending on pam to perform authentication, verify your pam config with pamtester. Consult your pam ldap module documentation as pam tends to be one of the more complicated parts of this type of setup.
Re: How to move from hdb to mdb
On 09/20/16 12:40 +, Nikolas Stylianides wrote: Hi there. Is there a howto move from hdb to mdb? What we need to do is to transfer our directory from hdb to the mdb. Is there a book to learn about openldap? With the new OLC way of doing things? Can i have hdb and mdb running at the same time? Currently I have done the following: 1. Load the Module back_mdb 2. Created a OlcBackend 3. Created a OlcDatabase See http://www.openldap.org/doc/admin24/ and slapcat(8), slapadd(8), slapd-mdb(5), and slapd-config. Consider converting in two steps - converting your database to mdb first, then converting to slapd-config.
Re: nslcd listing users and groups twice
On 08/15/16 14:50 -0400, John Lewis wrote: The commands return duplicate data is getent passwd and getent group, if I don't add a specific user as a parameter in the command. # /etc/nsswitch.conf passwd: compat ldap group: compat ldap Are you using netgroups in /etc/passwd? On 08/14/16 13:50 -0400, John Lewis wrote: uid nslcd gid nslcd uri ldap://localhost base dc=d,dc=oflameo,dc=com ldap_version 3 binddn cn=ldap-connect,ou=Users,dc=d,dc=oflameo,dc=com bindpw x tls_cacertfile /etc/ssl/certs/ca-certificates.crt base dc=d,dc=oflameo,dc=com filter passwd (objectClass=posixAccount) filter group (objectClass=posixGroup) map passwd uiduid map passwd uidNumber uidNumber map passwd loginShell loginShell map passwd homeDirectory homeDirectory map passwd gecos gecos map passwd gidNumber gidNumber map group member member bind_timelimit 60 timelimit 60 idle_timelimit 300 Do you have multiple users which meet the above criteria? -- Dan White
Re: nslcd listing users and groups twice
On 08/14/16 13:50 -0400, John Lewis wrote: Subject: nslcd listing users and groups twice This is surprisingly non-trivial especially when the nis schema for openldap is more documented than the samba one when I use to run samba-ad-dc. I have the nslcd.conf attatched. What command are you running which duplicates data? What are the contents of your nsswitch.conf? -- Dan White
Re: require authc and SASL GSSAPI
On 05/09/16 09:29 +0200, Christian wrote: Dear list, I use Kerberos/GSSAPI for authentication, and I recently locked down my ldap servers with "require authc". With Kerberos tickets, I used to be able to just enter ldapsearch What response do you get? on the command line. Now I have to do ldapsearch -Y GSSAPI I assume this is because ldapsearch has to do a nonauthenticated bind to find out about the SASL auth mechanisms (by looking for supportedSASLMechanisms), and that fails now. So it would be great if I You can verify with: ldapsearch -LLL -x -H ldap://ldap.example.org -s "base" -b "" supportedSASLMechanisms had a way of setting the default SASL auth mechanism on a machine for all users. However, man ldap.conf tells me that the setting for SASL_MECH is a per user setting only. Is there any other way to achieve this, or am I doing the wrong thing by requiring authc? Thanks, Two options come to mind: 1) Configure GSSAPI as the only available SASL mechanism, within your sasl slapd.conf, on the server. 2) Remove all other sasl mechanisms/shared libraries on the client machine. -- Dan White
Re: LDAPI mechanism too weak for this user
On 04/07/16 16:16 -0400, Frank Crow wrote: I have locked down my server to disallow anonymous binds and set the SSF=128. I also have SaslSecProps: noplain,noanonymous,minssf=128 Which all seems to work fine for my usage with one exception. If I try to use any of the command line tools with "-Y EXTERNAL -H ldapi:///", I now get: additional info: SASL(-15): mechanism too weak for this user: mech EXTERNAL is too weak Is there some configuration item that I can change to allow that work while maintaining my existing policy of no anonymous binds for everything else, etc? Set olcLocalSSF to your desired value within your server config. -- Dan White
Re: Question about ldap_init()/ldap_initialize() behavior with OpenLDAP
On 03/30/16 10:19 -0400, Frank Crow wrote: I'm not clear on whether I'm allowed to ask "C" API questions here. If not, I apologize in advance and please disregard in that case. However, the question is more about configuration than coding. I'm seeing that the ldap_init() function allows the hostname parameter to be null or a list of hosts.If it is null, the function attempts to determine the default ldap host. How does it determine the default LDAP host when the hostname parameter is null? Does it load the list of hosts from the ldap.conf URI parameter? And/or does it use the LDAPURI environment variable? The order is detailed in the ldap.conf manpage, within the DESCRIPTION section. -- Dan White
Re: BINDDN in ~/.ldaprc ignored(?)
On 02/09/16 10:28 +0100, Frank Thommen wrote: BINDDN in ~/.ldaprc seems to be ignored or I'm doing something wrong. /etc/openldap/ldap.conf is empty. ~/.ldaprc is: $ cat ~/.ldaprc BINDDN BASE URI ldaps:// TLS_REQCERT never $ ldapsearch returns an error if I don't declare the bindDN on the commandline: $ ldapsearch -W -v cn=xyz ldap_initialize( ) Enter LDAP Password: SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Local error (-2) additional info: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (No Kerberos credentials available) $ For SASL binds, specify SASL_AUTHCID instead; however this option will be ignored by the sasl library for GSSAPI binds, in which case SASL_AUTHZID may be used if you need to specify an authz identity. For non-sasl binds, specify '-x' on your command line, which does make use of BINDDN. -- Dan White
Re: pass-through authentication
You can view your config with: slapcat -n0 And verify that object exists. If you're receiving this error due to an ACL problem, verify you have the proper configuration in place to authenticate as the rootdn using sasl/external. See the slapd-config manpage, and see section 15.2 (and in particular 15.2.5) of the Administrator's guide, and reference your OS/distro documentation. On 01/21/16 12:35 -0600, Timothy Keith wrote: I commented the mech_list in slapd.conf The ldapsearch result is now No such object ldapsearch -LLLQY EXTERNAL -H ldapi:/// -b cn=config "(|(cn=config)(olcDatabase={1}hdb))" No such object (32) On Fri, Jan 8, 2016 at 2:34 PM, Dan White wrote: On 01/07/16 17:24 -0600, Timothy Keith wrote: ldapsearch -LLLQY EXTERNAL -H ldapi:/// -b cn=config "(|(cn=config)(olcDatabase={1}hdb))" ldap_sasl_interactive_bind_s: Authentication method not supported (7) additional info: SASL(-4): no mechanism available: I'm missing some context here. Most likely you have a mech_list hard coded in your slapd.conf sasl, which does not include the external mech.
Re: LDAP with MySQL Support and Radius
On 01/20/16 18:07 +, Alexandre Vilarinho wrote: I'm trying to install LDAP wirh mysql support to authenticate users radius account and I'm having problems finding documentation explaining how to do it. Does any implemented an environment link I'm willing to do? It is possible to share this documentation? Is there a step-by-step explaining how to do it? OpenLDAP supports sql authentication via ODBC and back-sql. See the back-sql manpage, and sections 11.11 and 1.8 of the Administrator's guide for an PostgreSQL example and discussion. I would not recommend it, unless you have an entrenched environment and know what you're doing. RADIUS, MySQL, and OpenLDAP are orthogonal. A RADIUS server, such as FreeRADIUS can be configured to use MySQL or LDAP for its credentials database. -- Dan White
Re: pass-through authentication
On 01/07/16 17:24 -0600, Timothy Keith wrote: ldapsearch -LLLQY EXTERNAL -H ldapi:/// -b cn=config "(|(cn=config)(olcDatabase={1}hdb))" ldap_sasl_interactive_bind_s: Authentication method not supported (7) additional info: SASL(-4): no mechanism available: I'm missing some context here. Most likely you have a mech_list hard coded in your slapd.conf sasl, which does not include the external mech. -- Dan White
Re: pass-through authentication
On Wed, Dec 30, 2015 at 7:04 PM, Dan White wrote: Is DIGEST-MD5 available on your ldap server? Try: ldapsearch -LLL -x -H ldap://1.2.3.4 -s "base" -b "" supportedSASLMechanisms On 12/31/15 09:51 -0600, Timothy Keith wrote: Dan, that ldapsearch returns : dn: supportedSASLMechanisms: PLAIN On Mon, Jan 4, 2016 at 1:16 PM, Dan White wrote: On 01/04/16 09:41 -0600, Timothy Keith wrote: ldapwhoami -Y PLAIN -H ldap://182.19.136.42 -U testuser produces : ldap_sasl_interactive_bind_s: Unknown authentication method (-6) additional info: SASL(-4): no mechanism available: No worthy mechs found On 01/04/16 14:47 -0600, Timothy Keith wrote: pluginviewer returned this, as well as several other plugins : List of server plugins follows Plugin "plain" [loaded],API version: 4 SASL mechanism: PLAIN, best SSF: 0, supports setpass: no security flags: NO_ANONYMOUS features: WANT_CLIENT_FIRST|PROXY_AUTHENTICATION Something doesn't add up here. The remote server claims to support sasl plain, and your local server claims to support it as well. I suppose your server could be claiming support, but not really supporting it without a security layer, in which case you might investigate doing ssl/starttls. See if you can get a hold of any logs from the server. -- Dan White
Re: pass-through authentication
On 01/04/16 09:41 -0600, Timothy Keith wrote: ldapwhoami -Y PLAIN -H ldap://182.19.136.42 -U testuser produces : ldap_sasl_interactive_bind_s: Unknown authentication method (-6) additional info: SASL(-4): no mechanism available: No worthy mechs found Verify you have the sasl plain mechanism available on your local system with saslpluginviewer/pluginviewer. On some systems it is contained in a separate package from the libsasl2 glue library, e.g. libsasl2-modules. -- Dan White
Re: pass-through authentication
On 12/31/15 11:13 -0600, Timothy Keith wrote: I defined: ldap_mech: PLAIN I am new at LDAP , that is obvious I guess. But, I've been around Unix for 30 years. This is the latest output from saslauthd in debug mode : saslauthd[19271] :main: num_procs : 5 saslauthd[19271] :main: mech_option: NULL saslauthd[19271] :main: run_path : /var/run/saslauthd saslauthd[19271] :main: auth_mech : ldap saslauthd[19271] :ipc_init: using accept lock file: /var/run/saslauthd/mux.accept saslauthd[19271] :detach_tty : master pid is: 0 saslauthd[19271] :ipc_init: listening on socket: /var/run/saslauthd/mux saslauthd[19271] :main: using process model saslauthd[19271] :have_baby : forked child: 19272 saslauthd[19271] :have_baby : forked child: 19273 saslauthd[19271] :have_baby : forked child: 19274 saslauthd[19271] :have_baby : forked child: 19275 saslauthd[19271] :get_accept_lock : acquired accept lock saslauthd[19271] :rel_accept_lock : released accept lock saslauthd[19272] :get_accept_lock : acquired accept lock ldap_sasl_interactive_bind: user selected: PLAIN ldap_int_sasl_bind: PLAIN ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP 182.19.136.42:389 ldap_new_socket: 10 ldap_prepare_socket: 10 ldap_connect_to_host: Trying 182.19.136.42:389 ldap_pvt_connect: fd: 10 tm: 10 async: 0 ldap_ndelay_on: 10 attempting to connect: connect errno: 115 ldap_int_poll: fd: 10 tm: 10 ldap_is_sock_ready: 10 ldap_ndelay_off: 10 ldap_pvt_connect: 0 ldap_int_sasl_open: host=182.19.136.42 ldap_msgfree ldap_err2string ldap_unbind ldap_free_connection 1 1 ldap_send_unbind ldap_free_connection: actually freed ldap_create ldap_url_parse_ext(ldap:// 182.19.136.42:389) ldap_sasl_interactive_bind: user selected: PLAIN ldap_int_sasl_bind: PLAIN ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP 182.19.136.42:389 ldap_new_socket: 10 ldap_prepare_socket: 10 ldap_connect_to_host: Trying 182.19.136.42:389 ldap_pvt_connect: fd: 10 tm: 10 async: 0 ldap_ndelay_on: 10 attempting to connect: connect errno: 115 ldap_int_poll: fd: 10 tm: 10 ldap_is_sock_ready: 10 ldap_ndelay_off: 10 ldap_pvt_connect: 0 ldap_int_sasl_open: host=182.19.136.42 ldap_msgfree ldap_err2string saslauthd[19271] :do_auth : auth failure: [user=testuser] [service=slapd] [realm=] [mech=ldap] [reason=Unknown] saslauthd[19271] :do_request : response: NO On 12/31/15 11:43 -0600, Timothy Keith wrote: attempting to connect: connect errno: 115 *EINPROGRESS* That doesn't appear to be a critical piece of the problem. Notice libldap is polling and reporting the socket as ready. Trouble shoot this as a basic authentication problem between your unix server and the ldap server. I.e., attempt to reproduce a sasl plain authentication using ldapwhoami: ldapwhoami -Y PLAIN -H ldap://182.19.136.42 -U testuser Adjust to match your saslauthd ldap config. Assuming your connection is unencrypted, which is appears to be, performing a tcpdump/wireshark trace will help. -- Dan White
Re: pass-through authentication
On 12/17/15 18:32 -0600, Timothy Keith wrote: We are attempting to set up an LDAP server which will answer queries from an application. The database will contain metadata on a set of users in the application. The application will also query the server to authenticate the user’s password, however, this server will not house the password. That resides on another server, which our server will query. We do not have administrative rights to the other server. The difficulty we are having now is setting up the pass-through authentication for the passwords. Any pointers in how to proceed with this would be greatly appreciated. On 12/21/15 17:24 -0600, Timothy Keith wrote: We have limited access to the servers. Same company, different IT organization. Our LDAP requirement must be transparent to those servers. We want to inherit the LDAP directory information from the Unix servers - mostly the user Id and passwords, and add information that is needed by applications that our servers will manage. On 12/31/15 09:51 -0600, Timothy Keith wrote: On Wed, Dec 30, 2015 at 7:04 PM, Dan White wrote: On 12/30/15 18:51 -0600, Timothy Keith wrote: This is tail of the latest saslauthd debug output : ldap_sasl_interactive_bind: user selected: DIGEST-MD5 res_errno: 7, res_error: , res_matched: <> ldap_free_request (origid 1, msgid 1) ldap_int_sasl_bind: DIGEST-MD5 ldap_parse_sasl_bind_result ldap_parse_result ldap_msgfree ldap_err2string Is DIGEST-MD5 available on your ldap server? Try: ldapsearch -LLL -x -H ldap://1.2.3.4 -s "base" -b "" supportedSASLMechanisms Which should list the advertised sasl mechanisms. Verify the digest-md5 mechanism is installed with saslpluginviewer/pluginviewer. Dan, that ldapsearch returns : dn: supportedSASLMechanisms: PLAIN The server is only offering the PLAIN mechanism to you. It appears you're using saslauthd's ldap backend, and have explicitly configured 'ldap_mech: digest-md5' in your corresponding config. If that's correct, you could change that to PLAIN instead. Consider protecting the bind with tls if available. slapo-pbind may be a simpler alternative (to pass-through sasl authentication), depending on the specifics of your setup. -- Dan White
Re: pass-through authentication
On 12/30/15 18:51 -0600, Timothy Keith wrote: This is tail of the latest saslauthd debug output : ldap_sasl_interactive_bind: user selected: DIGEST-MD5 res_errno: 7, res_error: , res_matched: <> ldap_free_request (origid 1, msgid 1) ldap_int_sasl_bind: DIGEST-MD5 ldap_parse_sasl_bind_result ldap_parse_result ldap_msgfree ldap_err2string Is DIGEST-MD5 available on your ldap server? Try: ldapsearch -LLL -x -H ldap://1.2.3.4 -s "base" -b "" supportedSASLMechanisms Which should list the advertised sasl mechanisms. Verify the digest-md5 mechanism is installed with saslpluginviewer/pluginviewer. -- Dan White
Re: pass-through authentication
On 12/30/15 18:29 -0600, Timothy Keith wrote: I'm still having troubles with pass-through SASL on RHEL testsaslauthd produces this message : 0: NO "authentication failed" Consult the cyrus sasl documentation, which for saslauthd is underneath the saslauthd directory within the source, as well as the manpage. With this in the system log : saslauthd logs reason=Unknown When saslauthd is launched in verbose mode and followed by testsaslauthd it prints : connect() : No such file or directory When running in debug mode, verify you're including the exact options with which saslauthd is normally running, with the -d option added. The mux location compiled into testsaslauthd is not matching where the mux is listening in this case, or the mux isn't listening. On Thu, Dec 24, 2015 at 1:46 PM, Timothy Keith wrote: As per my ongoing LDAP SASL design question, can anyone recommend a good tutorial for pass-through authentication ? See section 14.5 of the Administrator's Guide, and read through the documentation at cyrussasl.org. -- Dan White
Re: SASL Passthrough no request
On 12/30/15 08:40 +, Küchler, Simon wrote: Our password authetication should use SASL but we don't see any requests in our Logs or by tcpdump. The password authentication should work as follows - userPassword-Attribute: {SASL}User@Domain - saslauthd -> use PAM - PAM -> use kerberos - kerberos -> send request to Active-Directory Server Configuration files: lshxx0693:~ # cat /etc/sasl2/slapd.conf mech_list: plain login pwcheck_method: saslauthd lshxx0693:~ # cat /etc/sysconfig/saslauthd SASLAUTHD_AUTHMECH=pam SASLAUTHD_THREADS=5 SASLAUTHD_PARAMS="-r" lshxx0693:~ # cat /etc/pam.d/ldap auth required pam_krb5.so no_user_check account requiredpam_permit.so lshxx0693:~ # cat /etc/krb5.conf [libdefaults] default_realm = INT.IT.DPP dns_lookup_kdc = true [realms] INT.IT.DPP = { kdc = 10.150.10.10 kdc = 10.150.10.10 } [logging] default = SYSLOG:NOTICE:DAEMON Is testsaslauthd successful? If not, address that first (on the cyrus sasl mailing list). If you're still having issues, run saslauthd in debug mode, and verify your slapd process is communicating with the saslauthd mux. Verify it is writable by the slapd process. -- Dan White
Re: OpenLdap Clear-text Password in Debug Mode
Two approaches are Kerberos and SASL EXTERNAL authentication over client TLS certificates. Neither approach reveals private key material to the server. On 12/01/15 07:39 -0500, Rich Alford wrote: Thank you Ryan. So there's no way around that? I.e. Is there a strategy that can alleviate that? On Mon, Nov 30, 2015 at 4:34 PM, Ryan Tandy wrote: On Mon, Nov 30, 2015 at 02:20:44PM -0500, Rich Alford wrote: Theoretically, the password should be hashed on the client, sent across the network, to be compared against the hashed passwords in the database. The client has no idea how the server stores or hashes passwords. The server might not even store them directly, but could be passing them to a third party (f.ex. a Kerberos KDC) for verification. So the client sends the password to the server in the clear (but protected by TLS), and the server verifies the password however it's configured to, in your case by hashing it and comparing the hash to the stored hash. -- Dan White
Re: sasl-auxprop (and sasl/slapd.conf)
On 11/17/15 18:38 +0100, Simone Piccardi wrote: I'm trying to understand which values I can use for the sasl-auxprop directives and how to configure (if possible) sasl/slapd.conf. That's a lot more painful to determine than it should be. Do: # cat > /sasl/pluginviewer.conf << EOF ldapdb_uri: ldapi:/// sql_select: select foo from bar EOF # pluginviewer -a Installed and properly configured auxprop mechanisms are: sasldb List of auxprop plugins follows Plugin "sasldb" , API version: 8 supports store: yes On Debian based systems, use saslpluginviewer. To this list, add 'slapd', which is the internal auxprop plugin, and subtract ldapdb, which should not be used within the slapd server. I was trying to use the users created with slappasswd2 -c (as written in the Administration guide) but no sasldb file was open by the server (I straced out a full session). I tried to put an explicit configuration in sasl/slapd.conf, and stracing the server I saw it was open and read, but the configuration inside is just ignored. The auxprop_plugin configuration parameter is ignored. Most/all other config statements will be honored. Reading the manpage I found it says that sasl-auxprops "Specify which auxprop plugins to use for authentication lookups." and that the default is use the slapd internal support. But I did not define this one, and sasl/slapd.conf still seems to be ignored. And no possible values for the available plugins to use as sasl-auxprops parameter are listed. If you wish to use the sasldb database, specify the 'sasldb' auxprop plugin (via sasl-auxprops/olcSaslAuxprops), and maintain your authentication database with saslpasswd2. I could get DIGEST-MD5 authentication working putting the password inside the server (userPassword in CLEARTEXT), so it seems that the default is used anyway. But I'd like to have it working using using sasldb or configuring sasl/slapd.conf to use saslauthd. pwcheck_method is honored within sasl/slapd.conf. -- Dan White
Re: I don't want to use GSSAPI !?
On 10/26/15 15:49 +0100, Olivier wrote: supported before redhat6. So my nswitch.conf looks like this : # cat /etc/nsswitch.conf sudoers:ldap passwd: files sss shadow: files sss group: files sss ... The problem is that I have not found which option I should use in ldap.conf to say NOT to use sasl when binding the ldap directory (aka the equivalent of '-x'). There is no such option. Consult the documentation for your pam ldap module. If you're using PADL, consider using nss-pam-ldapd, or nssov (which is distributed with OpenLDAP). -- Dan White
Re: I don't want to use GSSAPI !?
On 10/23/15 23:31 +0200, Olivier wrote: 2015-10-22 20:54 GMT+02:00 Dan White : Without including a '-x' option on the command line, you are directing ldapsearch to perform a SASL authenticated bind. See the ldapsearch manpage. I use SASL in certain circumstances (aka: EXTERNAL), but not GSSAPI and find strange that this particular machine (I mean the client) even tries it. Do you know why ldapsearch tries to authenticate using GSSAPI ? Because your local cyrus sasl library determined it was the best option, because it was not provided with a specific mechanism to use (-Y). In this case, ldapsearch deferred the underlying authentication exchange to libsasl2, which has determined that GSSAPI is the most appropriate SASL mechanism to use, likely because the ldap server is offering it. You can use '-Y' to specify a preferred sasl mechanism, if that is your intention. Is there any way to configure the server not to serve GSSAPI mechanism ? I have not fount any parameter that could deal with that on the server side. Yes. Configure a sasl slapd.conf file, and specify an explicit 'mech_list' which excludes GSSAPI. See: http://www.cyrussasl.org/docs/cyrus-sasl/2.1.25/options.php You can remove the GSSAPI libsasl2 shared library from your system, but that would simply mask the problem. Mmm... Thanks for this idea, but again, this is GSSAPI that I don't want to use, not SASL. Is there any documentation that describes the dialog between the client and the server before they agree an a particular mechanism ? SASL authentication is based on a server-offers - client-chooses model. The server offers all available mechanisms to the client, which then chooses the most appropriate mechanism to use based on which mechanisms it has available. You can explicitly set the mechanism with the '-Y' option, or via a SASL_MECH user-only option (see ldap.conf(5)). See section 5.2 of RFC 4513 for further detail. -- Dan White
Re: I don't want to use GSSAPI !?
On 10/22/15 17:59 +0200, Olivier wrote: Hello everyone, authentication over ldap doesn't work on one of my linux box. Trying to query the ldap server from this machine with ldapsearch, I get this : $ ldapsearch -ZZZ -h ldap1.example:389 -D uid=olivier,dc=example,dc=fr -b dc=example,dc=fr -W Enter LDAP Password: SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Local error (-2) additional info: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (No credentials cache found) Without including a '-x' option on the command line, you are directing ldapsearch to perform a SASL authenticated bind. See the ldapsearch manpage. Do you know why ldapsearch tries to authenticate using GSSAPI ? In this case, ldapsearch deferred the underlying authentication exchange to libsasl2, which has determined that GSSAPI is the most appropriate SASL mechanism to use, likely because the ldap server is offering it. You can use '-Y' to specify a preferred sasl mechanism, if that is your intention. I don'use such a mechanism (nor kerberos) and I don't remember that I configured any such a thing. Any idea to desactivate the attempt to use GSSAPI to authenticate ? You can remove the GSSAPI libsasl2 shared library from your system, but that would simply mask the problem. -- Dan White
Re: configuring ldap-client to use TLS (Certificate not found in database)
On 10/20/15 21:24 -0400, Sridhar Acharya Malkaram wrote: I am a novice to linux administration. Recently I had to configure a system to authenticate using LDAP with TLS. I have read guides from several websites. But I still could configure it. There seem to be several reasons for the failure. I tried many suggestions, but with no success. I don’t have access to the LDAP server. So I have been just playing with config on the client. The LDAP server is sso.abcdef.edu My ldap.conf content is below BASE dc=abcdef,dc=edu TLS_REQCERT allow TLS_CACERT /etc/openldap/cacerts/sso.abcdef.edu.crt uri ldap://sso.abcdef.edu TLS_CACERTDIR /etc/openldap/cacerts You output below says your local ldap libraries are linked against moznss. See: http://www.openldap.org/faq/data/cache/1514.html and the ldap.conf manpage. More comments below. I could issue a ldapsearch -x which returns several entries. However, when I couldn’t do using TLS. The following command shows some errors. Could you suggest me possible directions to resolve this. The directory /etc/openldap/cacerts/ contains the server certificate sso.abcdef.edu.crt. I also made a copy of it with name sso.abcdef.edu.pem. I am not sure whether this pem file should be that of the server or the client. Another question, should the client also have a ca (or self-signed ) certificate and it whether it should be uploaded onto the LDAP server? The depends on the security needs of your network. If the server is configured to require client certificates, then you'll need to specify a TLS_CERT and TLS_KEY (again, see ldap.conf(5)). /etc/openldap/cacerts root@wserver[0.5]5019 > ldapsearch -ZZZ -h sso.abcdef.edu -d -1 ldap_msgfree TLS: loaded CA certificate file /etc/openldap/cacerts/sso.abcdef.edu.crt. TLS: error: the certificate '/etc/openldap/cacerts/sso.abcdef.edu.pem' could not be found in the database - error -12285:Unable to find the certificate or key necessary for authentication.. TLS: certificate '/etc/openldap/cacerts/sso.abcdef.edu.pem' successfully loaded from PEM file. TLS: could not add the private key '/etc/openldap/cacerts/sso.abcdef.edu.pem' - error -8018:Unknown PKCS #11 error.. TLS: error: could not initialize moznss security context - error -8018:Unknown PKCS #11 error. TLS: can't create ssl handle. ldap_err2string ldap_start_tls: Connect error (-11) Does /etc/openldap/cacerts/sso.abcdef.edu.pem exist? If so, moznss will attempt to open it as a database. It should not exist if you wish to use the collective cert files within /etc/openldap/cacerts/ as your cacerts. You should not specify TLS_CACERT in that case either. -- Dan White
Re: ldapsearch and kerberos keytab
On 09/02/15 16:22 +0300, l...@avc.su wrote: Hi all. I've got CentOS 6.5 server enrolled in an AD domain. Does that mean you're using Samba, or something else? There's a script which should connect to AD and get some info with ldapsearch. We were using simple bind with username and password, but I wonder if there is any way to do queries and being authenticated by GSSAPI without the need of password entering? Yes, it should work fine. Maybe, I somehow can use system krb5.keytab and do queries from the name of the server (host/pc@DOMAIN credentials)? You'll need to export a keytab file from Active Directory. See: https://cwiki.apache.org/confluence/display/DIRxINTEROP/Exporting+Keytabs+from+Active+Directory Or I should create separate keytab and specify it in ldapsearch? But I haven't found this option. Moreover, I know that kerberos tickets could expire and I should re-enter pass to obtain new one. ldapsearch will not initialize your credentials cache. You're responsible for kinit to initialize it, such as from your crontab. Using a keytab would obviate the need for sticking a password in your crontab of course. The underlying kerberos libraries will request necessary service tickets as needed. -- Dan White
Re: Change userPassword
On 09/03/15 12:16 -0700, Chuck Theobald wrote: Thanks to all who replied. I did not realize or remember that the output of ldapsearch was base64 encoded for userPassword. Decoding gives me the string I expect, so it is set correctly in the database. Since testsaslauthd works, I just need to get ldap to reference the saslauthd, which is still failing. I recommend running saslauthd in debug mode to trouble shoot. If no connections are established when authenticating against slapd, verify permissions are good to your saslauthd mux, and explicitly set a saslauthd_path within your (sasl) slapd.conf if necessary. See: http://www.openldap.org/doc/admin24/security.html#Pass-Through authentication http://www.cyrussasl.org/docs/cyrus-sasl/2.1.25/options.php -- Dan White
Re: Change userPassword
On 09/03/15 10:54 -0700, Chuck Theobald wrote: I am finding it impossible to set user passwords to the form {SASL}n...@ad.domain.my ldapmodify can delete userPassword, and can add it again but ends of setting it to a hash despite trying password-hash {CLEARTEXT} and password-hash {SASL} in slapd.conf. And no, I am not using slapd.d. By hash, I assume you mean base64 encoding, which is how ldapsearch displays contents of userPassword when retrieved. uudecode the contents to see the actual data. Here's a simple perl script I use: #!/usr/bin/perl use MIME::Base64; print decode_base64($ARGV[0]); print "\n"; If you are actually retrieving a crypt(3) style hash, verify you are not running ldapmodify with an extention (-E) and that you are not doing something strange with an overlay. password-hash should only come into play when performing an ldap password extended operation, such as with ldappasswd. Every post I find taunts me with things like "oh, set the userpassword to {SASL} and it will Just Work". This simple step eludes me. I am seriously missing some thing quit easy. -- Dan White
Re: SASL/EXTERNAL not available
On 09/02/15 08:25 -0500, Dan White wrote: dn: supportedSASLMechanisms: GSSAPI supportedSASLMechanisms: LOGIN supportedSASLMechanisms: CRAM-MD5 supportedSASLMechanisms: DIGEST-MD5 supportedSASLMechanisms: PLAIN If you have a olcSaslAuxprops configured, verify it includes EXTERNAL. That's a mistake. Check your SASL slapd.conf file for mech_list. If it exists, add EXTERNAL to it. olcSaslAuxprops is something totally unrelated. -- Dan White
Re: SASL/EXTERNAL not available
On 08/31/15 19:43 -0400, Frank Crow wrote: If set the TLSClientVerify to "allow" or "try" and attempt to use "-Y EXTERNAL", I get the following message: SASL/EXTERNAL authentication started ldap_sasl_interactive_bind_s: Unknown authentication method (-6) additional info: SASL (-4): no mechaism available: If I do a search on the DSE, I get the following available methods: dn: supportedSASLMechanisms: GSSAPI supportedSASLMechanisms: LOGIN supportedSASLMechanisms: CRAM-MD5 supportedSASLMechanisms: DIGEST-MD5 supportedSASLMechanisms: PLAIN If you have a olcSaslAuxprops configured, verify it includes EXTERNAL. Enable debugging on your client (e.g. -d -1), or enable logging on the server, to verify you're properly authenticating with your client certificate. On 09/02/15 11:04 +0200, Dirk Kastens wrote: Hi Frank, if you want SASL to work, you need to have the cyrus-sasl libraries installed. And slapd has to be compiled with sasl support: # rpm -qa | grep sasl cyrus-sasl-lib-2.1.23-8.el6.x86_64 cyrus-sasl-2.1.23-8.el6.x86_64 cyrus-sasl-plain-2.1.23-8.el6.x86_64 # ldd /usr/sbin/slapd ... libsasl2.so.2 => /usr/lib64/libsasl2.so.2 (0x7f8152dbb000) ... Based on his output, it's clear has those listed mechanisms properly installed. The EXTERNAL mechanism requires no additional shared libraries, other than the libsasl2 glue library. -- Dan White
Re: authz-regexp behavior with GSSAPI
From: Dan White [dwh...@olp.net] Sent: Sunday, August 30, 2015 10:09 AM To: Peter Heinemann Cc: openldap-technical@openldap.org Subject: Re: authz-regexp behavior with GSSAPI On 08/26/15 12:51 +, Peter Heinemann wrote: I am trying to figure out different behaviors with authz-regexp in slapd.conf. Any differences in your /etc/krb5.conf? What is your default realm? Any differences in the libraries you're using (cyrus-sasl and kerberos)? On 08/31/15 13:52 +, Peter Heinemann wrote: Here are version details: openldap 2.4-39 RHEL 6.5 cyrus-sasl and cyrus-sasl-gssapi 2.1.23-15 krb5-libs 1.10.3-42 It appears that cross-realm authentication is problematic. In the following results, "success" means that the search specified by the regex occurred and the identity was remapped. Both commands used GSSAPI (-Y for ldapwhoami, -M for slapauth): so: slapauth appears to work if a realm is explicitly specified with -R (either cross-realm or within realm), but won't remap if the realm isn't specified. ldapwhoami (and ldapsearch) works within a realm whether or not the realm is specified with -R; but won't remap if -R specifies a different realm. There are several possibilities as to why this behavior might occur. You might be able to change sasl-host/sasl-realm to make things work consistently, or change your default realm in krb5.conf. The pragmatic solution would be to create more than one authz-regexp to match each/all cases, so that future Kerberos changes don't break your setup. -- Dan White
Re: LDAP over TLS
On Tue, Jul 14, 2015 at 11:09 PM, Dan White On 07/14/15 23:05 +0500, Aneela Saleem wrote: I found three libraries in mangpages of slapd-config i.e., OpenSSL, GnuTLS, or Mozilla NSS This should give you a hint: ~# ldd `which slapd` On 07/15/15 00:37 +0500, Aneela Saleem wrote: It gives the following output: *libgnutls.so.26 => /usr/lib/x86_64-linux-gnu/libgnutls.so.26 GnuTLS. -- Dan White
Re: LDAP over TLS
Dan White wrote: ldap_start_tls: Protocol error (2) additional info: unsupported extended operation Which ssl library is your slapd compiled against? See the slapd-config manpage for appropriate configuration for your ssl lib. On 07/14/15 23:05 +0500, Aneela Saleem wrote: Hi Dan, I found three libraries in mangpages of slapd-config i.e., OpenSSL, GnuTLS, or Mozilla NSS Correct, as OpenLDAP supports all three of those libraries. Consult your system documentation for which library your binary slapd was linked against. This should give you a hint: ~# ldd `which slapd` -- Dan White
Re: LDAP over TLS
On 07/14/15 03:45 +0500, Aneela Saleem wrote: but when i run the search command: i.e., *ldapsearch -x -b "dc=platalytics,dc=com" -H 'ldap://localhost:389' -ZZ* i get the following error: ldap_start_tls: Protocol error (2) additional info: unsupported extended operation Which ssl library is your slapd compiled against? See the slapd-config manpage for appropriate configuration for your ssl lib. Following is my *cn=config.ldif* file: # AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify. # CRC32 0cd16f20 dn: cn=config objectClass: olcGlobal cn: config *TLSCertificateFile: /etc/ldap/servercrt.pem* *TLSCertificateKeyFile: /etc/ldap/serverkey.pem* *TLSCACertificateFile: /etc/ldap/cacert.pem* Assuming these are correct paths, verify permissions to these files, and check them again. Enable logging/debugging on the server side to trouble shoot. olcArgsFile: /var/run/slapd/slapd.args olcLogLevel: none olcPidFile: /var/run/slapd/slapd.pid olcToolThreads: 1 structuralObjectClass: olcGlobal entryUUID: 59729584-bdf0-1034-90b9-fdf431101d87 creatorsName: cn=config createTimestamp: 20150713211745Z entryCSN: 20150713211745.443612Z#00#000#00 modifiersName: cn=config modifyTimestamp: 20150713211745Z -- Dan White
Re: ldap.conf not being used for TLS_CERT/TLS_KEY
On 07/06/15 08:53 +1000, Deon George wrote: Hi, Looking for feedback on why this is not working, or if it is a bug. The details of my configuration are here: http://serverfault.com/questions/702739 <http://serverfault.com/questions/702739> I discovered (and proved), that ldapsearch is not honouring TLS_CERT/TLS_KEY in /etc/openldap/ldap.conf. I’m running the query as “root” and selinux is disabled. If however, I put the TLS_CERT/TLS_KEY in my ~/ldaprc or ~/.ldaprc, then they are honoured. Is this a bug? What is stopping the “global default” of TLS_CERT/TLS_KEY from being read? Both TLS_CERT and TLS_KEY are user-only options, by design. See the manpage for ldap.conf for details on how to specify the settings within a user configuration file. -- Dan White
Re: proxy to AD does not work during login client machine
From: Dan White On 06/11/15 23:38 +, Leo Xiao wrote: Hi technical, I hit a problem during configure proxy to AD. I can run command: $ldapsearch -x -h localhost -LLL -b dc=mydomain,dc=local -D cn=open,cn=users,dc=mydomain,dc=local -W "(cn=open1)" cn sAMAccountName which return the SAMACCOUNTNAME:open successfully. --- This may mean the proxy works well. But if I run command with out -D -D cn=open,cn=users,dc=mydomain,dc=local. The search will failed. So you are attempting to authenticate anonymously? Or with SASL? On 06/15/15 22:58 +, Leo Xiao wrote: Hi Dan, Thanks a lot for the comments. I want to authenticate anonymously, Not with SASL. Is there any pam configuration needed for this scenario? Could you share some link/doc to me? Thanks so much. When I use openldap user login, just run authconfig-gtk(modified the /etc/openldap/ldap.conf) and set the ldapserver/base DN can lead me login success. The configuration to do anonymous binds is highly dependent on the ldap pam module you are using. See slapo-nssov(5) if you are using the one distributed by the OpenLDAP project. Otherwise, configuration of your ldap pam module is outside the scope of this project. However, assuming your pam ldap module uses (links against) libldap, consult the ldap.conf(5) manpage as well. -- Dan White
Re: proxy to AD does not work during login client machine
On 06/11/15 23:38 +, Leo Xiao wrote: Hi technical, I hit a problem during configure proxy to AD. I can run command: $ldapsearch -x -h localhost -LLL -b dc=mydomain,dc=local -D cn=open,cn=users,dc=mydomain,dc=local -W "(cn=open1)" cn sAMAccountName which return the SAMACCOUNTNAME:open successfully. --- This may mean the proxy works well. But if I run command with out -D -D cn=open,cn=users,dc=mydomain,dc=local. The search will failed. So you are attempting to authenticate anonymously? Or with SASL? when I try to login my client machine with AD user. It always failed. --- I can login with openldapuser successfully. You'll need to trouble shoot your nss/pam config, which ever one you're using. I think I need some configuration to force the -D in slapd.con. Is there any problems with my slapd.conf? Or any trouble shooting comments? Appreciate it very much. Below is my slapd.conf: ### # database definitions ### database ldap suffix "DC=mydomain,DC=local" urildap://dc-ad.mydomain.local/ chase-referrals no rebind-as-user yes idassert-bind bindmethod=simple binddn="CN=open,OU=users,DC=mydomain,DC=local" credentials=open mode=none flags=non-prescriptive idassert-authzFrom "*" Thanks, Leo -- Dan White
Re: nss_ldap: failed to bind to LDAP ser
On 05/31/15 10:12 +0300, Gokan Atmaca wrote: I installed OpenLDAP. "ldapsearch -x" comes with everything. However, I get an error when I try to connect to the client as follows: Ldapcliet: (/var/log/auth.log) 02:49:58 debian8 nscd: nss_ldap: reconnecting to LDAP server (sleeping 1 seconds)... May 31 02:49:59 debian8 nscd: nss_ldap: could not connect to any LDAP server as (null) - Can't contact LDAP server May 31 02:49:59 debian8 nscd: nss_ldap: failed to bind to LDAP server ldapi://ldap01.gokan.local: Can't contact LDAP server ldapi://ldap01.gokan.local is wrong. You probably want ldap://ldap01.gokan.local. Consult ldap.conf(5), and the nss_ldap documentation. # ldapsearch -x # extended LDIF # # LDAPv3 # base (default) with scope subtree # filter: (objectclass=*) # requesting: ALL # Listening to the socket. tcp0 0 0.0.0.0:389 0.0.0.0:* LISTEN 4409/slapd tcp6 0 0 :::389 :::* LISTEN 4409/slapd -- Dan White
Re: Create Mailing List
On 06/01/15 07:16 -0400, Jerry wrote: Is it possible to create a "mailing list" in openldap? My MUA allows me to create an alias like "MyGroup" that would then contain all the email addresses of the people in the group. I can then simply type that alias and it is replaced by the actual email addresses. I am looking for something like that in openldap. I realize that I can associate multiple email addresses to a single name; however, only one address can be chosen at a time. You're looking for Address Book integration within your mailer. See: http://www.openldap.org/faq/data/cache/1005.html or google around for examples. -- Dan White
Re: Openldap password problems
On 05/14/15 21:02 +, jeevan kc wrote: Hello all,We've just noticed that when a user authenticates via LDAP, it ignores characters after the right password. For example a user jkc900 has Password Welcome1 But the user can type in Welcome or Welcome12 etc and still can get into the application. Its just checking the first Welcome1 and they can type anything after that and still can log in. We've tested at least 50 users and they all have the same issues. Any clues/ solution for this? Your inputs are highly appreciated. Can you reproduce this with ldapwhoami? Is there a 3rd party PAM or NSS library involved in your authentication? -- Dan White
Re: Ldap challenge
On 04/22/15 20:08 +, Ross, Daniel B. wrote: Ok I have looked a couple options but I really dont know how to accomplish what I need to do. Here is what I am trying to do. I have a greater organization that is stuck on using Microsoft products namely Microsoft LDS. To make matters worse they present the data to my linux servers in a completely non-standard way. Its driving my solaris and linux box nuts and they simply dont want to work with it. What i need to do is continue to use the campus usernames and passwords but present the Data in a format that my linux/unix hosts can use. Is this possible? i.e. userid would still be samwise but instead of a bizzarre OU=monkeypeople,dc=example,dc=com I want it to present as people,dc=example,dc=com. I looked at referral and aliasing but it does not seem to be doing what I am trying to do. Passthrough authentication looks close but I cant find sufficient documentation to actually configure a system to use it. See slapo-rwm(5). Pass-through is documented in section 14.5 of the Administrator's Guide: http://www.openldap.org/doc/admin24/ Supporting Cyrus SASL documentation: http://www.cyrussasl.org/docs/cyrus-sasl/2.1.25/ And /saslauthd/LDAP_SASLAUTHD within the Cyrus SASL source. You'll find workable pass-through examples for authenticating to Exchange in this list's archives as well as the Cyrus SASL list archives. The 'ldap' and 'kerberos5' saslauthd backends should both be workable solutions. -- Dan White
Re: How to disable SSF (integrity) on GSSAPI mech?
On 04/19/15 17:11 +, Osipov, Michael wrote: On 04/15/15 21:10 +, Osipov, Michael wrote: >Hi folks, > >I am binding against Active Directory with GSSAPI mech and would like to disable SASL integrity for debugging purposes with Wireshark. Unfortunately, this call fails: Setting a minssf should not be necessary. Do you also get this error with "maxssf=0"? "maxssf=1" may be a more workable option, since encryption is really what you want to turn off, not integrity. Yes, the error remains the same. Maxssf=1 does not help because integrity won't be disabled. The encryption you are talking about is GSS confidentiality which won't be active anyway with maxssf=1. I recall being able to capture GSSAPI traffic with wireshark several years ago. I wasn't doing it programatically though. I was either using maxssf=1 or maxssf=0, and was likely using Heimdal. -- Dan White
Re: slapd verifyclient fails on demand
On 04/20/15 20:07 +0200, E.therepa wrote: Dear Tech list, I'd like to use CRL's to regulate client connections to my slapd server. So i've build working certs and keys with gnutls. The whole keysetup is tested and working properly, by invoking gnu-serv and gnu-cli i could succesfully create connections and drop clients in my revocation list. In order to use this in slapd/ldap utils i use this settings, slapd.conf, TLSCACertificateFile /etc/ldap/ssl/ca-cert.pem TLSCertificateFile /etc/ldap/ssl/clients/lrc-ldap.crt TLSCertificateKeyFile /etc/ldap/ssl/clients/lrc-ldap.key TLSCRLFile /etc/ldap/ssl/crl.pem TLSCipherSuite SECURE256:-VERS-SSL3.0 TLSVerifyClient hard ldap.conf # TLS certificates (needed for GnuTLS) TLS_CACERT /etc/ldap/ssl/ca-cert.pem TLS_CERT /etc/ldap/ssl/clients/lrc-ldapsearch.crt This is a user only option. See ldap.conf(5). TLS_KEY /etc/ldap/ssl/clients/lrc-ldapsearch.key TLS_REQCERT hard Slapd debug, 55353d59 slapd starting 55353d5b conn=1000 fd=16 ACCEPT from IP=10.50.2.12:50764 (IP=0.0.0.0:636) TLS: can't accept: No certificate was found.. 55353d5b conn=1000 fd=16 closed (TLS negotiation failure) ldapsearch debug, ldap_start_tls: Can't contact LDAP server (-1) ldap_free_connection 1 1 ldap_send_unbind ber_flush2: 7 bytes to sd 4 : 30 05 02 01 02 42 00 0B. ldap_write: want=7 error=Broken pipe ldap_free_connection: actually freed As far as i can see and found info my client and servers TLS settings are configured properly. What i really don't get is that the client doesnt send his certs to the server. -- Dan White
Re: How to disable SSF (integrity) on GSSAPI mech?
On 04/15/15 21:10 +, Osipov, Michael wrote: Hi folks, I am binding against Active Directory with GSSAPI mech and would like to disable SASL integrity for debugging purposes with Wireshark. Unfortunately, this call fails: char *secprops = "minssf=0,maxssf=0"; rc = ldap_set_option(ld, LDAP_OPT_X_SASL_SECPROPS, secprops); with: Diagnostic message: SASL(-1): generic failure: GSSAPI Error: A required input parameter could not be read (Unknown error) Result code: -2 This error is likely produced by your Kerberos library (whichever one Cyrus is compiled against), or perhaps with the way the security properties are passed down from OpenLDAP to Cyrus to Kerberos. Setting a minssf should not be necessary. Do you also get this error with "maxssf=0"? "maxssf=1" may be a more workable option, since encryption is really what you want to turn off, not integrity. -- Dan White
Re: can't chang ldap user passwd by self
On 04/12/15 22:56 +0800, feora wrote: I found log in ldap.log file Apr 12 14:20:54 abc slapd[3136]: => access_allowed: auth access to "uid=bobliu,ou=it,dc=abc,dc=com" "userPassword" requested Apr 12 14:20:54 abc slapd[3136]: => slap_access_allowed: backend default auth access granted to "(anonymous)" Apr 12 14:20:54 abc slapd[3136]: => access_allowed: auth access granted by read(=rscxd) Apr 12 14:20:54 abc slapd[3136]: => access_allowed: backend default write access denied to "uid=bobliu,ou=it,dc=abc,dc=com" why access granted to anoymous not bobliu. On 04/12/2015 10:05 PM, feora wrote: hi, Dan thanks for u answer. I still a little confused about it. I run the following command /opt/openldap/bin/ldappasswd -x -D "uid=bobliu,ou=it,dc=abc,dc=com" -W -S New password: Re-enter new password: Enter LDAP Password: Result: Insufficient access (50) when I run ldapsearch is ok. userPassword:: Be aware that your ssha password hash is know publicly known. The above would indicate that you *are* successfully authenticating, since the userPassword attribute was returned. That's assuming that your ACL config below is accurate. On 04/02/2015 01:40 AM, Dan White wrote: On 03/31/15 17:47 +0800, rockwang wrote: access to attrs=userPassword by self write by anonymous auth by dn.base="cn=Manager,dc=abc,dc=com" by * none This config block has been through the wringer, but verify user userPassword ACL config. Something's up. Run slaptest on your config to verify and verify it's formatted properly. access to * by self write by dn.base="cn=Manager,dc=abc,dc=com" by * read by * none -- Dan White
Re: can't chang password via simple authentication
On 04/09/15 12:59 +0800, rockwang wrote: hi,guys I can't chang user password via simple authentication at ldap client. I have set acl rule in slapd.conf. access to attr=userPassword by self write by anonymous auth by dn.base="cn=Manager,dc=abc,dc=com" write by * none access to * by self write by dn.base"cn=Manager,dc=abc,dc=com" write by * read ldappasswd -x -D "uid=bobliu,ou=it,dc=abc,dc=com" -W -S New password: Re-enter new password: Enter LDAP Password: ldap_bind: Invalid credentials (49) but can use ldapsearch via simple authentication. what about problem. thks Are you positive that you are successfully authenticating with ldapsearch? Your 'by * read' for 'access to *' would allow anonymous users read access to everything except the userPassword entry. See chapter 8 in the OpenLDAP Admin Guide for a saner example. Use debugging/logging to trouble shoot. See slapd(8), and slapd.conf(5). -- Dan White
Re: can't chang ldap user passwd by self
On 03/31/15 17:47 +0800, rockwang wrote: access to attrs=userPassword by self write by anonymous auth by dn.base="cn=Manager,dc=abc,dc=com" by * none access to * by self write by dn.base="cn=Manager,dc=abc,dc=com" by * read by * none my question is user can't change his own password. I use following command so I have different result. when not add -x Consult the manpage for ldappasswd. In the first case (simple bind) you did not provide a binddn (-D). In the second case, you directed ldappasswd to perform a SASL bind but did not correctly provide an authentication identity, and the sasl mechanism negotiated could not derive one. Hint: if using a simple bind, specify a full DN (with -D), and not a uid. -- Dan White
Re: still can't run ldapadd command after install openldap
On 03/27/15 20:45 +, Wang, Hui wrote: [root@oldaptest01 bin]# pwd /opt/bin [root@oldaptest01 bin]# ls -l total 2268 lrwxrwxrwx 1 root root 10 Mar 25 10:34 ldapadd -> ldapmodify -rwxr-xr-x 1 root root 264824 Mar 25 10:34 ldapcompare -rwxr-xr-x 1 root root 265432 Mar 25 10:34 ldapdelete -rwxr-xr-x 1 root root 265624 Mar 25 10:34 ldapexop -rwxr-xr-x 1 root root 277336 Mar 25 10:34 ldapmodify -rwxr-xr-x 1 root root 265016 Mar 25 10:34 ldapmodrdn -rwxr-xr-x 1 root root 264216 Mar 25 10:34 ldappasswd -rwxr-xr-x 1 root root 287864 Mar 25 10:34 ldapsearch -rwxr-xr-x 1 root root 155256 Mar 25 10:34 ldapurl -rwxr-xr-x 1 root root 262648 Mar 25 10:34 ldapwhoami [root@oldaptest01 bin]# [root@oldaptest01 bin]# ldapadd -x -D "cn=Directory Manager,o=csun" -W -f example.ldif -bash: ldapadd: command not found [root@oldaptest01 bin]# You've installed your ldap binaries in a location which is not in your path. Try adding /opt/bin to your path. -- Dan White
Re: OpenLDAP permissions question
On 03/19/15 23:05 +0200, Igor Shmukler wrote: Hello Dan, I must have done something wrong, yet this thing did not work either. One: the delete still failed with the usual error, and second - I got an error concerning my olcs: 550b380f /etc/ldap/slapd.d: line 1: rootdn is always granted unlimited privileges. 550b380f olcRootPW: value #0: can only be set when rootdn is under suffix You don't need to set olcRootPW in this case. See slapd-config(5). -- Dan White
Re: OpenLDAP permissions question
On 03/19/15 22:33 +0200, Igor Shmukler wrote: Hello Dieter, $ sudo ldapwhoami -Y EXTERNAL -H ldapi:/// SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 dn:gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth I have been trying to delete a record using LDAPI as well as -D cn=config with a password. I have also added commands olcAccess to both dn: olcDatabase={0}config,cn=config as well as dn: olcDatabase={1}hdb,cn=config [DIT] databases. The result is always the same: ldap_delete: Insufficient access (50) additional info: no write access to parent If your goal is to manage your server using EXTERNAL over ldapi:///, configuring a olcAuthzRegexp is a far simpler approach. Map 'gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth' to your rootdn identity and you'll bypass acl restrictions altogether. -- Dan White
Re: external authentication source
On 03/12/15 20:24 +0100, Dieter Klünter wrote: Am Thu, 12 Mar 2015 14:00:02 +0100 schrieb Hallvard Breien Furuseth : What you describe sounds to me more like stuff like Kerberos tickets. These are passed inside a SASL mechanism (GSSAPI), after SASL on the server side is configured to check them against a Kerberos server. It is a more bit complicated than Krb5 and GSSAPI. I'm in a erlang/OTP environment which provides an authorization server, called sasl server. I have no clue yet, what this sasl server provides. But there is a requirement that slapd accepts the authorization string, which should be mapped to a DN. Mapping seems to be not a problem. Doesn't sound like EXTERNAL is appropriate here. Cyrus SASL has designed its EXTERNAL support around the idea of the server having a priori knowledge of who the user is, outside of the SASL exchange. You can't "tell" slapd who the user is, or at least without modifying slapd code. With EXTERNAL, you would not submit an authentication identity, only an authz identity, *if* you wished to be authorized as another user. Consider implementing a new SASL mechanism, or modifying the existing OTP code. If software is advertising itself as a "sasl server", then perhaps they've already implemented this. -- Dan White
Re: Error while instaling slapd
On 03/04/15 11:33 -0300, Verónica Ovando wrote: I need some help for solving this problem when I try to install slapd package on Debian from testing repositories. |Leyendo lista de paquetes... Hecho Creando árbol de dependencias Leyendo la información de estado... Hecho Se instalarán los siguientes paquetes NUEVOS: slapd 0 actualizados, 1 se instalarán, 0 para eliminar y 2 no actualizados. Necesito descargar 1.344 kB de archivos. Se utilizarán 4.091 kB de espacio de disco adicional después de esta operación. Des:1 http://debian.linuxmint.com/latest/ testing/main slapd amd64 2.4.31-1+nmu2+b1 [1.344 kB] Descargados 1.344 kB en 50seg. (26,4 kB/s) Preconfigurando paquetes ... Seleccionando el paquete slapd previamente no seleccionado. (Leyendo la base de datos ... 260763 ficheros o directorios instalados actualmente.) Desempaquetando slapd (de .../slapd_2.4.31-1+nmu2+b1_amd64.deb) ... Procesando disparadores para man-db ... Configurando slapd (2.4.31-1+nmu2+b1) ... Omitting slapd configuration as requested. insserv: warning: script 'K01subversion' missing LSB tags and overrides insserv: warning: script 'subversion' missing LSB tags and overrides [warn] No configuration file was found for slapd at /etc/ldap/slapd.conf. ... (warning). invoke-rc.d: initscript slapd, action "start" failed. dpkg: error al procesar slapd (--configure): el subproceso instalado el script post-installation devolvió el código de salida de error 1 Se encontraron errores al procesar: slapd E: Sub-process /usr/bin/dpkg returned an error code (1) | I do not understand why is trying to find the slapd.conf file, because this versión of slapd(2.4.31) uses cn=config. Verónica, I suggest filing a debian bug, or contacting: pkg-openldap-de...@lists.alioth.debian.org. The 'Omitting slapd configuration as requested.' leads me to believe you've answered some debconf question in a way which is breaking installation, or using a debconf frontend that is not interactive. Try dpkg --purge slapd, and reinstalling. -- Dan White
Re: main: TLS init def ctx failed: -1
Date: Thu, 26 Feb 2015 15:04:40 -0600 From: dwh...@cafedemocracy.org To: jeev_...@hotmail.com CC: openldap-technical@openldap.org Subject: Re: main: TLS init def ctx failed: -1 On 02/26/15 20:53 +, jeevan kc wrote: >§ olcTLSCACertificateFile: >/usr/local/etc/openldap/cacert.pem >§ olcTLSCertificateFile: >/usr/local/etc/openldap/servercrt.pem >§ olcTLSCertificateKeyFile: >/usr/local/etc/openldap/serverkey.pem >Feb 26 15:28:56 lap00551 slapd[14775]: main: TLS init def ctx failed: -1 >Can Someone please tell me what the error is and how I fix the issue? Which version of OpenLDAP, and which SSL library have you compiled against? Verify permissions to the 3 files above, for the user that slapd is running On 02/26/15 21:30 +, jeevan kc wrote: Hi Dan,OpenLDAP version 2.4.30OpenSSL version1.0.0dAre these two compatible? Also I've verified the permissions. Your reply is appreciated . Thanks Try increasing your debug log level, or starting slapd in debug mode for additional details. Use 'openssl verify' (manpage verify(1)) to verify your cert. Running the command *as* your slapd user could also verify permissions. -- Dan White
Re: main: TLS init def ctx failed: -1
On 02/26/15 20:53 +, jeevan kc wrote: Hi all,I followed the TLS directives and was able to generate cacert, servercert and server key and also sign it. I also did the configuration o to /usr/local/etc/openldap/slapd.d/cn=config.ldif: § olcTLSCACertificateFile: /usr/local/etc/openldap/cacert.pem § olcTLSCertificateFile: /usr/local/etc/openldap/servercrt.pem § olcTLSCertificateKeyFile: /usr/local/etc/openldap/serverkey.pem Everything was working fine but when I shut down slapd, it doesn't start and gives me this error daemon: IPv6 socket() failed errno=97 (Address family not supported by protocol) Feb 26 15:28:56 lap00551 slapd[14775]: main: TLS init def ctx failed: -1 Can Someone please tell me what the error is and how I fix the issue? Which version of OpenLDAP, and which SSL library have you compiled against? Verify permissions to the 3 files above, for the user that slapd is running as. Verify your configuration matches the configuration options necessary to support your SSL library. See slapd-config(5), and the TLS OPTIONS section. -- Dan White
Re: create new user with same UID and GID
On 02/19/15 11:54 -0300, Fabián M Sales wrote: I am creating users in LDAP and I assign different UID and GUI. For example. What utility or process are you using to create these entries? uid = _16661_ (user1) gid = _16664_ (user1) groups = _16664_ (user1) I need that when the user is created is created with the same UID and GID for user created. as I do this? I would love for it to be so: uid = _16664_ (user1) gid = _16664_ (user1) groups = _16664_ (user1) The values entered for uid/gid into your ldap directory are up to you (and the tools you use). If you wish to limit or restrict the values that can be used, see slapo-constraint(5) and slapo-unique(5). -- Dan White
Re: Search with wildcard
On 01/28/15 18:19 +, Alessandro Lasmar Mourao wrote: I have the following structure in my OpenLDAP: ou = groups |_cn = system1 | | _cn = Group1 | | _cn = Group2 |_cn = system2 | _cn = Group1 | _cn = Group2 I need to perform a search and return only users who are registered on system1, regardless of the registered group. When I use the search with the filter: memberOf=cn=*,cn=system1,ou=groups nothing is returned. How do I perform this search in OpenLDAP? In search Oracle SJDS works! Please provide a more concrete example of your DIT layout. -- Dan White
Re: Creating LDAP schema issue
On 01/22/15 22:32 +0100, Leander Schäfer wrote: a user. So in the end I want to add a(nother) mail account by something like this: cat << EOF > ./newUser.ldif dn: mailAddress=t...@domain.tld,ou=mail,uid=User-1,ou=people,dc=MyDomain,dc=TLD objectclass: top objectclass: mailAccount mailAddress: t...@domain.tld MailPassword: {SSHA}SomePassword MailAccountStatus: active [...] EOF You have an errant newline between objectclass and mailAddress. You should have received an error if you processed this file with ldapadd. Your blank line should come at the end of your input file, or between distinct dn entries. Therefore I setup a LDAP schema like the following, but it seems to ignore the attributes "MailPassword" and "noMailAccountStatus". Why? I don't understand what I'm missing here on my objectclass? I'm sure it is an easy little thing to fix - but I just can't figure it out with the tutarials provided I went thorugh ;/ I assume your mean 'MailAccountStatus' here. If so, the above typo would explain your situation. objectclass ( objectClassAccount:2.1 NAME 'mailAccount' SUP ( top ) STRUCTURAL DESC 'Mail account' MUST ( mailAddress ) MAY ( MailPassword $ MailAccountStatus ) ) -- Dan White
Re: 回复: 回复: slapcat command
On 01/12/15 20:41 +0800, Eileen(=^ω^=) wrote: [root@tmsr-ldap0 ldap]# ldapadd -x -D "cn=manager,dc=xxx,dc=xxx" -W -f test.ldif See the manpage for slapadd(8), which is appropriate for restoring your DB. ldapadd is something else. If you want to store data in portable ldif format appropriate for use with ldapadd, use ldapsearch. -- Dan White
Re: GSSAPI vs GSS-SPNEGO
On 12/30/14 11:09 -0500, Brendan Kearney wrote: /run: drwxr-xr-x 2 rootroot 100 Dec 30 10:26 saslauthd /var/run: lrwxrwxrwx. 1 root root 6 Dec 10 21:46 /var/run -> ../run so the ldap user would have read and execute permissions. should i change anything? No. i do have a user for dhcpd setup in that way (dn: uid=dhcpd,dc=bpk2,dc=com and userPassword: {SASL}dh...@bpk2.com). the kerberos object does exist as well. What testsaslauthd command are you running? Are you currently using the '-r' option when starting saslauthd? Try running saslauthd in debug mode and compare output. If you're not seeing any output when authenticating against slapd, verify your configured saslauthd_path in slapd.conf. It should include the '/mux' in the path, e.g. '/var/run/saslauthd/mux'. -- Dan White
Re: GSSAPI vs GSS-SPNEGO
On 12/30/14 10:32 -0500, Brendan Kearney wrote: On Mon, 2014-12-29 at 10:49 -0600, Dan White wrote: http://www.openldap.org/doc/admin24/security.html#Pass-Through%20authentication Add 'pwcheck_method: saslauthd' to your libsasl slapd.conf file, and should need nothing else unless you're using a non standard location for your saslauthd mux. Verify that your slapd user has permissions to access the saslauthd mux, and verify your saslauthd config with testsaslauthd. i had the pwcheck_method directive in there, along with the path to one of two saslauthd mux's. /var/run/saslauthd/mux and /run/saslauthd/mux, which both show up as "srwxrwxrwx" and are owned by root:root. testing Typically for the saslauthd mux, it's the parents' directory permissions that restrict access. using testsaslauthd works with my id, but i am not sure how to have authentication work when the other process is binding with "cn=user,dc=domain,dc=tld" and not a username. dn: cn=user,dc=domain,dc=tld userPassword: {SASL}username@realm -- Dan White
Re: GSSAPI vs GSS-SPNEGO
On 12/28/14 11:24 -0500, Brendan Kearney wrote: On Sun, 2014-12-28 at 02:50 +, Howard Chu wrote: Brendan Kearney wrote: > i want to use the "pass-through" auth mechanism with sasl, so that i > validate credentials against the kerberos database, and not have to > maintain passwords in multiple places. ok, then i have misunderstood PLAIN vs SIMPLE, it seems. i will back up and explain what i am trying to do. apache, dhcp and freeradius can all use ldap for various functionality. they all use what i now believe to be SIMPLE auth, where they are using "cn=user,dc=domain,dc=tld" as ldap usernames. these processes are using ldap for authentication, whereas i have only kerberos authentication setup in my environment (and ldap authorization). my hope was that sasl could allow me to push the ldap authN request through to kerberos, and in essence proxy the authentication. This is a valid use of pass-through in my opinion, but you'll want to protect the authentication as Howard mentioned over ldapi:/// ideally, or tls otherwise. pass-through does not require that you advertise any other sasl mechanisms, such as plain, since it does not involve sasl over the wire. To use, see: http://www.openldap.org/doc/admin24/security.html#Pass-Through%20authentication Add 'pwcheck_method: saslauthd' to your libsasl slapd.conf file, and should need nothing else unless you're using a non standard location for your saslauthd mux. Verify that your slapd user has permissions to access the saslauthd mux, and verify your saslauthd config with testsaslauthd. -- Dan White
Re: GSSAPI vs GSS-SPNEGO
On 12/26/14 12:10 -0500, Brendan Kearney wrote: i am in the process of updating all of my systems to fedora 20 from fedora 16, and am using all the latest available builds for openldap, cyrus-sasl and mit kerberos. i have put everything together as i had on fedora 16, and i am finding that the sasl instance is using sasl/gss-spnego, and not sasl/gssapi like it did on the older version. i am not sure if i should be concerned about this, but it feels like i should be. i am not able to find anything that allow me to configure things one way or another, so i can force the use of gssapi from configs, it seems. can anyone point me in a direction about this, tell me if i should be concerned, or if you might have come across this before what i should be doing that i am not? To limit the use of specific sasl mechanisms, configure a libsasl slapd.conf file which contains a 'mech_list' option explicitly listing the mechanisms (space separated) you wish to offer. Consult the fedora documentation for both slapd and libsasl2 for the location to place the slapd.conf file in. To obtain a list of advertised mechanisms, do: ldapsearch -LLL -x -H ldap://ldap.example.org -s "base" -b "" supportedSASLMechanisms You should also force your clients to use gssapi explicitly if that's your preferred mechanism. The OpenLDAP client utilities offer a '-Y' option for to do that. -- Dan White
Re: -DLDAP_CONNECTIONLESS
On 12/10/14 09:59 +0100, Michael Ströder wrote: => dropped -DLDAP_CONNECTIONLESS BTW: Experience shows that the code of rarely needed or unused features most times get not much attention. Thus it's also a security measure not to add it. Good point. This feature sounds ripe for amplification attacks. -- Dan White
Re: SASL hashing schemes
On 12/08/14 13:59 -0600, Dan White wrote: On 12/08/14 20:41 +0100, Dieter Klünter wrote: Hi, RFC 5802 describe a Salted Challenge Response Authentication Mechanism and RFC 5803 describes a schema for storing salted challenge response mechanism secrets, which recommend a authPassword attribute type and a salted hash and a hashing scheme as attribute value. It seems, that OpenLDAP doesn't know authPassword ldapmodify -Y EXTERNAL -H ldapi:/// SASL/EXTERNAL authentication started SASL username: gidNumber=100+uidNumber=1000,cn=peercred,cn=external,cn=auth SASL SSF: 0 dn: cn=dieter kluenter,ou=partner,o=avci,c=de changetype: modify add: authPassword authPassword: xxx modifying entry "cn=dieter kluenter,ou=partner,o=avci,c=de" ldap_modify: Undefined attribute type (17) additional info: authPassword: attribute type undefined Although the SASL Mechanism is provided and known, but the attribute userPassword maintains a plaintext value. ldapwhoami -Y SCRAM-SHA-1 -U dieter -w -H ldapi:/// SASL/SCRAM-SHA-1 authentication started SASL username: dieter SASL SSF: 0 dn:cn=dieter kluenter,ou=partner,o=avci,c=de It seems that SASl authentication only supports scram Mechanisms as plaintext value. Is there any intention to fully implement RFC 5802 and RFC 5803? You could adapt this: https://github.com/bindle/canned-openldap/blob/master/schema-custom/cmusasl.schema Also, it's cyrus sasl that is likely deciding which attribute to use. You'll need to check it's source to verify if it supports authPassword. -- Dan White
Re: SASL hashing schemes
On 12/08/14 20:41 +0100, Dieter Klünter wrote: Hi, RFC 5802 describe a Salted Challenge Response Authentication Mechanism and RFC 5803 describes a schema for storing salted challenge response mechanism secrets, which recommend a authPassword attribute type and a salted hash and a hashing scheme as attribute value. It seems, that OpenLDAP doesn't know authPassword ldapmodify -Y EXTERNAL -H ldapi:/// SASL/EXTERNAL authentication started SASL username: gidNumber=100+uidNumber=1000,cn=peercred,cn=external,cn=auth SASL SSF: 0 dn: cn=dieter kluenter,ou=partner,o=avci,c=de changetype: modify add: authPassword authPassword: xxx modifying entry "cn=dieter kluenter,ou=partner,o=avci,c=de" ldap_modify: Undefined attribute type (17) additional info: authPassword: attribute type undefined Although the SASL Mechanism is provided and known, but the attribute userPassword maintains a plaintext value. ldapwhoami -Y SCRAM-SHA-1 -U dieter -w -H ldapi:/// SASL/SCRAM-SHA-1 authentication started SASL username: dieter SASL SSF: 0 dn:cn=dieter kluenter,ou=partner,o=avci,c=de It seems that SASl authentication only supports scram Mechanisms as plaintext value. Is there any intention to fully implement RFC 5802 and RFC 5803? You could adapt this: https://github.com/bindle/canned-openldap/blob/master/schema-custom/cmusasl.schema -- Dan White
Re: Add attribute to already defined objectclass organizationalUnit in core.schema
On 11/24/14 14:11 +, Shashi Ranjan wrote: I need to add two elements to organizationalUnit Object Class. How can I do it without modifying the core.schema file? Is there a way to define two new attributes in my private schema file (local.schema) and then extend the object class organizationalUnit defined in core.schema? I do not want to modify the file core.schema. I wish to deliver only my local schema file (local.schema) with other changes also. A better option is to create a new non-structural objectClass and *add* it to your existing entries using organizationalUnit. Extending/replacing organizationalUnit is an option, but would make maintenance for future admins a bit more confusing. -- Dan White
Re: OpenLDAP Proxy for Active Directory Authentication (slapd.d)
On 11/11/14 09:50 +, Šmucr Jan wrote: User wants to authenticate --> Client (Gerrit 2.9.1) connects to the local OpenLDAP server --> The OpenLDAP server searches its local database for a relevant entry * Entry found --> Inform the client * Entry not found --> Delegate the request to the remote Active directory server o Entry found --> Inform the OpenLDAP server --> Inform the client o Entry not found --> Inform the OpenLDAP server --> Inform the client [1] http://ltb-project.org/wiki/documentation/general/sasl_delegation To work with pass-through authentication, all users will need a valid entry within your OpenLDAP tree. Those you wish to authenticate against active directory will need a userPassword attribute of: userPassword: {SASL}user@domain And those you wish to authenticate locally should have a standard hashed password string. All authentication (or at least pass-through authentication) will need to use simple binds (-x command line option). If that requirement does not meet your needs, use ldap SASL binds instead of pass-through authentication, which do not require your authenticated users to exist within the local tree. To trouble shoot pass-through authentication, run saslauthd in debug mode (-d), and use testsaslauthd to validate your saslauthd.conf configuration prior to troubleshooting your slapd config. Verify your slapd process has permissions to communicate with the saslauthd mux, which is a common mistake. For project documentation, see: http://www.openldap.org/doc/admin24/security.html#Pass-Through authentication http://www.openldap.org/doc/admin24/sasl.html saslauthd(8) testsaslauthd(8) 'saslauthd/LDAP_SASLAUTHD' in the cyrus sasl source code -- Dan White
Re: OpenLDAP w/ SSL cert signed by Network Solutions
On 10/20/14 11:12 -0700, Jeff Lebo wrote: Running openldap-2.4.31 on Ubuntu 14.04.1 LTS compiled with gnutls. I created a local key and CSR using certtool: server.csr server.key I was then issued the following from Network Solutions: AddTrustExternalCARoot.crt hostname.domain.com.crt NetworkSolutions_CA.crt UTNAddTrustServer_CA.crt I added the following to slapd.conf: TLSCertificateFile /etc/ldap/certs/hostname.domain.com.crt TLSCertificateKeyFile /etc/ldap/certs/server.key TLSCACertificateFile /etc/ldap/certs/NetworkSolutions_CA.crt ...and I now get the following error when I try to start slapd: Oct 20 10:49:58 hostname slapd[3476]: main: TLS init def ctx failed: -1 Can someone point me in the right direction as to what I am missing here? Google for "TLS init def ctx failed: -1". A common cause of this error is a permissions problem. -- Dan White
Re: OpenLDAP, SASL and TLS
On 10/06/14 13:24 -0500, Dan White wrote: There is a known bug in Cyrus SASL which triggers this problem: https://bugzilla.cyrusimap.org/show_bug.cgi?id=3480 If adding "-O maxssf=0" to your ldapsearch command, when using both Kerberos and TLS, works then that's likely the culprit. Apparently I can't read my own bug reports. This may or may not be your issue. -- Dan White
Re: OpenLDAP, SASL and TLS
On 10/06/14 13:27 -0400, Kristof Takacs wrote: I am having issues when I have Kerberos bind and TLS turned on. On 10/06/14 14:03 -0400, Kristof Takacs wrote: I use the following version: - OpenLDAP (2.4.35), but I have tried 2.4.39 as well - Cyrus SASL (2.1.26) - OpenSSL (1.0.1h) - Heimdal ( I beleive 1.5.2) There is a known bug in Cyrus SASL which triggers this problem: https://bugzilla.cyrusimap.org/show_bug.cgi?id=3480 If adding "-O maxssf=0" to your ldapsearch command, when using both Kerberos and TLS, works then that's likely the culprit. -- Dan White
Re: Syncrepl authentication via GSSAPI/SASL/Kerberos
On 09/30/14 13:14 -0400, Steven Presser wrote: I'm running a pair of OpenLDAP servers on a network which primarily uses kerberos for authentication. The two servers replicate data (via a simple syncrepl master-slave setup). Right now, they're using simple authentication. I'd like to move them to using kerberos authentication. Sep 30 13:11:09 hawking slapd[1620]: conn=1005 op=2 BIND dn="uid=ldap/mordor.pressers.name,cn=gssapi,cn=auth" mech=GSSAPI sasl_ssf=56 ssf=56 On 09/30/14 13:30 -0400, Steven Presser wrote: No; That bind DN is used only in simple authentication. I am maintaining them as separate accounts, for the time being. One of my ACLs is: access to * by dn.exact="cn=repl,dc=pressers,dc=name" read by dn.exact="uid=ldap/mordor.pressers.name, cn=pressers.name,cn=gssapi,cn=auth" read Your line here does not match the identity from your logs. -- Dan White
Re: troubles while setting-up ldap server + pam
On 09/24/14 14:30 +0200, Ivaylo Ganchev wrote: Hello, I am installing openldap in my cathedra and am running into a strange problem. - When I use libnss_ldapd and libpam_ldapd, the communication is OK, but it seems that the client is not asking for the userPassword agrument and so, there is no way to login (it only asks for "loginShell cn gidNumber uidNumber objectClass homeDirectory gecos uid" and then in another request "shadowExpire shadowInactive shadowFlag shadowWarning shadowLastChange uid shadowMin shadowMax" See: http://arthurdejong.org/nss-pam-ldapd/setup and its troubleshooting steps, namely, getent passwd, getent shadow, and debug mode. In default configuration, you will not directly expose the userPassword attribute to the client - a successful bind will authenticate the client's credentials. -- Dan White
Re: LDAP authentication using email address
On 07/28/14 15:31 +0530, Gokul nath wrote: Hi, I have configured openldap and it is working for username and password authentication. How do i make my email address as login id in LDAP? my working scenario is below. User : user1, user2Group: Group1, Group2 I have added user1 to Group1 and done apache authentication using Group1. Login is working if i add any user to that group. i would like to make email address as login id. Please suggest how to configure the same. ThanksGokul Specify the fully qualified username within the RDN (e.g. uid=jsm...@example.com). You may, however, need to patch your ldap nss library to support the @ sign. Consult the documentation for the library you're using. -- Dan White
Re: multiple DIT
On 07/23/14 10:10 -0400, andres palomo wrote: ubuntu 12.04 openLdap 2.4.28-1 I have created a DIT dc=com i need to create 2 additional dit for dc=net and dc=org I have been all over the web and it is not vlear how to create the additional DIT with the cn=config.ldif any help will be greatly appreciated please request additional info if required to solve Create two new suffixes (olcSuffix) similar to your existing olcSuffix for dc=com. See slapd-config(5), and use 'slapcat -n0' to view your config. If you have slapd.conf examples to work with, slaptest can be used to a generate a temporary config prior to applying (specify a temporary directory for the -F option). -- Dan White
Re: capture password
On 07/04/14 09:57 -0300, Rogério Augusto Rondini wrote: I need to implement password sync between AD and OpenLDAP using an IDM tool. I want to know how to capture clear text password in OpenLDAP before encryption so that I can sync with AD and potentially with others user repositories. You can capture cleartext passwords using the libsasl 'auto_transition' option, although that requires a specific usage scenario. You'd need to be authenticating against slapd using SASL LOGIN or PLAIN (or perhaps sasl pass-through) with a saslauthd daemon authenticating against AD. Like this in your sasl slapd.conf config: pwcheck_method: saslauthd mech_list: plain login auto_transition: yes Your saslauthd daemon would need to use the ldap or kerberos backends to authenticate against AD. The clear text password should get stored into userPassword by way of the slapd auxprop plugin. -- Dan White
Re: slapd dead. pls advise how I can restart it
On 06/24/14 10:10 -0400, Mauricio Tavares wrote: On Tue, Jun 24, 2014 at 9:47 AM, Dan White wrote: On 06/24/14 16:19 +0800, Eileen(=^ω^=) wrote: bdb(dc=npl,dc=tmsr): unable to join the environment bdb_db_open: database "dc=npl,dc=tmsr" cannot be opened, err 11. Restore from backup! bdb(dc=npl,dc=tmsr): txn_checkpoint interface requires an environment configured for the transaction subsystem bdb_db_close: database "dc=npl,dc=tmsr": txn_checkpoint failed: Invalid argument (22). backend_startup_one (type=bdb, suffix="dc=npl,dc=tmsr"): bi_db_open failed! (11) bdb_db_close: database "dc=npl,dc=tmsr": alock_close failed slapd stopped. I'm not familiar with the specific error messages you're getting. There are error codes in your output produced by BerkeleyDB. Consult the documentation for that project for how to proceed in the safest manner. Have you performed any upgrades? Do you have any permissions problems on your directory location? Check the location corresponding to your configured directory/olcDbDirectory. I does sound like the database is corrupted somehow. slapcat needs slapd to be running, right? slapcat does not need slapd to be running, but will probably hit similar errors. -- Dan White
Re: slapd dead. pls advise how I can restart it
On 06/24/14 16:19 +0800, Eileen(=^ω^=) wrote: When I start slapd, below will be come. [root@nplserver1 openldap]# slapd start -d 256 @(#) $OpenLDAP: slapd 2.4.23 (Feb 22 2013 01:50:21) $ mockbu...@c6b7.bsys.dev.centos.org:/builddir/build/BUILD/openldap-2.4.23/openldap-2.4.23/build-servers/servers/slapd bdb(dc=npl,dc=tmsr): unable to join the environment bdb_db_open: database "dc=npl,dc=tmsr" cannot be opened, err 11. Restore from backup! bdb(dc=npl,dc=tmsr): txn_checkpoint interface requires an environment configured for the transaction subsystem bdb_db_close: database "dc=npl,dc=tmsr": txn_checkpoint failed: Invalid argument (22). backend_startup_one (type=bdb, suffix="dc=npl,dc=tmsr"): bi_db_open failed! (11) bdb_db_close: database "dc=npl,dc=tmsr": alock_close failed slapd stopped. I'm not familiar with the specific error messages you're getting. There are error codes in your output produced by BerkeleyDB. Consult the documentation for that project for how to proceed in the safest manner. Have you performed any upgrades? Do you have any permissions problems on your directory location? Check the location corresponding to your configured directory/olcDbDirectory. -- Dan White
Re: AD pass through to Openladp?
On 06/06/14 14:54 -0400, Justin Stanczak wrote: Is there a method of connecting Active Directory to use OpenLDAP as the authentication source. So pass through to OpenLDAP. Making OpenLDAP the primary system with all the passwords and usernames. I realize this might be more of a AD question, but the places I've looked seem to always make AD the primary. Then everyone else must proxy to AD. Thanks. What is your usage scenario? Are you supporting user logins to Windows systems? If so, see Samba. -- Dan White
Re: regarding logging when running in the foreground
On 05/16/14 12:12 +0300, Mike Jackson wrote: Hi, Is there a way to prevent slapd from using syslog when running in the foreground? I run slapd permanently under the runit process supervision package with -d 256, and it already captures stderr to it's own logging system. However, I also get the same log messages cluttering up my syslog with local4.debug lines. Running in the foreground is pretty much a requirement for using process supervision and almost every service related software supports it for this reason. The background logging, despite running in the foreground, is undesired behavior. You could direct your syslog daemon to ignore those messages. Look for lines which include: *.debug local4.debug local4.* -- Dan White
Re: Help with SASL generic GSSAPI error
On 05/13/14 07:32 -0400, Brendan Kearney wrote: On Tue, 2014-05-13 at 08:26 +0200, Dieter Klünter wrote: Am Mon, 12 May 2014 20:52:14 -0600 schrieb Joshua Schaeffer : > root@mytest:~# ldapsearch -Y GSSAPI > SASL/GSSAPI authentication started > ldap_sasl_interactive_bind_s: Other (e.g., implementation specific) > error (80) > additional info: SASL(-1): generic failure: GSSAPI Error: > Unspecified GSS failure. Minor code may provide more information () Check your syslog - auth facility, and check your kdc logs. a couple of things that may need attention. you need to map the kerberos-established identities to ldap user objects. adjust the below to match your environment (these need to be in cn=config): olcSaslRealm: BPK2.COM This may be necessary. olcAuthzRegexp: {0}uid=([^,]*),cn=bpk2.com,cn=gssapi,cn=auth uid= $1,ou=Users,dc=bpk2,dc=com olcAuthzRegexp: {1}uid=([^,]*),cn=gssapi,cn=auth uid= $1,ou=Users,dc=bpk2,dc=com This is not necessary, for GSSAPI authentication. That is, the error message above is a SASL error message. olcAuthzRegexp would be needed to map the user after authentication has been completed. you might also need to tell sasl to use the kerberos auth mechanism, and where to find the ldap servers. again, adjust to your environment (saslauthd.conf): ldap_servers: ldap://ldap1.bpk2.com/ ldap://ldap2.bpk2.com ldap_use_sasl: yes ldap_mech: kerberos5 ldap_auth_method: fastbind keytab: /etc/ldap.keytab This is also not necessary, as GSSAPI authentication does not depend on or use saslauthd. It would be needed if performing pass-through or PLAIN/LOGIN authentication. -- Dan White
Re: common name
On 05/12/14 09:30 -0400, Jignesh wrote: I have confusion on on common name. In Open ldap it is a combination of first name and last name and other side it is unique. So it is forces us to use something else then combination of first name and last name. That's incorrect. The value can be anything that meets the syntax constraints (see RFC 2256), and it "is typically the person's full name." If you choose to use CN within the entry's DN, then you may well run into conflicts with other entries. Consider using a uid, with a unique value, instead. Now tools like php openldap, apache directory shows the LDPA user in left navigation by common name. So if we map common name to something else then we will have problem to view the list in these tools. Make liberal use of search filters within client tools, such as apache directory studio, to find particular entries (such as by common name). Of course, if you actually have two people with the same name, then you'll need to find your own method of distinguishing between them. Is it possible to change the setting for above tools so that they can reflect based on first name and last name instead of common name? You also have other attributes to store partial, or whole, names into, such as gecos and surname. Or you can create your custom attributes via schema definition. -- Dan White
Re: Multiple userPasswords entries & resetting one value
On 05/01/14 21:36 -0400, Michael wrote: I have a user with a SSHA userPassword value as well as a SASL userPassword entry. The SASL entry will never change but I'd like to be able to reset and age the SSHA entry only. Is this aging of only one value possible with ppolicy and is it possible to handle manual resets with ldappasswd and/or utilizing an LDIF file? By SASL userPassword entry, do you mean a cleartext value, or a {SASL}u...@domain.com pass-through entry? I'll assume cleartext. Try setting olcPasswordHash to {SSHA} only. slapd may (or may not) leave the cleartext userPassword entry alone. I haven't used that case. A more straight forward approach would be to store your sasl authentication material in another sasl auxprop plugin (sasldb or sql) and set olcSaslAuxprops appropriately. -- Dan White
Re: Duplicate dynamically an OU with another RDN ?
On 04/29/14 14:57 +0200, Sylvain wrote: Hi ! I have a branch "ou=people" where RDN are in the form "X1234" and NEVER change for one people. Ex. : uid=X1234,ou=people,dc=example,dc=org In this node, I have the login under "eduPersonPrincipalName" attribute which MAY change. Some applications doesn't allow us to define which login to use and so take "uid" attribute by default, not so cool. Is there any possibility in OpenLDAP to duplicate dynamically an OU with another RDN to have for example : uid=sylvain,ou=peoplebis,dc=example,dc=org ? The rwm overlay should handle this. Point your broken applications to a unique suffix (e.g. dc=example,dc=org,dc=brokenapps), which overwrites the incoming DN to use eduPersonPrincipalName instead of uid. See slapo-rwm(5). -- Dan White
Re: Getting the list of members in an AD group
On 04/07/14 11:06 +0530, Sankar P wrote: Hi, I have the SID of an AD group. I want to get the list of members who belong to that group. All the documentation page that I search for points me to the reverse only (i.e., getting all the groups membership information of a user). Can someone show me to the relevant way to get the users who belong to a group whose SID I have ? ldapsearch -Y DIGEST-MD5 -U joe -H ldap://192.0.2.1 \ -b "dc=example,dc=com" -s "sub" "objectSid=XXX" dn -- Dan White
Re: What is the replacement for /etc/ldap.conf?
On 03/29/14 10:32 -0500, Peng Yu wrote: http://ubuntuforums.org/showthread.php?t=1421998 The above link mentioned the following code. But /etc/ldap.conf is not available on ubuntu 13.10. Does anybody know what I should do instead? Thanks. Consult the manpage for ldap.conf. It should list the correct location, for your system, under the FILES section. -- Dan White
Re: Why "ldapadd -x -D cn=admin, cn=config -W -f ~/sudoWork/cn\=sudo.ldif" does not work?
On 03/29/14 09:41 -0500, Peng Yu wrote: On Sat, Mar 29, 2014 at 8:32 AM, Dan White wrote: On 03/28/14 22:21 -0500, Peng Yu wrote: I get the following error. pengy@openldapserver:~$ ldapadd -x -D cn=admin,cn=config -W -f ~/sudoWork/cn\=sudo.ldif Enter LDAP Password: ldap_bind: Invalid credentials (49) This means that either 'cn=admin,cn=config' does not match your oldRootDN, or (/and) the password you are providing does not match your oldRootPW. You may get an idea of which is the case by viewing your config with: slapcat -n0 I assume that this should be run on the server not the client. Here is what I get. But I have no idea what to look at. Would you please help me understand how it can be used for debugging my case. Read the fine manual: See the slapd-config(5) manpage, and http://www.openldap.org/doc/admin24/slapdconf2.html pengy@openldapserver:~$ sudo slapcat -n0 dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcDatabase: {0}config olcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external ,cn=auth manage by * break structuralObjectClass: olcDatabaseConfig entryUUID: a3343a42-465f-1033-9540-f5ee9a20f09d creatorsName: cn=config createTimestamp: 2014034706Z entryCSN: 2014034706.118986Z#00#000#00 modifiersName: cn=config modifyTimestamp: 2014034706Z You have no olcRootDN listed for your configuration database, which, as I understand it, means you have no capability to modify your config using ldapadd. For a solution, see: http://www.openldap.org/lists/openldap-technical/201211/msg00195.html You'll need to add olcRootDN and olcRootPW to the above entry, such as the ones you have listed below for your dc=yulab,dc=tamu suffix, assuming that you know what your original password is: dn: olcDatabase={1}hdb,cn=config objectClass: olcDatabaseConfig objectClass: olcHdbConfig olcDatabase: {1}hdb olcDbDirectory: /var/lib/ldap olcSuffix: dc=yulab,dc=tamu olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by anonymou s auth by dn="cn=admin,dc=yulab,dc=tamu" write by * none olcAccess: {1}to dn.base="" by * read olcAccess: {2}to * by self write by dn="cn=admin,dc=yulab,dc=tamu" write by * read olcLastMod: TRUE olcRootDN: cn=admin,dc=yulab,dc=tamu olcRootPW:: e1NTSEF9QWk1Z280ZEo1Zy9UYTJEVEpBdWNLRkxoekh1c1kyN1A= -- Dan White