Problem browsing LDAP with Outlook
by Chris Bryant
When configuring Microsoft Outlook (not Outlook Express) to access an LDAP directory, there is an option to 'Enable Browsing (requires server support)'. If this option is chosen and the directory server supports it, then you should be able to open the LDAP address book and page up and down through the results. I have been unable to get this working properly with 389 DS.
When I try to browse from Outlook against the 389 DS directory, I am able to see the first page of results perfectly. However, if I move to the next page, only the first object returned will have any attributes included, and all of the rest of the objects in the page will have no attributes. I have a test perl script that duplicates this functionality as well.
I can get this to work properly with an older version of Netscape Directory Server, and I can get it working with OpenDS. Since 389 DS advertises support for the controls that are required for this to work, just like the other two servers, then I would expect it to work there also.
Has anyone out there gotten this to work with 389 DS? If so, can you share if there was anything special that you needed to do to get this to work? I'm trying to determine if this is a bug in the server, or if I'm just missing something in the configuration.
Thanks,
Chris
USA.NET
You Run Your Business. We'll Run Your Email.
This message is for the sole use of the intended recipient(s) and may contain confidential and/or privileged information of USA.NET, Inc. Any unauthorized review, use, copying, disclosure, or distribution is prohibited. If you are not the intended recipient, please immediately contact the sender by reply email and delete all copies of the original message.
3 years, 3 months
389 Master - Master Replication
by Santos Ramirez
Good Morning,
We have a master - master replication agreement. When we initialize the replication it works perfectly we can see changes to a test user we have set up go up and down from the two servers. However at some point the replication stops and we cannot get replication to start once again. The only way we can get replication to start once again is to recreate the replication agreement and then it fails again. Can anyone please point us in a direction. I am relatively new to 389 so any help would be greatly appreciated.
Santos U. Ramirez
Linux Systems Administrator
National DCP, LLC
150 Depot Street
Bellingham, Ma. 02019
Phone: 508-422-3089
Fax: 508-422-3866
Santos.Ramirez(a)natdcp.com<mailto:Santos.Ramirez@natdcp.com>
This email and any attachments are intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, do not copy or forward to any unauthorized persons, permanently delete the original and notify the sender by replying to this email.
9 years, 2 months
invalid password syntax - passwords with storage scheme are not allowed
by Fosiul Alam
Hi Expert
We have 389 server installed with ssl enabled.
When we try to change password from centos 5 servers its fine . but
from centos 6, i get bellow error :
Changing password for user testuser
Enter login(LDAP) password:
New password:
Retype new password:
LDAP password information update failed: Constraint violation
invalid password syntax - passwords with storage scheme are not allowed
passwd: Authentication token manipulation error
we have this in /etc/ldap.conf
ssl start_tls
tls_cacertfile /etc/openldap/cert/ourcert.crt
pam_password clear
same /etc/ldap.conf works fine in centos5 but for centos6 its looks
like not working
what shall i do ??
Thanks for help
10 years, 9 months
invalid password syntax - passwords with storage scheme are not allowed
by Fosiul Alam
Hi Expert
We have 389 server installed with ssl enabled.
When we try to change password from centos 5 servers its fine . but
from centos 6, i get bellow error :
Changing password for user testuser
Enter login(LDAP) password:
New password:
Retype new password:
LDAP password information update failed: Constraint violation
invalid password syntax - passwords with storage scheme are not allowed
passwd: Authentication token manipulation error
we have this in /etc/ldap.conf
ssl start_tls
tls_cacertfile /etc/openldap/cert/ourcert.crt
pam_password clear
same /etc/ldap.conf works fine in centos5 but for centos6 its looks
like not working
what shall i do ??
Thanks for help
10 years, 9 months
389 and AD group sync
by Vesa Alho
Hi,
I'm having problems with syncing groups from 389 to AD. I wrote about
this earlier but made some more testing.
Using the latest EPEL6 stable:
389-ds-base-1.2.10.12-1.el6.x86_64
389-ds-1.2.2-1.el6.noarch
AD: 2008 R2 64-bit
========
Group description
# testgroup, People, domain.com
dn: cn=testgroup,ou=People,dc=domain,dc=com
ntGroupCreateNewGroup: on
description: testroup
objectClass: top
objectClass: groupofuniquenames
objectClass: ntgroup
uniqueMember: uid=user1,ou=People,dc=domain,dc=com
ntUserDomainId: testgroup
===========
Replication log snippet follows:
NSMMReplicationPlugin - agmt="cn=adtestsync" (adtest:636):
windows_replay_update: Processing add operation local
dn="cn=testgroup,ou=People,dc=domain,dc=com" remote
dn="cn=testgroup,cn=Users,dc=domain,dc=com"
NSMMReplicationPlugin - agmt="cn=adtestsync" (adtest:636):
process_replay_add: dn="cn=testgroup,cn=Users,dc=domain,dc=com" (not
present,add not allowed)
=============
Group sync works correctly when I initiate manual Full resync. This
means AD sync user must have proper permissions.
Bottom line, incremental group sync doesn't work. Only clue is that log
message "not present,add not allowed". Any ideas or some known bug?
-Mr. Vesa Alho
10 years, 9 months
MMR not working after upgrade to 8.2
by Chris Taylor
Hi I have two servers in an MMR setup I upgraded them from 8.1 to 8.2 as per the guide but now replication isn't working. I even went so far as to rebuild the agreements, but when I did that only the initial consumer initialize seemed to have worked but did generate this any updates after that failed with the errors below.
[28/Feb/2013:10:40:41 -0400] - CentOS-Directory/8.2.8 B2012.041.1227 starting up
[28/Feb/2013:10:40:41 -0400] - slapd started. Listening on All Interfaces port 389 for LDAP requests
[28/Feb/2013:10:42:10 -0400] NSMMReplicationPlugin - repl_set_mtn_referrals: could not set referrals for replica dc=domain,dc=ca: 32
[28/Feb/2013:10:42:56 -0400] NSMMReplicationPlugin - repl_set_mtn_referrals: could not set referrals for replica dc=domain,dc=ca: 32
[28/Feb/2013:10:43:50 -0400] NSMMReplicationPlugin - agmt="cn=web-ldap02.eastlink.ca" (web-ldap02:389): Unable to acquire replica: there is no replicated area "dc=eastlink,dc=ca" on the consumer server. Replication is aborting.
[28/Feb/2013:10:43:50 -0400] NSMMReplicationPlugin - agmt="cn=web-ldap02.domain.ca" (web-ldap02:389): Incremental update failed and requires administrator action
[28/Feb/2013:10:46:03 -0400] NSMMReplicationPlugin - repl_set_mtn_referrals: could not set referrals for replica dc=domain,dc=ca: 32
[28/Feb/2013:10:48:42 -0400] NSMMReplicationPlugin - Beginning total update of replica "agmt="cn=web-ldap02.domain.ca" (web-ldap02:389)".
[28/Feb/2013:10:49:06 -0400] NSMMReplicationPlugin - Finished total update of replica "agmt="cn=web-ldap02.domain.ca" (web-ldap02:389)". Sent 54794 entries.
This was off the first master after I force an update
NSMMReplicationPlugin - Replication agreement for agmt="cn=web-ldap02.domain.ca" (web-ldap02:389) could not be updated. For replication to take place, please enable the suffix and restart the server
I checked under the data container there is a check mark where it says enable this suffix.
What should I be looking for? Why would I be able to do an initialize consumer and have it work then have later updates fail.
Any help would be appreciated
Thanks,
Chris
10 years, 9 months
AD sync problem for group with more than 1500 entries
by David Baird
Hi,
We have been experiencing an intermittent problem with our AD sync, where
updates to a group in 389 have resulted in the group being emptied of users.
This has been occurring at various times but not consistently, so was very
difficult to track. Previously, the group would be emptied in the AD, which
would then replicate back to 389, resulting in an empty group in both Directories.
Since installing a fresh CentOS 6.3 server and the latest stable 389 (at the
time, 1.2.10.12-1) the behaviour has only changed slightly, in that now the 389
group gets emptied and the AD group remains intact. When this happens,
initiating a full re-sync will not fix the issue.
We have since discovered that this behaviour is, in fact, consistent and
repeatable if the group contains more than 1500 members. Below that threshold,
adding or subtracting users from the 389 group replicates perfectly. As soon as
you exceed that limit, the group gets emptied.
Turning on replication logging revealed the following.....
(domain and server names have been made anonymous)
[27/Feb/2013:12:20:33 +1300] - Calling dirsync search request plugin
[27/Feb/2013:12:20:33 +1300] - Sending dirsync search request
[27/Feb/2013:12:20:33 +1300] NSMMReplicationPlugin - received entry from
dirsync: CN=students,OU=Groups,OU=Active,OU=People,DC=domain,DC=com
[27/Feb/2013:12:20:33 +1300] NSMMReplicationPlugin - agmt="cn=DC01" (DC01:636):
map_entry_dn_inbound: looking for local entry matching AD entry
[CN=students,OU=Groups,OU=Active,OU=People,DC=domain,DC=com]
[27/Feb/2013:12:20:33 +1300] NSMMReplicationPlugin - agmt="cn=DC01" (DC01:636):
map_entry_dn_inbound: looking for local entry by guid
[919561f60fe49f409afcdf80a63eb089]
[27/Feb/2013:12:20:33 +1300] NSMMReplicationPlugin - agmt="cn=DC01" (DC01:636):
map_entry_dn_inbound: found local entry
[CN=students,ou=Groups,ou=Active,ou=People,dc=domain,dc=com]
[27/Feb/2013:12:20:33 +1300] - Calling windows entry search request plugin
[27/Feb/2013:12:20:33 +1300] - windows_search_entry: received 2 messages, 1
entries, 0 references
[27/Feb/2013:12:20:33 +1300] NSMMReplicationPlugin - agmt="cn=DC01" (DC01:636):
map_entry_dn_inbound: looking for local entry matching AD entry
[CN=students,OU=Groups,OU=Active,OU=People,DC=domain,DC=com]
[27/Feb/2013:12:20:33 +1300] NSMMReplicationPlugin -
windows_generate_update_mods:
CN=students,ou=Groups,ou=Active,ou=People,dc=domain,dc=com, description : values
are equal
[27/Feb/2013:12:20:33 +1300] NSMMReplicationPlugin -
windows_generate_update_mods:
CN=students,ou=Groups,ou=Active,ou=People,dc=domain,dc=com, ntUserDomainId :
values are equal
[27/Feb/2013:12:20:33 +1300] NSMMReplicationPlugin -
windows_generate_update_mods: deleting uniquemember attribute from local entry
[27/Feb/2013:12:20:33 +1300] - smod - windows sync
[27/Feb/2013:12:20:33 +1300] - smod 0 - delete: uniquemember
The particularly interesting line is this
[27/Feb/2013:12:20:33 +1300] NSMMReplicationPlugin -
windows_generate_update_mods: deleting uniquemember attribute from local entry
This only appears to happen when the group contains more than 1500 entries.
Surely there must be someone else out there syncing groups with more than 1500
members between 389 and AD?
It wasn't until I used Apache Directory Studio to compare entries between the
389 server and the AD that I noticed the attribute name was represented
differently when the group contained over 1500 entries.
This is a result of the range retrieval limit in AD. When you hit the range
limit, the attribute name changes from "member" to "member;range=0-1499", which
causes the mismatch that leads to the uniquemember attribute being deleted.
In order to prevent this from happening, we have had to increase the MaxValRange
setting in our Active Directory as per http://support.microsoft.com/kb/2009267
and http://support.microsoft.com/kb/315071
The value defaults to 1500 for Windows Server 2003 or 5000 for Windows Server 2008.
Personally I consider this a bug in the AD sync plugin, as it fails to correctly
handle range retrieval. At the very least, the documentation for Windows Sync
should contain information about this limit.
David.
10 years, 9 months
389-console: tries to connect to localhost:389 instead of hostname:389
by Steffen
Hi,
I'm new to the 389 DS environment and this probably is some really
stupid mistake on my side, but I can't figure it out alone.
What I want: Connect to my server (Debian Wheezy) with the 389-console
What I got: A running (and working...well partially) 389-DS (no SSL/TLS!
).
What does work: I can login/access http://myservername.org:9830
What does not work: Accessing the same site via 389-console from a
remote host.
What happens when I try to connect with '389-console -a
http://myhostname.org:9830 -u cn=Directory Manager -w secret -D':
GUI: Changes to 'Initializing' then a message appears
"Cannot connect to the Directory Server "ldap://localhost:389.
LDAP error: failed to connect to server ldap://localhost:389.
Would you like to attempt to restart the Directory Server?"
(since I know that the server is running, I'm choosing 'No' which exits
the program)
Terminal output: http://pastebin.ca/2317259
Slapd-instancename/access log: http://pastebin.ca/2317260
The instance's error log has no new entries.
The content of admin-serv/access and admin-serv/error are only success
messages, no real errors.
If you need more informations, please ask.
10 years, 9 months
Which ports are used/needed by the admin console?
by Steffen
Hi,
another question: Which ports do I need to open/allow for the console to
work? Currently I've to disable my firewall rules to make it 'work',
else I get a timeout. The default port (3890) is allowed but that
doesn't seem to be enough.
10 years, 9 months
