Yes, this. I saw that in all of my tools On Wed, Mar 23, 2022, 1:19 PM Jason King <[email protected]> wrote:
> 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]> > 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 > > > > On 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-Mdffc59a113e4b6b36154f3b2> > ------------------------------------------ illumos: illumos-discuss Permalink: https://illumos.topicbox.com/groups/discuss/Tb99e88b61c690e04-M1ee5fd09d4c9a4fb9022a36a Delivery options: https://illumos.topicbox.com/groups/discuss/subscription
