I need to configure openldap as a proxy to AD so that AD can be upgraded to version 2019.
Currently using Unix services for Windows, which works to provide nis information to solaris (11) and zfsappliance but it was deprecated after windows 2012.
There's still nis info info in various attributes in AD schema, but the nis service is about to go. So an alternative is needed.
I have the proxy configured with ldap-backend and its very happy to provide all the attribute information, but the solaris ldap client wants the DSE through the proxy and for the life of me I can't work out what is impeding it.
I can "ldapsearch -Y EXTERNAL -H ldapi:/// -b "" -s base -LLL "+"" on the openldap system and the DSE is returned
and I can get the DSE with an ldapsearch from the solaris client if I point directly at the AD ldap server, but if i point solaris at the openldap proxy - nada. This really upsets the ldapclient on solaris - it feels degraded.
It feels like its an access issue as I can get a DSE when root on the openldap system.
from config:
# {1}ldap, config dn: olcDatabase={1}ldap,cn=config objectClass: olcDatabaseConfig objectClass: olcLDAPConfig olcDatabase: {1}ldap olcSuffix: dc=myorg,dc=lcl olcAccess: {0}to dn.base="" by * read olcAccess: {1}to dn.base="cn=Schema" by * read olcAccess: {2}to dn.base="cn=Subschema" by * read olcAccess: {3}to * by self read by users read by anonymous auth olcAddContentAcl: FALSE olcLastMod: FALSE olcMaxDerefDepth: 15 olcReadOnly: TRUE olcRootDN: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth olcSyncUseSubentry: FALSE olcMonitoring: FALSE olcDbURI: "ldaps://myorgdevad.myorgdev.lcl:636"
Any guidance appreciated - logs available on request.
Craig Silva | Specialist Engineer – Unix & Storage Services Level 18, 80 Collins Street, Melbourne 3000 (03) 9063 5126 cenitex.vic.gov.au Cenitex acknowledges the Traditional Owners and custodians of the land and we pay our respects to their Elders, past, present and emerging. We are an inclusive workplace that embraces diversity in all its forms.
---------------------------------------------------------------------- Notice:
This email and any attachments may contain information that is personal, confidential, legally privileged and/or copyright. No part of it should be reproduced, adapted or communicated without the prior written consent of the copyright owner.
It is the responsibility of the recipient to check for and remove viruses.
If you have received this email in error, please notify the sender by return email, delete it from your system and destroy any copies. You are not authorised to use, communicate or rely on the information contained in this email.
Please consider the environment before printing this email.
Craig H Silva (Cenitex) wrote:
I need to configure openldap as a proxy to AD so that AD can be upgraded to version 2019.
Currently using Unix services for Windows, which works to provide nis information to solaris (11) and zfsappliance but it was deprecated after windows 2012.
There's still nis info info in various attributes in AD schema, but the nis service is about to go. So an alternative is needed.
I have the proxy configured with ldap-backend and its very happy to provide all the attribute information, but the solaris ldap client wants the DSE through the proxy and for the life of me I can't work out what is impeding it.
I can "ldapsearch -Y EXTERNAL -H ldapi:/// -b "" -s base -LLL "+"" on the openldap system and the DSE is returned
and I can get the DSE with an ldapsearch from the solaris client if I point directly at the AD ldap server, but if i point solaris at the openldap proxy - nada. This really upsets the ldapclient on solaris - it feels degraded.
It feels like its an access issue as I can get a DSE when root on the openldap system.
You're talking about the rootDSE, not just any DSE.
The rootDSE is a per-server virtual entry. Requests for the rootDSE received by slapd are handled by the slapd frontend, they don't ever get forwarded to any backends. As such, it's impossible for back-ldap to proxy those requests to anywhere else.
You should just extract whatever attributes Solaris wants to see from the remote server, and add them to the slapd rootDSE. See the olcRootDSE directive in slapd-config(5).
from config:
# {1}ldap, config dn: olcDatabase={1}ldap,cn=config objectClass: olcDatabaseConfig objectClass: olcLDAPConfig olcDatabase: {1}ldap olcSuffix: dc=myorg,dc=lcl olcAccess: {0}to dn.base="" by * read olcAccess: {1}to dn.base="cn=Schema" by * read olcAccess: {2}to dn.base="cn=Subschema" by * read olcAccess: {3}to * by self read by users read by anonymous auth olcAddContentAcl: FALSE olcLastMod: FALSE olcMaxDerefDepth: 15 olcReadOnly: TRUE olcRootDN: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth olcSyncUseSubentry: FALSE olcMonitoring: FALSE olcDbURI: "ldaps://myorgdevad.myorgdev.lcl:636"
Any guidance appreciated - logs available on request.
Craig Silva | Specialist Engineer – Unix & Storage Services Level 18, 80 Collins Street, Melbourne 3000 (03) 9063 5126 cenitex.vic.gov.au Cenitex acknowledges the Traditional Owners and custodians of the land and we pay our respects to their Elders, past, present and emerging. We are an inclusive workplace that embraces diversity in all its forms.
Notice:
This email and any attachments may contain information that is personal, confidential, legally privileged and/or copyright. No part of it should be reproduced, adapted or communicated without the prior written consent of the copyright owner.
It is the responsibility of the recipient to check for and remove viruses.
If you have received this email in error, please notify the sender by return email, delete it from your system and destroy any copies. You are not authorised to use, communicate or rely on the information contained in this email.
Please consider the environment before printing this email.
Craig H Silva (Cenitex) wrote:
from config:
# {1}ldap, config dn: olcDatabase={1}ldap,cn=config objectClass: olcDatabaseConfig objectClass: olcLDAPConfig olcDatabase: {1}ldap olcSuffix: dc=myorg,dc=lcl olcAccess: {0}to dn.base="" by * read olcAccess: {1}to dn.base="cn=Schema" by * read olcAccess: {2}to dn.base="cn=Subschema" by * read
The above 3 ACLs are useless since none of them reside under the olcSuffix namespace.
olcAccess: {3}to * by self read by users read by anonymous auth olcAddContentAcl: FALSE olcLastMod: FALSE olcMaxDerefDepth: 15 olcReadOnly: TRUE olcRootDN: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth olcSyncUseSubentry: FALSE olcMonitoring: FALSE olcDbURI: "ldaps://myorgdevad.myorgdev.lcl:636"
Any guidance appreciated - logs available on request.
openldap-technical@openldap.org