389-users February 2017

389-users@lists.fedoraproject.org

17 participants
15 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

MemberOf group restrictions to a client system (server and client running CentOS 7)
by Janet Houser 06 Aug '20

06 Aug '20

Hi, I'm new to 389-ds and last week downloaded and installed the software. I have a running instance of the server, and I've added TLS/SSL. I've configured a CentOS 7 client to be able to query the server using TLS/SSL, and all appears working. I've created users and groups on the 389-ds server successfully. For each user and group, I've enabled posix attributes and my client can see the unix users and groups using the "getent password" or "getent group" commands. Now, here's where I'm getting tripped up.......... I need to limit which users have access to which systems. I've been trying to do this via memberOf group limitations. I found the following online resource (https://thornelabs.net/2013/01/28/aix-restrict-server-login-via-ldap-groups…) which is close enough to CentOS that the initial commands worked. I enabled the MemberOf plugin and changed the attributes per the link, and restarted the system. I created a test group (that I didn't enable a posix GID) and tried to add a single user via: Right click on group -- > click Properties --> then Members --> click Add --> Search for user --> click Add. When I try to go this route (which worked before enabling the memberOf plugin) it worked. Now it seems I get the error: "Cannot save to directory server. netscape.ldap.LDAPException: error resiult(65): Object class violation" And the messages file throws the error (/var/log/dirsrv/slapd-<instancename>/errors: "Entry "uid=test,ou=People,dc=int,dc=com" -- attribute "memberOf" not allowed [17/Feb/2016:11:22:58 -0700] memberof-plugin - memberof_postop_modify: failed to add dn (cn=testgroup,ou=Groups,dc=int,dc=com) to target. Error (65)" So it seems my server isn't quite using the memberOf plugin properly, but I'm not sure what else to enable. I'll have to solve this issue before I even try to filter login access via groups on my client system. I should mention that if I go under the advanced tab for one of the groups I created, I can add the the attribute "uniquemember", but I'm not sure what I should set the "value" to be. I've tried creating new users to see if I could set their "uniquemember" attributes, but no luck. It seems that I don't have the ability to set this attribute on individual users, only groups. This might not be the right road to head down when trying to restrict access to servers via groups, so I'm open to any suggestions. Any suggestions would be appreciated.

6 19

ldapsearch doesn't return the userpassword field
by Janet Houser 14 May '18

14 May '18

Hi, 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-1.3.4.0) 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. Thanks,

5 12

password not expire 389
by tuan88＠gmail.com 06 Mar '17

06 Mar '17

Hi with the new 1.2.2-1 389* the user can resure the same password Again & Again, the passwordhistory stop to Work and not showing anymore. see my test below. It is the first time i get this kind of issue [root@centos6 ~]# rpm -qa|grep 389 389-console-1.1.7-1.el6.noarch 389-adminutil-1.1.19-1.el6.x86_64 389-ds-console-1.2.6-1.el6.noarch 389-ds-1.2.2-1.el6.noarch 389-ds-base-libs-1.2.11.15-85.el6_8.x86_64 389-admin-1.1.35-1.el6.x86_64 389-admin-console-1.1.8-1.el6.noarch 389-ds-base-1.2.11.15-85.el6_8.x86_64 [root@centos6 scripts]# cat test_passwd_history.ksh #!/bin/ksh #Ldap test passwd if it is expired or not - tng 20170226 ldapsearch -xLLL -ZZ -b dc=nnit '(&(uid=tnng))' passwordRetryCount passwordExpWarned accountUnlockTime passwordExpirationTime passwordHistory createtimestamp modifytimestamp retryCountResetTime passwordAllowChangeTime nsRoleDN ldappasswd -s 123 -w 12345678 -x -ZZ -D cn='directory manager' cn='Tuan Nguyen,cn=unixtek,ou=Infrastructure,dc=nnit' [root@centos6 scripts]# ./test_passwd_history.ksh dn: cn=Tuan Nguyen,cn=unixtek,ou=Infrastructure,dc=nnit passwordExpWarned: 0 passwordExpirationTime: 19700101000000Z createtimestamp: 20170114110541Z modifytimestamp: 20170226085143Z [root@centos6 scripts]# ./test_passwd_history.ksh dn: cn=Tuan Nguyen,cn=unixtek,ou=Infrastructure,dc=nnit passwordExpWarned: 0 passwordExpirationTime: 19700101000000Z createtimestamp: 20170114110541Z modifytimestamp: 20170226091223Z [root@centos6 scripts]# ./test_passwd_history.ksh dn: cn=Tuan Nguyen,cn=unixtek,ou=Infrastructure,dc=nnit passwordExpWarned: 0 passwordExpirationTime: 19700101000000Z createtimestamp: 20170114110541Z modifytimestamp: 20170226091224Z [root@centos6 scripts]# policy [root@centos6 scripts]# ldapsearch -xLLL -ZZ -b cn='cn\3DnsPwPolicyEntry\2Cou\3DInfrastructure\2Cdc\3Dnnit,cn=nsPwPolicyContainer,ou=Infrastructure,dc=nnit' -s base '(&(objectclass=passwordpolicy))' dn: cn=cn\3DnsPwPolicyEntry\2Cou\3DInfrastructure\2Cdc\3Dnnit,cn=nsPwPolicyCon tainer,ou=Infrastructure,dc=nnit passwordStorageScheme: ssha passwordGraceLimit: 1 passwordChange: on passwordWarning: 86400 passwordMinAge: 0 passwordExp: on passwordMustChange: on passwordMaxAge: 86400 objectClass: ldapsubentry objectClass: passwordpolicy objectClass: top cn: cn=nsPwPolicyEntry,ou=Infrastructure,dc=nnit Policy settings from GUI: www.chezmoi.dk/389-passwd-not-expire.png

6 23

passwordexpirationtime question
by xinhuan zheng 28 Feb '17

28 Feb '17

Hello, I have setup password policy for user account to enforce a few things: passwordchange: on passwordchecksyntax: on passwordexp: on passwordlockout: on passwordlockoutduration: 180 passwordmaxage: 7 passwordmaxfailure: 3 passwordmustchange: on passwordwarning: 518400 With that policy on a user account, I changed one user's password from 389 console. It basically resets user's password. When user login, user gets "Password expired. Change your password now." prompt. The user goes through prompt to change the password. Then user gets login shell successfully. User then logout. Next time when user login again, the user still gets "Password expired. Change your password now." prompt. It appears 'passwordexpirationtime' attribute is set to the very first time when user changed password, but never set to password change time + 7 days, as the policy is configured. What went wrong in my previous procedure? How do I get passwordexpirationtime set to correct time when user change their password from administrative reset? Thanks, - xinhuan

2 2

Re: Need help to tune 389 DS
by Steve Holden 24 Feb '17

24 Feb '17

> -----Original Message----- > From: Mark Reynolds [mailto:mareynol@redhat.com] > Sent: 23 February 2017 16:00 > To: General discussion list for the 389 Directory server project. <389- > users(a)lists.fedoraproject.org> > Subject: [389-users] Re: Need help to tune 389 DS > > On 02/23/2017 10:48 AM, Gordon Messmer wrote: > > On 02/23/2017 12:11 AM, William Brown wrote: > >> As Noriko pointed you, you are missing nsIndexType: pres on this > > > > I hate to repeat myself, but is that a thing that changed *recently*? > No, it has always only been indexed for "eq". > > As Rich said, having a "pres" index on objectclass is redundant(and > wasteful). Every entry has objectclass - so if this was indexed for > "presence" it could actually create overhead. It's faster to read > directly from the DB, or candidate list, than trying to use an index > that contains every entry anyway. Hi, folks We've seen similar problems (and weren't sure whether the objectClass issues were part of broader indexing issues - more on that separately). We discourage the use of '(objectClass=*)' as a (partial) filter for precisely the reason Mark mentions - but one of our applications is hard-coded to use it, and our monitoring tools are highlighting that searches which contain that *partial* filter are being logged as partially unindexed: conn=3921153 op=1 SRCH base="ou=people,dc=brighton,dc=ac,dc=uk" scope=2 filter="(&(objectClass=*)(uid=USERNAME))" attrs=ALL conn=3921153 op=1 RESULT err=0 tag=101 nentries=1 etime=0 notes=U Would you recommend we just ignore these warnings? And am I right in assuming you wouldn't recommend adding 'nsIndexType: pres' to 'cn=objectclass,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config' as it wouldn't actually improve performance? (and would just generate a 1:1 map of every entry!) Out of interest, is there a reason why a filter which *only* includes 'objectClass=*' doesn't do that...? conn=3914283 op=1 SRCH base="uid=USERNAME,ou=People,dc=brighton,dc=ac,dc=uk" scope=0 filter="(objectClass=*)" attrs=ALL conn=3914283 op=1 RESULT err=0 tag=101 nentries=1 etime=0 Or is that just because in this case the base is the uid (not the branch above it)? Best wishes, Steve ___________________________________________________________ This email has been scanned by MessageLabs' Email Security System on behalf of the University of Brighton. For more information see: https://staff.brighton.ac.uk/is/computing/Pages/Email/spam.aspx

3 2

Need help to tune 389 DS
by wodel youchi 23 Feb '17

23 Feb '17

Hi, We have a simple installation of 389DS, a master/slave installation. Our directory server is mainly used with our mail and portal servers for now. We did create some custom attributes for our needs. Here is a simple entry model : *uid=lastname.firstname,ou=People,dc=domain;dc=tlddn: uid=lastname.firstname,ou=People,dc=domain,dc=tldou: SUPPORT TEAMrecruitmentDate: 20030510mailQuota: 2048576000 <%28204%29%20857-6000>teletexTerminalIdentifier: 3053maidenName: MaindeNameemployeeNumber: 28813gender: FdepartmentNumber: 1121employeeType: SmailAlternateAddress: f.lastname(a)domain.tlddisplayName: Lastname Firstnamemail: lastname.firstname(a)domain.tldjobTitle: Supervisorsn: Firstnamecn: LastnameobjectClass: topobjectClass: personobjectClass: organizationalPersonobjectClass: inetorgpersonobjectClass: shadowAccountobjectClass: mailrecipientobjectClass: customprofilemailMessageStore: /var/vmail/lastname.firstnameuid: lastname.firstnamemailHost: mail.domain.tldtitle: MuserPassword:: e1NIQX02TjBCaXpjcWRkNVJCUXlyVHV6TDlwT1NGK3c9* *webtelxmail : f.lastname(a)telex.domain.tld* We run logconv against our directory Server and we get a pretty long result file, with some recommendations, but we don't know how proceed, especially with indexes. we have many entries like these * Unindexed Search #32105 (notes=A) - Date/Time: 13/Jan/2017:01:21:49 - Connection Number: 434118 - Operation Number: 74292 - Etime: 0 - Nentries: 0 - IP Address: 172.16.16.9 - Search Base: ou=people,dc=domain,dc=tld - Search Scope: 2 (subtree) - Search Filter: (&(null=uid=lastname.lastname,ou=people,dc=domain,dc=tld)) - Bind DN: cn=directory manager* *Unindexed Search #76240 (notes=A) - Date/Time: * *13/Jan/2017:00:16:55 - Connection Number: 433231 - Operation Number: 205936 - Etime: 0 - Nentries: 0 - IP Address: Unknown_Host - Search Base: ou=people,* *dc=domain,dc=tld - Search Scope: 2 (subtree) - Search Filter: (&(null=uid=lastname2.firstname2,ou=people,* *dc=domain,dc=tld))Unindexed Component #1 (notes=U) - Date/Time: * *13/Jan/2017:00:01:19 - Connection Number: 433951 - Operation Number: 1 - Etime: 0 - Nentries: 0 - IP Address: 172.16.16.1 - Search Base: ou=people,* *dc=domain,dc=tld - Search Scope: 2 (subtree) - Search Filter: (&(objectclass=*)(uid=pat)) - Bind DN: uid=dovecot,**dc=domain,dc=tld* In the end of the result file we got this : In the end of the result file we got this : FDs Taken: 573 FDs Returned: 569 Highest FD Taken: 81 Broken Pipes: 0 Connections Reset By Peer: 0 Resource Unavailable: 235 - 235 (T1) Idle Timeout Exceeded Max BER Size Exceeded: 0 Binds: 4627 Unbinds: 45 - LDAP v2 Binds: 24 - LDAP v3 Binds: 4603 - AUTOBINDs: 0 - SSL Client Binds: 0 - Failed SSL Client Binds: 0 - SASL Binds: 0 - Directory Manager Binds: 4 - Anonymous Binds: 24 - Other Binds: 4599 ----- Connection Latency Details ----- (in seconds) <=1 2 3 4-5 6-10 11-15 >15 -------------------------------------------------------------------------- (# of connections) 250 8 3 5 55 4 244 ----- Current Open Connection IDs ----- Conn Number: 434505 (172.16.16.8) Conn Number: 434171 (172.16.16.9) Conn Number: 434506 (172.16.16.8) Conn Number: 434301 (172.16.16.9) Conn Number: 434150 (172.16.16.9) Conn Number: 434118 (172.16.16.9) Conn Number: 434507 (172.16.16.8) Conn Number: 434508 (172.16.16.8) Conn Number: 434504 (172.16.16.8) ----- Errors ----- err=0 295657 Successful Operations err=32 627 No Such Object err=49 44 Invalid Credentials (Bad Password) err=4 24 Size Limit Exceeded err=11 6 Administrative Limit Exceeded (Look Through Limit) ----- Top 10 Failed Logins ------ 12 uid=lastname.firstname,ou=people,dc=domain,dc=tld 12 uid=admin,ou=people,dc=domain,dc=tld 8 uid=lastname10.firstname10,ou=people,dc=domain,dc=tld 4 uid=lastname11.firstname11,ou=people,dc=domain,dc=tld 3 uid=lastname12.firstname12,ou=people,dc=domain,dc=tld 3 uid=lastname13.firstname13,ou=people,dc=domain,dc=tld 2 uid=dakar,ou=people,dc=domain,dc=tld From the IP address(s) : 32 Unknown_Host 12 172.16.16.1 ----- Total Connection Codes ----- B1 289 Bad Ber Tag Encountered T1 235 Idle Timeout Exceeded U1 45 Cleanly Closed Connections ----- Top 10 Clients ----- Number of Clients: 4 [1] Client: 172.16.16.8 308 - Connections 235 - T1 (Idle Timeout Exceeded) 68 - B1 (Bad Ber Tag Encountered) [2] Client: 172.16.16.1 221 - Connections 221 - B1 (Bad Ber Tag Encountered) [3] Client: 172.16.16.14 24 - Connections 24 - U1 (Cleanly Closed Connections) [4] Client: 172.16.16.9 20 - Connections 16 - U1 (Cleanly Closed Connections) ----- Top 10 Bind DN's ----- Number of Unique Bind DN's: 368 529 uid=dovecot,dc=domain,dc=tld 242 uid=helpdesk-ventes,ou=people,dc=domain,dc=tld 182 uid=helpdesk,ou=people,dc=domain,dc=tld 161 uid=lastname.firstname,ou=people,dc=domain,dc=tld 122 uid=lastname2.firstname2,ou=people,dc=domain,dc=tld 121 uid=lastname3.firstname3,ou=people,dc=domain,dc=tld 120 uid=lastname4.firstname4,ou=people,dc=domain,dc=tld 119 uid=lastname5.firstname5,ou=people,dc=domain,dc=tld 110 uid=lastname6.firstname6,ou=people,dc=domain,dc=tld 110 uid=lastname7.firstname7,ou=people,dc=domain,dc=tld ----- Top 10 Search Bases ----- Number of Unique Search Bases: 7628 192079 ou=people,dc=domain,dc=tld 352 uid=postmaster,ou=people,dc=domain,dc=tld 254 uid=helpdesk-ventes,ou=people,dc=domain,dc=tld 208 uid=helpdesk,ou=people,dc=domain,dc=tld 173 uid=lastname20.firstname20,ou=people,dc=domain,dc=tld 145 uid=lastname21.firstname21,ou=people,dc=domain,dc=tld 136 uid=lastname22.firstname22,ou=people,dc=domain,dc=tld 133 uid=lastname23.firstname23,ou=people,dc=domain,dc=tld 132 uid=lastname24.firstname24,ou=people,dc=domain,dc=tld 123 uid=lastname25.firstname25,ou=people,dc=domain,dc=tld ----- Top 10 Search Filters ----- Number of Unique Search Filters: 15887 95285 (objectclass=*) 456 (&(|(mail=domain.tld)(mailalternateaddress=domain.tld))(objectclass=inetorgperson)) 352 (&(|(mail=postmaster(a)domain.tld )(mailalternateaddress=postmaster(a)domain.tld))(objectclass=inetorgperson)) 242 (&(|(mail=helpdesk-ventes(a)domain.tld )(mailalternateaddress=helpdesk-ventes(a)domain.tld ))(objectclass=inetorgperson)) 224 (&(|(mail=helpdesk(a)domain.tld )(mailalternateaddress=helpdesk(a)domain.tld))(objectclass=inetorgperson)) 161 (&(|(mail=lastname22.firstname22(a)domain.tld )(mailalternateaddress=lastname22.firstname22(a)domain.tld ))(objectclass=inetorgperson)) 161 (&(|(mail=lastname10.firstname10(a)domain.tld )(mailalternateaddress=lastname10.firstname10(a)domain.tld ))(objectclass=inetorgperson)) 153 (&(|(mail=lastname15.firstname15(a)domain.tld )(mailalternateaddress=lastname15.firstname15(a)domain.tld ))(objectclass=inetorgperson)) ----- Top 10 Most Frequent etimes ----- 286125 etime=0 10227 etime=1 6 etime=2 ----- Top 10 Longest etimes ----- etime=2 6 etime=1 10227 etime=0 286125 ----- Top 10 Largest nentries ----- nentries=7622 12 nentries=13 1 nentries=10 1 nentries=6 1 nentries=1 194973 nentries=0 96743 ----- Top 10 Most returned nentries ----- 194973 nentries=1 96743 nentries=0 12 nentries=7622 1 nentries=13 1 nentries=6 1 nentries=10 ----- Top 10 Most Requested Attributes ----- 194890 mailQuota 96898 mail 95504 uid 95267 displayName 95267 sn 95261 createTimestamp 95261 creatorsName 95261 employeeType 95261 modifyTimestamp 95261 ou ----- Abandon Request Stats ----- - UNKNOWN conn=433250 op=NOTFOUND msgid=102278 client=Unknown_Host - UNKNOWN conn=433250 op=NOTFOUND msgid=102667 client=Unknown_Host - UNKNOWN conn=433250 op=NOTFOUND msgid=89071 client=Unknown_Host - UNKNOWN conn=434150 op=NOTFOUND msgid=26399 client=172.16.16.9 - UNKNOWN conn=434150 op=NOTFOUND msgid=50332 client=172.16.16.9 - UNKNOWN conn=434150 op=NOTFOUND msgid=54880 client=172.16.16.9 - UNKNOWN conn=433250 op=NOTFOUND msgid=88929 client=Unknown_Host - UNKNOWN conn=434150 op=NOTFOUND msgid=13986 client=172.16.16.9 - UNKNOWN conn=434150 op=NOTFOUND msgid=21519 client=172.16.16.9 - UNKNOWN conn=434150 op=NOTFOUND msgid=35708 client=172.16.16.9 - UNKNOWN conn=434150 op=NOTFOUND msgid=43639 client=172.16.16.9 - UNKNOWN conn=434150 op=NOTFOUND msgid=44806 client=172.16.16.9 ----- Recommendations ----- 1. You have unindexed searches, this can be caused from a search on an unindexed attribute, or your returned results exceeded the allidsthreshold. Unindexed searches are not recommended. To refuse unindexed searches, switch 'nsslapd-require-index' to 'on' under your database entry (e.g. cn=UserRoot,cn=ldbm database,cn=plugins,cn=config). 2. You have unindexed components, this can be caused from a search on an unindexed attribute, or your returned results exceeded the allidsthreshold. Unindexed components are not recommended. To refuse unindexed searches, switch 'nsslapd-require-index' to 'on' under your database entry (e.g. cn=UserRoot,cn=ldbm database,cn=plugins,cn=config). 3. You have some connections that are are being closed by the idletimeout setting. You may want to increase the idletimeout if it is set low. 4. You have a significant difference between binds and unbinds. You may want to investigate this difference. 5. You have more abnormal connection codes than cleanly closed connections. You may want to investigate this difference. Cleaning up temp files... Done. Any advice on how to interpret all this data? Can these problems slow users connection? Could someone point us to how improve our directory server. If you need more info let me know. Thanks in advance.

6 9

elapsed time gremlin
by Winstanley, Anthony 17 Feb '17

17 Feb '17

Hi, I'm hoping somebody can tell me where I might look to find why this is happening... We're running 389-Directory/1.2.11.15 B2014.300.2010 I have two ldapsearch queries that only vary in searchbase, one which is taking too long. (Times don't vary much with consecutive executions.) ou=PEOPLE has just under 700,000 entries. Search takes 0-3 seconds. ou=STUDENTS,ou=RECORDS has just under 6000 entries. Search takes 123-126 seconds. There are no attributes used in ou=STUDENTS,ou=RECORDS that aren't also used in ou=PEOPLE. Two sample executions and log output: [user@workstation ~]$ ldapsearch -x -LLL -H ldaps://ldap.example.com:636 -b ou=STUDENTS,ou=RECORDS,dc=example,dc=com -D cn=Directory\ Manager -w password -s one -z 5 'cn=*' dn ... 5 entries returned ... [user@workstation ~]$ [root@server slapd-ldap1]# grep conn=33505 access [16/Feb/2017:16:31:37] conn=33505 fd=96 slot=96 SSL connection from IP1 to IP2 [16/Feb/2017:16:31:37] conn=33505 SSL 256-bit AES [16/Feb/2017:16:31:37] conn=33505 op=0 BIND dn="cn=Directory Manager" method=128 version=3 [16/Feb/2017:16:31:37] conn=33505 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="cn=directory manager" [16/Feb/2017:16:31:37] conn=33505 op=1 SRCH base="ou=STUDENTS,ou=RECORDS,dc=example,dc=com" scope=1 filter="(cn=*)" attrs="distinguishedName" [16/Feb/2017:16:33:40] conn=33505 op=1 RESULT err=4 tag=101 nentries=5 etime=123 notes=A [16/Feb/2017:16:33:40] conn=33505 op=2 UNBIND [16/Feb/2017:16:33:40] conn=33505 op=2 fd=96 closed - U1 [root@server slapd-ldap1]# [user@workstation ~]$ ldapsearch -x -LLL -H ldaps://ldap.example.ca:636 -b ou=PEOPLE,dc=example,dc=com -D cn=Directory\ Manager -w password -s one -z 5 'cn=*' dn ... 5 entries returned ... [user@workstation ~]$ [root@server slapd-ldap1]# grep conn=33578 access [16/Feb/2017:16:38:43] conn=33578 fd=96 slot=96 SSL connection from 142.103.30.27 to 10.7.128.16 [16/Feb/2017:16:38:44] conn=33578 SSL 256-bit AES [16/Feb/2017:16:38:44] conn=33578 op=0 BIND dn="cn=Directory Manager" method=128 version=3 [16/Feb/2017:16:38:44] conn=33578 op=0 RESULT err=0 tag=97 nentries=0 etime=1 dn="cn=directory manager" [16/Feb/2017:16:38:44] conn=33578 op=1 SRCH base="ou=PEOPLE,dc=example,dc=com" scope=1 filter="(cn=*)" attrs="distinguishedName" [16/Feb/2017:16:38:44] conn=33578 op=1 RESULT err=4 tag=101 nentries=5 etime=0 notes=A [16/Feb/2017:16:38:44] conn=33578 op=2 UNBIND [16/Feb/2017:16:38:44] conn=33578 op=2 fd=96 closed - U1 [root@server slapd-ldap1]# Help? This is driving me nuts... Where can I look to find out why this might be happening? Thanks, Anthony

4 6

389 Roadmap?
by Ric 15 Feb '17

15 Feb '17

Hi All, I am aware that RHDS9 goes EoL in March. As I understand it, 389 is effectively upstream of RHDS and thus not directly affected. However, is there a similar roadmap for 389 please? i.e. is there a forecast time when yum-upgrade will no longer get the latest patches and fixes for 389 and a new install/upgrade/migration will be required? Many thanks. Regards, Ric.

3 4

Replication Between RHDS 9 and RHDS 10
by Paul Whitney 15 Feb '17

15 Feb '17

Hi everyone, I am currently testing RHDS 10 and have successfully initialized/replicated from RHDS 9 to RHDS 10. Can I do the reverse? Replicate from RHDS 10 to RHDS 9? Paul M. Whitney E-mail: paul.whitney(a)mac.com

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 2017