One other thing I noticed – if you’re using LDAPS, change your authentication method to ‘tls:simple’
From: Schweiss, Chip <[email protected]> Date: Wednesday, March 23, 2022 at 1:07 PM To: illumos-discuss <[email protected]> Cc: omnios-discuss <[email protected]> Subject: Re: [discuss] [OmniOS-discuss] Active Directory LDAP client My problem is that I have no control over our institution's AD environment. There are a couple of dozen AD servers scattered around 3 campuses. There is a ldap proxy on each campus that I've been given SSL certs for all the way to the public root. This is where I started testing by putting all those certs in the database. I can do ldapseach against any AD server or the proxy with SSL. I did just manage to find one AD server still allowing unencrypted LDAP and got ldapclient to connect to it. That won't last as it will get decommissioned or upgraded soon. However, I can do other tests to see if it is even feasible. Now I'm thinking I may be at a dead end with Illumos here. Our AD has over 500K users in the database. That makes group lookups horribly slow unless some optimizations can be applied. I managed to find a group lookup mode in SSSd on our Linux systems that works reasonably well with local caching. Looking up my own ID on Illumos it takes over 4 minutes to look up groups and faults on ID lookup. I'm also missing nested group memberships. Nested memberships blow up really bad using the Microsoft prescribed (member:1.2.840.113556.1.4.1941:=%{UserDN}) search. That will almost always timeout on our domain. # time id lschweiss uid=1068768(lschweiss) gid=1000070 groups=1000070Segmentation Fault (core dumped) real 0m3.637s user 0m0.007s sys 0m0.015s # time groups lschweiss lschweiss : groups: cannot find name for group ID 1000070 1000070 nrg-group-ib wuitglobal require mfa WUSTL-EpicPlayground SN_DSO_WUIT WUSTL-EpicProduction WUIT-SL-Matlab MIR_MDM_Users NRG Desktop Support nrg NRG-IT-ADMIN AD-Groups-NRG root root Proxy-Faculty-Staff-WK Proxy-Students-WK NRG-HCPi-FS MIR All Users storage-uk-biobank-UKB_Genetics-ro NRG-MIRRIR-UKB-cardiac NRG-MIRRIR-UKB-pheno real 4m14.335s user 0m0.578s sys 0m0.784s Ultimately I want NFS to handle more than 16 groups. For this to happen the server needs to know what groups a user is in. ---- I guess I'll try SMB next. I couldn't find an SSSd port to Illumos. That would be great. -Chip On Wed, Mar 23, 2022 at 11:35 AM Brian Bennett <[email protected]<mailto:[email protected]>> wrote: You're probably missing the issuer (intermediate) and/or the trust anchor (root). Most servers do not provide the root, instead relying on the client to already have a list of trusted roots (i.e., the trust anchor). The illumos LDAP client has no trust anchor at all, so you need to use certutil to add the certs all the way up to and including the root self-signed certificate. If you're using a public issuer, you can probably just dig the root out of the curl or mozilla-certificates root list and add that. If you're using Let's Encrypt, you can use the list at the bottom of this message. For example, here's mine (these are all Let's Encrypt, by the way): # p certutil -d /var/ldap -L Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI E1 C,, R3 C,, Let's Encrypt Authority X4 C,, ISRG Root X2 C,, ISRG Root X1 C,, E2 C,, R4 C,, Let's Encrypt Authority X3 C,, Let's Encrypt Authority X4 C,, Let's Encrypt Authority X1 C,, Let's Encrypt Authority X2 C,, Let's Encrypt Authority X3 C,, Without the root in the trust database you'll get an error about certs issued by an unknown authority. For each PEM file you're adding, run this: openssl x509 -noout -subject_hash -issuer_hash -in <file> The issuer_hash on the leaf certificate will be the subject_hash on the next certificate in the chain. You need to keep following the chain until the subject_hash and issuer_hash are the same, that's the root certificate which also needs to be in the database. If you've got a broken chain, the certs won't be considered valid. If you're using Let's Encrypt, this is the current list of certs to add to the trust database: https://letsencrypt.org/certs/isrgrootx1.pem https://letsencrypt.org/certs/isrg-root-x2.pem https://letsencrypt.org/certs/lets-encrypt-x3-cross-signed.pem https://letsencrypt.org/certs/lets-encrypt-x4-cross-signed.pem https://letsencrypt.org/certs/lets-encrypt-r3.pem https://letsencrypt.org/certs/lets-encrypt-e1.pem https://letsencrypt.org/certs/lets-encrypt-r4.pem https://letsencrypt.org/certs/lets-encrypt-e2.pem https://letsencrypt.org/certs/letsencryptauthorityx1.pem https://letsencrypt.org/certs/letsencryptauthorityx2.pem https://letsencrypt.org/certs/letsencryptauthorityx3.pem https://letsencrypt.org/certs/letsencryptauthorityx4.pem -- Brian Bennett Systems Engineer, Cloud Operations Joyent, Inc. | www.joyent.com<http://www.joyent.com> On Mar 23, 2022, at 8:22 AM, Schweiss, Chip <[email protected]<mailto:[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<http://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<http://accounts.ad.wustl.edu/> \ -a certificatePath=/var/ldap \ -a defaultServerList=accounts14.ad.wustl.edu:636<http://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]<mailto:[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<http://www.joyent.com/> On Mar 18, 2022, at 12:44 PM, Jason King <[email protected]<mailto:[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]<mailto:[email protected]>> Date: Friday, March 18, 2022 at 2:36 PM To: omnios-discuss <[email protected]<mailto:[email protected]>> Cc: illumos-discuss <[email protected]<mailto:[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]<mailto:[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> / illumos-discuss / see discussions<https://illumos.topicbox.com/groups/discuss> + participants<https://illumos.topicbox.com/groups/discuss/members> + delivery options<https://illumos.topicbox.com/groups/discuss/subscription> Permalink<https://illumos.topicbox.com/groups/discuss/Tb99e88b61c690e04-M0f6a76b21138f9ca2e814b48> ------------------------------------------ illumos: illumos-discuss Permalink: https://illumos.topicbox.com/groups/discuss/Tb99e88b61c690e04-Me7734e21be8f9b04e97643ad Delivery options: https://illumos.topicbox.com/groups/discuss/subscription
