Password policy questions
by Greg Kuchyt
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.
11 years, 8 months
setting ACI to countryCode attribute
by Vlad
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.
11 years, 8 months
Syncing multiple OUs
by Chris Visser
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
11 years, 8 months
Rate-limiting MOD operations?
by Justin Piszcz
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.
11 years, 8 months
389-ds + CentOS 6.2 + TLS (self-signed, setupssl2.sh-script) + 389-console : complete FAIL. Would appreciate help.
by Ray
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
11 years, 8 months
Re: [389-users] openldap client HA for multimaster replication
by Howard Chu
> 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/
11 years, 8 months
openldap client HA for multimaster replication
by Ryan Palamara
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.
11 years, 8 months
Syncing AD groups and multiple (samba) domains
by Orion Poplawski
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
11 years, 8 months
restore or replace admin server
by Josh Ellsworth
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
11 years, 8 months
Replication field doubt
by Alberto Viana
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
11 years, 8 months