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
changelogdb has gotten large...
by Hartmann, Tim
Hi,
I've run into a situation where one of the files in /var/lib/dirsrv/<instance>/changelogdb has grown almost as large as the partition it's on. In my directory server configs, I noticed I was keeping an unlimited changelog, so I set that to what seems like a reasonably long amount of time (18 weeks) but didn't see any decrease in the file size. I'm wondering now about the best course of action. I can
a) move the whole dirsrv directory to another partition with more space available and symlink the old location to the new, which worked when I tested it, but I wanted to make sure I wouldn't be hosing something up the next time I upgrade.
b) find some means of manually shrinking the *.db ( can you even do that?)
c) point dirsrv at a new location, and reinitialize the consumers (which doesn't seem all that desirable)
Has anyone else found it necessary to shrink your changelogdb?
Thanks
-Tim
13 years, 3 months
Announcing CN=Monitor 1.3
by Andreas Andersson
Hi!
It’s been a year since I announced the 1.0 release of my little open source project CN=Monitor (LDAP Monitoring) here on the 389 Users list.
A lot of features and improvements have been added since then.
If you are running 389 DS / CentOS DS or Red Hat DS and needs a web application to monitor your directory server environment(s) you should download the today released stable version 1.3.
Features:
* Live monitoring to view current load
* Collect historical events and view trends
* Replication, Cache status verification
* Verify server performance and load balancing
* Mobile phone GUI support
Project website:
http://cnmonitor.sourceforge.net/
Freshmeat:
http://freshmeat.net/projects/cnmonitor
Best Regards - Andreas Andersson
13 years, 3 months
Problems with chaining (was: RE: Sanity check for install approach)
by Jonathan Boulle
I've done a colossal amount of reading and experimentation to remedy the ignorance demonstrated in my last email, so let's start again:
I have, in a simple two-node (one supplier, one consumer) setup:
- Consumer set up with one local database (replicated from the supplier), + one database link back to the supplier
- Suffix dc=example using both of these databases, + replication plugin (with repl_chain_on_update) enabled, + suffix request processing set to "use the databases" (i.e. no referrals)
- Database link on the consumer using cn=replication manager,cn=config; an ACI on the supplier of (targetattr = "*")(version 3.0; acl "proxy acl"; allow(proxy) userdn="ldap:///cn=replication manager,cn=config";)
So, on a client which is pointed towards the consumer, let's try modify something:
[bloggsj@client02 ~]$ ldapmodify -x -ZZ -D uid=bloggsj,ou=people,dc=example -w example
dn: uid=bloggsj,ou=People,dc=example
changetype: modify
replace: title
title: Sir
modifying entry "uid=bloggsj,ou=People,dc=example"
---
On the supplier I see the relevant bind requests (as replication user *and* as the bloggsj user, i.e. successfully proxied), and also that the change succeeds (I turned on some ACL logging):
<snip>
[30/Jul/2010:17:10:03 +0100] NSACLPlugin - proxied authorization dn is (uid=bloggsj,ou=people,dc=example)
[30/Jul/2010:17:10:03 +0100] NSACLPlugin - #### conn=26 op=2 binddn="cn=replication manager,cn=config"
[30/Jul/2010:17:10:03 +0100] NSACLPlugin - #### conn=26 op=2 binddn="cn=replication manager,cn=config"
<snip>
[30/Jul/2010:16:56:27 +0100] NSACLPlugin - conn=20 op=2 (main): Allow write on entry(uid=bloggsj,ou=people,dc=example).attr(title) to proxy (uid=bloggsj,ou=people,dc=example): allowed by aci(51): aciname= "Enable self write for common attributes", acidn="dc=example
<snip>
Great. Works fine, as expected. But if I try to change the userPassword, for some reason the database link does _not proxy the authorisation_, but instead uses the replication user to try make the change:
[bloggsj@client02 ~]$ ldapmodify -x -ZZ -D uid=bloggsj,ou=people,dc=example -w example
dn: uid=bloggsj,ou=People,dc=example
changetype: modify
replace: userPassword
userPassword: abc123!@#
modifying entry "uid=bloggsj,ou=People,dc=example"
ldapmodify: Insufficient access (50)
additional info: Insufficient 'write' privilege to the 'userPassword' attribute of entry 'uid=bloggsj,ou=people,dc=example'.
---
On the supplier:
<snip>
[30/Jul/2010:17:08:13 +0100] NSACLPlugin - #### conn=24 op=2 binddn="cn=replication manager,cn=config"
<snip>
[30/Jul/2010:16:57:09 +0100] NSACLPlugin - conn=21 op=2 (main): Deny write on entry(uid=bloggsj,ou=people,dc=example).attr(userPassword) to cn=replication manager,cn=config: no aci matched the subject by aci(53): aciname= "self", acidn="dc=example"
<snip>
Why do userPassword changes not proxy?
I have tried
- enabling/disabling "ACL Plugin" component to chain
- enabling/disabling "password policy" component to chain
- enabling/disabling various LDAP controls to chain
- other attributes (homephone, surname, etc), all of which proxy fine
to no avail.
Rich (or anyone else :-), do you have any ideas? This really looks like a bug to me - I haven't started poking around in the source yet though.
-----Original Message-----
From: 389-users-bounces(a)lists.fedoraproject.org [mailto:389-users-bounces@lists.fedoraproject.org] On Behalf Of Jonathan Boulle
Sent: 29 July 2010 14:54
To: 'General discussion list for the 389 Directory server project.'
Subject: Re: [389-users] Sanity check for install approach
On closer examination of the doc, it appears that chaining updates is only possible when using database links.
However, as I infer, using database links removes the possibility of replication, because the link would pass any modification back to the remote database.
Thus, if you had a consumer configured with a database link back to a supplier, and then set up a replication agreement from the supplier to the consumer, it would be replicating to its own database!
Am I understanding this correctly?
Is there a way to achieve our desired scenario: where no clients can directly access a read-write supplier (i.e. referrals are disabled, because network access is blocked); but they're still able to change their passwords, because the read-only consumer chains the update request back to a supplier?
Cheers
________________________________________________________________________
In order to protect our email recipients, Betfair Group use SkyScan from
MessageLabs to scan all Incoming and Outgoing mail for viruses.
________________________________________________________________________
13 years, 4 months
Synching with multiple Windows ADs
by John A. Sullivan III
Hello, all. I know one can only have one sync agreement with an AD.
However, is it possible to have a sync agreement with multiple ADs. We
would like to synchronize the top of our tree with our main,
multi-tenant AD and then synchronize lower levels of the domains with
separate domains controlled by our clients. Thus, the same users and
groups are synchronized to two different AD trees.
As much as we dearly want this to work, I think it is asking for trouble
as the GUID from AD is passed back to LDAP as part of the
synchronization. Since these GUIDs will be different for the same user
from different AD trees, is this a problem?
I know that sounds a bit convoluted so let me give an example. I have a
user Joe in LDAP. I synchronize him to MyAD so he is MyAD\Joe. I also
synchronize him to TheirAD so he is also TheirAD\Joe. The GUID for MyAD
\Joe is different from the GUID for TheirAD\Joe even though it is the
same LDAP Joe. Is that a problem? Thanks - John
13 years, 4 months
Re: [389-users] Synching with multiple Windows ADs
by Phil Daws
Is the DIT object ntuniqueid constructed from the Windows user object uuid and domain sid to keep the uniqueness ?
Sent from Zimbra and my HTC Desire
----- Reply message -----
From: "John A. Sullivan III" <jsullivan(a)opensourcedevel.com>
Date: Tue, Jul 27, 2010 21:42
Subject: [389-users] Synching with multiple Windows ADs
To: <389-users(a)lists.fedoraproject.org>
Hello, all. I know one can only have one sync agreement with an AD.
However, is it possible to have a sync agreement with multiple ADs. We
would like to synchronize the top of our tree with our main,
multi-tenant AD and then synchronize lower levels of the domains with
separate domains controlled by our clients. Thus, the same users and
groups are synchronized to two different AD trees.
As much as we dearly want this to work, I think it is asking for trouble
as the GUID from AD is passed back to LDAP as part of the
synchronization. Since these GUIDs will be different for the same user
from different AD trees, is this a problem?
I know that sounds a bit convoluted so let me give an example. I have a
user Joe in LDAP. I synchronize him to MyAD so he is MyAD\Joe. I also
synchronize him to TheirAD so he is also TheirAD\Joe. The GUID for MyAD
\Joe is different from the GUID for TheirAD\Joe even though it is the
same LDAP Joe. Is that a problem? Thanks - John
--
389 users mailing list
389-users(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
13 years, 4 months
issue getting schema - Version 1.2.x return no operational attributes
by Rudolf Hatheyer
Hi,
I've noticed a difference in behavior between 1.0.x and 1.2.x Version of
FDS.
Version 1.2.x will not return the hole schema (without specifying
attributes objectClasses, matchingRules ).
This a problem when querying by use of VBScript (i need this ugly stuff
in a windows login script to get specific user data from the LDAP). ADSI
will first do a root-DSE query to determine the provided schema. If the
server returns no schema, ADSI will allow you to query only standard
LDAP V2 attributes (and not my special ones).
Query a Server with Version 1.2.5
# ./ldapsearch -h 192.168.1.202 -b cn=schema -s base "objectclass=*"
version: 1
dn: cn=schema
objectClass: top
objectClass: ldapSubentry
objectClass: subschema
cn: schema
Specifying for instance "objectClasses" attribut in the query returns
the wanted data:
version: 1
dn: cn=schema
objectClasses: ( 2.5.6.0 NAME 'top' ABSTRACT MUST objectClass X-ORIGIN
'RFC 45
12' )
objectClasses: ( 2.5.6.1 NAME 'alias' SUP top STRUCTURAL MUST
aliasedObjectNam
e X-ORIGIN 'RFC 4512' )
objectClasses: ( 2.5.20.1 NAME 'subschema' AUXILIARY MAY (
dITStructureRules $
nameForms $ dITContentRules $ objectClasses $ attributeTypes $
matchingRule
s $ matchingRuleUse ) X-ORIGIN 'RFC 4512' )
objectClasses: ( 1.3.6.1.4.1.1466.101.120.111 NAME 'extensibleObject'
SUP top
[...]
Query a Server with Version 1.0.4
version: 1
dn: cn=schema
objectClass: top
objectClass: ldapSubentry
objectClass: subschema
cn: schema
objectClasses: ( 2.5.6.0 NAME 'top' DESC 'Standard LDAP objectclass'
ABSTRACT
MUST objectClass X-ORIGIN 'RFC 2256' )
objectClasses: ( 2.5.6.1 NAME 'alias' DESC 'Standard LDAP objectclass'
SUP top
ABSTRACT MUST aliasedObjectName X-ORIGIN 'RFC 2256' )
objectClasses: ( 1.3.6.1.4.1.1466.101.120.111 NAME 'extensibleObject'
DESC 'LD
APv3 extensible object' SUP top AUXILIARY X-ORIGIN 'RFC 2252' )
[...]
Is there a way to configure the 1.2.x series to get the old behavior?
Regards, Rudolf
--
Rudolf Hatheyer
alpha nova Betriebsgesm.b.H.
Idlhofgasse 59-63
8020 Graz
Tel: 0043/316/722622
Fax: 0043/316/722622-16
Mobil: 0699/14032570
http://www.alphanova.at
13 years, 4 months
Sanity check for install approach
by Gerrard Geldenhuis
Hi
I would appreciate anyone just giving the tasks below a sanity check.
We will have a multimaster setup with various consumers from which clients will be authenticating off. Clients can not reach the masters directly and can only reach the consumer servers.
To enable password policies to work correctly I will configure the consumer servers to chain requests back to the masters and enable chaining for the Password policy component. My understanding is thus that when a client tries to authenticate against the consumer server and fails, the password policy configured on the consumer will activate and the counter incremented for failed logins. This incremented counter change will then be chained back to the master which will replicate it back to the consumer and any other consumers.
To rephrase the above... in a user story.
User authenticates against consumer01
Authentication fails
Consumer01 has password policy configured and replication from master01.
What happens next?
Does the consumer automatically communicate this failure back to master01, or do you need to setup chaining for this to happen?
Regards
________________________________________________________________________
In order to protect our email recipients, Betfair Group use SkyScan from
MessageLabs to scan all Incoming and Outgoing mail for viruses.
________________________________________________________________________
13 years, 4 months
dynamic group expansion: writing a patch...
by Roberto Polli
Hi all,
I'd like to start a patch on dynamic group expansion, but dunno where to
start.
Can you point me?
Should be something like reusing VLV code?
Thx+Peace,
R-
--
Roberto Polli
Babel S.r.l. - http://www.babel.it
Tel. +39.06.91801075 - fax +39.06.91612446
Tel. cel +39.340.6522736
P.zza S.Benedetto da Norcia, 33 - 00040 Pomezia (Roma)
"Il seguente messaggio contiene informazioni riservate. Qualora questo
messaggio fosse da Voi ricevuto per errore, Vogliate cortesemente darcene
notizia a mezzo e-mail. Vi sollecitiamo altresì a distruggere il messaggio
erroneamente ricevuto. Quanto precede Vi viene chiesto ai fini del rispetto
della legge in materia di protezione dei dati personali."
13 years, 4 months
Windows Replication Agreement Help
by Phil Daws
Hi,
We are setting up a new Windows 2K3 AD server and attempting to syncronise the users from our LDAP server version 8.1.0.
Performing the full sync fails after about 30 seconds with a message in the error log:
[14/Jul/2010:07:46:10 -0400] - add value "^V" to attribute type "ARecord" in entry "DC=@,DC=RootDNSServers,CN=MicrosoftDNS,CN=System,DC=domain,DC=com" failed: duplicate new value
[14/Jul/2010:07:46:10 -0400] - add value "null or non-ASCII" to attribute type "dnsproperty" in entry "DC=RootDNSServers,CN=MicrosoftDNS,CN=System,DC=domain,DC=com" failed: duplicate new value
and none of the users or groups are sent to AD. I am guessing it may be how our LDAP server schema is setup as we use something like:
dc=domain,dc=com
|_ o=Internal
|___o=a0000
|____ou=Desktops
|_____uid=fred
We have set the Windows subtree to be dc=domain,dc=com and the replication subtree to be dc=domain,dc=com with a DS subtree of o=Internal,dc=domain,dc=com.
Our understanding was that within AD Users & Groups GUI we should have seen a similar schema created.
Though for some reason the replication is traversing the whole of the internal AD tree. Should we create a new Organisational Unit within AD called, for arguments sake, clients and set the Windows subtree to be ou=clients,dc=domain,dc=com so that it forces it to that branch ?
--
Thanks, Phil
13 years, 4 months
