I've been looking through the archives for information, but I haven't stumbled on a solution to my problem.
I'm running ds-389 (389-ds-base-184.108.40.206) on a centos 7 box (CentOS Linux release 7.2.1511). I have a centos OS client configured using SSL/TLS
which queries the LDAP server. Per a previous thread, I configured the memeberOf plugin and all seems to be working properly.
I have a php script that will run on the client and change the LDAP password for the user. The problem is, the script looks for the SSHA has
of the password when an ldapsearch is issued.
However, when I issue a general ldapsearch (anonymously) I don't get the userpassword field. I read in your archives that I might have
to be the "directory manager" user in order to see the hashed password. I've been playing around with the ldapsearch syntax, but I can't
quite get it right.
Anyway, my question is, can I set a flag in 389-ds that will display the hashed userpassword? I think that will solve my problem with the php script returning an error that it can't retrieve the old password.
I am trying to activate Account policy plug-in in order to record the
last time when an user is authenticated. I am following this guide
and when I execute the ldapmodify query (14.5.2), the response is
I have also looked at the 389-console, but I can not find how to set the
values of "alwaysrecordlogin", "stateAttrName" and so on.
My goal is simply to log the activity, not to lock the inactive users
(at least for now)
Can someone give an advice when am I missing as steps?
In 389ds ACI, many operations like search,read,write,... can be restricted based on evaluating time, ip, dns name, authenticated user and some other conditions.
We have multiple applications which authenticate(bind only) their users with a Directory (389ds).
I need to restrict users from logging on applications based on a policy. For example UserA could be logged on App1, and not App2, and so on.
For that I'm looking for a feature that could be helpful.
I thought of a feature in ACI, in which ACI could be defined on Bind operations, too. For example we could define an ACI saying users with a filter, say (attributeA=App1) or (objectClass=App1User) and fromIP restriction(of the server of application App1), allows or denies binding of users. And users + apps which are not match in the criteria could not login(they will get err=49 or Invalid Credential), and those who match could login.
I thought of another solution, too, in which by putting users in dynamic containers which have bind feature. For example there is a certain type of OU which is dynamically filled by users that has certain characteristic,
- OU=App1,DC=domain,DC=com contains users with (attributeA=App1) or (objectClass=App1User).
- OU=App2,DC=domain,DC=com contains users with (attributeA=App2) or (objectClass=App1User).
In this case I can tell app1 to authenticate UserA against its own OU=App1,DC=domain,DC=com contains users, and app2 against OU=App2,DC=domain,DC=com.
I'm wondering if anyone has any idea or had been in the same place.
Older Directory Server 1.2.6 - Fedora
On my test server, I was trying to mimic some behaviour restrictions that exists on another LDAP server,
Using console I managed to create an ACI for ALL Users to disallow access completely to test123 OU, realising perhaps now even Admin can no longer access, which is too much of a restriction, I need to remove the ACI. After a restart of dirsrv.target and admin, the test OU is no longer listed, so I cant 'set access permissions'. However I know it exists as it was my user actions that likely caused this and I can't recreate an OU with the same name as I get *error 68*.
Is there any way I can manually remove this ACI setting?
Many thanks for any advice,
What I Need:
Enforce a global password policy but disable for some specifics OUs.
Everything was working fine but I realized for that specific OU that I
created a local policy started to storage user password as plaintext:
I created the local policy using the script ns-newpwpolicy.pl as below:
/opt/dirsrv/sbin/ns-newpwpolicy.pl -v -D "cn=Directory Manager" -w
my_manager_pass -S OU=testing,dc=homolog,dc=rnp
Here's my config:
nsslapd-pwpolicy-local: on (under cn=config)
Double checked using 389 console that under this OU, "Fine-grained subtree
policy enabled" is set on.
-D "cn=Directory Manager" -x -W '(objectclass=ldapsubentry)'
# extended LDIF
with scope subtree
# filter: (objectclass=ldapsubentry)
# requesting: ALL
# cn\3DnsPwTemplateEntry\2COU\3Dtesting\2Cdc\3Dhomolog\2Cdc\3Drnp, nsPwPol
icyContainer, testing, homolog.rnp
A user entry on this OU:
Am I missing something?
I am planning to migrate our 389-ds servers, which are currently on
Centos6, to Centos7.
Install 2 machines, create SSL certificates, set the hostnames as the
old one, put the old IPs in /etc/hosts, use the 389 GUI on oldserver1
to back up, use 389 GUI on newserver1 to import the backup.
Question: Is this the proper way? I am wondering if "export" and then
"import" will do the trick.
need help with following error after a fresh installation on FC 24:
rpm -qa | grep 389-ds
Seeing the following:
service dirsrv stop
Redirecting to /bin/systemctl stop dirsrv.service
Failed to stop dirsrv.service: Unit dirsrv.service not loaded.
service dirsrv status
Redirecting to /bin/systemctl status dirsrv.service
Loaded: not-found (Reason: No such file or directory)
Active: inactive (dead)
I'm trying to track down a problem we are seeing on two relatively
lightly used instances on CentOS 7 (and previously on CentOS 6, which is
no longer in use). Our servers have 3624 entries according to last
night's export (we export userRoot daily). There are currently just
over 400 connections established to each server.
We have a local cron job that runs every 5 minutes that performs a
simple query. If it takes more than 7 seconds to get an answer, the
attempt is aborted and another query issued. If three consecutive test
fail, the directory server is restarted.
The issue we're seeing is that the longer the system is up, the more
often checks will fail. Restarting the directory does not resolve the
problem. Our servers have currently been up for 108 days, and are
restarting the service several times a day, as a result of the checks.
Only if we reboot the systems does the problem subside.
CPU utilization seems relatively high for such a small directory, but
it's not constant. I tried to manually capture a bit of data with
strace during a period when CPU use was bursting high. During a capture
of maybe two seconds, I saw most of the CPU time was spent in futex.
usecs/call was fairly high for calls to futex and select, as detailed below.
Since restarting the service doesn't fix the problem, it seems most
likely that this is an OS bug, but I'm hoping that the list can help me
identify other useful data to track down the problem. Does anyone have
any suggestions for what I can capture now, while I can sometimes
observe the problem? If I reboot, it'll take months before I can get
any new data.
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
74.61 4.505251 3590 1255 340 futex
17.65 1.065548 6660 160 select
4.41 0.266344 88781 3 2 restart_syscall
3.07 0.185566 50 3718 poll
0.10 0.006185 2 3610 sendto
0.09 0.005189 5189 1 fsync
0.04 0.002134 37 58 write
0.03 0.001618 27 61 setsockopt
0.00 0.000111 3 36 recvfrom
0.00 0.000078 1 57 read
0.00 0.000014 14 1 fstat
0.00 0.000003 2 2 accept
0.00 0.000003 1 6 fcntl
0.00 0.000002 1 2 getsockname
0.00 0.000001 1 2 close
------ ----------- ----------- --------- --------- ----------------
100.00 6.038047 8972 342 total
I'll admit up front that comparatively speaking, this is a tiny, tiny, tiny little environment, only a few hundred users in the directory service.
We have a 60 day password expiration requirement. Users range from nerdy infrastructure types to Windows developers to business users.
Is anybody using an httpd (Apache2) based self-service password reset tool?
I've been looking at the LTB self-service password reset application(http://ltb-project.org/wiki/documentation/self-service-passwo.... I can probably get it to work for me, but I'm also looking at some fairly non-trivial modifications, I suspect.
This message may contain confidential material from Land O'Lakes, Inc. (or its subsidiary) for the sole use of the intended recipient(s) and may not be reviewed, disclosed, copied, distributed or used by anyone other than the intended recipient(s). If you are not the intended recipient, please contact the sender by reply email and delete all copies of this message.