389-users February 2013

389-users@lists.fedoraproject.org

26 participants
27 discussions

Problem browsing LDAP with Outlook
by Chris Bryant 26 Aug '20

26 Aug '20

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 2

389 Master - Master Replication
by Santos Ramirez 03 Oct '14

03 Oct '14

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.

3 9

invalid password syntax - passwords with storage scheme are not allowed
by Fosiul Alam 01 Mar '13

01 Mar '13

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

2 1

invalid password syntax - passwords with storage scheme are not allowed
by Fosiul Alam 28 Feb '13

28 Feb '13

1 0

389 and AD group sync
by Vesa Alho 28 Feb '13

28 Feb '13

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

2 3

MMR not working after upgrade to 8.2
by Chris Taylor 28 Feb '13

28 Feb '13

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

1 0

Add additional attributes to a Winsync agreement
by William_Darton＠navyfederal.org 28 Feb '13

28 Feb '13

3 3

AD sync problem for group with more than 1500 entries
by David Baird 27 Feb '13

27 Feb '13

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.

3 5

389-console: tries to connect to localhost:389 instead of hostname:389
by Steffen 27 Feb '13

27 Feb '13

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.

2 3

Which ports are used/needed by the admin console?
by Steffen 27 Feb '13

27 Feb '13

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.

2 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

389-users February 2013