389-users July 2012

389-users@lists.fedoraproject.org

39 participants
40 discussions

Password policy questions
by Greg Kuchyt 10 Jul '12

10 Jul '12

First off, I'm sorry if I missed a document somewhere that covers this, but after some searching I failed to find such a source that explicitly spells this out. In order to verify my findings in testing, I had a couple questions about the userPassword attribute and its relationship to the password policy. Is it accurate that the 389DS password policy only comes into effect when the LDAPv3 password modify operation is used (i.e. via ldappasswd)? I noticed that setting a default password hashing algorithm does not affect my ability to use any type of hash or clear text in the userPassword attribute or bind. We have historically managed the userPassword field like it is any other field and are looking to switch the hash type we use to store passwords. I was wondering what exactly switching the default password algorithm "does". From my testing it appears that it does not affect the existing data or manual changes to it. This leads me to believe it only comes into play during the password modify extended operation. Thanks for any help, and again my apologies if this is covered somewhere and I failed to find it.

2 1

setting ACI to countryCode attribute
by Vlad 10 Jul '12

10 Jul '12

Hello, I'm trying to define ACI for "countryCode" attribute and getting an error "Attribute is not defined in the schema". However, i can create an entry with this attribute. Could somebody clarify what the problem is. Thank you in advance, Vlad.

3 3

Syncing multiple OUs
by Chris Visser 09 Jul '12

09 Jul '12

Hi, I've got 389-ds configured and I'm busy setting up my sync agreement with my Windows AD server. My AD has nested OUs e.g. -DivisionOU1 --BranchOU ---Department1OU ---Department2OU --Branch2OU ---Department1OU ---Department2OU All my users and groups sit in the Department OUs and if I setup my agreement to sync on the Department OU it syncs the users in OU. If I however point it higher up in the hierarchy it doesn't go down the levels and sync the OUs below it. Do I need to setup a separate agreement for each OU? Or is there a way I can sync the whole DivisionOU recursively? I tried searching on the internet for the answer, but all I come across are other people asking the same question and receiving no answer. Chris Visser Linux/Network Infrastructure ================== Please read our Email Disclaimer : http://www.rtt.co.za/disclaimer.html

3 2

Rate-limiting MOD operations?
by Justin Piszcz 09 Jul '12

09 Jul '12

Hello, Aside from writing a custom script, is there a way (within fedora-ds/LDAP) to rate-limit the number of MOD's a specific bind can perform at one time? E.g., 10/minute instead of 1,000/minute? Justin.

2 1

389-ds + CentOS 6.2 + TLS (self-signed, setupssl2.sh-script) + 389-console : complete FAIL. Would appreciate help.
by Ray 09 Jul '12

09 Jul '12

Hi there, here's what I would like to do: Run the 389 directory server on CentOS 6.2 (x86_64). As you guys know, TLS is a must in RHEL 6+ and I do not want to turn it off, switching in sysconfig to RHEL 5 "legacy mode". Instead I would like to use the setupssl2.sh script from the 389-site to set up TLS. This fails completely: I start out switching off & deleteing everything: -------------------------------------------------------------------------- root@ldap:~# service dirsrv stop Shutting down dirsrv: bb_auth... [ OK ] root@ldap:~# service dirsrv-admin stop Shutting down dirsrv-admin: [ OK ] root@ldap:~# yum remove 389-ds* root@ldap:~# rm -rf /etc/sysconfig/dirsrv* /etc/dirsrv /var/lib/dirsrv /root/.389-console -------------------------------------------------------------------------- Now everything 389-related should be wiped from the box. Please correct me if I'm wrong. Next, I switch off iptables and disable selinux: -------------------------------------------------------------------------- root@ldap:~# service iptables stop root@ldap:~# setenforce 0 -------------------------------------------------------------------------- Now I start from scratch: /etc/hosts: -------------------------------------------------------------------------- root@ldap:~# cat /etc/hosts 127.0.0.1 ldap.baar.intra.bbcomputing.org localhost localhost.localdomain localhost4 localhost4.localdomain4 ::1 ldap.baar.intra.bbcomputing.org localhost localhost.localdomain localhost6 localhost6.localdomain6 192.168.10.37 ldap.baar.intra.bbcomputing.org -------------------------------------------------------------------------- Installation: -------------------------------------------------------------------------- root@ldap:~# yum install 389-ds ... Running Transaction Installing : 389-ds-base-libs-1.2.9.14-1.el6_2.2.x86_64 1/9 Installing : 389-ds-base-1.2.9.14-1.el6_2.2.x86_64 2/9 Installing : 389-admin-1.1.29-1.el6.x86_64 3/9 Installing : 389-admin-console-1.1.8-1.el6.noarch 4/9 Installing : 389-ds-console-1.2.6-1.el6.noarch 5/9 Installing : 389-ds-console-doc-1.2.6-1.el6.noarch 6/9 Installing : 389-admin-console-doc-1.1.8-1.el6.noarch 7/9 Installing : 389-dsgw-1.1.9-1.el6.x86_64 8/9 Installing : 389-ds-1.2.2-1.el6.noarch 9/9 Installed: 389-ds.noarch 0:1.2.2-1.el6 ... -------------------------------------------------------------------------- Looks ok to me. (Again: Please correct m if I'm wrong) Setup: -------------------------------------------------------------------------- root@ldap:~# setup-ds-admin.pl My answers here: Would you like to continue with set up? [yes]: y Would you like to continue? [yes]: y Choose a setup type [2]: 2 Computer name [ldap.baar.intra.bbcomputing.org]: ldap.baar.intra.bbcomputing.org System User [nobody]: nobody System Group [nobody]: nobody Do you want to register this software with an existing configuration directory server? [no]: n administrator ID [admin]: admin Password: <pw1> Password (confirm): <pw1> Administration Domain [baar.intra.bbcomputing.org]: intra.bbcomputing.org Directory server network port [389]: 389 Directory server identifier [ldap]: bb_auth Suffix [dc=baar, dc=intra, dc=bbcomputing, dc=org]: dc=bbcomputing,dc=org Directory Manager DN [cn=Directory Manager]: cn=Directory Manager Password: <pw2> Password (confirm): <pw2> Administration port [9830]: 9830 Are you ready to set up your servers? [yes]: y -------------------------------------------------------------------------- Here's the following output: -------------------------------------------------------------------------- Creating directory server . . . Your new DS instance 'bb_auth' was successfully created. Creating the configuration directory server . . . Beginning Admin Server creation . . . Creating Admin Server files and directories . . . Updating adm.conf . . . Updating admpw . . . Registering admin server with the configuration directory server . . . Updating adm.conf with information from configuration directory server . . . Updating the configuration for the httpd engine . . . Starting admin server . . . output: Starting dirsrv-admin: output: [ OK ] The admin server was successfully started. Admin server was successfully created, configured, and started. Exiting . . . Log file is '/tmp/setup1dRGLl.log' -------------------------------------------------------------------------- Again, looks all ok to me. Especially the processes looks good: -------------------------------------------------------------------------- root@ldap:~# ps -ef |grep dirsrv nobody 7541 1 0 11:30 ? 00:00:00 ./ns-slapd -D /etc/dirsrv/slapd-bb_auth -i /var/run/dirsrv/slapd-bb_auth.pid -w /var/run/dirsrv/slapd-bb_auth.startpid root 7652 1 0 11:30 ? 00:00:00 /usr/sbin/httpd.worker -k start -f /etc/dirsrv/admin-serv/httpd.conf root 7655 7652 0 11:30 ? 00:00:00 /usr/sbin/httpd.worker -k start -f /etc/dirsrv/admin-serv/httpd.conf nobody 7656 7652 0 11:30 ? 00:00:00 /usr/sbin/httpd.worker -k start -f /etc/dirsrv/admin-serv/httpd.conf root 7839 7816 0 11:36 pts/2 00:00:00 grep dirsrv -------------------------------------------------------------------------- And netstat also looks just sweet: -------------------------------------------------------------------------- root@ldap:~# netstat -lntp Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name ... tcp 0 0 0.0.0.0:9830 0.0.0.0:* LISTEN 7652/httpd.worker ... tcp 0 0 :::389 :::* LISTEN 7541/./ns-slapd ... -------------------------------------------------------------------------- In fact, I can run 389-console at this point and successfully log into the management console: -------------------------------------------------------------------------- root@ldap:~# 389-console Using: User ID: cn=Directory Manager Password: <pw2> Administration URL: http://localhost:9830 -------------------------------------------------------------------------- So far so good without TLS. Now the pain pain starts: To set up TLS I foung this script in the 389 Howto:SSL docs: http://github.com/richm/scripts/tree/master%2Fsetupssl2.sh?raw=true So I naively ran this thing: -------------------------------------------------------------------------- root@ldap:~# ./setupssl2.sh /etc/dirsrv/slapd-bb_auth/ Using /etc/dirsrv/slapd-bb_auth/ as sec directory No CA certificate found - will create new one No Server Cert found - will create new one No Admin Server Cert found - will create new one Creating password file for security token Creating noise file Creating new key and cert db Creating encryption key for CA Generating key. This may take a few moments... Creating self-signed CA certificate Generating key. This may take a few moments... Is this a CA certificate [y/N]? Enter the path length constraint, enter to skip [<0 for unlimited path]: > Is this a critical extension [y/N]? Exporting the CA certificate to cacert.asc Generating server certificate for 389 Directory Server on host ldap.baar.intra.bbcomputing.org Using fully qualified hostname ldap.baar.intra.bbcomputing.org for the server name in the server cert subject DN Note: If you do not want to use this hostname, edit this script to change myhost to the real hostname you want to use Generating key. This may take a few moments... Creating the admin server certificate Generating key. This may take a few moments... Exporting the admin server certificate pk12 file pk12util: PKCS12 EXPORT SUCCESSFUL Creating pin file for directory server Importing the admin server key and cert (created above) pk12util: PKCS12 IMPORT SUCCESSFUL Importing the CA certificate from cacert.asc Creating the admin server password file Enabling the use of a password file in admin server Turning on NSSEngine Use ldaps for config ds connections Enabling SSL in the directory server when prompted, provide the directory manager password Password:modifying entry "cn=encryption,cn=config" modifying entry "cn=config" adding new entry "cn=RSA,cn=encryption,cn=config" Enabling SSL in the admin server modifying entry "cn=slapd-bb_auth,cn=389 Directory Server,cn=Server Group,cn=ldap.baar.intra.bbcomputing.org,ou=intra.bbcomputing.org,o=NetscapeRoot" modifying entry "cn=configuration,cn=admin-serv-ldap,cn=389 Administration Server,cn=Server Group,cn=ldap.baar.intra.bbcomputing.org,ou=intra.bbcomputing.org,o=NetscapeRoot" Done. You must restart the directory server and the admin server for the changes to take effect. -------------------------------------------------------------------------- Again everything appears good to me, I can even restart the services without any hickups: -------------------------------------------------------------------------- root@ldap:~# service dirsrv restart Shutting down dirsrv: bb_auth... [ OK ] Starting dirsrv: bb_auth... [ OK ] root@ldap:~# service dirsrv-admin restart Shutting down dirsrv-admin: [ OK ] Starting dirsrv-admin: [ OK ] -------------------------------------------------------------------------- Now I try again to run 389-console with the same credentials and everything as above, and it fails: In the login window it simply hangs saying 'Authenticating User ID "cn=Directory Manager"...' and after some seconds an error messages appears that reads: "Cannot login because of an incorrect User ID, incorrect password or Directory problem. java.io.InterruptedIOException: HTTP response timeout.". netstat now looks like this: -------------------------------------------------------------------------- root@ldap:~# netstat -lntp Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name ... tcp 0 0 0.0.0.0:9830 0.0.0.0:* LISTEN 8331/httpd.worker ... tcp 0 0 :::636 :::* LISTEN 8228/ns-slapd tcp 0 0 :::389 :::* LISTEN 8228/ns-slapd ... -------------------------------------------------------------------------- Honestly, I don't even want an SSL listener on port 636, I really only want a listener on port 389 that requires clients to use start_tls. But I don't care for the moment. Here's more pain: -------------------------------------------------------------------------- root@ldap:~# cat /etc/openldap/ldap.conf URI ldap://ldap.baar.intra.bbcomputing.org/ BASE dc=bbcomputing,dc=org TLS_CACERTDIR /etc/openldap/cacerts -------------------------------------------------------------------------- To my understanding, this should tell CentOS to query the LDAP box mentioned in the URI part, using TLS, for users, but: -------------------------------------------------------------------------- root@ldap:~# id raimund -------------------------------------------------------------------------- produces nothing but these entries in /var/log/messages -------------------------------------------------------------------------- Jul 7 12:04:49 ldap nslcd[1422]: [81823a] ldap_start_tls_s() failed: Connect error (uri="ldap://ldap.baar.intra.bbcomputing.org/") Jul 7 12:04:49 ldap nslcd[1422]: [81823a] failed to bind to LDAP server ldap://ldap.baar.intra.bbcomputing.org/: Connect error Jul 7 12:04:49 ldap nslcd[1422]: [81823a] no available LDAP server found -------------------------------------------------------------------------- This looks bad. Actually the LDAP server sould respond that this user does not exist (empty directory at this moment), but instaead, these lines indicate that the entire communication with the server ist broken. Now, this is pretty useless, isn't it? I now have two running LDAP services (dirsrv and diesrv-admin). The first can't be contacted at all and the door to the admin server is also slammed shut, because 389-console can't talk to it any more. I went on a bit more and switched off SSL/TLS for the admin server again, then 389-console logins worked at least again, but once in the console, it's not possible to open any of the directories. Please help! I already wasted 1.5 days with this, reinstalling about 15 times! Sure there must be a way to get this running with TLS *and* the 389-console? Cheers, Raimund

4 6

Re: [389-users] openldap client HA for multimaster replication
by Howard Chu 07 Jul '12

07 Jul '12

> Date: Fri, 06 Jul 2012 12:29:55 -0600 > From: Rich Megginson <rmeggins(a)redhat.com> > On 07/06/2012 12:27 PM, Ryan Palamara wrote: >> > >> > I am using a mix of CentOS 5 and 6 servers using openldap for client >> > ldap. I have 2 289 Directory servers that are using multi-master >> > replication. >> > >> > When dirsrv stops working on the first server listed under URI, >> > authentication picks up seamlessly on the second LDAP server listed. >> > >> > However if the first server is down completely, it then takes a long >> > time for authentication for go to the second server. >> > >> > Any suggestions on what can be done with openldap, to allow the >> > seamless failover to the second server when the first one is down >> > completely? >> > > > Can you explain exactly what you mean by "stops working" and "down > completely"? I'm not sure why that would make a difference. When the host is down, the TCP connect request must timeout before the client library will see a failure and move on to the next server. When the host is up but the directory server is down, the host will immediately send a TCP connection refused, so the client will switch immediately. The solution is to look into the LDAP network timeout option, to tell the OpenLDAP library to wait for a shorter amount of time for the connection attempt. (LDAP_OPT_NETWORK_TIMEOUT) -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

2 1

openldap client HA for multimaster replication
by Ryan Palamara 06 Jul '12

06 Jul '12

I am using a mix of CentOS 5 and 6 servers using openldap for client ldap. I have 2 289 Directory servers that are using multi-master replication. When dirsrv stops working on the first server listed under URI, authentication picks up seamlessly on the second LDAP server listed. However if the first server is down completely, it then takes a long time for authentication for go to the second server. Any suggestions on what can be done with openldap, to allow the seamless failover to the second server when the first one is down completely? Thank you, Ryan Palamara ZAIS Group, LLC 2 Bridge Avenue, Suite 322 Red Bank, New Jersey 07701 Phone: (732) 450-7444 Ryan.palamara(a)zaisgroup.com<mailto:Ryan.palamara@zaisgroup.com> ________________________________ This e-mail message is intended only for the named recipient(s) above. It may contain confidential information. If you are not the intended recipient you are hereby notified that any dissemination, distribution or copying of this e-mail and any attachment(s) is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender by replying to this e-mail and delete the message and any attachment(s) from your system. Thank you. This is not an offer (or solicitation of an offer) to buy/sell the securities/instruments mentioned or an official confirmation. This is not research and is not from ZAIS Group but it may refer to a research analyst/research report. Unless indicated, these views are the author's and may differ from those of ZAIS Group research or others in the Firm. We do not represent this is accurate or complete and we may not update this. Past performance is not indicative of future returns. IRS CIRCULAR 230 NOTICE:. To comply with requirements imposed by the IRS, we inform you that any U.S. federal tax advice contained herein (including any attachments), unless specifically stated otherwise, is not intended or written to be used, and cannot be used, for the purpose of (i) avoiding penalties under the Internal Revenue Code or (ii) promoting, marketing or recommending any transaction or matter addressed herein to another party. Each taxpayer should seek advice based on the taxpayer's particular circumstances from an independent tax advisor. "ZAIS", "ZAIS Group" and "ZAIS Solutions" are trademarks of ZAIS Group, LLC.

3 5

Syncing AD groups and multiple (samba) domains
by Orion Poplawski 06 Jul '12

06 Jul '12

We are looking to sync our groups between our ldap server and an AD server. Our LDAP server also serves a samba domain for one of our offices. As a result we have Domain Admins and Domain Computers groups for the samba domain that we don't want to conflict with the AD groups of the same names. So it seems like we should move the samba domain groups into a different part of the tree. But we would still want to have a common shared group area that is visible by all. Any suggestions as to how to achieve this? Thanks! -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder Office FAX: 303-415-9702 3380 Mitchell Lane orion(a)nwra.com Boulder, CO 80301 http://www.nwra.com

2 10

restore or replace admin server
by Josh Ellsworth 06 Jul '12

06 Jul '12

I have an instance of 389DS that currently has a broken admin server. Somehow the admin DIT got deleted. Is there a way to rebuild or replace it? There is currently no backup available. Josh -- Joshua Ellsworth System Administrator, Primatics Financial Phone: 571.765.7528 jellsworth(a)primaticsfinancial.com

2 1

Replication field doubt
by Alberto Viana 05 Jul '12

05 Jul '12

I have a replication with a 389 DS server and my AD domain. According to the documentation the field used to control the replication is "NT user ID" on 389 DS and it is populated from Active directory´s field " sAMAccountName". The fact is that "sAMAccountName" is limited to 20 characters. My problem is that I always create my user´s in the active directory first, so when I create a user longer than 20 characters, 389 DS create it missing letters (off corse the problem is about windows limitation and I know that), I´m just trying to find out the esiest solution to my problem. For example, I have an user called "therezinha.figueiredo" and when I create it on my AD the "sAMAccountName" is "therezinha.figueired", so the replication plugin create in the 389 Server an user Called " therezinha.figueired" I Also tried to modifify the user uid and keep the "NT user ID". For example: After the replication plugin created the user called "therezinha.figueired" I modified it manually to ""therezinha.figueiredo" and kept the "NT user ID", but something strange hapenned with this user groups (in the 389 DS and also in the Active Directory). Any clues? Can I use another field to populate users "NT user ID" and change it on the replication plugin? Thanks Alberto Viana

2 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

389-users July 2012