openldap-technical

openldap-technical@openldap.org

14 participants
9796 discussions

Should I be able to select an 'orphaned' DN from a translucent overlap proxy?
by Sullivan, Daniel [AAA] 31 Mar '16

31 Mar '16

Hi, I am writing to confirm the expected behavior of a translucent overlay proxy. I have the proxy working and can filter from the local database using the olcTranslucentLocal configuration option (I can see a merged record). My question pertains to ‘orphaned data’. For example, I can arbitrarily add a record to the local database by DN using ldapadd, the glue records are created and I can see the record in the output of slapcat. My problem is that a search via ldapsearch does not return this record unless their is a matching DN in the remote database, even if I am filtering by an attribute specifed in olcTranslucentLocal . Is this the expected behavior? There is more that one reason why I want to do this, but the lowest common denominator is that people are going to be moving records around upstream and I’d like to keep the local database tidy by blowing away records that no longer have a matching remote DN. On that note, the second reason why I’m interested in doing this is to create an individual default group for each user in the local database. I was planning on creating an actual group for each user programmatically, and have no problem doing this. Is there a more elegant best practice way to facilitate this sort of thing (i.e. an overlay solution), or is just creating the groups the way to go? I am using openldap-ltb.x86_64 2.4.44-2.el6. I appreciate your time and expertise. Dan ******************************************************************************** This e-mail is intended only for the use of the individual or entity to which it is addressed and may contain information that is privileged and confidential. If the reader of this e-mail message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is prohibited. If you have received this e-mail in error, please notify the sender and destroy all copies of the transmittal. Thank you University of Chicago Medicine and Biological Sciences ********************************************************************************

1 0

Question about ldap_init()/ldap_initialize() behavior with OpenLDAP
by Frank Crow 31 Mar '16

31 Mar '16

I'm not clear on whether I'm allowed to ask "C" API questions here. If not, I apologize in advance and please disregard in that case. However, the question is more about configuration than coding. I'm seeing that the ldap_init() function allows the hostname parameter to be null or a list of hosts. If it is null, the function attempts to determine the default ldap host. How does it determine the default LDAP host when the hostname parameter is null? Does it load the list of hosts from the ldap.conf URI parameter? And/or does it use the LDAPURI environment variable? Thanks, -- Frank

4 7

CSN is matching but entries count differs in master and slaves
by scn_73＠yahoo.com 31 Mar '16

31 Mar '16

Hello all, CSN is matching with master and slaves but if i count number of entries it's different. I am replicating complete DIT so count should be equal in Master and slave. Should i diff the missed entries and catch them in replications logs. Please suggest .. $ ldapsearch -H ldaps://ldapmaster -D "cn=manager,dc=xxx,dc=com" -x -xxx -s base contextCSN -LLL dn: dc=xxx,dc=com contextCSN: 20160326180539Z#000006#00#000000 $ ldapsearch -H ldaps://ldap-slave -D "cn=manager,dc=xxx,dc=com" -x -wxx -s base contextCSN -LLL dn: dc=xxx,dc=com contextCSN: 20160326180539Z#000006#00#000000 $ ldapsearch -H ldaps://ldapmaster -D "cn=manager,dc=xxx,dc=com" -x -wxx -s sub "objectclass=*" | tail -2 # numResponses: 28751 # numEntries: 28750 $ ldapsearch -H ldaps://ldap-slave "cn=manager,dc=xxx,dc=com" -x -wxxx -s sub "objectclass=*" | tail -2 # numResponses: 28772 # numEntries: 28771

3 4

ACL problem
by Cole 29 Mar '16

29 Mar '16

Hi, I am using OLC and ACL's to limit response from LDAP based on IP address, and this is working fine if I have a single ACL. When I add a second ACL, with a different IP address, the new ACL works, but the previous one does not. Example: Entries in LDAP: # 10.0.0.92, servers, test.com dn: cn=10.0.0.92,ou=servers,dc=test,dc=com objectClass: groupOfNames cn: 10.0.0.92 description: Allowed access member: uid=aaa,dc=test,dc=com # 10.0.0.94, servers, test.com dn: cn=10.0.0.94,ou=servers,dc=test,dc=com objectClass: groupOfNames cn: 10.0.0.94 description: Allowed access member: uid=aaa,dc=test,dc=com # aaa, test.com dn: uid=aaa,dc=test,dc=com objectClass: inetOrgPerson objectClass: posixAccount objectClass: ldapPublicKey objectClass: shadowAccount uid: aaa uidNumber: 10005 gidNumber: 10005 homeDirectory: /home/aaa loginShell: /usr/local/bin/bash mail: a(a)test.com ou: users cn: User A sn: A userPassword:: xxx OLC entries: # {1}ldif, config dn: olcDatabase={1}ldif,cn=config objectClass: olcLdifConfig olcDatabase: {1}ldif olcDbDirectory: /var/pq/0/mount/resolve/installations/entities/vmi/location/za /parts/new/instances/test/openldap-data olcSuffix: dc=test,dc=com olcAccess: {0}to filter=(|(&(objectClass=inetOrgPerson)(memberOf=cn=10.0.0.92, ou=servers,dc=test,dc=com))(objectClass=posixGroup)) by self read by peername .ip="10.0.0.92" read by * none olcAccess: {1}to * by self write by peername.ip="127.0.0.1" write by * none olcRootDN: cn=Manager,dc=test,dc=com olcRootPW: test At this point, running ldapsearch from the computer with ip address 10.0.0.92 works correctly, and only the filtered results are returned. If I then add a second ACL: # {1}ldif, config dn: olcDatabase={1}ldif,cn=config objectClass: olcLdifConfig olcDatabase: {1}ldif olcDbDirectory: /var/pq/0/mount/resolve/installations/entities/vmi/location/za /parts/new/instances/test/openldap-data olcSuffix: dc=test,dc=com olcAccess: {0}to filter=(|(&(objectClass=inetOrgPerson)(memberOf=cn=10.0.0.94, ou=servers,dc=test,dc=com))(objectClass=posixGroup)) by self read by peername .ip="10.0.0.94" read by * none olcAccess: {1}to filter=(|(&(objectClass=inetOrgPerson)(memberOf=cn=10.0.0.92, ou=servers,dc=test,dc=com))(objectClass=posixGroup)) by self read by peername .ip="10.0.0.92" read by * none olcAccess: {2}to * by self write by peername.ip="127.0.0.1" write by * none olcRootDN: cn=Manager,dc=test,dc=com olcRootPW: test The computer with IP 10.0.0.94 can now query LDAP, and receives the correct filtered results, however the computer with IP 10.0.0.92 receives a blank result: $ ldapsearch -x -h 10.0.0.91 -b dc=test,dc=com # extended LDIF # # LDAPv3 # base <dc=test,dc=com> with scope subtree # filter: (objectclass=*) # requesting: ALL # # search result search: 2 result: 0 Success # numResponses: 1 Is this the way that ACLs work in openldap? Or have I missed a configuration setting somewhere? Thanks /Cole

1 1

Transparent Overlay proxy not returning memberOf
by Sullivan, Daniel [AAA] 29 Mar '16

29 Mar '16

Hi, I apologize if this is a silly question; I’ve done a preliminary search of the mailing list archives and read through the documentation in as much detail as I can muster for the moment. I can’t seem to find an answer to this seemingly simple question. My question is this; I am implementing an Overlay Proxy against Active Directory. I have it working (i.e. I can query the local and remote databases and get a composite LDIF record returned that merges my added attributes). My problem is that the returned record doesn’t appear to contain the complete attribute set from the remote server. For example, if I use ldapsearch to query Active Directory directly, I see a bunch of memberOf: attributes for the user object returned. When I query the proxy, I clearly see the brunt of AD attributes for my user object, although the memberOf attributes are missing. Is there a reason for this? My configuration is very basic, and I don’t understand why attributes would be filtered by the proxy. My configuration is probably as simple as it can get (for the proxy): dn: olcOverlay={0}translucent,olcDatabase={2}bdb,cn=config objectClass: olcOverlayConfig objectClass: olcTranslucentConfig olcOverlay: {0}translucent olcTranslucentLocal: uidNumber structuralObjectClass: olcTranslucentConfig dn: olcDatabase={0}ldap,olcOverlay={0}translucent,olcDatabase={2}bdb,cn=conf ig objectClass: olcLDAPConfig objectClass: olcTranslucentDatabase olcDatabase: {0}ldap olcDbURI: ldap://domaincontroller:389 olcDbACLBind: bindmethod=simple timeout=0 network-timeout=0 binddn="cn=s.a aa.ldapsearch,ou=SrvcAccts,ou=AAA,dc=somedomain,dc=uchicago,dc=edu" credentials =“secret" tls_reqcer t=never olcDbIDAssertBind: bindmethod=simple binddn="cn=s.aaa.ldapsearch,ou=SrvcAcc ts,ou=AAA,dc=somedomain,dc=uchicago,dc=edu" credentials=“secret" mode=none tls_reqcert=never olcDbIDAssertAuthzFrom: {0}dn.regex:.* olcDbRebindAsUser: TRUE structuralObjectClass: olcLDAPConfig I’ve turned on debug logging for slapd and it looks like the memberOf attributes are being served up by AD. If anybody could provide insight as to why this would be occurring I would greatly appreciate it. Thank you, Dan Sullivan ******************************************************************************** This e-mail is intended only for the use of the individual or entity to which it is addressed and may contain information that is privileged and confidential. If the reader of this e-mail message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is prohibited. If you have received this e-mail in error, please notify the sender and destroy all copies of the transmittal. Thank you University of Chicago Medicine and Biological Sciences ********************************************************************************

1 1

ITS 7345 (Add Connection Information in Access Log Entries)
by Dario Zanzico 29 Mar '16

29 Mar '16

I've been using the patch attached to ITS 7345 for a couple months without any problem, and I find it necessary for working a comprehensive audit system. Can any work be done to make it acceptable for merging? thanks, dario

1 0

Syncrepl TLS woes
by Xavier Landreville 28 Mar '16

28 Mar '16

Hello, I am currently in the grips of trying to get syncrepl replication working with StartTLS. It was working fine until recently. The only change that occurred over the last 12 months (that relates to OpenLDAP) is that I've started requiring TLS for connections. My provider is running OpenLDAP 2.4.31 on Ubuntu 14.04, while one consumer is running the exact same version on a Ubuntu 14.04 machine and the other consumer is running OpenLDAP 2.4.28 on Ubuntu 12.04. The provider has, AFAIK, a correct TLS configuration, given that I can connect and search using the ldapsearch -ZZ utility from any of the servers. The syncprov overlay is loaded and configured on the provider. The consumers have the following (redacted, with unique rid values) olcSyncRepl: olcSyncrepl: {0}rid=1 provider=ldap://[LDAP_DNS] bindmethod=simple bi nddn="[SYNC_USER]" credentials=[SYNC_PASS] searchbase="[L DAP_BASE]" logbase="cn=accesslog" logfilter="(&(objectClass=auditWr iteObject)(reqResult=0))" schemachecking=on type=refreshAndPersist retry="60 +" syncdata=accesslog starttls=critical tls_reqcert=demand Unfortunately, on both consumers can't seem to be able to actually start the TLS connection: slapd[1257]: slap_client_connect: URI=ldap://[LDAP_DNS] Error, ldap_start_tls failed (-11) slapd[1257]: do_syncrepl: rid=001 rc -11 retrying And the provider shows the following errors: slapd[2126]: conn=1586 fd=100 ACCEPT from IP=[CONSUMER_IP]:35500 (IP=0.0.0.0:389) slapd[2126]: conn=1586 op=0 EXT oid=1.3.6.1.4.1.1466.20037 slapd[2126]: conn=1586 op=0 STARTTLS slapd[2126]: conn=1586 op=0 RESULT oid= err=0 text= slapd[2126]: conn=1586 fd=100 closed (TLS negotiation failure) Is there anything that I'm missing? Cheers, -- Xavier

3 2

LDAP authentication with uid
by Mary Kao 23 Mar '16

23 Mar '16

Hello, This is a real newbie question ::) I have configured apache httpd to use LDAP for basic authentication (userid and password). I am not sure what the directory DN should look like when using "uid" rather than "cn"? In my LDAP directory I have: dn: cn=Christine Smith,ou=ELOGAccounts,ou=RavenApps,dc=my-domain,dc=com objectClass: top objectClass: person objectClass: organizationalPerson objectClass: uidObject cn: Christine Smith sn: Smith uid: christine userPassword:: Y2hyaXN0aW5l Where do I put the "uid" so that when the httpd sends over the uid the ldap server will search on it? Thank you,Mary

4 4

Safely Allow Users to Write self Attributes
by Daniel Howard 23 Mar '16

23 Mar '16

I would like to allow users to ldapmodify a few of their attibutes ... sshPublicKey,gecos .. This does not appear to do the trick: 0-14:08 djh@ldap0 ~$ *sudo ldapsearch -Q -LLL -Y EXTERNAL -H ldapi:/// -b \> cn=config '(olcDatabase={1}hdb)' olcAccess* dn: olcDatabase={1}hdb,cn=config olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by anonymou s auth by dn="cn=admin,dc=example,dc=com" write by * none olcAccess: {1}to dn.base="" by * read olcAccess: {2}to * by dn="cn=admin,dc=example,dc=com" write by * read olcAccess: {3}to attrs=sshPublicKey,gecos by self write Why? I would guess the {2} rule "to * by * read" has precedence. As I understand it, if I wanted to re-order those rules, I would delete and rewrite the rules. This would require me to delete the rule that gives admin the access to write the rules in the first place ... sounds like a way to lock myself out of my LDAP database? So, my guess is that I want and LDIF like so: dn: olcDatabase={1}hdb,cn=config changetype: modify remove: olcAccess olcAccess: {3}to attrs=sshPublicKey,gecos by self write - add: olcAccess olcAccess: {2}to attrs=sshPublicKey,gecos by self write - add: olcAccess olcAccess: {3}to * by dn="cn=admin,dc=example,dc=com" write by * read - remove: olcAccess olcAccess: {2}to * by dn="cn=admin,dc=example,dc=com" write by * read If I run this as cn=admin then it should: 1) Remove ineffective {3} 2) Add an effective {2} (now there are two {2}s..) 3) Add a new {3} to match incumbent {2} 4) Remove incumbent {2} I shouldn't lock myself out because I add a new rule for admin access before deleting the old rule, and as far as LDAP is superficially concerned, all these olcAccess attributes are just unique records, so the conflicting number rules aren't going to be a problem .. ? Am I on the right track? Thanks, -danny -- http://dannyman.toldme.com

2 2

Translucent proxy and changing upstream DNs
by Sullivan, Daniel [AAA] 23 Mar '16

23 Mar '16

Hi, Please forgive my ignorance if this is a stupid question; I have only been messing around with OpenLDAP for a few days, but I believe I hit a roadblock that somebody must have seen somewhere. Basically, I am planning on using a translucent proxy to augment the attribute set served up by an external LDAP provider. Specifically I am provisioning uidNumber and gidNumbers for AD accounts. I cannot populate the upstream RFC2307 attributes. My problem is this; it is my understanding that a translucent proxy is going to match records in the local and remote databases based on DN. Admins are going to be moving user and group objects around upstream, which will reliably break the mapping between local and remote databases after the objects with uidNumber and gidNumbers are populated into the local database. I can think of a couple of algorithms that would reconcile this, although they would require custom coding and maintaining a localized external view of the data (i.e. in a SQL database). So, I suppose my question is this; Is there an elegant way to solve this problem, for example, having the translucent proxy map by an attribute other than DN, such as an AD SID? I appreciate your time and input :-) Thank you, Dan Sullivan ******************************************************************************** This e-mail is intended only for the use of the individual or entity to which it is addressed and may contain information that is privileged and confidential. If the reader of this e-mail message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is prohibited. If you have received this e-mail in error, please notify the sender and destroy all copies of the transmittal. Thank you University of Chicago Medicine and Biological Sciences ********************************************************************************

2 4

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical