I think what I wound up doing was making my Solaris box an LDAP slave, and then running my LDAP bind against localhost without any encryption.
I'm digging through notes from 2010 when I was using Apple Open Directory as my LDAP master, and was playing with overlaying info from AD ... Ian On Wed, Mar 23, 2022 at 8:22 AM Schweiss, Chip <[email protected]> wrote: > I'm still fighting this. It's really hard to see where it is failing. > ldapclient times out starting the ldap client service. I can see from > tcpdump it is trying repeatedly to make the connection but appears to be > failing with the SSL handshake. > > I collected the certificate chain with openssl: > > # openssl s_client -connect accounts14.ad.wustl.edu:636 -showcerts > > It gave me a CA cert and server cert. I put those both in files and > created the certificate store: > > # certutil -A -n ca-cert -i ~/accounts.ldap-certs/ca.crt -a -t 'C,,' -d > /var/ldap > # certutil -A -n accounts-ldap-cert -i > ~/accounts.ldap-certs/accounts-ldap.crt -a -t 'C,,' -d /var/ldap > > Here's my ldapclient call: > > ldapclient -v manual \ > -a credentialLevel=proxy \ > -a proxyDN="CN=NRG-zfs-proxy,OU=Service > Accounts,DC=accounts,DC=ad,DC=wustl,DC=edu" \ > -a proxyPassword="**{redacted}**" \ > -a authenticationMethod=tls:sasl/DIGEST-MD5 \ > -a defaultSearchBase="DC=accounts,DC=ad,DC=wustl,DC=edu" \ > -a domainName=accounts.ad.wustl.edu \ > -a certificatePath=/var/ldap \ > -a defaultServerList=accounts14.ad.wustl.edu:636 \ > -a followReferrals=false \ > -a defaultSearchScope=sub \ > -a attributeMap=group:userpassword=userPassword \ > -a attributeMap=group:memberuid=memberUid \ > -a attributeMap=group:gidnumber=gidNumber \ > -a attributeMap=passwd:gecos=gecos \ > -a attributeMap=passwd:gidnumber=gidNumber \ > -a attributeMap=passwd:uidnumber=uidNumber \ > -a attributeMap=passwd:uid=sAMAccountName \ > -a attributeMap=passwd:homedirectory=unixHomeDirectory \ > -a attributeMap=passwd:loginshell=loginShell \ > -a attributeMap=shadow:shadowflag=shadowFlag \ > -a attributeMap=shadow:userpassword=userPassword \ > -a attributeMap=shadow:uid=sAMAccountName \ > -a objectClassMap=group:posixGroup=group \ > -a objectClassMap=passwd:posixAccount=user \ > -a objectClassMap=shadow:shadowAccount=user \ > -a > serviceSearchDescriptor=passwd:OU=Current,OU=People,DC=accounts,DC=ad,DC=wustl,DC=edu?sub > \ > -a > serviceSearchDescriptor=group:OU=Groups,DC=accounts,DC=ad,DC=wustl,DC=edu?sub > > > I can use the same credentials to do ldapsearch via the SSL port so I at > least know that it works. I've tried every documented authentication > method. It aways times out starting the service. > > Any clue what I'm missing or doing wrong here? > > Thanks again, > -Chip > > > > > > On Sat, Mar 19, 2022 at 2:39 PM Brian Bennett <[email protected]> > wrote: > >> I can also confirm that LDAPS works. I've been using it for years. The >> only catch is that you need to import your certs into the LDAP trust store. >> >> The syntax, if you need it, is: >> >> certutil -A -d . -i <certificate file> -n <certificate name> -t 'C,,' >> >> You need to import all the way up to the root. There is no pre-existing >> list of trust anchors. >> >> >> -- >> Brian Bennett >> Systems Engineer, Cloud Operations >> Joyent, Inc. | www.joyent.com >> >> On Mar 18, 2022, at 12:44 PM, Jason King <[email protected]> >> wrote: >> >> A bit of clarification ‘ldaps’ is running ldap over TLS on port 636 >> (similar to http port 80 and https port 443). >> >> This is different from StartTLS which connects in plaintext on port 389 >> then sends a request to switch the existing connection to TLS. >> >> Ldaps should be supported, StartTLS is not. >> >> There’s also a bit of a third option. If you are using smbadm to join an >> illumos system to active directory and use idmap to map SIDs to UID/GIDs, >> it can also use SASL/GSSAPI (basically Kerberos). >> >> >> >> *From: *Ian Kaufman <[email protected]> >> *Date: *Friday, March 18, 2022 at 2:36 PM >> *To: *omnios-discuss <[email protected]> >> *Cc: *illumos-discuss <[email protected]> >> *Subject: *[discuss] Re: [OmniOS-discuss] Active Directory LDAP client >> I used to force port 636 comm with my OpenSolaris clients and had my LDAP >> slaves listen and handle both TLS and LDAPS >> >> Ian >> >> On Fri, Mar 18, 2022 at 8:38 AM Schweiss, Chip <[email protected]> >> wrote: >> >> I'm trying to join my OmniOS 038 systems to our AD so that UIDs and GIDs >> resolve and I can get around the NFS 16 group limit. >> >> The problem I'm having is that it appears the LDAP client in Illumos has >> no support for LDAPS which is now a requirement. >> >> From the ldapclient man page: >> >> CAUTION >> Currently StartTLS is not supported by libldap.so.5, therefore the >> port >> number provided refers to the port used during a TLS open, rather >> than >> the port used as part of a StartTLS sequence. To avoid timeout >> delays, >> mixed use of TLS and non-TLS authentication mechanisms is not >> recommended. >> >> For example: >> >> -h foo:1000 -a authenticationMethod=tls:simple >> >> ...or: >> >> defaultServerList= foo:1000 >> authenticationMethod= tls:simple >> >> The preceding refers to a raw TLS open on host foo port 1000, not >> an >> open, StartTLS sequence on an unsecured port 1000. If port 1000 is >> unsecured the connection will not be made. >> >> As a second example, the following will incur a significant timeout >> delay while attempting the connection to foo:636 with an unsecured >> bind. >> >> defaultServerList= foo:636 foo:389 >> authenticationMethod= simple >> >> Has anyone found a way to work around this? >> >> Thanks, >> -Chip >> >> >> >> -- >> Ian Kaufman >> Research Systems Administrator >> UC San Diego, Jacobs School of Engineering ikaufman AT ucsd DOT edu >> >> *UC San Diego is working thoughtfully and strategically to consider our >> return to campus, with safety as the top priority. Stay informed about UC >> San Diego developments and updates in response to COVID-19 at * >> *https://returntolearn.ucsd.edu* <https://returntolearn.ucsd.edu/> >> >> >> *illumos <https://illumos.topicbox.com/latest>* / omnios-discuss / see > discussions <https://illumos.topicbox.com/groups/omnios-discuss> + > participants <https://illumos.topicbox.com/groups/omnios-discuss/members> > + delivery options > <https://illumos.topicbox.com/groups/omnios-discuss/subscription> > Permalink > <https://illumos.topicbox.com/groups/omnios-discuss/Tb99e88b61c690e04-Me0d1b59fa40cbdd6643e2e4d> > -- Ian Kaufman Research Systems Administrator UC San Diego, Jacobs School of Engineering ikaufman AT ucsd DOT edu *UC San Diego is working thoughtfully and strategically to consider our return to campus, with safety as the top priority. Stay informed about UC San Diego developments and updates in response to COVID-19 at https://returntolearn.ucsd.edu <https://returntolearn.ucsd.edu/>* ------------------------------------------ illumos: illumos-discuss Permalink: https://illumos.topicbox.com/groups/discuss/Tb99e88b61c690e04-Mc762f26768173cf4b12dc862 Delivery options: https://illumos.topicbox.com/groups/discuss/subscription
