[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openldap-technical
Subject:    Re: solaris client ldap-backend to AD and DSE
From:       Howard Chu <hyc () symas ! com>
Date:       2023-11-30 17:35:29
Message-ID: 8292b1a4-6739-04fe-e1e6-426367f652ac () symas ! com
[Download RAW message or body]

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.
> 


-- 
  -- Howard Chu
  CTO, Symas Corp.           http://www.symas.com
  Director, Highland Sun     http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/


[prev in list] [next in list] [prev in thread] [next in thread]