Re: migrating from (old) /etc/shadow to LDAP
Hi Gerardo,
the 'short strings' You mentioned are 13-character DES password hashes.
For security reasons they should not be used anymore if possible.
Putting {crypt} in front of them should be sufficient for conversion.
Normalizing the passwords might become difficult if only their DES hashes are
available.
Especially in a heterogenous environment using simple authentication together
with
ssl/tls will prevent some trouble.
In that case OpenLDAP will take care of the crypto algorithm, creation of
password hashes and so on while clients just send plaintext passwords
over an encrypted ssl/tls connection to the LDAP server.
This will also prevent trouble if there is no common algorithm supported by
all OS flavors and releases in Your environment which use LDAP for
authentication.
Regards
Juergen
Re: migrating from (old) /etc/shadow to LDAP
juergen.spren...@swisscom.com wrote:
Hi Gerardo,
the 'short strings' You mentioned are 13-character DES password hashes.
For security reasons they should not be used anymore if possible.
It's always interesting to see how things have progressed. ~15 years ago a
desktop processor could perform 130,000 crypts/second, and could crack a
typical 8 character password in ~251 days.
http://personal.stevens.edu/~khockenb/crypt3.html
Skip ahead to 2010 and a single-core desktop processor can do 10 million
crypts/second - so your crack time is now down to ~2.5 days for a single
password, even less for multi-core. Of course, you can crack an entire
password file all in parallel, since you only need to perform a simple
comparison of the crypt result with each password.
http://openwall.info/wiki/john/benchmarks
So if all else fails, you can most likely generate the original plaintext for
the majority of these old passwords in not much time. Of course, having done
that, you probably won't want any of your users to continue using them...
Putting {crypt} in front of them should be sufficient for conversion.
Normalizing the passwords might become difficult if only their DES hashes are
available.
Especially in a heterogenous environment using simple authentication together
with
ssl/tls will prevent some trouble.
In that case OpenLDAP will take care of the crypto algorithm, creation of
password hashes and so on while clients just send plaintext passwords
over an encrypted ssl/tls connection to the LDAP server.
This will also prevent trouble if there is no common algorithm supported by
all OS flavors and releases in Your environment which use LDAP for
authentication.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: migrating from (old) /etc/shadow to LDAP
On 22/09/2011 16:10, Christopher Wood wrote: Debian/Ubuntu: install nslcd, libnss-ldapd, libpam-ldapd, configure your /etc/nslcd.conf, and ensure you have compat ldap as lookups listed in /etc/nsswitch.conf for passwd, group, shadow. (I figure on the whole nss-pam-ldapd arrangement for CentOS6 too, but I haven't gotten that far yet.) This, at least for Debian Stable and Ubuntu LTS has an important shortcoming, it does not update shadowLastChange on password change. So if you set a password expiration they will stay expired forever. It can be made working with a patched smbk5pwd overlay in the openldap server, but that's not present in Debian or Ubuntu. Simone -- Simone Piccardi Truelite Srl picca...@truelite.it (email/jabber) Via Monferrato, 6 Tel. +39-347-103243350142 Firenze http://www.truelite.it Tel. +39-055-7879597Fax. +39-055-736
Re: migrating from (old) /etc/shadow to LDAP
Simone Piccardi wrote: On 22/09/2011 16:10, Christopher Wood wrote: Debian/Ubuntu: install nslcd, libnss-ldapd, libpam-ldapd, configure your /etc/nslcd.conf, and ensure you have compat ldap as lookups listed in /etc/nsswitch.conf for passwd, group, shadow. (I figure on the whole nss-pam-ldapd arrangement for CentOS6 too, but I haven't gotten that far yet.) This, at least for Debian Stable and Ubuntu LTS has an important shortcoming, it does not update shadowLastChange on password change. So if you set a password expiration they will stay expired forever. Not a major shortcoming. If you're actually using LDAP then you should set expiration using ppolicy and not using shadow attributes at all. It can be made working with a patched smbk5pwd overlay in the openldap server, but that's not present in Debian or Ubuntu. Simone -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: migrating from (old) /etc/shadow to LDAP
On 23/09/2011 13:20, Howard Chu wrote: Not a major shortcoming. If you're actually using LDAP then you should set expiration using ppolicy and not using shadow attributes at all. Did this solve problems with current nslcd, libnss-ldapd, libpam-ldapd packages on Debian Stable and Ubuntu LTS? I was not aware of this. Anyway I have more than 80 server in schools, with hundred of students registered in each one. When they where created 6 years ago ppolicy was not an option. I prefer to install a patched slapd-smbk5passwd package on each server and have a consistent managament of the actual information than reworking the data in each database and make changes in about 2500 client configurations. Ppolicy could be the future, but I have to deal with the present and the past. Simone -- Simone Piccardi Truelite Srl picca...@truelite.it (email/jabber) Via Monferrato, 6 Tel. +39-347-103243350142 Firenze http://www.truelite.it Tel. +39-055-7879597Fax. +39-055-736
Re: migrating from (old) /etc/shadow to LDAP
On Fri, Sep 23, 2011 at 12:19:17PM +0200, Simone Piccardi wrote: On 22/09/2011 16:10, Christopher Wood wrote: Debian/Ubuntu: install nslcd, libnss-ldapd, libpam-ldapd, configure your /etc/nslcd.conf, and ensure you have compat ldap as lookups listed in /etc/nsswitch.conf for passwd, group, shadow. (I figure on the whole nss-pam-ldapd arrangement for CentOS6 too, but I haven't gotten that far yet.) This, at least for Debian Stable and Ubuntu LTS has an important shortcoming, it does not update shadowLastChange on password change. So if you set a password expiration they will stay expired forever. This depends where passwords are maintained. Certainly in your case it sounds like the authoritative password copy is maintained in the directory. It can be made working with a patched smbk5pwd overlay in the openldap server, but that's not present in Debian or Ubuntu. Simone -- Simone Piccardi Truelite Srl picca...@truelite.it (email/jabber) Via Monferrato, 6 Tel. +39-347-103243350142 Firenze http://www.truelite.it Tel. +39-055-7879597Fax. +39-055-736
Re: migrating from (old) /etc/shadow to LDAP
On 23/09/2011 14:42, Christopher Wood wrote: On Fri, Sep 23, 2011 at 12:19:17PM +0200, Simone Piccardi wrote: On 22/09/2011 16:10, Christopher Wood wrote: Debian/Ubuntu: install nslcd, libnss-ldapd, libpam-ldapd, configure your /etc/nslcd.conf, and ensure you have compat ldap as lookups listed in /etc/nsswitch.conf for passwd, group, shadow. (I figure on the whole nss-pam-ldapd arrangement for CentOS6 too, but I haven't gotten that far yet.) This, at least for Debian Stable and Ubuntu LTS has an important shortcoming, it does not update shadowLastChange on password change. So if you set a password expiration they will stay expired forever. This depends where passwords are maintained. Certainly in your case it sounds like the authoritative password copy is maintained in the directory. The problem I'm talking is not about password, they are just in userPassword. Problem arise form the lack of managament of shadowLastChange in the current version of nslcd, libnss-ldapd, libpam-ldapd, for both Squeeze and Lucid. It should work if you use the old libpam-ldap. Simone -- Simone Piccardi Truelite Srl picca...@truelite.it (email/jabber) Via Monferrato, 6 Tel. +39-347-103243350142 Firenze http://www.truelite.it Tel. +39-055-7879597Fax. +39-055-736
schema question
To the ldap forum: I have loaded suse 12.1 m5. I have setup an openldap server, which was the main mission of this machine, and it works. It has ssl /tls, certificates are loaded, that works. I used ldap client to setup the ldap browser and that works also. This is the new 2.4.26 server, which has some rather major changes in how ldap is setup. After about 2 weeks I have that under control. My little domain is setup on dark.net [dc=dark,dc=net]. I used ldapadd to put in the administrator, and I have used ldapsearch to list the subschema. I took the default schema. The list of the subschema includes everything I would like to use. Now I want to go about the real business of defining users. I have reviewed a number of pages to ensure I am doing what appears to be the correct procedure, for instance : http://www.yolinux.com/TUTORIALS/LinuxTutorialLDAP-BindPW.html Which lists: File: fratbrother.ldif dn: cn=fratbrother,o=delta cn: fratbrother sn: fratbrother objectclass: top objectclass: person userPassword: fratsecret ldapadd -f fratbrother.ldif -cxv -D cn=DeanWormer,o=delta -w secret2 And other similar updates. But on my machine I create something simple like: File : dark.ldif dn: cn=jctobin,dc=dark,dc=net cn: jctobin userPassword: Hello1$ Ldapadd -x -D “cn=admin,dc=dark,dc=net” -W -f dark.ldif Enter LDAP Password: Adding new entry “cn=jctobin,dc=dark,dc=net” Ldap_add: Object class violation (65) Additional info: no objectClass attribute Obviously my ldap server does not like the “userPassword” class. I have not been able to use any of the other classes I would like to either [ou: (organizational Unit), uid (unix term for a number corresponding to the user id), etc.] What have I not setup correctly? I need to get these users up and running. tob
JLDAP Search
I'm using the example code from the Novell site to perform a Java JLDAP search by uid of my directory. http://developer.novell.com/documentation/samplecode/jldap_sample/index.htm the one called search.java My program does this: the main java class prompts the user over and over (it's in a while(true) loop) for search parameters, then executes this search.java method. I'm using this (above) code as is except for the Systems.exit(0). The first time it runs it returns the correct result...but every run after that it returns 0 results. I have to restart my Java program to get it to return the correct result again. There's no public variables in the way...I'm not sure what could be the issue. I've looked through the LDAPConnection.java and nothing looks looks like anything that would corrupt, clear a cache, or queue, or do anything more than what the disconnect (should) does. Anyone run into this?...or have any ideas? Thanks! Kevin
multi master no syncing.
Hi, I've setup a multimaster cluster composed of two machine (in my example 192.168.0.204 and 192.168.0.197). Everything is working ok and both side are replicating ok. However, I've a problem I'd like to submit to your sagacity. When I put down a server, and modify the other server (delete or add), when the first server comes back, the modifications are not pushed in the old server. Server 1 says Entry cn=seb,ou=orgunit,o=org,dc=example,dc=com changed by peer, ignored Adding new entries works ok and synchronisation happens but for the nodes altered while one of the servers was down, the modifications are lost (or more precisely ignored by the other). My questions: Is this normal behaviour (Maybe I got the configuration wrong) ? How may I force the missing entries to be replicated to the other ? (Only solution I found is to wipe the entire database on the down server that force a replication from its peer). sincerely, Seb Here an extract of the slapd.log from server 1: Sep 22 10:12:32 dhcp204 slapd[2689]: do_syncrep2: rid=002 (-1) Can't contact LDAP server Sep 22 10:12:32 dhcp204 slapd[2689]: do_syncrepl: rid=002 rc -1 retrying (4 retries left) Sep 22 10:12:32 dhcp204 slapd[2689]: do_syncrep2: rid=004 (-1) Can't contact LDAP server Sep 22 10:12:32 dhcp204 slapd[2689]: do_syncrepl: rid=004 rc -1 retrying (4 retries left) Sep 22 10:12:32 dhcp204 slapd[2689]: conn=1002 op=2 UNBIND Sep 22 10:12:32 dhcp204 slapd[2689]: conn=1002 fd=19 closed Sep 22 10:12:32 dhcp204 slapd[2689]: conn=1003 op=2 UNBIND Sep 22 10:12:32 dhcp204 slapd[2689]: conn=1003 fd=20 closed Sep 22 10:12:37 dhcp204 slapd[2689]: slap_client_connect: URI=ldap://192.168.0.197 DN=cn=config ldap_sasl_bind_s failed (-1) Sep 22 10:12:37 dhcp204 slapd[2689]: do_syncrepl: rid=002 rc -1 retrying (3 retries left) Sep 22 10:12:37 dhcp204 slapd[2689]: slap_client_connect: URI=ldap://192.168.0.197 DN=cn=manager,dc=example,dc=com ldap_sasl_bind_s failed (-1) Sep 22 10:12:37 dhcp204 slapd[2689]: do_syncrepl: rid=004 rc -1 retrying (3 retries left) Sep 22 10:12:42 dhcp204 slapd[2689]: slap_client_connect: URI=ldap://192.168.0.197 DN=cn=manager,dc=example,dc=com ldap_sasl_bind_s failed (-1) Sep 22 10:12:42 dhcp204 slapd[2689]: do_syncrepl: rid=004 rc -1 retrying (2 retries left) Sep 22 10:12:42 dhcp204 slapd[2689]: slap_client_connect: URI=ldap://192.168.0.197 DN=cn=config ldap_sasl_bind_s failed (-1) Sep 22 10:12:42 dhcp204 slapd[2689]: do_syncrepl: rid=002 rc -1 retrying (2 retries left) Sep 22 10:12:47 dhcp204 slapd[2689]: slap_client_connect: URI=ldap://192.168.0.197 DN=cn=manager,dc=example,dc=com ldap_sasl_bind_s failed (-1) Sep 22 10:12:47 dhcp204 slapd[2689]: do_syncrepl: rid=004 rc -1 retrying (1 retries left) Sep 22 10:12:47 dhcp204 slapd[2689]: slap_client_connect: URI=ldap://192.168.0.197 DN=cn=config ldap_sasl_bind_s failed (-1) Sep 22 10:12:47 dhcp204 slapd[2689]: do_syncrepl: rid=002 rc -1 retrying (1 retries left) Sep 22 10:12:52 dhcp204 slapd[2689]: slap_client_connect: URI=ldap://192.168.0.197 DN=cn=config ldap_sasl_bind_s failed (-1) Sep 22 10:12:52 dhcp204 slapd[2689]: do_syncrepl: rid=002 rc -1 retrying Sep 22 10:12:52 dhcp204 slapd[2689]: slap_client_connect: URI=ldap://192.168.0.197 DN=cn=manager,dc=example,dc=com ldap_sasl_bind_s failed (-1) Sep 22 10:12:52 dhcp204 slapd[2689]: do_syncrepl: rid=004 rc -1 retrying Sep 22 10:12:57 dhcp204 slapd[2689]: slap_client_connect: URI=ldap://192.168.0.197 DN=cn=config ldap_sasl_bind_s failed (-1) Sep 22 10:12:57 dhcp204 slapd[2689]: do_syncrepl: rid=002 rc -1 retrying (4 retries left) Sep 22 10:12:57 dhcp204 slapd[2689]: slap_client_connect: URI=ldap://192.168.0.197 DN=cn=manager,dc=example,dc=com ldap_sasl_bind_s failed (-1) Sep 22 10:12:57 dhcp204 slapd[2689]: do_syncrepl: rid=004 rc -1 retrying (4 retries left) Sep 22 10:13:02 dhcp204 slapd[2689]: conn=1007 fd=13 ACCEPT from IP=192.168.0.197:55471 (IP=0.0.0.0:389) Sep 22 10:13:02 dhcp204 slapd[2689]: conn=1007 op=0 BIND dn=cn=manager,dc=example,dc=com method=128 Sep 22 10:13:02 dhcp204 slapd[2689]: conn=1007 op=0 BIND dn=cn=manager,dc=example,dc=com mech=SIMPLE ssf=0 Sep 22 10:13:02 dhcp204 slapd[2689]: conn=1007 op=0 RESULT tag=97 err=0 text= Sep 22 10:13:02 dhcp204 slapd[2689]: conn=1008 fd=15 ACCEPT from IP=192.168.0.197:55473 (IP=0.0.0.0:389) Sep 22 10:13:02 dhcp204 slapd[2689]: conn=1008 op=0 BIND dn=cn=config method=128 Sep 22 10:13:02 dhcp204 slapd[2689]: conn=1008 op=0 BIND dn=cn=config mech=SIMPLE ssf=0 Sep 22 10:13:02 dhcp204 slapd[2689]: conn=1008 op=0 RESULT tag=97 err=0 text= Sep 22 10:13:02 dhcp204 slapd[2689]: conn=1008 op=1 SRCH base=cn=config scope=2 deref=0 filter=(objectClass=*) Sep 22 10:13:02 dhcp204 slapd[2689]: conn=1008 op=1 SRCH attr=* + Sep 22 10:13:02 dhcp204 slapd[2689]: conn=1008 op=1 INTERM oid=1.3.6.1.4.1.4203.1.9.1.4 Sep 22 10:13:02 dhcp204 slapd[2689]: conn=1007 op=1 SRCH base=dc=example,dc=com scope=2 deref=0 filter=(objectClass=*) Sep 22
rwm + cn=config
Hello,
I use the rwm overlay to forward the authentication of some users to the
general ldap replicas of my corp.
Part of slapd.conf :
###
...
overlay rwm
rwm-rewriteEngine on
rwm-rewriteContext bindDN
rwm-rewriteMap ldap mysearch ldap://
ldap.example.com:389/ou=users,dc=example,dc=com?dn?sub
rwm-rewriteRule ^uid=([^,]+),ou=people,dc=[^,]+,dc=example,dc=com$
${mysearch(((objectClass=posixAccount)(uid=$1)))} :@I
databaseldap
suffix ou=users,dc=example,dc=com
uri ldap://ldap.example.com:389/;
restrictread write extended
databasebdb
suffix dc=example,dc=com
rootdn cn=admin,dc=example,dc=com
rootpw mypassword
directory /var/db/openldap-data/mydb
...
Now I converted the 'slapd.conf' to 'cn=config' with slaptest, the remote
authentication stopped working;
and looking at cn=config, all the rules are there...
Any Ideas ?
Rafael NAVAZA.
OpenLDAP with MySQL backend not working
Hi all, I am using OpenLDAP with MySQL backend for testing purpose, a future project of linux authentication via LDAP but with MySQL backend. For this I am using 2 virtual machines with the following configurations: Centos 5.6 x86_64 Iptables is off Memory: 1 GB of RAM Packages installed on server: openldap.x86_64 , openldap-servers-sql.x86_64 , openldap-servers.x86_64 , openldap-clients.x86_64 (all are version 2.3.43) , openldap24-libs.x86_64 (version 2.4.23) , mysql-connector-odbc.x86_64 (version 3.51.26r1127 ) Packages installed on client: openldap-clients.x86_64 (version 2.3.43) On the server I have created a user ldap, group ldap and granted him FULL access on ldap_test database After that I imported from /usr/share/doc/openldap-servers-sql-2.3.43/rdbms_depend/mysql/ the files: backsql_create.sql , testdb_create.sql , testdb_data.sql , testdb_metadata.sql into the database ldap_test When I try to ldap search from the CLIENT computer with ldapsearch -x it should show me all the contents in the database tried also with ldapsearch -x -D cn=admin,dc=example,dc=com -W still no result In a manual check the data is in the MySQL database, in all tables Can someone provide me some info/ideeas on how to configure it to work? Thank you in advance. Below are all my config files and the output from slapd /etc/odbc.ini ; ; odbc.ini configuration for Connector/ODBC and Connector/ODBC 3.51 drivers ; [ODBC Data Sources] mysql = MySQL 3.51 [mysql] driver = mysql server = localhost port = 3306 database = ldap_test user = ldap password = ldappass socket = /var/lib/mysql/mysql.sock [default] driver = MySQL server = localhost port = 3306 database = ldap_test user = ldap password = ldappass socket = /var/lib/mysql/mysql.sock ## /etc/odbcinst.ini ## mysql] driver = /usr/lib64/libmyodbc3.so usagecount = 1 /etc/openldap/slapd.conf # # See slapd.conf(5) for details on configuration options. # This file should NOT be world readable. # include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/nis.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 # Level of LOG loglevel-1 pidfile /var/run/openldap/slapd.pid argsfile/var/run/openldap/slapd.args # Load dynamic backend modules: #modulepath /usr/lib64/openldap/ # Modules available in openldap-servers-overlays RPM package # Module syncprov.la is now statically linked with slapd and there # is no need to load it here # moduleload accesslog.la # moduleload auditlog.la # moduleload denyop.la # moduleload dyngroup.la # moduleload dynlist.la # moduleload lastmod.la # moduleload pcache.la # moduleload ppolicy.la # moduleload refint.la # moduleload retcode.la # moduleload rwm.la # moduleload smbk5pwd.la # moduleload translucent.la # moduleload unique.la # moduleload valsort.la # modules available in openldap-servers-sql RPM package: moduleload /usr/lib64/openldap/back_sql.la # The next three lines allow use of TLS for encrypting connections using a # dummy test certificate which you can generate by changing to # /etc/pki/tls/certs, running make slapd.pem, and fixing permissions on # slapd.pem so that the ldap user or group can read it. Your client software # may balk at self-signed certificates, however. # TLSCACertificateFile /etc/pki/tls/certs/ca-bundle.crt # TLSCertificateFile /etc/pki/tls/certs/slapd.pem # TLSCertificateKeyFile /etc/pki/tls/certs/slapd.pem # Sample security restrictions # Require integrity protection (prevent hijacking) # Require 112-bit (3DES or better) encryption for updates # Require 63-bit encryption for simple bind # security ssf=1 update_ssf=112 simple_bind=64 # Sample access control policy: # Root DSE: allow anyone to read it # Subschema (sub)entry DSE: allow anyone to read it # Other DSEs: # Allow self write access # Allow authenticated users read access # Allow anonymous users to authenticate # Directives needed to implement policy: # access to dn.base= by * read # access to dn.base=cn=Subschema by * read access to * by self write by users read by anonymous auth # # if no access controls are present, the default policy # allows anyone and everyone to read anything but restricts # updates to rootdn. (e.g., access to * by
Newbie here
I have downloaded and installed OpenLDAP from www.sunfreeware.com. I have also installed the required supporting software. I know nothing about OpenLDAP. This is my first exposure. It will be on a test setup, running on old SPARCstations. I have settup the conf file, started slapd and it returns to the the prompt. Adding the debug flag shows its complaining about Berkley DB. Has someone here made a similar setup? I don't have access to the machine at this point. Its not connected to the net. I was just wondering if someone else had a like install. Thanks.
Re: rwm + cn=config
Hi,
I got it working :
overlay rwm MUST be declared before database config in slapd.conf, then it
will be placed in olcDatabase={-1}frontend when converting with slaptest
-f slapd.conf -F slapd.d
Rafael.
Hello,
I use the rwm overlay to forward the authentication of some users to the
general ldap replicas of my corp.
Part of slapd.conf :
###
...
overlay rwm
rwm-rewriteEngine on
rwm-rewriteContext bindDN
rwm-rewriteMap ldap mysearch ldap://
ldap.example.com:389/ou=users,dc=example,dc=com?dn?sub
rwm-rewriteRule
^uid=([^,]+),ou=people,dc=[^,]+,dc=example,dc=com$
${mysearch(((objectClass=posixAccount)(uid=$1)))} :@I
databaseldap
suffix ou=users,dc=example,dc=com
uri ldap://ldap.example.com:389/;
restrictread write extended
databasebdb
suffix dc=example,dc=com
rootdn cn=admin,dc=example,dc=com
rootpw mypassword
directory /var/db/openldap-data/mydb
...
Now I converted the 'slapd.conf' to 'cn=config' with slaptest, the remote
authentication stopped working;
and looking at cn=config, all the rules are there...
Any Ideas ?
Rafael NAVAZA.
Tutorial to make an overlay?
Hello everyone, I'm Johan and I am in the final year of my studies in industrial engineering. For my stage, I've been asked to make an overlay for an OpenLDAP server. But, I can't find any documentation on how to make an overlay, could someone please redirect me to a tutorial or something likewise? I would really appreciate it! Thanks! Best regards, Johan
Schema question... userPassword doesn't work
To the ldap forum: I have loaded suse 12.1 m5. I have setup an openldap server, which was the main mission of this machine, and it works. It has ssl /tls, certificates are loaded, that works. I used ldap client to setup the ldap browser and that works also. This is the new 2.4.26 server, which has some rather major changes in how ldap is setup. After about 2 weeks I have that under control. My little domain is setup on dark.net [dc=dark,dc=net]. I used ldapadd to put in the administrator, and I have used ldapsearch to list the subschema. I took the default schema. The list of the subschema includes everything I would like to use. Now I want to go about the real business of defining users. I have reviewed a number of pages to ensure I am doing what appears to be the correct procedure, for instance : http://www.yolinux.com/TUTORIALS/LinuxTutorialLDAP-BindPW.html Which lists: File: fratbrother.ldif dn: cn=fratbrother,o=delta cn: fratbrother sn: fratbrother objectclass: top objectclass: person userPassword: fratsecret ldapadd -f fratbrother.ldif -cxv -D cn=DeanWormer,o=delta -w secret2 And other similar updates. But on my machine I create something simple like: File : dark.ldif dn: cn=jctobin,dc=dark,dc=net cn: jctobin userPassword: Hello1$ Ldapadd -x -D ³cn=admin,dc=dark,dc=net² -W -f dark.ldif Enter LDAP Password: Adding new entry ³cn=jctobin,dc=dark,dc=net² Ldap_add: Object class violation (65) Additional info: no objectClass attribute Obviously my ldap server does not like the ³userPassword² class. I have not been able to use any of the other classes I would like to either [ou: (organizational Unit), uid (unix term for a number corresponding to the user id), etc.] What have I not setup correctly? I need to get these users up and running. What can you do for me? Sincerely, Tob
Unable to start slapd, syncrepl error
Oh the wise and mighty of the openLDAP community,
I have an issue that I have not been able to understand. Partially because
Im an enthusitis, not an expert in the domain. That being said, I've used
an openLDAP RPM compiled by one of the fellow *nix admins:
http://staff.telkomsa.net/packages - Yes, besides the security reasons I'm
desparate enough to try this. I'll eventually use the spec to compile my own
RPM.
I'm running CentOS 5.7 x86_64 with the latest packages. I was able to
successfully install and configure openLDAP but when I attempt to start it
with MIrrorMode, it will not start. I ran slaptest to figure out where it's
hanging up on:
[root@ldap1 ~]# slaptest2.4 -f /etc/openldap2.4/slapd.conf
/etc/openldap2.4/slapd.conf: line 207: rootDN must be defined before
syncrepl may be used
slaptest2.4: bad configuration file!
Any suggestions why it continues to complain about rootDN? I have it
specified and if slapd is going through the lines, it should have picked up
the rootdn before syncrepl. Thoughts?
Here is my slapd.conf:
include /usr/share/openldap2.4/schema/core.schema
include /usr/share/openldap2.4/schema/cosine.schema
include /usr/share/openldap2.4/schema/corba.schema
include /usr/share/openldap2.4/schema/inetorgperson.schema
include /usr/share/openldap2.4/schema/java.schema
include /usr/share/openldap2.4/schema/krb5-kdc.schema
include /usr/share/openldap2.4/schema/kerberosobject.schema
include /usr/share/openldap2.4/schema/misc.schema
include /usr/share/openldap2.4/schema/nis.schema
include /usr/share/openldap2.4/schema/openldap.schema
include /usr/share/openldap2.4/schema/autofs.schema
include /usr/share/openldap2.4/schema/samba.schema
include /usr/share/openldap2.4/schema/kolab.schema
include /usr/share/openldap2.4/schema/evolutionperson.schema
include /usr/share/openldap2.4/schema/calendar.schema
include /usr/share/openldap2.4/schema/sudo.schema
include /usr/share/openldap2.4/schema/dnszone.schema
include /usr/share/openldap2.4/schema/dhcp.schema
#include /usr/share/openldap2.4/schema/rfc822-MailMember.schema
#include /usr/share/openldap2.4/schema/pilot.schema
#include /usr/share/openldap2.4/schema/qmail.schema
#include /usr/share/openldap2.4/schema/mull.schema
#include /usr/share/openldap2.4/schema/netscape-profile.schema
#include /usr/share/openldap2.4/schema/trust.schema
include /etc/openldap2.4/schema/local.schema
include /etc/openldap2.4/slapd.access.conf
access to dn.subtree=dc=domain,dc=pvt
by group=cn=Replicator,ou=Group,dc=domain,dc=pvt
by users read
by anonymous read
pidfile /var/run/ldap2.4/slapd.pid
argsfile/var/run/ldap2.4/slapd.args
modulepath /usr/lib64/openldap2.4
# database backend modules available:
#moduleload back_dnssrv.la
#moduleload back_ldap.la
#moduleload back_meta.la
moduleload back_monitor.la
#moduleload back_passwd.la
#moduleload back_sql.la
# overlay modules available:
#moduleload accesslog.la
#moduleload denyop.la
#moduleload dyngroup.la
#moduleload dynlist.la
#moduleload glue.la
#moduleload lastmod.la
#moduleload pcache.la
#moduleload ppolicy.la
#moduleload refint.la
#moduleload retcode.la
#moduleload rwm.la
moduleload syncprov.la
#moduleload translucent.la
#moduleload unique.la
#contrib overlays
#moduleload smbk5pwd.so
# SASL config
#sasl-host ldap.domain.com
# To allow TLS-enabled connections, create /etc/ssl/openldap2.4/ldap.pem
# and uncomment the following lines.
#TLSRandFile/dev/random
#TLSCipherSuite HIGH:MEDIUM:+SSLv2
TLSCertificateFile /etc/pki/tls/private/ldap.pem
TLSCertificateKeyFile /etc/pki/tls/private/ldap.pem
#TLSCACertificatePath /etc/ssl/openldap2.4/
#TLSCACertificateFile/etc/ssl/cacert.pem
TLSCACertificateFile/etc/pki/tls/private/ldap.pem
#TLSVerifyClient never # ([never]|allow|try|demand)
# logging
#loglevel 256
###
# database definitions
###
databasebdb
suffix dc=domain,dc=pvt
#suffix o=My Organization Name,c=US
rootdn cn=Manager,dc=domain,dc=pvt
#rootdn cn=Manager,o=My Organization Name,c=US
# Cleartext passwords, especially for the rootdn, should
# be avoided. See slappasswd(8) and slapd.conf(5) for details.
# Use of strong authentication encouraged.
# rootpwsecret
# rootpw{crypt}ijFYNcSNctBYg
rootpw {SSHA}[NeeeNer NeeeNer NeeeNer]
# The database directory MUST exist prior to running slapd AND
# should only be accessable by the slapd/tools. Mode 700 recommended.
directory /var/lib/ldap2.4
# Tuning settings, please see the man page for slapd-bdb for more
information
# as well as the DB_CONFIG file in the database directory
# commented entries are at their defaults
# In-memory cache size in entries
#cachesize 1000
#
Unable to start slapd, syncrepl error
Oh the wise and mighty of the openLDAP community,
I have an issue that I have not been able to understand. Partially because
I練 an enthusitis, not an expert in the domain. That being said, I've used
an openLDAP RPM compiled by one of the fellow *nix admins:
http://staff.telkomsa.net/packages - Yes, besides the security reasons I'm
desparate enough to try this. I'll eventually use the spec to compile my own
RPM.
I'm running CentOS 5.7 x86_64 with the latest packages. I was able to
successfully install and configure openLDAP but when I attempt to start it
with MIrrorMode, it will not start. I ran slaptest to figure out where it's
hanging up on:
[root@ldap1 ~]# slaptest2.4 -f /etc/openldap2.4/slapd.conf
/etc/openldap2.4/slapd.conf: line 207: rootDN must be defined before
syncrepl may be used
slaptest2.4: bad configuration file!
Any suggestions why it continues to complain about rootDN? I have it
specified and if slapd is going through the lines, it should have picked up
the rootdn before syncrepl. Thoughts?
Here is my slapd.conf:
include /usr/share/openldap2.4/schema/core.schema
include /usr/share/openldap2.4/schema/cosine.schema
include /usr/share/openldap2.4/schema/corba.schema
include /usr/share/openldap2.4/schema/inetorgperson.schema
include /usr/share/openldap2.4/schema/java.schema
include /usr/share/openldap2.4/schema/krb5-kdc.schema
include /usr/share/openldap2.4/schema/kerberosobject.schema
include /usr/share/openldap2.4/schema/misc.schema
include /usr/share/openldap2.4/schema/nis.schema
include /usr/share/openldap2.4/schema/openldap.schema
include /usr/share/openldap2.4/schema/autofs.schema
include /usr/share/openldap2.4/schema/samba.schema
include /usr/share/openldap2.4/schema/kolab.schema
include /usr/share/openldap2.4/schema/evolutionperson.schema
include /usr/share/openldap2.4/schema/calendar.schema
include /usr/share/openldap2.4/schema/sudo.schema
include /usr/share/openldap2.4/schema/dnszone.schema
include /usr/share/openldap2.4/schema/dhcp.schema
#include /usr/share/openldap2.4/schema/rfc822-MailMember.schema
#include /usr/share/openldap2.4/schema/pilot.schema
#include /usr/share/openldap2.4/schema/qmail.schema
#include /usr/share/openldap2.4/schema/mull.schema
#include /usr/share/openldap2.4/schema/netscape-profile.schema
#include /usr/share/openldap2.4/schema/trust.schema
include /etc/openldap2.4/schema/local.schema
include /etc/openldap2.4/slapd.access.conf
access to dn.subtree=dc=domain,dc=pvt
by group=cn=Replicator,ou=Group,dc=domain,dc=pvt
by users read
by anonymous read
pidfile /var/run/ldap2.4/slapd.pid
argsfile /var/run/ldap2.4/slapd.args
modulepath /usr/lib64/openldap2.4
# database backend modules available:
#moduleloadback_dnssrv.la
#moduleloadback_ldap.la
#moduleloadback_meta.la
moduleloadback_monitor.la
#moduleloadback_passwd.la
#moduleloadback_sql.la
# overlay modules available:
#moduleload accesslog.la
#moduleload denyop.la
#moduleload dyngroup.la
#moduleload dynlist.la
#moduleload glue.la
#moduleload lastmod.la
#moduleload pcache.la
#moduleload ppolicy.la
#moduleload refint.la
#moduleload retcode.la
#moduleload rwm.la
moduleload syncprov.la
#moduleload translucent.la
#moduleload unique.la
#contrib overlays
#moduleloadsmbk5pwd.so
# SASL config
#sasl-host ldap.domain.com
# To allow TLS-enabled connections, create /etc/ssl/openldap2.4/ldap.pem
# and uncomment the following lines.
#TLSRandFile/dev/random
#TLSCipherSuite HIGH:MEDIUM:+SSLv2
TLSCertificateFile/etc/pki/tls/private/ldap.pem
TLSCertificateKeyFile /etc/pki/tls/private/ldap.pem
#TLSCACertificatePath /etc/ssl/openldap2.4/
#TLSCACertificateFile/etc/ssl/cacert.pem
TLSCACertificateFile/etc/pki/tls/private/ldap.pem
#TLSVerifyClient never # ([never]|allow|try|demand)
# logging
#loglevel 256
###
# database definitions
###
database bdb
suffix dc=domain,dc=pvt
#suffix o=My Organization Name,c=US
rootdn cn=Manager,dc=domain,dc=pvt
#rootdn cn=Manager,o=My Organization Name,c=US
# Cleartext passwords, especially for the rootdn, should
# be avoided.See slappasswd(8) and slapd.conf(5) for details.
# Use of strong authentication encouraged.
# rootpw secret
# rootpw {crypt}ijFYNcSNctBYg
rootpw {SSHA}[NeeeNer NeeeNer NeeeNer]
# The database directory MUST exist prior to running slapd AND
# should only be accessable by the slapd/tools. Mode 700 recommended.
directory /var/lib/ldap2.4
# Tuning settings, please see the man page for slapd-bdb for more
information
# as well as the DB_CONFIG file in the database directory
# commented entries are at their defaults
# In-memory cache size in entries
#cachesize 1000
# Checkpoint the bdb database after 256kb of writes or 5 minutes have passed
# since the last checkpoint
checkpoint 256 5
# Indices to maintain
index objectClass eq
# persion-type searches
index cn,mail,surname,givenname
eq,subinitial
#
Re: schema question
On Sep 20, 2011, at 12:05 AM, John Tobin wrote: dn: cn=fratbrother,o=delta cn: fratbrother sn: fratbrother objectclass: top objectclass: person userPassword: fratsecret [...] dn: cn=jctobin,dc=dark,dc=net cn: jctobin userPassword: Hello1$ […] Ldap_add: Object class violation (65) Additional info: no objectClass attribute Obviously my ldap server does not like the “userPassword” class. userPassword is an attribute, not an objectClass. If you look at the first object, there's two object classes defined in the objectClass attribute: 'top' and 'person' Left of the colon is an attribute, right side is a value. I.e., you specify the object class to use, using the objectClass attribute... What have I not setup correctly? Your knowledge of what LDAP is :). I need to get these users up and running. No, what you need to do is go back to the drawing board and learn a little theory - you need to learn to walk before you can drive… Kinda :). -- Turbo Fredriksson tu...@bayour.com
Re: multi master no syncing.
Sébastien Bernard wrote: Hi, I've setup a multimaster cluster composed of two machine (in my example 192.168.0.204 and 192.168.0.197). Everything is working ok and both side are replicating ok. However, I've a problem I'd like to submit to your sagacity. When I put down a server, and modify the other server (delete or add), when the first server comes back, the modifications are not pushed in the old server. Server 1 says Entry cn=seb,ou=orgunit,o=org,dc=example,dc=com changed by peer, ignored You have not provided enough useful information (OpenLDAP version, exact server configurations, which one is server 1 in your description) to be certain. But most likely you have not configured their ServerIDs correctly. Adding new entries works ok and synchronisation happens but for the nodes altered while one of the servers was down, the modifications are lost (or more precisely ignored by the other). My questions: Is this normal behaviour (Maybe I got the configuration wrong) ? How may I force the missing entries to be replicated to the other ? (Only solution I found is to wipe the entire database on the down server that force a replication from its peer). sincerely, Seb Here an extract of the slapd.log from server 1: Sep 22 10:12:32 dhcp204 slapd[2689]: do_syncrep2: rid=002 (-1) Can't contact LDAP server Sep 22 10:12:32 dhcp204 slapd[2689]: do_syncrepl: rid=002 rc -1 retrying (4 retries left) Sep 22 10:12:32 dhcp204 slapd[2689]: do_syncrep2: rid=004 (-1) Can't contact LDAP server Sep 22 10:12:32 dhcp204 slapd[2689]: do_syncrepl: rid=004 rc -1 retrying (4 retries left) Sep 22 10:12:32 dhcp204 slapd[2689]: conn=1002 op=2 UNBIND Sep 22 10:12:32 dhcp204 slapd[2689]: conn=1002 fd=19 closed Sep 22 10:12:32 dhcp204 slapd[2689]: conn=1003 op=2 UNBIND Sep 22 10:12:32 dhcp204 slapd[2689]: conn=1003 fd=20 closed Sep 22 10:12:37 dhcp204 slapd[2689]: slap_client_connect: URI=ldap://192.168.0.197 DN=cn=config ldap_sasl_bind_s failed (-1) Sep 22 10:12:37 dhcp204 slapd[2689]: do_syncrepl: rid=002 rc -1 retrying (3 retries left) Sep 22 10:12:37 dhcp204 slapd[2689]: slap_client_connect: URI=ldap://192.168.0.197 DN=cn=manager,dc=example,dc=com ldap_sasl_bind_s failed (-1) Sep 22 10:12:37 dhcp204 slapd[2689]: do_syncrepl: rid=004 rc -1 retrying (3 retries left) Sep 22 10:12:42 dhcp204 slapd[2689]: slap_client_connect: URI=ldap://192.168.0.197 DN=cn=manager,dc=example,dc=com ldap_sasl_bind_s failed (-1) Sep 22 10:12:42 dhcp204 slapd[2689]: do_syncrepl: rid=004 rc -1 retrying (2 retries left) Sep 22 10:12:42 dhcp204 slapd[2689]: slap_client_connect: URI=ldap://192.168.0.197 DN=cn=config ldap_sasl_bind_s failed (-1) Sep 22 10:12:42 dhcp204 slapd[2689]: do_syncrepl: rid=002 rc -1 retrying (2 retries left) Sep 22 10:12:47 dhcp204 slapd[2689]: slap_client_connect: URI=ldap://192.168.0.197 DN=cn=manager,dc=example,dc=com ldap_sasl_bind_s failed (-1) Sep 22 10:12:47 dhcp204 slapd[2689]: do_syncrepl: rid=004 rc -1 retrying (1 retries left) Sep 22 10:12:47 dhcp204 slapd[2689]: slap_client_connect: URI=ldap://192.168.0.197 DN=cn=config ldap_sasl_bind_s failed (-1) Sep 22 10:12:47 dhcp204 slapd[2689]: do_syncrepl: rid=002 rc -1 retrying (1 retries left) Sep 22 10:12:52 dhcp204 slapd[2689]: slap_client_connect: URI=ldap://192.168.0.197 DN=cn=config ldap_sasl_bind_s failed (-1) Sep 22 10:12:52 dhcp204 slapd[2689]: do_syncrepl: rid=002 rc -1 retrying Sep 22 10:12:52 dhcp204 slapd[2689]: slap_client_connect: URI=ldap://192.168.0.197 DN=cn=manager,dc=example,dc=com ldap_sasl_bind_s failed (-1) Sep 22 10:12:52 dhcp204 slapd[2689]: do_syncrepl: rid=004 rc -1 retrying Sep 22 10:12:57 dhcp204 slapd[2689]: slap_client_connect: URI=ldap://192.168.0.197 DN=cn=config ldap_sasl_bind_s failed (-1) Sep 22 10:12:57 dhcp204 slapd[2689]: do_syncrepl: rid=002 rc -1 retrying (4 retries left) Sep 22 10:12:57 dhcp204 slapd[2689]: slap_client_connect: URI=ldap://192.168.0.197 DN=cn=manager,dc=example,dc=com ldap_sasl_bind_s failed (-1) Sep 22 10:12:57 dhcp204 slapd[2689]: do_syncrepl: rid=004 rc -1 retrying (4 retries left) Sep 22 10:13:02 dhcp204 slapd[2689]: conn=1007 fd=13 ACCEPT from IP=192.168.0.197:55471 (IP=0.0.0.0:389) Sep 22 10:13:02 dhcp204 slapd[2689]: conn=1007 op=0 BIND dn=cn=manager,dc=example,dc=com method=128 Sep 22 10:13:02 dhcp204 slapd[2689]: conn=1007 op=0 BIND dn=cn=manager,dc=example,dc=com mech=SIMPLE ssf=0 Sep 22 10:13:02 dhcp204 slapd[2689]: conn=1007 op=0 RESULT tag=97 err=0 text= Sep 22 10:13:02 dhcp204 slapd[2689]: conn=1008 fd=15 ACCEPT from IP=192.168.0.197:55473 (IP=0.0.0.0:389) Sep 22 10:13:02 dhcp204 slapd[2689]: conn=1008 op=0 BIND dn=cn=config method=128 Sep 22 10:13:02 dhcp204 slapd[2689]: conn=1008 op=0 BIND dn=cn=config mech=SIMPLE ssf=0 Sep 22 10:13:02 dhcp204 slapd[2689]: conn=1008 op=0 RESULT tag=97 err=0 text= Sep 22 10:13:02 dhcp204 slapd[2689]: conn=1008 op=1 SRCH base=cn=config scope=2 deref=0 filter=(objectClass=*) Sep 22 10:13:02 dhcp204 slapd[2689]: conn=1008 op=1 SRCH attr=* + Sep 22
Re: rwm + cn=config
Frava wrote:
Hi,
I got it working :
overlay rwm MUST be declared before database config in slapd.conf, then it
will be placed in olcDatabase={-1}frontend when converting with slaptest -f
slapd.conf -F slapd.d
Of course since you omitted that part of the slapd.conf you posted, nobody on
the mailing list could have known this was relevant to your problem.
And for such global config items, you can eliminate all uncertainty by simply
using database frontend to hold these overlays.
Rafael.
Hello,
I use the rwm overlay to forward the authentication of some users to the
general ldap replicas of my corp.
Part of slapd.conf :
###
...
overlay rwm
rwm-rewriteEngine on
rwm-rewriteContext bindDN
rwm-rewriteMap ldap mysearch
ldap://ldap.example.com:389/ou=users,dc=example,dc=com?dn?sub
http://ldap.example.com:389/ou=users,dc=example,dc=com?dn?sub
rwm-rewriteRule ^uid=([^,]+),ou=people,dc=[^,]+,dc=example,dc=com$
${mysearch(((objectClass=posixAccount)(uid=$1)))} :@I
databaseldap
suffix ou=users,dc=example,dc=com
uri ldap://ldap.example.com:389/ http://ldap.example.com:389/
restrictread write extended
databasebdb
suffix dc=example,dc=com
rootdn cn=admin,dc=example,dc=com
rootpw mypassword
directory /var/db/openldap-data/mydb
...
Now I converted the 'slapd.conf' to 'cn=config' with slaptest, the remote
authentication stopped working;
and looking at cn=config, all the rules are there...
Any Ideas ?
Rafael NAVAZA.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Tutorial to make an overlay?
Johan Jakus wrote: Hello everyone, I'm Johan and I am in the final year of my studies in industrial engineering. For my stage, I've been asked to make an overlay for an OpenLDAP server. But, I can't find any documentation on how to make an overlay, could someone please redirect me to a tutorial or something likewise? No such document exists. Perhaps you can produce one while engaged in your project. But in general, if you know anything about C programming, no such document is necessary. Overlays are pretty small pieces of code, read the code for any existing one and copy what it does. Probably the first dozen or so overlays were all copied and pasted from the original one, then customized as needed. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Schema question... userPassword doesn't work
John Tobin wrote: I have reviewed a number of pages to ensure I am doing what appears to be the correct procedure, for instance : _http://www.yolinux.com/TUTORIALS/LinuxTutorialLDAP-BindPW.html _ Which lists: File: fratbrother.ldif dn: cn=fratbrother,o=delta cn: fratbrother sn: fratbrother objectclass: top objectclass: person userPassword: fratsecret ldapadd -f fratbrother.ldif -cxv -D cn=DeanWormer,o=delta -w secret2 And other similar updates. But on my machine I create something simple like: File : dark.ldif dn: cn=jctobin,dc=dark,dc=net cn: jctobin userPassword: Hello1$ Ldapadd -x -D “cn=admin,dc=dark,dc=net” -W -f dark.ldif Enter LDAP Password: Adding new entry “cn=jctobin,dc=dark,dc=net” Ldap_add: Object class violation (65) Additional info: no objectClass attribute Obviously my ldap server does not like the “userPassword” class. Obviously you have the reading comprehension skills of a turnip. The error message you received says nothing about userPassword at all. Compare your dark.ldif to your fratbrother.ldif. One of these is not like the other. If you can't spot the differences, then you need more help than an email list can provide. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Unable to start slapd, syncrepl error
William S. wrote:
Oh the wise and mighty of the openLDAP community,
I have an issue that I have not been able to understand. Partially because
I’m an enthusitis, not an expert in the domain. That being said, I've used
an openLDAP RPM compiled by one of the fellow *nix admins:
http://staff.telkomsa.net/packages - Yes, besides the security reasons I'm
desparate enough to try this. I'll eventually use the spec to compile my own
RPM.
I'm running CentOS 5.7 x86_64 with the latest packages. I was able to
successfully install and configure openLDAP but when I attempt to start it
with MIrrorMode, it will not start. I ran slaptest to figure out where it's
hanging up on:
[root@ldap1 ~]# slaptest2.4 -f /etc/openldap2.4/slapd.conf
/etc/openldap2.4/slapd.conf: line 207: rootDN must be defined before
syncrepl may be used
slaptest2.4: bad configuration file!
Any suggestions why it continues to complain about rootDN? I have it
specified and if slapd is going through the lines, it should have picked up
the rootdn before syncrepl. Thoughts?
You have placed these directives in your database monitor config, which has
no rootdn configured. You probably meant to place them further up in the file,
under the database bdb config.
Here is my slapd.conf:
include /usr/share/openldap2.4/schema/core.schema
include /usr/share/openldap2.4/schema/cosine.schema
include /usr/share/openldap2.4/schema/corba.schema
include /usr/share/openldap2.4/schema/inetorgperson.schema
include /usr/share/openldap2.4/schema/java.schema
include /usr/share/openldap2.4/schema/krb5-kdc.schema
include /usr/share/openldap2.4/schema/kerberosobject.schema
include /usr/share/openldap2.4/schema/misc.schema
include /usr/share/openldap2.4/schema/nis.schema
include /usr/share/openldap2.4/schema/openldap.schema
include /usr/share/openldap2.4/schema/autofs.schema
include /usr/share/openldap2.4/schema/samba.schema
include /usr/share/openldap2.4/schema/kolab.schema
include /usr/share/openldap2.4/schema/evolutionperson.schema
include /usr/share/openldap2.4/schema/calendar.schema
include /usr/share/openldap2.4/schema/sudo.schema
include /usr/share/openldap2.4/schema/dnszone.schema
include /usr/share/openldap2.4/schema/dhcp.schema
#include /usr/share/openldap2.4/schema/rfc822-MailMember.schema
#include /usr/share/openldap2.4/schema/pilot.schema
#include /usr/share/openldap2.4/schema/qmail.schema
#include /usr/share/openldap2.4/schema/mull.schema
#include /usr/share/openldap2.4/schema/netscape-profile.schema
#include /usr/share/openldap2.4/schema/trust.schema
include /etc/openldap2.4/schema/local.schema
include /etc/openldap2.4/slapd.access.conf
access to dn.subtree=dc=domain,dc=pvt
by group=cn=Replicator,ou=Group,dc=domain,dc=pvt
by users read
by anonymous read
pidfile /var/run/ldap2.4/slapd.pid
argsfile/var/run/ldap2.4/slapd.args
modulepath /usr/lib64/openldap2.4
# database backend modules available:
#moduleload back_dnssrv.la
#moduleload back_ldap.la
#moduleload back_meta.la
moduleload back_monitor.la
#moduleload back_passwd.la
#moduleload back_sql.la
# overlay modules available:
#moduleload accesslog.la
#moduleload denyop.la
#moduleload dyngroup.la
#moduleload dynlist.la
#moduleload glue.la
#moduleload lastmod.la
#moduleload pcache.la
#moduleload ppolicy.la
#moduleload refint.la
#moduleload retcode.la
#moduleload rwm.la
moduleload syncprov.la
#moduleload translucent.la
#moduleload unique.la
#contrib overlays
#moduleload smbk5pwd.so
# SASL config
#sasl-host ldap.domain.com
# To allow TLS-enabled connections, create /etc/ssl/openldap2.4/ldap.pem
# and uncomment the following lines.
#TLSRandFile/dev/random
#TLSCipherSuite HIGH:MEDIUM:+SSLv2
TLSCertificateFile /etc/pki/tls/private/ldap.pem
TLSCertificateKeyFile /etc/pki/tls/private/ldap.pem
#TLSCACertificatePath /etc/ssl/openldap2.4/
#TLSCACertificateFile/etc/ssl/cacert.pem
TLSCACertificateFile/etc/pki/tls/private/ldap.pem
#TLSVerifyClient never # ([never]|allow|try|demand)
# logging
#loglevel 256
###
# database definitions
###
databasebdb
suffix dc=domain,dc=pvt
#suffix o=My Organization Name,c=US
rootdn cn=Manager,dc=domain,dc=pvt
#rootdn cn=Manager,o=My Organization Name,c=US
# Cleartext passwords, especially for the rootdn, should
# be avoided. See slappasswd(8) and slapd.conf(5) for details.
# Use of strong authentication encouraged.
# rootpwsecret
# rootpw{crypt}ijFYNcSNctBYg
rootpw {SSHA}[NeeeNer NeeeNer NeeeNer]
# The database directory MUST exist prior to running slapd AND
# should only be accessable by the slapd/tools. Mode 700 recommended.
directory /var/lib/ldap2.4
# Tuning settings, please
