[389][Active Directory] Replication issue
by Moisés Barba Pérez
Hello,
Unfortunately in our organization we have a replication agreement
between 389 DS and an Active Directory.
For some reason, some Active Directory admin has run a script which has
change the "givenname" and "sn" attrs (now they are in base64) and that
change have been replicated to the 389 DS (1).
The issue is: This changes coming from replication aren't shown in the
server logs with the AD agreement, I saw them in the access file and audit
file but from another 389 DS (2) server with multimaster replication
agreement not in the server with the AD agreement ¿Is this normal? We are
using 1.2.5 version.
AD <=====> 389 DS (1) <=====> 389 DS (2)
Regards,
Moses.
10 years
Admin console login fails with LDAP users first time only
by Groten, Ryan
When I restart the dirsrv-admin process on my 389 server, any attempt to login to the 389-console with my LDAP user ID fails with the following message:
"Cannot logon because of an incorrect User ID, Incorrect Password or Directory problem
HttpException:
Response: HTTP/1.1 401 Authorization Required
Status: 401
URL: http://389-srv1:9830/admin-serv/authenticate"
After that I login with the built-in admin user, close the window, then log in with my LDAP user again and from then on it works (until the next time dirsrv-admin is restarted).
Here's what I see in the error log (I added comments to show the sequence of events):
# Restart dirsrv-admin
[Tue Apr 15 12:02:56 2014] [notice] caught SIGTERM, shutting down
[Tue Apr 15 12:02:57 2014] [notice] SELinux policy enabled; httpd running as context unconfined_u:system_r:httpd_t:s0
[Tue Apr 15 12:02:58 2014] [notice] Access Host filter is: *.domain.com
[Tue Apr 15 12:02:58 2014] [notice] Access Address filter is: *
[Tue Apr 15 12:02:59 2014] [notice] Apache/2.2.15 (Unix) configured -- resuming normal operations
[Tue Apr 15 12:02:59 2014] [notice] Access Host filter is: *.domain.com
[Tue Apr 15 12:02:59 2014] [notice] Access Address filter is: *
# Failed login with rgroten
[Tue Apr 15 12:03:11 2014] [notice] [client 11.22.33.44] admserv_host_ip_check: ap_get_remote_host could not resolve 11.22.33.44
[Tue Apr 15 12:03:11 2014] [error] [client 11.22.33.44] user rgroten not found: /admin-serv/authenticate
# Successful login with admin
[Tue Apr 15 12:08:59 2014] [notice] [client 11.22.33.44] admserv_host_ip_check: ap_get_remote_host could not resolve 11.22.33.44
[Tue Apr 15 12:08:59 2014] [notice] [client 11.22.33.44] admserv_check_authz(): passing [/admin-serv/authenticate] to the userauth handler
# Successful login with rgroten
[Tue Apr 15 12:09:25 2014] [notice] [client 11.22.33.44] admserv_host_ip_check: ap_get_remote_host could not resolve 11.22.33.44
[Tue Apr 15 12:09:25 2014] [notice] [client 11.22.33.44] admserv_check_authz(): passing [/admin-serv/authenticate] to the userauth handler
Package versions:
389-ds-base-libs-1.2.11.25-1.el6.x86_64
389-ds-console-1.2.6-1.el6.noarch
389-adminutil-1.1.19-1.el6.x86_64
389-ds-base-1.2.11.25-1.el6.x86_64
389-admin-console-1.1.8-1.el6.noarch
389-ds-console-doc-1.2.6-1.el6.noarch
389-dsgw-1.1.11-1.el6.x86_64
389-console-1.1.7-1.el6.noarch
389-admin-1.1.35-1.el6.x86_64
389-admin-console-doc-1.1.8-1.el6.noarch
389-ds-1.2.2-1.el6.noarch
Thanks!
Ryan
10 years
Long distance replication
by Elizabeth Jones
Have any of you encountered issues with replication over long distances,
such as between data centers? We have a master in each of our data
centers and a consumer at each data center, but all changes are pretty
much made at data center A and then replicated to its local consumer, then
across our mpls to the master at data center B. For the second time in
two months now our two LDAPs at data center B have gotten corrupted and I
have had to reinitialize them from the master in data center A. Are there
any replication tricks for long distance replication that could keep this
from happening?
thanks -
EJ
10 years
389 training?
by Elizabeth Jones
Does anyone know of any 389 training that they could recommend? My
manager has decided that he wants me to have "ldap training", but I am not
aware of anything for 389 DS other than all the online documentation.
thanks -
EJ
10 years
Operations Error deleting large groups
by Michael Gettes
I am using 389-Directory/1.2.11.29 B2014.094.2116
when deleting a large group (let’s say members > 25000) we see the following error in the errors log
(which yields an Operations Error (err=1) back to the ldap client) and creates an object with
dn: nsuniqueid=cef92c21-b69711e3-8a25d834-1f7e47a1,CN=CommunityBLAH,ou=BLAH,DC=BLAH
[14/Apr/2014:13:21:49 -0400] - libdb: Lock table is out of available lock entries
[14/Apr/2014:13:21:49 -0400] - idl_new.c BAD 22, err=12 Cannot allocate memory
[14/Apr/2014:13:21:49 -0400] - database index operation failed BAD 1130, err=12 Cannot allocate memory
[14/Apr/2014:13:21:49 -0400] - database index operation failed BAD 1140, err=12 Cannot allocate memory
[14/Apr/2014:13:21:49 -0400] - database index operation failed BAD 1230, err=12 Cannot allocate memory
[14/Apr/2014:13:21:49 -0400] - database index operation failed BAD 1030, err=12 Cannot allocate memory
after investigating the error message I tried to increase the number of locks according to the documentation in section 2.5 of the admin guide “Lock Files” by setting nsslapd-db-locks to 30000. I notice in cn=database,cn=monitor,cn=ldbm database,cn=plugins,cn=config the attribute nsslapd-db-configured-locks does not change - it was 10000 before I set it to 30000 and it remains 10000.
Is this expected behavior? I can’t see any other indication my change has taken effect (I do see my change in cn=config,cn=ldbm database,cn=plugins,cn=config).
Also, if I set this attribute (nsslapd-db-locks) on my multi-replicated masters to resolve this problem, do i need to set it on my non-master servers?
Many thanks!
/mrg
10 years
Custom schema in 389-ds version 1.1
by Chris Taylor
I am just looking to replace my older 8.2 ds servers with the new 389-ds version 1.1, my only hang up is that I have some custom schema files used for RADIUS and FTP. I have read the docs and it looks like it's the same process, just have the custom ldif files located in the /etc/dirsrv/slapd-servername/schema is this correct or am I off base.
Thanks,
Chris
10 years
ns-activate/inactivate/accountstatus.pl
by Elizabeth Jones
I just discovered the ns-activate/inactivate/accountstatus.pl scripts but
I can't seem to get them to work. I've tried a bunch of different
combinations along these lines --
s-accountstatus.pl -D "cn=Directory Manager" -w password -p 389 -h
myldapserver -I cn=ejtest,ou=Deactivated
Accts,ou=People,dc=mycompany,dc=com
ns-accountstatus.pl -D Directory Manager -w password -p 389 -h
myldapserver -I cn=ejtest,ou=Deactivated
Accts,ou=People,dc=mycompany,dc=com
ns-accountstatus.pl -D "cn=Directory Manager" -w password -p 389 -h
myldapserver -I "cn=ejtest,ou=Deactivated
Accts,ou=People,dc=mycompany,dc=com"
ns-accountstatus.pl -D Directory Manager -w password -p 389 -h
myldapserver -I "cn=ejtest,ou=Deactivated
Accts,ou=People,dc=mycompany,dc=com"
basically with and without "" and with and without cn=, but every
combination I've tried it only returns the help menu back to me.
I looked up the ldapsearch commands that it is using, this seems to be the
accountstatus command:
$ldapsearch -p $port -h $host -D \"$rootdn\" -w \"$rootpw\" -s base -b
\"$entry\" \"(objectclass=*)\" nsaccountlock
It looks pretty basic, but I can't figure out why it won't work for me.
Are others able to get this working?
thanks -
EJ
10 years
password modify extended operation chaining?
by Dawei Wang
I tried numerous time and it seems that chain on update(database link) does not chain password modify extended operation. The version i am working on is Redhat DS 8.2. Just wondering what is the status of supporting this, is this available in some newer version of 389?
10 years
1.2.11.29 prediction?
by Michael Gettes
Hi all,
I recognize 389 is a community project and asking for timelines can be problematic. Right now, I am sorta stuck between a rock and a hard place. In production, I am on 1.2.11.15 which has problems that are fixed by 1.2.11.28. I have 1.2.11.28 in test and fixes all my prod problems but introduces a new problem which makes it rather difficult to manage the environment and it would appear this will be corrected in 1.2.11.29. So, I am a little curious as to when we might see 29. I do see on the roadmap 29 has 4 closed and 5 active but no date set.
I’m wondering if anyone would want to out on a limb and guesstimate - are we thinking days or a couple of weeks or several weeks or any estimate would be so appreciated. No, I will not hold anyone to anything - I can’t. I’m just trying to gauge things for internal planning estimates recognizing I have no control over this process. (yeah, i know, so why bother? cuz, i have to try).
Lastly, although I am on RHEL6 and have RHEL support, I don’t have RHEL DS support. I find the 389 community generally excellent. I have been trying to keep to what’s available in the repo but, as it would appear, I am now going to have to go with what’s available by source. So, if I go with the source route for maintenance… should I move from the 1.2.11 line to 1.3.1? I am not sure I fully appreciate the differences. I get the sense 1.3.1 is where the current effort is really at and 1.2.11 is in maintenance, but I could be all wrong. Any perspective is appreciated here as well. I have read through the site and it isn't directly obvious.
Many thanks! Especially to the fine dev team!
/mrg
10 years
