Admin server console and TLS
by Mitja Mihelič
Hi!
I am using the Centos directory server and I have run into a problem
with the Admin console.
I restored the /etc/dirsrv/admin-serv files form from backup and now I
get the following error in my error log file for the Admin server:
Wed Aug 04 13:50:15 2010] [notice] [client 127.0.0.1]
admserv_host_ip_check: ap_get_remote_host could not resolve 127.0.0.1
[Wed Aug 04 13:50:15 2010] [crit] buildUGInfo(): unable to initialize
TLS connection to LDAP host cds.example.com port 2389: 4
[Wed Aug 04 13:50:15 2010] [notice] [client 127.0.0.1]
admserv_check_authz(): passing [/admin-serv/authenticate] to the
userauth handler
[Wed Aug 04 13:50:15 2010] [crit] buildUGInfo(): unable to initialize
TLS connection to LDAP host cds.example.com port 2389: 4
There is a server running on the 2389 port, I can connect to it.
This is the adm.conf :
AdminDomain: example.com
sysuser: cds
isie: cn=CentOs Administration Server, cn=Server Group,
cn=cds.example.com, ou=example.com, o=NetscapeRoot
SuiteSpotGroup: cds
sysgroup: cds
userdn: uid=admin, ou=Administrators, ou=TopologyManagement, o=NetscapeRoot
ldapStart: /usr/lib/dirsrv/slapd-cds-config/start-slapd
ldapurl: ldap://cds.example.com:2389/o=NetscapeRoot
SuiteSpotUserID: cds
sie: cn=admin-serv-cds, cn=CentOs Administration Server, cn=Server
Group, cn=cds.example.com, ou=example.com, o=NetscapeRoot
How can I turn OFF TLS for the Admin console ?
I know there must be switch in a config file, but where...
I have compared the config files with the ones on the sister machine
(replica), and they seem alike to me.
(Posted host names and domain names are not actual names.)
Rerards,
Mitja
13 years, 8 months
Set of Attributes Uniqueness
by A Robinson
Hello,
I'm trying to check that values contained in one than one attribute is
unique. A solution exists for other directory servers, but I wondered
if it was achievable in 389?
Is there an equivalent to the NSUniqueAttrSet plugin -- which appears
similar to NSUniqueAttr, but for across multiple attributes?
http://docs.sun.com/app/docs/doc/819-4438/gcfeh?l=en&n=1&a=view
nsslapd-pluginInitfunc: NSUniqueAttrSet_Init
nsslapd-pluginType: preoperation
nsslapd-pluginEnabled: on
nsslapd-pluginarg0: attributeset=mail,mailalternateaddress,mailequivalentaddress
nsslapd-pluginarg1: ugldapbasedn
Thanks,
A Robinson
13 years, 8 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, 8 months
Tuning 389 DS
by Juan Asensio Sánchez
Hi
I am trying to tune the performance of the Directory Server. We have
increased the memory for the database cache and for each database entry
cache. These are the new values:
cn=config, cn=ldbm database, cn=plugins, cn=config
nsslapd-dbcachesize: 838860800 (~800MB)
cn=*,cn=ldbm database, cn=plugins, cn=config
nsslapd-cachememsize: 125829120 (~120MB)
We have 27 databases, and the servers have 16 GB of RAM, so the server
should be able to handle all that memory (800 + 120*27 = 4040MB). But when I
go to the monitoring section of the management console, the database cache
says the hit ratio is 99% (this is OK according to the documentation, near
100%), but the entry cache is 0%, that is very far for 100% that the
documentation recomends (see screenshots attached). Am I confused or the
configuration is not correct?
Regards.
* http://www.redhat.com/docs/manuals/dir-server/8.1/admin/memoryusage.html
*
http://www.redhat.com/docs/manuals/dir-server/8.1/admin/Monitoring_Server...
*
http://www.redhat.com/docs/manuals/dir-server/8.1/admin/Monitoring_Server...
*
http://www.redhat.com/docs/manuals/dir-server/8.1/admin/Monitoring_Server...
13 years, 8 months
Replication without password
by Prashanth Sundaram
Hi,
Is it possible to have different password store on two ldap servers and also
setup replication in M-M or M-S(slave) fashion? In other words can I exclude
the userPassword¹ field from being replicated between two servers?
We need to have different password for two ldap server but they both will
have same user/group data?
Thanks,
Prashanth
13 years, 8 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, 8 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, 8 months
