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
MemberOf group restrictions to a client system (server and client running CentOS 7)
by Janet Houser
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-grou...)
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.
3 years, 4 months
ldapsearch doesn't return the userpassword field
by Janet Houser
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 years, 6 months
password not expire 389
by tuan88＠gmail.com
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 years, 9 months
passwordexpirationtime question
by xinhuan zheng
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
6 years, 9 months
Re: Need help to tune 389 DS
by Steve Holden
> -----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
6 years, 9 months
Need help to tune 389 DS
by wodel youchi
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 years, 9 months
elapsed time gremlin
by Winstanley, Anthony
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
6 years, 9 months
389 Roadmap?
by Ric
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.
6 years, 9 months
Replication Between RHDS 9 and RHDS 10
by Paul Whitney
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
6 years, 9 months
