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, 9 months
changelog
by Denise Cosso
Hi,
How to modify the attribute nsslapd-encryptionalgorithm in Centos?
Thanks,
Denise
Stop Master servers and set nsslapd-encryptionalgorithm. The allowed value is AES or 3DES.
dn: cn=changelog5,cn=config
[...]
nsslapd-encryptionalgorithm: AES
--- Em ter, 4/6/13, Rich Megginson <rmeggins(a)redhat.com> escreveu:
De: Rich Megginson <rmeggins(a)redhat.com>
Assunto: Re: [389-users] changelog
Para: "Denise Cosso" <guanaes51(a)yahoo.com.br>
Data: Terça-feira, 4 de Junho de 2013, 16:34
On 06/04/2013 01:26 PM, Denise Cosso
wrote:
Hi, Rich
CentOS release 6.3 (Final)
389-ds-base-libs-1.2.10.2-20.el6_3.x86_64
389-ds-1.2.2-1.el6.noarch
389-dsgw-1.1.10-1.el6.x86_64
389-ds-console-1.2.6-1.el6.noarch
389-ds-console-doc-1.2.6-1.el6.noarch
389-ds-base-1.2.10.2-20.el6_3.x86_64
As far as replication goes - you will need to use a security layer
(SSL, TLS, or GSSAPI) to protect the clear text password on the wire
As far as encrypting it in the changelog - not sure
Denise
--- Em ter, 4/6/13, Rich Megginson <rmeggins(a)redhat.com>
escreveu:
De: Rich Megginson <rmeggins(a)redhat.com>
Assunto: Re: [389-users] changelog
Para: "General discussion list for the 389 Directory
server project."
<389-users(a)lists.fedoraproject.org>
Cc: "Denise Cosso" <guanaes51(a)yahoo.com.br>
Data: Terça-feira, 4 de Junho de 2013, 16:11
On
06/04/2013 12:39 PM, Denise Cosso wrote:
Hi,
Description of problem:
When a userPassword is changed in a server with changelog, the hashed password
is logged and also a cleartext pseudo-attribute version. It looks like this:
change::
replace: userPassword
userPassword: {SHA256}vqtiN2LHdrEUOJUKu+IBVqAVFsAlvFw+11kD/Q==
-
replace: unhashed#user#password
unhashed#user#password: secret12
This unhashed version is used in winsync where the cleartext version of the
password must be written to the AD.
Now if the DS is involved in replication with another DS, the change will be
replayed exactly as it is logged to the other DS replicas, including the
cleartext pseudo-attribute password.
What platform? What version of 389-ds-base are you
using?
thanks,
Denise
--
389 users mailing list
389-users(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
9 years, 1 month
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, 8 months
bind fails with err=32 until binding object is queried
by Jesse Defer
I have a multi-master 389 directory setup, two are 1.2.11.25 (RHEL5) and
two are 1.2.11.15 (RHEL6). The RHEL5 servers have been running for
years without issue, while we recently created the RHEL6 servers and
initialized them from the existing ones. One of the .15 servers
exhibits a strange issue where I can't bind as a user (err=32) until I
first search for the user. Every time I restart it I have to perform a
search otherwise none of my users can bind. Any suggestions?
Occasionally I get these errors on all 4 of the servers, but nothing
else:
[28/May/2014:16:39:43 -0700] _entry_set_tombstone_rdn - Failed to
convert DN uid=myuserid to RDN
[28/May/2014:16:39:43 -0700] id2entry - str2entry returned NULL for id
11, string="rdn"
Example of failure:
# ldapsearch -x -h localhost -D
"uid=myuserid,ou=ReadOnly,o=mydomain.edu" -w 'xxxxxx' -b
"o=mydomain.edu" uid=myuserid
ldap_bind: No such object (32)
matched DN: ou=ReadOnly,o=mydomain.edu
# ldapsearch -x -h localhost -b "o=mydomain.edu" "uid=myuserid"
# extended LDIF
#
# LDAPv3
# base <o=mydomain.edu> with scope subtree
# filter: uid=myuserid
# requesting: ALL
#
# search result
search: 2
result: 0 Success
# numResponses: 1
# ldapsearch -x -h localhost -D
"uid=myuserid,ou=ReadOnly,o=mydomain.edu" -w 'xxxxxx' -b
"o=mydomain.edu" uid=myuserid
# extended LDIF
#
# LDAPv3
# base <o=mydomain.edu> with scope subtree
# filter: uid=myuserid
# requesting: ALL
#
# myuserid, ReadOnly, mydomain.edu
dn: uid=myuserid,ou=ReadOnly,o=mydomain.edu
uid: myuserid
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
sn: myuserid
cn: myuserid
# search result
search: 2
result: 0 Success
# numResponses: 2
# numEntries: 1
Thanks,
Jesse DeFer
10 years
db2index Not Stopping
by Fong, Trevor
Hi Everyone,
Searches and any kind of access to a particular ou seem to be hanging (yep, even tried deleting it and it's children) so I ran db2index and left it running all night. It's still running 20 hours later - is that normal? If it's not, is it OK to kill the process? What would you recommend?
Here's the kind of output I'm getting:
[30/May/2014:07:46:27 -0700] - WARNING: Import is running with nsslapd-db-private-import-mem on; No other process is allowed to access the database
[30/May/2014:07:46:27 -0700] - reindex userRoot: Sweep done.
[30/May/2014:07:46:27 -0700] - reindex userRoot: Beginning pass number 210
[30/May/2014:07:46:47 -0700] - reindex userRoot: Processed 678827 entries (pass 210) -- average rate 214714423.4/sec, recent rate 0.0/sec, hit ratio 0%
[30/May/2014:07:47:07 -0700] - reindex userRoot: Processed 678827 entries (pass 210) -- average rate 107357211.7/sec, recent rate 0.0/sec, hit ratio 0%
[30/May/2014:07:47:27 -0700] - reindex userRoot: Processed 678827 entries (pass 210) -- average rate 71571474.5/sec, recent rate 0.0/sec, hit ratio 0%
[30/May/2014:07:47:47 -0700] - reindex userRoot: Processed 678827 entries (pass 210) -- average rate 53678605.9/sec, recent rate 0.0/sec, hit ratio 0%
[30/May/2014:07:48:08 -0700] - reindex userRoot: Processed 678827 entries (pass 210) -- average rate 42942884.7/sec, recent rate 0.0/sec, hit ratio 0%
[30/May/2014:07:48:28 -0700] - reindex userRoot: Processed 678827 entries (pass 210) -- average rate 35489987.3/sec, recent rate 0.0/sec, hit ratio 0%
[30/May/2014:07:48:48 -0700] - reindex userRoot: Processed 678827 entries (pass 210) -- average rate 30455946.6/sec, recent rate 0.0/sec, hit ratio 0%
[30/May/2014:07:49:08 -0700] - reindex userRoot: Processed 678827 entries (pass 210) -- average rate 26672599.2/sec, recent rate 0.0/sec, hit ratio 0%
[30/May/2014:07:49:28 -0700] - reindex userRoot: Processed 678827 entries (pass 210) -- average rate 23725350.7/sec, recent rate 0.0/sec, hit ratio 0%
[30/May/2014:07:49:48 -0700] - reindex userRoot: Processed 678827 entries (pass 210) -- average rate 21364619.2/sec, recent rate 0.0/sec, hit ratio 0%
[30/May/2014:07:50:08 -0700] - reindex userRoot: Processed 678827 entries (pass 210) -- average rate 19431169.5/sec, recent rate 0.0/sec, hit ratio 0%
[30/May/2014:07:50:28 -0700] - reindex userRoot: Processed 678827 entries (pass 210) -- average rate 17818624.4/sec, recent rate 0.0/sec, hit ratio 0%
[30/May/2014:07:50:48 -0700] - reindex userRoot: Processed 678827 entries (pass 210) -- average rate 16453212.5/sec, recent rate 0.0/sec, hit ratio 0%
[30/May/2014:07:51:08 -0700] - reindex userRoot: Processed 678827 entries (pass 210) -- average rate 15282165.4/sec, recent rate 0.0/sec, hit ratio 0%
[30/May/2014:07:51:28 -0700] - reindex userRoot: Processed 678827 entries (pass 210) -- average rate 14266739.1/sec, recent rate 0.0/sec, hit ratio 0%
[30/May/2014:07:51:28 -0700] - reindex userRoot: Decided to end this pass because the progress rate has dropped below the 50% threshold.
[30/May/2014:07:51:28 -0700] - reindex userRoot: Ending pass number 210 ...
[30/May/2014:07:51:28 -0700] - reindex userRoot: Foreman is done; waiting for workers to finish...
[30/May/2014:07:51:28 -0700] - reindex userRoot: Workers finished; cleaning up...
[30/May/2014:07:51:28 -0700] - reindex userRoot: Workers cleaned up.
[30/May/2014:07:51:28 -0700] - reindex userRoot: Sweeping files for merging later...
We're running 389-ds-base.x86_64 1.2.11.29-1.el6
Thanks a lot,
Trev
---------------------------------------------------------
Trevor Fong - Senior Programmer Analyst
Identity and Access Management Group
University of British Columbia - Information Technology
6356 Agricultural Road, Vancouver, BC, V6T 1Z2, Canada
Ph: (604) 827-5247
10 years
Retna Scan Results
by John Trump
I have a system running 389-ds that was scanned using retna. Retna showed
vulnerabilities which are fairly old. Can anyone confirm that these were
fixed. Only thing using port 9830 is the admin-serv. Below are the rpm
versions I have installed and the CVE's retna supposidly detected.
389-adminutil-1.1.19-1.el6.x86_64
389-ds-console-doc-1.2.6-1.el6.noarch
389-admin-1.1.35-1.el6.x86_64
389-admin-console-1.1.8-5.fc19.noarch
389-console-1.1.7-1.el6.noarch
389-ds-1.2.2-1.el6.noarch
389-ds-base-libs-1.2.11.25-1.el6.x86_64
389-ds-base-1.2.11.25-1.el6.x86_64
389-dsgw-1.1.11-1.el6.x86_64
389-ds-console-1.2.6-1.el6.noarch
389-admin-console-doc-1.1.8-5.fc19.noarch
Audit ID: 6310 Vul ID: N/A
Risk Level: Medium
Sev Code: Category II
PCI Level: Medium (Fail) - CVSS Score
CVSS Score: 5 [AV:N/AC:L/Au:N/C:N/I:N/A:P]
BugTraq ID 27234,26838,27236,27237
CVE: CVE-2008-0005,CVE-2007-6388,CVE-2007-6422,CVE-2007-64
20,CVE-2007-5000,CVE-2007-6421,CVE-2008-1678
CCE: N/A
Exploit: No
IAV: N/A
STIG:
Context: TCP:9830
Result: Success
Tested Value: BR T WB Server:
(Apache(\([[]^)]*\))?/((2\.((2(\.[[]0-7])?)|(0(\.([[]1-5]?[[]0-9]|6[[]0-2]))
?)|(1(\..*)?)))|(1\.((3(\.([[]1-3]?[[]0-9]|40))?)|([[]0-2](\..*)?)))|(0+\..*))
($|[[]^0-9.]([[]^(]*\([[]^R][[]^)]*\))*[[]^()]*$))
Found Value: Server: Apache/2.2##Content-Length: 301##Connection:
close##Content-Type: text/html;
charset[=]iso-8859-1####<!DOCTYPE HTML PUBLIC
"-//IETF//DTD HTML 2.0//EN">#<html><head>#<title>404 Not
Found</title>#</head><body>#<h1>Not Found</h1>
(truncated...)
Audit ID: 6059 Vul ID: N/A
Risk Level: Medium
Sev Code: Category II
PCI Level: Medium (Fail) - CVSS Score
CVSS Score: 5 [AV:N/AC:L/Au:N/C:P/I:N/A:N]
BugTraq ID 24215,24645,25489,24649,24553
CVE: CVE-2007-1862,CVE-2007-3847,CVE-2007-3304,CVE-2006-57
52,CVE-2007-1863
CCE: N/A
Exploit: No
IAV: N/A
STIG:
Context: TCP:9830
Result: Success
Tested Value: RR T WB
(Apache(\([[]^)]*\))?/(2\.2(\.[[]0-5])?)($|[[]^0-9.]([[]^(]*\([[]^R][[]^)]*\)
)*[[]^()]*$))
Found Value: Apache/2.2
Audit ID: 9820 Vul ID: N/A
Risk Level: Medium
Sev Code: Category II
PCI Level: High (Fail) - CVSS Score
CVSS Score: 7.8 [AV:N/AC:L/Au:N/C:N/I:N/A:C]
BugTraq ID 35565,35253,35623,35251,34663,35221,35115
CVE: CVE-2009-1891,CVE-2009-1955,CVE-2009-1191,CVE-2009-00
23,CVE-2009-1956,CVE-2009-1195,CVE-2009-1890
CCE: N/A
Exploit: Yes
IAV: N/A
STIG:
Context: TCP:9830
Result: Success
Tested Value: APACHE(-ADVANCEDEXTRANETSERVER)?/2\.2(\.(1[[]01]|[[]0
-9])(\.[[]0-9]+)*)?($|[[]^0-9.])
Found Value: APACHE/2.2
10 years
Password too similar to old one
by John Trump
I would like to relax the password policy for specific users to allow them
to modify passwords but use similar password to their old one. These are
"group" accounts and would like to allow password to be set to: password01
then allow password to be changed to password02. Currently this is not
allowed. I understand security risk etc in allowing this. I do want to keep
other password complexity and history settings.
Suggestions?
10 years
Re: [389-users] 389-users Digest, Vol 108, Issue 21
by David Partridge
Ok
David M. Partridge
Senior Identity Management and Security Engineer
Tangible Software | 2010 Corporate Ridge, #620<x-apple-data-detectors://0>
McLean, Virginia 22102<x-apple-data-detectors://0> |dpartridge(a)tangible.net<mailto:dpartridge@tangible.net>
Direct: 800-913-9901 x3001<tel:800-913-9901;3001> | Cell: 571-2<tel:571-286-9628>43-8044
Fax: 703-288-1226<tel:703-288-1226> | DCO Jabber:david.partridge2@chat.dco.dod.mil<mailto:david.partridge2@chat.dco.dod.mil>
CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information or otherwise be protected by law. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.
Sent from my iPhone
On May 28, 2014, at 8:24 PM, "389-users-request(a)lists.fedoraproject.org<mailto:389-users-request@lists.fedoraproject.org>" <389-users-request(a)lists.fedoraproject.org<mailto:389-users-request@lists.fedoraproject.org>> wrote:
Send 389-users mailing list submissions to
389-users(a)lists.fedoraproject.org<mailto:389-users@lists.fedoraproject.org>
To subscribe or unsubscribe via the World Wide Web, visit
https://admin.fedoraproject.org/mailman/listinfo/389-users
or, via email, send a message with subject or body 'help' to
389-users-request(a)lists.fedoraproject.org<mailto:389-users-request@lists.fedoraproject.org>
You can reach the person managing the list at
389-users-owner(a)lists.fedoraproject.org<mailto:389-users-owner@lists.fedoraproject.org>
When replying, please edit your Subject line so it is more specific
than "Re: Contents of 389-users digest..."
<Today's Topics (6 messages)>
<mime-attachment>
<mime-attachment>
<mime-attachment>
<mime-attachment>
<mime-attachment>
<mime-attachment>
<Digest Footer>
10 years
