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 ********************************************************************************
Follow up:
It looks like if I explicitly request memberOf it is returned. Now I suppose my question is making this the default behavior for the proxy. I will go back to the docs on this and and ask again if I need further help. Sorry to bother you.
Dan Sullivan
On Mar 29, 2016, at 9:25 AM, Sullivan, Daniel [AAA] dsullivan2@bsd.uchicago.edu wrote:
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 ********************************************************************************
openldap-technical@openldap.org
-
Sullivan, Daniel [AAA]