openldap-technical December 2014

openldap-technical@openldap.org

44 participants
55 discussions

Obtaining the hashed password using ldapsearch, from aWwindows 2012 server.
by Mark London 02 Dec '14

02 Dec '14

Hi =- We upgraded the OS of our Active Directory server to Windows 2012. On a linux computer running Redhat 5, we use a script to obtain an account's hashed password, using the ldapsearch command. We request the msSFU30Password attribute. The script works fine for any account that was created before the new server was installed. For new accounts, no password is returned. Does anyone know how to make this possible again? One suggestion by someone, was to install the "Services for Unix <https://en.wikipedia.org/wiki/Windows_Services_for_UNIX>" package, which is now deprecated (I can't find what replaces it!). I installed it, but it didn't seem to help. Any other suggestions? Thanks. Mark London MIT PSFC

4 5

Have problem searching against ldap server after asyn sasl bind
by Qian Li 02 Dec '14

02 Dec '14

Hi All, Recently, I tried to write a ldap client to do ldap search asynchronously, but failed to perform search operation after a successful async sasl (digest-md5) bind. I’ve tried some code, but only succeeded in searching in synchronized sasl bind. I compared the captured sync and async packets: In sync bind, the search packets were encrypted. In async bind, after sasl (digest-md5) binding to ldap server asynchronously (by calling ldap_sasl_interactive_bind() twice), ldap_search_ext() was called. But the search packet was in plain text. Then the ldap server reset the connection or just didn’t response (in the case of MSAD). Did I use the ldap API incorrectly? Or async sasl bind doesn’t support search operation? Any suggestion will be appreciated and sorry for my poor English.

3 9

Debian style cn=config
by Christian Kratzer 01 Dec '14

01 Dec '14

Hi, while looking what debian generates in their cn=config for Debian Jessie I found following acl on the frontend database: dn: olcDatabase={-1}frontend,cn=config objectClass: olcDatabaseConfig objectClass: olcFrontendConfig olcDatabase: {-1}frontend olcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage by * break olcAccess: {1}to dn.exact="" by * read olcAccess: {2}to dn.base="cn=Subschema" by * read olcSizeLimit: 500 I somehow fail to grasp the relevance of granting manage access to the frontend database. Is it just me or is this is acl just mindless pasting. Apart from that debian jessie is now on openldap 2.4.40 thoug still built agains gnutls. Greetings Christian -- Christian Kratzer CK Software GmbH Email: ck(a)cksoft.de Wildberger Weg 24/2 Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart Mobile: +49 171 1947 843 Geschaeftsfuehrer: Christian Kratzer Web: http://www.cksoft.de/

2 1

need serious help on replication over ssl - getting do_syncrep1: rid 001 ldap_sasl_bind_s failed (-1)
by wailok tam 01 Dec '14

01 Dec '14

Hi, I would really be grateful if a nice guy would appear and save me with this one. Simple bind replication over ldaps port does not work. I don't have a clue. There are very few guides on setting up replication over ldaps on the web or on prints. I am following this one as I am using RH: Technical blurb about Oracle Engineered Systems: Configuring OpenLDAP for High Availability. (Master/Slave or Provider/Consumer configuration) [Part 3 of 4] Some of the suspicious bit are: 1. Concatenating the master CA cert and the original slave CA cert to make a new CA cert for use with the slave. But the server cert and key in the slave was signed with the original slave CA without the concatenation.2. the following line:tls_cert= in the slave replication directive seems to be suggesting the location of the master server certificate in the guide but there is no clear mention. I put the location of the master server certificate in this line. A billion thanks in advance. First the master slapd.conf: include /etc/openldap/schema/core.schemainclude /etc/openldap/schema/cosine.schemainclude /etc/openldap/schema/inetorgperson.schemainclude /etc/openldap/schema/nis.schemainclude /etc/openldap/schema/samba.schema # Allow LDAPv2 client connections. This is NOT the default.allow bind_v2 pidfile /var/run/openldap/slapd.pidargsfile /var/run/openldap/slapd.args ######################################################################## ldbm and/or bdb database definitions####################################################################### database bdbsuffix "dc=ier,dc=hit-u,dc=ac,dc=jp"rootdn "cn=root,dc=ier,dc=hit-u,dc=ac,dc=jp"rootpw sameforalldirectory /var/lib/ldap TLSCACertificateFile /usr/share/ssl/certs/nii-odca2.crtTLSCertificateFile /usr/share/ssl/certs/mail.ier.hit-u.ac.jp.crtTLSCertificateKeyFile /usr/share/ssl/certs/mail.ier.hit-u.ac.jp.key overlay syncprovsyncprov-checkpoint 50 10syncprov-sessionlog 100 # Indices to maintain for this databaseindex objectClass eq,presindex ou,cn,mail,surname,givenname eq,pres,subindex uidNumber,gidNumber,loginShell eq,presindex uid,memberUid eq,pres,subindex nisMapName,nisMapEntry eq,pres,subindex entryCSN,entryUUID eq idlcachesize 1000 access to attrs=userPassword by self write by dn="cn=root,dc=ier,dc=hit-u,dc=ac,dc=jp" write by dn="cn=dovecot,dc=ier,dc=hit-u,dc=ac,dc=jp" read by dn.exact="cn=replicator,ou=Users,dc=ier,dc=hit-u,dc=ac,dc=jp" read by anonymous auth by * none access to attrs=SambaLMPassword,SambaNTPassword by dn="cn=root,dc=ier,dc=hit-u,dc=ac,dc=jp" write by dn="cn=dovecot,dc=ier,dc=hit-u,dc=ac,dc=jp" read by dn.exact="cn=replicator,ou=Users,dc=ier,dc=hit-u,dc=ac,dc=jp" read by self read by anonymous auth by * none access to * by self write by dn="cn=root,dc=ier,dc=hit-u,dc=ac,dc=jp" write by dn.exact="cn=replicator,ou=Users,dc=ier,dc=hit-u,dc=ac,dc=jp" read by * read loglevel stats args trace sync ************************************************************************************************************************Next, the slapd.conf of the slave: ### configuration for IER### writeen by T.Tanaka include /etc/openldap/schema/core.schemainclude /etc/openldap/schema/cosine.schemainclude /etc/openldap/schema/inetorgperson.schemainclude /etc/openldap/schema/nis.schemainclude /etc/openldap/schema/samba.schema # Allow LDAPv2 client connections. This is NOT the default.allow bind_v2 # Do not enable referrals until AFTER you have a working directory# service AND an understanding of referrals.#referral ldap://root.openldap.org pidfile /var/run/openldap/slapd.pidargsfile /var/run/openldap/slapd.args ######################################################################## ldbm and/or bdb database definitions####################################################################### database bdbsuffix "dc=ier,dc=hit-u,dc=ac,dc=jp"rootdn "cn=root,dc=ier,dc=hit-u,dc=ac,dc=jp"rootpw sameforalldirectory /var/lib/ldap TLSCACertificateFile /etc/pki/CA/cacert.pemTLSCertificateFile /etc/pki/tls/misc/newcert.pemTLSCertificateKeyFile /etc/pki/tls/misc/clearkey.pem # Replicas of this database # Indices to maintain for this databaseindex objectClass eq,presindex ou,cn,mail,surname,givenname eq,pres,subindex uidNumber,gidNumber,loginShell eq,presindex uid,memberUid eq,pres,subindex nisMapName,nisMapEntry eq,pres,subindex entryCSN,entryUUID eq idlcachesize 1000 access to attrs=userPassword by dn="cn=replicator,ou=Users,dc=ier,dc=hit-u,dc=ac,dc=jp" write by self write by anonymous auth by * none access to * by dn="cn=replicator,ou=Users,dc=ier,dc=hit-u,dc=ac,dc=jp" write by self write by * read loglevel stats args trace sync syncrepl rid=001 provider=ldaps://mail.ier.hit-u.ac.jp:636 type=refreshOnly interval=00:00:05:00 bindmethod=simple searchbase="dc=ier,dc=hit-u,dc=ac,dc=jp" binddn="uid=root,dc=ier,dc=hit-u,dc=ac,dc=jp" credentials=sameforall tls_cert=/usr/share/ssl/certs/mail.ier.hit-u.ac.jp.crt mirrormode onupdateref ldaps://mail.ier.hit-u.ac.jp **************************************************************************************************************************

2 3

Re: OpenLDAP incroyable!
by Quanah Gibson-Mount 01 Dec '14

01 Dec '14

--On Wednesday, November 26, 2014 12:13 PM +0100 Onno van der Straaten <onno.van.der.straaten(a)gmail.com> wrote: > > And....another one. Amazing. So hard to understand the OpenLDAP > interface. Might just as well have been in Chinese. > > > > $ ldapmodify -h zimbra.server.com -p 389 -D "cn=config" -f > olc_password_hash.ldif -W > ldap_initialize( ldap://zimbra.onknows.com:389 ) > Enter LDAP Password: > replace olcPasswordHash: > {SSHA} > modifying entry "olcDatabase={-1}frontend,cn=config" > modify complete > > > So the "modify complete" sort of suggestive of some kind of success > completion or change applied. One would think. No. > > > The olcPasswordHash was "modified complete" to have exact same value as > before. Sort of expected OpenLDAP to be "unwilling to perform", which > often it is. Not now. It just is "willing to ignore". Almost human. Your list of complaints so far: a) You told OpenLDAP to load a file that didn't exist b) You modified a file, by hand, where the first comment in the file is: # AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify. c) In doing (b), you failed to preserve proper file permissions d) You failed to use the correct tools for doing what you wanted to do, after you broke the configuration (slapcat/slapadd) I'm not really sure what to make of your above complaint. It seems you are saying you think it is an error for ldap to replace a value with itself? All LDAP servers will do that with a replace operation. I.e., there is significant user error present here, and you got yourself into a bad spot, and made it worse via your own actions. A lack of understanding how to use a piece of software does not indicate the software itself is flawed. I will agree that it takes some time to learn how to work with LDAP in general, regardless of it is OpenLDAP, 389, Apache DS, etc. It may indeed be best in your case, to have a graphical UI hiding the grisly details from you, since those details are apparently causing significant challenge in your case. However, in the long run, it pays off significantly to understand the technology you're attempting to use. --Quanah -- Quanah Gibson-Mount Server Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

8 9

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical December 2014