objectClass attribute merging
by Hugo Monteiro
Hello,
I'm trying to merge the objectClass attribute between a central LDAP
server and a local one which is using translucent overlay.
I have configured the overlay with
translucent_remote objectClass
translucent_local objectClass
If i issue a query like
ldapsearch -D "cn=cdstaff,dc=unl,dc=pt" -b
"ou=grupos,dc=fct,dc=unl,dc=pt" -h localhost -W -x "(cn=cpd_srv_adm)"
i get
# extended LDIF
#
# LDAPv3
# base <ou=grupos,dc=fct,dc=unl,dc=pt> with scope subtree
# filter: (cn=cpd_srv_adm)
# requesting: ALL
#
# 637, grupos, fct.unl.pt
dn: uniqueIdentifier=637,ou=grupos,dc=fct,dc=unl,dc=pt
displayName: Admins Servidores ADM
cn: cpd_srv_adm
uniqueIdentifier: 637
gidNumber: 1637
member: uniqueIdentifier=18172,ou=agentes,dc=fct,dc=unl,dc=pt
member: uniqueIdentifier=18272,ou=agentes,dc=fct,dc=unl,dc=pt
member: uniqueIdentifier=15093,ou=agentes,dc=fct,dc=unl,dc=pt
objectClass: top
objectClass: grupoUNL
objectClass: posixGroup
# search result
search: 2
result: 0 Success
# numResponses: 2
# numEntries: 1
but then, if i change the filter to also use objectClass like
ldapsearch -D "cn=cdstaff,dc=unl,dc=pt" -b
"ou=grupos,dc=fct,dc=unl,dc=pt" -h localhost -W -x
"(&(objectClass=*)(cn=cpd_srv_adm))"
i get
# extended LDIF
#
# LDAPv3
# base <ou=grupos,dc=fct,dc=unl,dc=pt> with scope subtree
# filter: (&(objectClass=*)(cn=cpd_srv_adm))
# requesting: ALL
#
# 637, grupos, fct.unl.pt
dn: uniqueIdentifier=637,ou=grupos,dc=fct,dc=unl,dc=pt
displayName: Admins Servidores ADM
cn: cpd_srv_adm
uniqueIdentifier: 637
gidNumber: 1637
member: uniqueIdentifier=18172,ou=agentes,dc=fct,dc=unl,dc=pt
member: uniqueIdentifier=18272,ou=agentes,dc=fct,dc=unl,dc=pt
member: uniqueIdentifier=15093,ou=agentes,dc=fct,dc=unl,dc=pt
objectClass: top
objectClass: grupoUNL
objectClass: posixGroup
# search result
search: 2
result: 32 No such object
# numResponses: 2
# numEntries: 1
which apparently works, but do notice that it also reports result: 32 No
such object
If i try the query in another client, like phpldapadmin or even luma,
i'm only presented with the error message.
Is this a bug?
Best regards,
Hugo Monteiro.
--
fct.unl.pt:~# cat .signature
Hugo Monteiro
Email : hugo.monteiro(a)fct.unl.pt
Telefone : +351 212948300 Ext.15307
Web : http://hmonteiro.net
Divisão de Informática
Faculdade de Ciências e Tecnologia da
Universidade Nova de Lisboa
Quinta da Torre 2829-516 Caparica Portugal
Telefone: +351 212948596 Fax: +351 212948548
www.fct.unl.pt apoio(a)fct.unl.pt
fct.unl.pt:~# _
12 years, 7 months
Local root browsing for translucent proxy
by Hugo Monteiro
Hello,
I have set a translucent proxy and things have been working rather well.
I've been able to add/delete and modify local attributes authenticating
with the local rootdn. All this has been done using openldap's command
line tools.
I now have the need to use a web based interface and so i installed
phpldapadmin. To my surprise, i can login using the local rootdn but i'm
not able to browse or search for any entry in that branch, although i
have write access acls, besides the rootdn declaration.
the database definition is as follows:
--- snip ---
database hdb
suffix "dc=example,dc=com"
rootdn cn=loadmin,dc=example,dc=com
rootpw secret
directory "/var/lib/ldap"
lastmod on
access to attrs=userPassword,sambaNTPassword,krb5Key
by dn.exact="cn=admin,dc=example,dc=com" write
by dn.exact="cn=loadmin,dc=example,dc=com" write
by dn.exact="cn=reader,dc=example,dc=com" read
by self read
by anonymous auth
by * none
access to *
by dn.exact="cn=admin,dc=example,dc=com" write
by dn.exact="cn=loadmin,dc=example,dc=com" write
by * read
index sambaSID,sambaPrimaryGroupSID eq
overlay translucent
uri "ldap://ldapbackend.example.com"
acl-bind binddn="cn=reader,dc=example,dc=com" credentials="secret"
translucent_strict
translucent_remote objectClass
translucent_local sambaSID,sambaPrimaryGroupSID,sambaAcctFlags
overlay glue
--- snip ---
I seen no problem in the configuration, but do please point me out any
misconfiguration that might be leading to this behaviour.
Since i've been able to use the command line tools, i initially supposed
it was a misconfiguration or even a bug in phpldapadmin, but i'm
starting to consider the problem as limitiation for the translucent
overlay. Should i consider this scenario also?
(I know i should be using runtime config already... Let us leave that to
another occasion ;) )
Best regards,
Hugo Monteiro.
--
fct.unl.pt:~# cat .signature
Hugo Monteiro
Email : hugo.monteiro(a)fct.unl.pt
Telefone : +351 212948300 Ext.15307
Web : http://hmonteiro.net
Divisão de Informática
Faculdade de Ciências e Tecnologia da
Universidade Nova de Lisboa
Quinta da Torre 2829-516 Caparica Portugal
Telefone: +351 212948596 Fax: +351 212948548
www.fct.unl.pt apoio(a)fct.unl.pt
fct.unl.pt:~# _
12 years, 7 months
How to make ldappasswd obey password policy restrictions?
by Konstantin Boyandin
Greetings,
Given: OpenLDAP: 2.4.23, password policy module enabled, default
password policy loaded as
dn: cn=default,ou=Policies,dc=example,dc=com
cn: default
objectClass: pwdPolicy
objectClass: person
objectClass: top
pwdAllowUserChange: TRUE
pwdAttribute: userPassword
pwdCheckQuality: 0
pwdExpireWarning: 600
pwdFailureCountInterval: 30
pwdGraceAuthNLimit: 5
pwdInHistory: 5
pwdLockout: TRUE
pwdLockoutDuration: 30
pwdMaxAge: 7776000
pwdMaxFailure: 5
pwdMinAge: 0
pwdMinLength: 5
pwdMustChange: FALSE
pwdSafeModify: FALSE
sn: dummy value
Authentication is set via LDAP (.
The problem: when I try to set password via ldappassword, using command
like this:
ldappasswd -e ppolicy -W -x -D "cn=Manager,dc=example,dc=com" \
-H ldap://127.0.0.1/ -A -S "uid=testuser,ou=Users,dc=example,dc=com"
it bypasses password policy settings - I can set the same password, can
set the previously used password. It doesn't matter whether I specify
'-e ppolicy' or not.
However, when I try to change password with passwd (authentication is
set via LDAP, /etc/ldap.conf contains 'pam_password exop'):
passwd testuser
the password policy restrictions are in effect. I am not allowed to set
the same password, to set previous or similar password etc.
Is it possible to make ldappaswd observe password policy restrictions?
Thanks.
Sincerely,
Konstantin
12 years, 7 months
Ppolicy does not seem to work
by Jan Kohnert
Hi there,
I'm new to this list, so first of all welcome to everyone.
I have a problem with ppolicy and got stuck finding a solution. I configured
slapd using the information from [1] trying to be able to lock users. But
anyway, the lock seems to be ignored: As soon as one tries to log in, the
pwdLockedTime agument es removed from the entry and I seem to be too blind or
dumb to see the reason why.
Here is what happens (testing my own account):
b079 /etc/openldap # grep -v "^#" ldif/locked_users.ldif
dn: uid=jan,ou=xxx,dc=yyy,dc=zzz,dc=org
changetype: modify
add: pwdAccountLockedTime
pwdAccountLockedTime: 20110119225403Z
b079 /etc/openldap # ldapmodify -x -D "cn=admin, dc=yyy, dc=zzz, dc=org" -W -f
ldif/locked_users.ldif
Enter LDAP Password:
modifying entry "uid=jan,ou=xxx,dc=yyy,dc=zzz,dc=org"
b079 /etc/openldap # slapcat | grep -B 13 Locked | grep "uid: jan"
uid: jan
b079 /etc/openldap # ldapwhoami -x -D "uid=jan, ou=xxx, dc=yyy, dc=zzz,
dc=org" -W
Enter LDAP Password:
dn:uid=jan,ou=xxx,dc=yyy,dc=zzz,dc=org
b079 /etc/openldap # slapcat | grep -B 13 Locked | grep "uid: jan"b079
/etc/openldap #
And here is the relevant configuration;
b079 /etc/openldap # grep ppolicy slapd.conf
include /etc/openldap/schema/ppolicy.schema
moduleload ppolicy.so
overlay ppolicy
ppolicy_default "cn=default,ou=policies,dc=yyy,dc=zzz,dc=org"
b079 /etc/openldap #
b079 /etc/openldap # ldapsearch -x -s base -b "cn=default, ou=policies,
dc=yyy, dc=zzz, dc=org"
# extended LDIF
#
# LDAPv3
# base <cn=default, ou=policies, dc=yyy, dc=zzz, dc=org> with scope baseObject
# filter: (objectclass=*)
# requesting: ALL
#
# default, policies, yyy.zzz.org
dn: cn=default,ou=policies,dc=yyy,dc=zzz,dc=org
cn: default
sn: dummy value
objectClass: pwdPolicy
objectClass: person
objectClass: top
pwdAttribute: userPassword
pwdMinAge: 0
pwdMaxAge: 0
pwdInHistory: 0
pwdCheckQuality: 0
pwdLockout: TRUE
pwdLockoutDuration: 900
pwdFailureCountInterval: 1800
pwdMustChange: FALSE
pwdAllowUserChange: TRUE
pwdSafeModify: TRUE
pwdExpireWarning: 604800
pwdMaxFailure: 5
pwdGraceAuthNLimit: 0
pwdMinLength: 8
# search result
search: 2
result: 0 Success
# numResponses: 2
# numEntries: 1
b079 /etc/openldap #
Thank a lot in advance!
[1] http://www.openldap.org/lists/openldap-technical/200810/msg00107.html
--
MfG Jan
12 years, 7 months
[Q] Does anybody succeed to setup SASL(digest-md5) authentication with mysql database and latest openldap-server??
by Hiroyuki Sato
Dear members.
Does anybody succeed to setup SASL(digest-md5) authentication with
mysql database and latest openldap-server??
I'm not sure, why this configuration does not work correctly.
and It seems that LDAP server compare dn and input password in ldap
authentication. (see log below)
Thank you for your advice.
Sincerely.
--
Hiroyuki Sato.
My Environment
OS: Ubuntu 10.10
OpenLDAP : 2.4.24 (build myself)
1, slapd.conf
..
sasl-realm mydomain.com
sasl-auxprops sql
sasl-regexp
uid=(.*),cn=mydomain.com,cn=digest-md5,cn=auth
uid=$1,ou=users,ou=mydomain.com,dc=test,dc=mydomain,dc=com
Note: ``sasl-auxprops sql'' does not well document.
It is important config for sql authentication
2, /usr/lib/sasl2/slapd.conf
pwcheck_method: auxprop
mech_list: DIGEST-MD5
log_level: 7
auxprop_plugin: sql
sql_verbose: yes
sql_engine: mysql
sql_hostnames: database.server.add.ress
sql_user: username
sql_passwd: password
sql_database: db_name
sql_select: select password from sasl_test where username = '%u@%r'
3, dataase entry
mysql> select * from sasl_test \G
*************************** 1. row ***************************
username: ldapuser(a)mydomain.com
password: ldapuser_password
4, auth
ldapsearch -R mydomain.com -h server_add.ress -Y digest-md5 -U
ldapuser -b 'ou=users,ou=mydomain.com,dc=test,dc=test,dc=mydomain,dc=com'
-LLL '(objectclass=*)'
Password:
ldap_sasl_interactive_bind_s: Insufficient access (50)
5, log
......
<= ldap_dn2bv(uid=ldap_user,cn=mydomain,dc=com,cn=DIGEST-MD5,cn=auth)=0
slap_sasl_getdn: u:id converted to
uid=ldap_user,cn=mydomain,dc=com,cn=DIGEST-MD5,cn=auth
>>> dnNormalize: <uid=ldap_user,cn=mydomain,dc=com,cn=DIGEST-MD5,cn=auth>
=> ldap_bv2dn(uid=ldap_user,cn=mydomain,dc=com,cn=DIGEST-MD5,cn=auth,0)
<= ldap_bv2dn(uid=ldap_user,cn=mydomain,dc=com,cn=DIGEST-MD5,cn=auth)=0
=> ldap_dn2bv(272)
<= ldap_dn2bv(uid=ldap_user,cn=mydomain,dc=com,cn=digest-md5,cn=auth)=0
<<< dnNormalize: <uid=ldap_user,cn=mydomain,dc=com,cn=digest-md5,cn=auth>
==>slap_sasl2dn: converting SASL name
uid=ldap_user,cn=mydomain,dc=com,cn=digest-md5,cn=auth to a DN
daemon: activity on 1 descriptor
==> rewrite_context_apply [depth=1]
string='uid=ldap_user,cn=mydomain,dc=com,cn=digest-md5,cn=auth'
==> rewrite_rule_apply
rule='uid=(.*),cn=mydomain,dc=com,cn=digest-md5,cn=auth'
string='uid=ldap_user,cn=mydomain,dc=com,cn=digest-md5,cn=auth' [1
pass(es)]
==> rewrite_context_apply [depth=1]
res={0,'uid=ldap_user,ou=users,ou=mydomain,dc=com,dc=test,dc=mydomain,dc=com'}
[rw] authid:
"uid=ldap_user,cn=mydomain,dc=com,cn=digest-md5,cn=auth" ->
"uid=ldap_user,ou=users,ou=mydomain,dc=com,dc=test,dc=mydomain,dc=com"
slap_parseURI: parsing
uid=ldap_user,ou=users,ou=mydomain,dc=com,dc=test,dc=mydomain,dc=com
ldap_url_parse_ext(uid=ldap_user,ou=users,ou=mydomain,dc=com,dc=test,dc=mydomain,dc=com)
>>> dnNormalize:
<uid=ldap_user,ou=users,ou=mydomain,dc=com,dc=test,dc=mydomain,dc=com>
=> ldap_bv2dn(uid=ldap_user,ou=users,ou=mydomain,dc=com,dc=test,dc=mydomain,dc=com,0)
<= ldap_bv2dn(uid=ldap_user,ou=users,ou=mydomain,dc=com,dc=test,dc=mydomain,dc=com)=0
=> ldap_dn2bv(272)
<= ldap_dn2bv(uid=ldap_user,ou=users,ou=mydomain,dc=com,dc=test,dc=mydomain,dc=com)=0
<<< dnNormalize:
<uid=ldap_user,ou=users,ou=mydomain,dc=com,dc=test,dc=mydomain,dc=com>
<==slap_sasl2dn: Converted SASL name to
uid=ldap_user,ou=users,ou=mydomain,dc=com,dc=test,dc=mydomain,dc=com
slap_sasl_getdn: dn:id converted to
uid=ldap_user,ou=users,ou=mydomain,dc=com,dc=test,dc=mydomain,dc=com
SASL Canonicalize [conn=1003]:
slapAuthcDN="uid=ldap_user,ou=users,ou=mydomain,dc=com,dc=test,dc=mydomain,dc=com"
daemon: activity on:
daemon: epoll: listen=7 active_threads=0 tvp=NULL
daemon: epoll: listen=8 active_threads=0 tvp=NULL
SASL Canonicalize [conn=1003]: authzid="ldap_user"
SASL proxy authorize [conn=1003]:
authcid="ldap_user@mydomain,dc=com"
authzid="ldap_user@mydomain,dc=com"
==>slap_sasl_authorized: can
uid=ldap_user,ou=users,ou=mydomain,dc=com,dc=test,dc=mydomain,dc=com
become <INPUT_PASSWORD>?
^^^^^^^^^^^^^^^^^^^^
<== slap_sasl_authorized: return 48
SASL Proxy Authorize [conn=1003]: proxy authorization disallowed (48)
SASL [conn=1003] Failure: not authorized
send_ldap_result: conn=1003 op=1 p=3
send_ldap_result: err=50 matched="" text="SASL(-14): authorization
failure: not authorized"
send_ldap_response: msgid=2 tag=97 err=50
12 years, 7 months
Error: CSN too old and replication fails
by Jérémy Wagner
Hello,
I'm facing some issues with syncrepl...
The simplest situation in which I was able to reproduce the problem
consists of 1 provider and 1 consumer.
I have configured syncrepl to do a partial replication :
olcSyncrepl:
{0}rid=105
provider=ldaps://****:636
bindmethod=simple
timeout=0
network-timeout=0
starttls=no
filter="(mail=*)"
searchbase="ou=groups,o=mydir"
scope=sub
schemachecking=off
attrs="cn description mail member +"
type=refreshAndPersist
retry="60 +"
tls_cert=**** tls_cacert=**** tls_key=****
olcSyncrepl:
{1}rid=107
provider=ldaps://****:636
bindmethod=simple
timeout=0
network-timeout=0
starttls=no
filter="(objectclass=*)"
searchbase="ou=operators,o=mydir"
scope=sub
schemachecking=off
type=refreshAndPersist
retry="60 +"
tls_cert=**** tls_cacert=**** tls_key=****
olcSyncrepl:
{2}rid=104
provider=ldaps://****:636
bindmethod=simple
timeout=0
network-timeout=0
starttls=no
filter="(uid=mytestuser)"
searchbase="ou=people,o=mydir"
scope=sub
schemachecking=off
type=refreshAndPersist
retry="60 +"
tls_cert=**** tls_cacert=**** tls_key=****
The initial sync (i.e. from an empty base) is fine, but then when I
modify an entry (uid=mytestuser), it is not updated on the consumer, and
I get the
following messages:
Feb 16 15:42:32 do_syncrep2: rid=107 NEW_COOKIE:
rid=107,csn=20110216144232.222152Z#000000#000#000000
Feb 16 15:42:32 do_syncrep2: rid=104
cookie=rid=104,csn=20110216144232.222152Z#000000#000#000000
Feb 16 15:42:32 slap_graduate_commit_csn: removing 0x7fb58c0227d0
20110216144232.222152Z#000000#000#000000
Feb 16 15:42:32 do_syncrep2: rid=104 CSN too old, ignoring
20110216144232.222152Z#000000#000#000000
Feb 16 15:43:05 do_syncrep2: rid=105 LDAP_RES_INTERMEDIATE - NEW_COOKIE
Feb 16 15:43:05 do_syncrep2: rid=105 NEW_COOKIE:
rid=105,csn=20110216144305.545784Z#000000#000#000000
Feb 16 15:43:05 slap_queue_csn: queing 0x7fb58c020b50
20110216144305.545784Z#000000#000#000000
Feb 16 15:43:05 do_syncrep2: rid=107 LDAP_RES_INTERMEDIATE - NEW_COOKIE
Feb 16 15:43:05 do_syncrep2: rid=107 NEW_COOKIE:
rid=107,csn=20110216144305.545784Z#000000#000#000000
Feb 16 15:43:05 do_syncrep2: rid=104
cookie=rid=104,csn=20110216144305.545784Z#000000#000#000000
Feb 16 15:43:05 slap_graduate_commit_csn: removing 0x7fb58c0227d0
20110216144305.545784Z#000000#000#000000
Feb 16 15:43:05 do_syncrep2: rid=104 CSN too old, ignoring
20110216144305.545784Z#000000#000#000000
(both servers are perfectly in sync with an NTP daemon)
It looks like ITS #6619 is quite similar, and unresolved.
What do these messages mean ? Is there a way to force the update ?
Regards,
Jeremy W.
12 years, 7 months
ACL Issues
by Troy Knabe
I am attempting to be very granular in the access that I give to my directory, but I seem to be struggling with the implementation.
I have several proxy accounts that I want to grant the access to that they need, no more, no less. But I seem to have to put a line in like:
access to dn.children="dc=company,dc=com" by * read in order to authenticate. What I thought I wanted was something like this:
access to attrs=userPassword
by dn.exact=proxy,dc=company,dc=com write
by self write
by anonymous auth
But without read access above, it does not work. How can I allow proxy users/groups access w/out granting read access to everyone? Or does the dn.children allow read access to all attributes?
12 years, 7 months
Queries regarding pam_groupdn.
by Meghanand Acharekar
Hi,
I'm using pam_groupdn for restricting access to some for my servers,
by defining user groups as follows.
/etc/ldap.conf (Redhat 5.5)
# Group to enforce membership of
pam_groupdn cn=group1,ou=Group,dc=example,dc=com
# Group member attribute
pam_member_attribute memberUid
This works only if the pam_member_attribute is in following format.
memberUid: uid=user1,ou=People,dc=example,dc=com
memberUid: uid=user2,ou=People,dc=example,dc=com
Simply memberUid: user1 is not working, is there any way to fix this.
Second, if a user which dose not belong to this group tries to login server,
access is denied by displaying following message.
You must be a memberUid of cn=group1,ou=Group,dc=example,dc=com to login.
Connection closed by x.x.x.x
Is it possible to change this message ?
Thanks & Regards,
Meghanand N. Acharekar
12 years, 7 months
Aliasing entries with reserved characters
by MJ Hughes
Hi,
I'm an LDAP newbie who has inherited the maintenance of an LDAP system, and
am learning on the fly. Until now I've been able to puzzle out all the
issues I've faced, but finally my google fu has failed me, so I'm seeking
more human assistance.
My problem is with reserved characters, such as , (comma). The system
wasn't coping with RDNs that contained these characters, but this was easy
enough to fix by simply escaping these characters with a backslash.
My problem now involves trying to alias entries that contain these escaped
characters - I am consistently getting "Invalid DN syntax". This is what
the code to add the alias looks like:
$operationDN = "aliasedObjectName=" . $this->aliasSafe($aliasDN) . "," .
$locDN;
$aliasParameterArray = array(
"objectClass" => "alias",
"aliasedObjectName" => $aliasDN
);
$result = ldap_add($this->LDAPcon, $operationDN, $aliasParameterArray);
The aliasSafe() function converts "=" => "\3D" and "," => "\," (unless the
commas have already been escaped).
This produces DNs that have the following (hypothetical) format:
$aliasDN: cn=Tomorrow\, When The War Began,cn=books,dc=library,dc=com
$operationDN: cn\3DTomorrow\, When The War
Began\,cn\3Dbooks\,dc\3Dlibrary\,dc\3Dcom,cn=titles,cn=John
Marsden,cn=authors,dc=library,dc=com
I've tried every encoding of the comma (in the book name) that I can think
of (eg, a single backslash, a double backslash, a triple backslash, and even
'\2C') but everything I've tried so far has given me the "Invalid DN syntax"
error. Could someone please help me with the syntax and encoding these DNs
should have?
Thanks,
MJ
12 years, 7 months
Conflict resolution on Syncrepl
by Diego Lima
Hello all,
This is mostly a theoretical question. I currently have some OpenLDAP
multimaster clusters (using syncrepl and mirrormode) and although it
never happened before, what would happen if two (or more) masters
received a write request exactly at the same time? The entry would
have the same entryCSN on both servers and the contextCSN would be
updated at the same time? Would this lead to a situation where the
servers were actually out of sync but they would "think" they had the
same entries?
--
Diego Lima
http://www.diegolima.org
12 years, 7 months
