not able to use idassert-bind successfuly
by Charles Bueche
Dear members,
We are trying to create a LDAP proxy to hide two distinct AD servers
behind a "single LDAP view". The goal is to authentify and authorize
extranet and internal users using a single LDAP server, as LDAP clients
(eg Apache) should only talk to a single LDAP server, and not be aware
about the multiple AD servers behind the proxy.
Our understanding is that we can create a meta database with two
back-ends, using distinct uri/suffix/etc.
What works:
- using an AD user to talk to the proxy, which then is re-used by the
proxy to talk to the back-end
What does not work:
- one "front-end", simple-bind LDAP-user used to access the LDAP-proxy,
and only known to the proxy
- one back-end user per back-end (known in AD).
So we want to first search where a user is by using a front-end account,
and then retry a bind with the user's effective username and password
using its correct DN.
Our config:
--------------------------------------------------------------------
database meta
suffix dc=meta,dc=x1,dc=ch
uri "ldaps://ad1.ad.x1.ch/OU=O3,dc=meta,dc=x1,dc=ch"
suffixmassage "OU=O3,dc=meta,dc=x1,dc=ch" "OU=O3,dc=ad,dc=x1,dc=ch"
idassert-authzFrom "dn:*"
idassert-bind
bindmethod=simple
tls_reqcert=allow
binddn="CN=ldapsrvusr,OU=Service Accounts,OU=O3,dc=ad,dc=x1,dc=ch"
credentials="abcdef12345"
--------------------------------------------------------------------
When we try to use idassert-bind above, we always get the following
error in the log:
...
535a1f25 conn=1000 op=1 <<< meta_search_dobind_init[0]=4
535a1f25 conn=1000 op=1 <<< meta_back_search_start[0]=4
535a1f25 conn=1000 op=1 meta_back_search: ncandidates=1 cnd="*"
535a1f25 conn=1000 op=1 >>> meta_search_dobind_init[0]
535a1f25 conn=1000 op=1 meta_search_dobind_init[0] mc=0x7f17fc008ef0:
non-empty dn with empty cred; binding anonymously
...
so it looks our identity is never used beyond the proxy to talk to the AD.
help welcome.
TIA,
Charles
9 years, 7 months
slapd-ldap with translucent and rwm
by Balazs Kovacs
Hi,
I'd like to set up an LDAP backend toward a remote LDAP server. The base DN
of the searches for the remote server is runtime information and can be any
valid DN. I used slapd-ldap and found slapo-rwm which seems like doing
exactly what I need so I configured a suffixmassage, where I replace the
local DN to the remote base DN. So far so good, I got everything working. I
even applied some more manipulations on searches and results by rwm. I was
almost done except for one (not so) tiny thing: I wanted to have local
overrides on certain attributes. I was glad to encounter slapo-translucent
as it documents:
"Entries retrieved from a remote LDAP server may have some or all
attributes overridden, or new attributes added, by entries in the local
database before being presented to the client".
I started to set it up, but for me it looks like impossible to combine it
with rwm. I used the following example to set up translucent:
http://www.openldap.org/lists/openldap-technical/201205/msg00125.html
I tried to apply rwm together with translucent like 1) first. I thought
this is the ideal setup since I want the suffixmassage only when I turn to
the remote LDAP and I want the suffixmassage to be reverted when back from
remote.
---
1)
dn:
olcOverlay=rwm,olcDatabase={0}ldap,olcOverlay={0}translucent,olcDatabase={1}hdb,cn=config
And the result was:
adding new entry
"olcOverlay=rwm,olcDatabase={0}ldap,olcOverlay={0}translucent,olcDatabase={1}hdb,cn=config"
ldap_add: Object class violation (65)
I was a bit disappointed but tried other combinations as well.
2)
dn: olcOverlay={0}translucent,olcDatabase={2}hdb,cn=config
dn:
olcDatabase={0}ldap,olcOverlay={0}translucent,olcDatabase={2}hdb,cn=config
dn: olcOverlay={1}rwm,olcDatabase={2}hdb,cn=config
This one resulted in suffixmassage for remote ldap, but also for the
translucent local hdb search, which is obviously not a valid dn for the
local DB.
As an extra I also faced ITS#5941 (
http://www.openldap.org/its/index.cgi/Software%20Bugs?selectid=5941)
3)
dn: olcOverlay={0}rwm,olcDatabase={2}hdb,cn=config
dn: olcOverlay={1}translucent,olcDatabase={2}hdb,cn=config
dn:
olcDatabase={0}ldap,olcOverlay={1}translucent,olcDatabase={2}hdb,cn=config
This one resulted in intact suffix for ldap and a suffixmassage for local,
which is again useless for my case.
---
I also tried to look at if I can use the obsolete suffixmassage option of
the slapd-ldap, but that does not seem to have an olc schema by looking at
the source.
After these trials my conclusion was that I have to find a completely
different way of doing this.
Is it not possible to do a suffixmassage on an ldap backend over
translucent? For me this is so much a basic use case that I am surprised.
Can someone explain if this is a known missing feature or an intentional
limitation? If the latter, why?
Any proposal how to solve local overrides inside slapd? (I wouldn't like to
run two slapd to separate rwm from translucent)
Thanks and Regards,
Balazs Kovacs
ps: using OpenLDAP 2.4.28 on an Ubuntu 12.04 LTS
9 years, 7 months
N-Way Multimaster replication
by Flatfender
All,
I'm trying to get N-Way Multi-master replication working, and can see each
server polling each other but replication doesn't see to update.
I have two servers auth03 and auth04. Both servers are Centos 6.5 with
OpenLDAP 2.4.23-34.el6_5.1 from the Base/Updates CentOS repository.
What I see is that each server seems to contact the other and both get log
entries like this. I can post more logs if need be. I haven't been able to
find much on "got empty syncUUID"
Apr 14 15:44:32 auth03 slapd[1467]: daemon: epoll: listen=11
active_threads=0 tvp=zero
Apr 14 15:44:32 auth03 slapd[1467]: connection_get(22)
Apr 14 15:44:32 auth03 slapd[1467]: connection_get(22): got connid=0
Apr 14 15:44:32 auth03 slapd[1467]: =>do_syncrepl rid=004
Apr 14 15:44:32 auth03 slapd[1467]: =>do_syncrep2 rid=004
Apr 14 15:44:32 auth03 slapd[1467]: do_syncrep2: rid=004 got empty syncUUID
with LDAP_SYNC_ADD
Apr 14 15:44:32 auth03 slapd[1467]: connection_get(22)
Apr 14 15:44:32 auth03 slapd[1467]: connection_get(22): got connid=0
Apr 14 15:44:32 auth03 slapd[1467]: daemon: removing 22
Apr 14 15:44:32 auth03 slapd[1467]: do_syncrepl: rid=004 rc -1 retrying (29
retries left)
Here is the configs for each server: Each server has a unique server ID
as well. I haven't tried to get my main user database replicating, as it
appears the config database isn't replicating yet.
Auth03 Config:
slapcat -s olcDatabase={0}config,cn=config
dn: olcDatabase={0}config,cn=config
objectClass: olcDatabaseConfig
olcDatabase: {0}config
olcAccess: {0}to * by
dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external
,cn=auth" manage by dn.base="cn=Admin,cn=config" manage by
dn.exact="uid=sync
repl,ou=System,dc=livegamer,dc=com" read by * none
olcRootPW:: <redacted>
olcAddContentAcl: TRUE
olcLastMod: TRUE
olcMaxDerefDepth: 15
olcReadOnly: FALSE
olcRootDN: cn=config
olcSyncUseSubentry: FALSE
olcMonitoring: TRUE
structuralObjectClass: olcDatabaseConfig
olcSyncrepl: {0}rid=004 provider="ldaps://auth04.pax.livegamer.com"
type=refre
shAndPersist retry="60 30 300 +" searchbase="cn=config" bindmethod=simple
bin
ddn="uid=syncrepl,ou=System,dc=livegamer,dc=com" tls_reqcert=allow
credential
s=<redacted>
olcSyncrepl: {1}rid=003 provider=ldaps://auth03.pax.livegamer.comtype=refresh
AndPersist retry="60 30 300 +" searchbase="cn=config" bindmethod=simple
bindd
n="uid=syncrepl,ou=System,dc=livegamer,dc=com" tls_reqcert=allow
credentials=
<redacted>
olcMirrorMode: TRUE
entryCSN: 20140414153033.402795Z#000000#003#000000
modifiersName: cn=config
modifyTimestamp: 20140414153033Z
dn: olcOverlay={0}syncprov,olcDatabase={0}config,cn=config
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: {0}syncprov
structuralObjectClass: olcSyncProvConfig
entryUUID: 9cec0db6-5377-1033-940a-233ba8867211
creatorsName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
createTimestamp: 20140408144128Z
olcSpCheckpoint: 100 10
entryCSN: 20140409154557.570189Z#000000#003#000000
modifiersName: cn=config
modifyTimestamp: 20140409154557Z
dn: olcOverlay={1}syncprov,olcDatabase={0}config,cn=config
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: {1}syncprov
structuralObjectClass: olcSyncProvConfig
entryUUID: 4c7ef0fe-538c-1033-941d-1b46f26937f8
creatorsName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
createTimestamp: 20140408170933Z
olcSpCheckpoint: 100 10
entryCSN: 20140409154608.786640Z#000000#003#000000
modifiersName: cn=config
modifyTimestamp: 20140409154608Z
Auth04 Config:
slapcat -s olcDatabase={0}config,cn=config
dn: olcDatabase={0}config,cn=config
objectClass: olcDatabaseConfig
olcDatabase: {0}config
olcRootPW:: <redacted>
olcAddContentAcl: TRUE
olcLastMod: TRUE
olcMaxDerefDepth: 15
olcReadOnly: FALSE
olcRootDN: cn=config
olcSyncUseSubentry: FALSE
olcMonitoring: TRUE
structuralObjectClass: olcDatabaseConfig
olcAccess: {0}to * by
dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external
,cn=auth" manage by dn.base="cn=Admin,cn=config" manage by
dn.exact="uid=sync
repl,ou=System,dc=livegamer,dc=com" read by * none
olcSyncrepl: {0}rid=003 provider=ldaps://auth03.pax.livegamer.comtype=refresh
AndPersist retry="60 30 300 +" searchbase="cn=config" bindmethod=simple
bindd
n="uid=syncrepl,ou=System,dc=livegamer,dc=com" tls_reqcert=allow
credentials=
<redacted>
olcSyncrepl: {1}rid=004 provider=ldaps://auth04.pax.livegamer.comtype=refresh
AndPersist retry="60 30 300 +" searchbase="cn=config" bindmethod=simple
bindd
n="uid=syncrepl,ou=System,dc=livegamer,dc=com" tls_reqcert=allow
credentials=
<redacted>
olcMirrorMode: TRUE
entryCSN: 20140414152957.400652Z#000000#004#000000
modifiersName: cn=config
modifyTimestamp: 20140414152957Z
dn: olcOverlay={0}syncprov,olcDatabase={0}config,cn=config
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: {0}syncprov
structuralObjectClass: olcSyncProvConfig
entryUUID: aabb3a20-5377-1033-8399-57009c40c824
creatorsName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
createTimestamp: 20140408144151Z
olcSpCheckpoint: 100 10
entryCSN: 20140409154507.269469Z#000000#004#000000
modifiersName: cn=config
modifyTimestamp: 20140409154507Z
dn: olcOverlay={1}syncprov,olcDatabase={0}config,cn=config
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: {1}syncprov
structuralObjectClass: olcSyncProvConfig
entryUUID: 5151199a-538c-1033-83f9-bd35daeffcf0
creatorsName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
createTimestamp: 20140408170941Z
olcSpCheckpoint: 100 10
entryCSN: 20140409154526.632472Z#000000#004#000000
modifiersName: cn=config
modifyTimestamp: 20140409154526Z
Please let me know what additional info I may need to provide.
Thank you
Matt P.
9 years, 7 months
development mailing list?
by Paul B. Henson
I subscribed to the development mailing list Tuesday, to migrate a thread
discussing the password policy implementation that I was told belonged
there. However, neither of my two postings to that list seem to have been
delivered. I am definitely subscribed, having received a message from the
list, and my messages to openldap-technical are coming through fine, so I
don't think my mail isn't reaching the list.
The list description says the list is semi-moderated, so I'm assuming that
as a new subscriber my postings are awaiting approval. Reviewing the
archives, it doesn't seem like it's that busy of a list. I was just
wondering if anyone knew how long it usually took for a new subscriber to be
approved for posting?
Thanks.
9 years, 7 months
Q: syncprov_sendresp IDs
by Ulrich Windl
Hi!
Can anybody explain what the "rid", "sid", and "to" IDs refer to in the syncprov_sendresp message? Example:
slapd[28206]: syncprov_sendresp: to=002, cookie=rid=006,sid=003,csn=20140430111351.287889Z#000000#001#000000
I guess the original is from SID==1, the local SID==003. Does it send to SID==2? If so, what is rid==6 referring to?
Regards,
Ulrich
9 years, 7 months
Duplicate dynamically an OU with another RDN ?
by Sylvain
Hi !
I have a branch "ou=people" where RDN are in the form "X1234" and NEVER
change for one people.
Ex. : uid=X1234,ou=people,dc=example,dc=org
In this node, I have the login under "eduPersonPrincipalName" attribute
which MAY change.
Some applications doesn't allow us to define which login to use and so take
"uid" attribute by default, not so cool.
Is there any possibility in OpenLDAP to duplicate dynamically an OU with
another RDN to have for example :
uid=sylvain,ou=peoplebis,dc=example,dc=org ?
Best regards,
Sylvain
9 years, 7 months
Can't override TLS_REQCERT
by Andrew D. Arenson
I found the previous post of someone else who faced
the same problem I'm encountering, but I did not see a posted
solution:
http://www.openldap.org/lists/openldap-technical/201310/msg00084.html
In /etc/openldap/ldap.conf, TLS_REQCERT is set to 'allow'.
I would like to leave this setting, but override it for a
specific invocation of ldapsearch. I have attempted to do so by
setting TLS_REQCERT in ~/.ldaprc and be setting the LDAPTLS_REQCERT
environment variable. Neither has worked.
Interestingly, I _HAVE_ found that I can override TLS_CACERTDIR
in either of those locations.
Is this a bug?
Andy
--
Andrew D. Arenson | aarenson (@) iu.edu
Advanced Biomedical IT Core, Research Technologies, UITS | W (317) 278-1208
RT is a PTI Cyberinfrastructure & Service Center | C (317) 679-4669
Indiana University Purdue University Indianapolis | F (317) 278-1852
9 years, 7 months
What is the option '-e ppolicy' ?
by Thierry Thelliez
Hello,
Looking at the test source code of 2.4.39 for the ppolicy script, I can see
the ldapsearch is using a '-e ppolicy' option. The man page for
ldapsearch lists 'general extensions' under -e and -E options. But I
cannot figure out what these extensions are.
What is '-e ppolicy' ? and when do you need it?
Thanks,
Thierry
9 years, 7 months
