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
authenticated time stamp
by Chase Miller
Hello 389 Group,
Is there an object class/attribute that I can add to a user's entry that
will capture their last authenticated time stamp. I want to capture this
so I can go delete users that have not authenticated after so many days.
Chase
9 years
Connections hanging for unindexed searches
by Gerd Keßler
Hello,
doing an unindexed search with filter (uid=*ab*) the connection hang until the 389 Directory Server closes the connection after a long time (40 minutes or more) with error 11 (Resource temporarily unavailable).
After setting nsslapd-errorlog-level to 1 the following output was written to the error log:
389-Directory/1.3.3.10 B2015.141.1211
...
[30/May/2015:16:34:57 +0200] id2entry - => id2entry(498)
[30/May/2015:16:34:57 +0200] id2entry - <= id2entry 34c1510, dn "uid=kenz,ou=people,dc=ukl,dc=uni-freiburg,dc=de" (cache)
[30/May/2015:16:34:57 +0200] id2entry - <= id2entry( 498 ) 34c1510 (disk)
[30/May/2015:16:34:57 +0200] - re_exec (kenz) 0
[30/May/2015:16:34:57 +0200] id2entry - => id2entry(499)
[30/May/2015:16:34:57 +0200] id2entry - <= id2entry 19752c0, dn "uid=martens,ou=people,dc=ukl,dc=uni-freiburg,dc=de" (cache)
[30/May/2015:16:34:57 +0200] id2entry - <= id2entry( 499 ) 19752c0 (disk)
[30/May/2015:16:34:57 +0200] - --> pagedresults_is_timedout
[30/May/2015:16:34:57 +0200] - <-- pagedresults_is_timedout: -
[30/May/2015:16:34:57 +0200] - re_exec (martens) 0
[30/May/2015:16:34:57 +0200] id2entry - => id2entry(500)
[30/May/2015:16:34:57 +0200] id2entry - <= id2entry 7f0c5c3711b0, dn "uid=martinj,ou=people,dc=ukl,dc=uni-freiburg,dc=de" (cache)
[30/May/2015:16:34:57 +0200] id2entry - <= id2entry( 500 ) 7f0c5c3711b0 (disk)
[30/May/2015:16:34:57 +0200] - re_exec (martinj) 0
[30/May/2015:16:34:57 +0200] - --> pagedresults_is_timedout
[30/May/2015:16:34:57 +0200] - <-- pagedresults_is_timedout: -
[30/May/2015:16:34:58 +0200] - --> pagedresults_is_timedout
[30/May/2015:16:34:58 +0200] - <-- pagedresults_is_timedout: -
[30/May/2015:16:34:58 +0200] - --> pagedresults_is_timedout
[30/May/2015:16:34:58 +0200] - <-- pagedresults_is_timedout: -
...
nsslapd-lookthroughlimit was set to 500. After looking through 500 entries the 389 Directory Server stopped looking through the entries and called "pagedresults_is_timedout" for a long time (40 minutes or more).
Why does the 389 Directory Server not sent an error message and disconnects immediately?
Kind regards
Gerd
-----------------------------------------------------------------------------
UNIVERSITAETSKLINIKUM FREIBURG
Klinikrechenzentrum
Agnesen-Strasse 6-8, 79106 Freiburg
Telefon +49 761 270 22900 / Fax +49 761 270 20660
gerd.kessler(a)uniklinik-freiburg.de
http://www.uniklinik-freiburg.de
9 years
Odd Replication Behavior
by Dustin Rice
Hello folks, I'm running Centos 6 LDAP masters/replicas in a multi master
setup. I am running the latest version of 389ds available through EPEL
(389-Directory/1.2.11.15 B2014.314.1342).
So what I am seeing is an issue with the attributes: shadowFlag,
shadowWarning, shadowMin, shadowMax, shadowLastChange, shadowExpire
My issue is that if I add or change these values, they replicate down as
one would expect. If I, however, delete the attributes, this change does
*not* get replicated. It does not get replicated to the other master nor
any replicas.
I have tried to re-initialize one of my replicas, but the issue persists.
I'm not really seeing anything too out of the ordinary in the logs. I
enabled replication debug logging and the log blocks seem the same when an
attr is changed (replication works as expected) and when an attr is deleted
(seems to not work as expected).
It seems that any other attributes I tried behave as I would expect.
Thoughts?
9 years
grant access to get effective rights
by William
Hi,
Reading [0] and [1] I can't seem to find how to grant an object the
right to execute the getEffectiveRights extended operation. At this
time I seem to only be able to carry this out with Directory Manager.
What aci is needed to allow some groupdn access to the GER operation?
[0]
https://access.redhat.com/documentation/en
-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Viewing_the_
ACIs_for_an_Entry-Get_Effective_Rights_Control.html
[1]
https://access.redhat.com/documentation/en
-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_Acc
ess_Control.html#Managing_Access_Control-Access_Control_Principles
--
William <william(a)firstyear.id.au>
9 years
389 ds as main object for storage all users
by Carlos Raúl Laguna
Hello everyone,
It would be possible to create a scenario where 389 ds became a box for all
users through winsync and replication,We have some users in Windows AD and
some other in Freeipa, however we are looking a way to put together all the
user in one place 389 DS, (just the users) to create a single email system
for all users. Any input will be appreciated. Regards
9 years
389-console
by Ldap Tester
I would like to return to a problem that I have had since I first posted
about it on Feb 29, 2012, and which was never resolved. I have been
successfully running 2 FDS multi-masters since I installed them in ~2007,
and which have been updated ever since with yum. My current package set is:
389-admin-1.1.38-1.fc21.x86_64
389-admin-console-1.1.8-7.fc21.noarch
389-admin-console-doc-1.1.8-7.fc21.noarch
389-adminutil-1.1.21-1.fc21.x86_64
389-console-1.1.7-7.fc21.noarch
389-ds-1.2.2-6.fc21.noarch
389-ds-base-1.3.3.8-1.fc21.x86_64
389-ds-base-devel-1.3.3.8-1.fc21.x86_64
389-ds-base-libs-1.3.3.8-1.fc21.x86_64
389-ds-console-1.2.7-4.fc21.noarch
389-ds-console-doc-1.2.7-4.fc21.noarch
389-dsgw-1.1.11-4.fc21.x86_64
The directory service is working fine. I use it only to authenticate user
logins on ~dozen fedora clients. I can run 389-console on one of the
masters, but not the other. I used to be able to run it before 2012. Now
when I run 389-console and log in, I get:
Cannot connect to the directory server:
netscape.ldap.LDAPException: error result (32): No such object
I tried running setup-ds-admin.pl -u, but it yields:
Configuration directory server URL [ldap://XXXX.org:389/o%3DNetscapeRoot]:
Configuration directory server admin ID [uid=admin, ou=Administrators,
ou=TopologyManagement, o=NetscapeRoot]:
Configuration directory server admin password:
Configuration directory server admin domain [org]:
Could not authenticate as user 'uid=admin, ou=Administrators,
ou=TopologyManagement, o=NetscapeRoot' to server
'ldap://XXXX.org:389/o%3DNetscapeRoot'. Error: No such object
I notice that when I start dirsrv-admin, I get the following message in
/var/log/dirsrv/admin-serv/error:
[:crit] [pid 18514:tid 140642010404992] populate_tasks_from_server():
Unable to search [cn=admin-serv-XXXX, cn=389 Administration Server,
cn=Server Group, cn=XXXX.org, ou=org, o=NetscapeRoot] for LDAPConnection
[XXXX.org:389]
Each server is its own configuration directory server. There is a
replication agreement between the two servers, but only on userRoot, not
NetscapeRoot.
I also note that ldapsearch -x -b "o=NetscapeRoot" on the problem server
yields:
# extended LDIF
#
# LDAPv3
# base <o=NetscapeRoot> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#
# NetscapeRoot
dn: o=NetscapeRoot
objectClass: top
objectClass: organization
o: NetscapeRoot
# search result
search: 2
result: 0 Success
# numResponses: 2
# numEntries: 1
The same command on the working server produces a response with 46 entries
and lots of good things in it. Did my NetscapeRoot somehow get emptied?
How do I get it back?
I thought a "restoreconfig" command would help me, but I never did a
"saveconfig" and don't have any /var/lib/dirsrv/slapd-XXXX/bak/*.ldif
files. I do have a
/var/lib/dirsrv/slapd-XXXX/ldif/XXXX-NetscapeRoot-2010_09_16_090402.ldif
file, but it's quite old and from the documentation that I read, it says it
is an "example" file. I do have backups in
/var/lib/dirsrv/slapd-XXXX/bak/. Among others, I have ones from
2011_07_20_10_54_37/ and 2012_02_20_13_29_00/. I believe everything was
working correctly in 2011, but not by 2012. Could this help in any way?
Alternatively, I just now did a saveconfig, and it produced an .ldif file
with 146 entries! If I now restore from that file, might that fix things
up? Can it hurt to try?
9 years
flag "user must change password at next logon"
by Giovanni Baruzzi
Hi,
Under the MS AD, the information „user must change password at next logon“
is reflected through three attributes:
- the maxPwdAge attribute of the domain object,
- the pwdLastSet of the user object
- the userAccountControlof the user object
1) When the difference between the current date and pwdLastSet exceeds
maxPwdAge, the password is expired,
but nothing changes in AD. If you reset the password, please take care to
update the pwdLastSet date.
2) there are complex relationships between the operations to update the
password and the userAccountControlOf.
This is detailed status encoded in the single bits of a 32-bit word along
the following table:
ADS_UF_SCRIPT = 1, // 0x1
ADS_UF_ACCOUNTDISABLE = 2, // 0x2
ADS_UF_HOMEDIR_REQUIRED = 8, // 0x8
ADS_UF_LOCKOUT = 16, // 0x10
ADS_UF_PASSWD_NOTREQD = 32, // 0x20
ADS_UF_PASSWD_CANT_CHANGE = 64, // 0x40
ADS_UF_ENCRYPTED_TEXT_PWD = 128, // 0x80
ADS_UF_TEMP_DUPLICATE_ACCOUNT = 256, // 0x100
ADS_UF_NORMAL_ACCOUNT = 512, // 0x200
ADS_UF_INTERDOMAIN_TRUST_ACCOUNT = 2048, // 0x800
ADS_UF_WORKSTATION_TRUST_ACCOUNT = 4096, // 0x1000
ADS_UF_SERVER_TRUST_ACCOUNT = 8192, // 0x2000
ADS_UF_DONT_EXPIRE_PASSWD = 65536, // 0x10000
ADS_UF_MNS_LOGON_ACCOUNT = 131072, // 0x20000
ADS_UF_SMARTCARD_REQUIRED = 262144, // 0x40000
ADS_UF_TRUSTED_FOR_DELEGATION = 524288, // 0x80000
ADS_UF_NOT_DELEGATED = 1048576, // 0x100000
ADS_UF_USE_DES_KEY_ONLY = 2097152, // 0x200000
ADS_UF_DONT_REQUIRE_PREAUTH = 4194304, // 0x400000
ADS_UF_PASSWORD_EXPIRED = 8388608, // 0x800000
ADS_UF_TRUSTED_AUTH_DELEGATION = 16777216, // 0x1000000
ADS_UF_PARTIAL_SECRETS_ACCOUNT = 67108864, // 0x4000000
You must take care of the bits „ADS_UF_PASSWD_CANT_CHANGE“,
„ADS_UF_PASSWD_NOTREQD“, „ADS_UF_ENCRYPTED_TEXT_PWD“,
„ADS_UF_DONT_EXPIRE_PASSWD“, „ADS_UF_PASSWORD_EXPIRED“.
IF you maintain the password without using the native methods, you have to
take care to update the pwdLastSet and reset the bit
„ADS_UF_PASSWORD_EXPIRED“.
For more information relate to the article under:
http://www.jigsolving.com/activedirectory/user-account-attributes-part-5
Regards,
Giovanni
>
>
>----------------------------------------------------------------------
>
>Message: 1
>Date: Wed, 20 May 2015 14:28:25 +0300
>From: Mihai Carabas <mihai.carabas(a)gmail.com>
>To: "General discussion list for the 389 Directory server project."
> <389-users(a)lists.fedoraproject.org>
>Subject: [389-users] flag "user must change password at next logon"
> remains active after PassSync
>Message-ID:
> <CANg1yUvWfagVZjQjLgD-NUyh6CqwKGYFYhMh+668eN6_6EL+yg(a)mail.gmail.com>
>Content-Type: text/plain; charset="utf-8"
>
>Hello,
>
>We've setup an 389 Directory Server on a Fedora21 and configured
>synchronization with an Active Directory (running on an Windows2012R2
>Datacenter). We've managed to synchronize all the accounts from the 389DS
>to AD (about 44000). All the accounts have the "user must change password
>at next logon" in the AD, even if the users change their passwords on the
>389DS, The password gets to the AD, but the flag for "user must change
>password at next logon" still remains active (basically forces the user to
>change their password on the Active Directory). Is there any workaround
>for
>this?
>
>The attribute passwordMustChange in the 389DS is set to Off.
>
>Thank you,
>Mihai Carabas
>University POLITEHNICA of Bucharest
>-------------- next part --------------
>An HTML attachment was scrubbed...
>URL:
><http://lists.fedoraproject.org/pipermail/389-users/attachments/20150520/c
>760644b/attachment-0001.html>
>
>------------------------------
9 years
multiple password storage scheme
by Mihai Carabas
Hello,
Can I have multiple storage schemes at the same in 389DS? For example right
now I have active the SSHA scheme, but I want to import a UNIX shadow
database too. Is this scenario possible?
Thank you,
Mihai Carabas
9 years
