Have you tried filtering on more than one object? It came in very handy when I did searches against AD
On Wed, Mar 23, 2022, 11:06 AM Schweiss, Chip <[email protected]> wrote: > 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-Md22b6c86b1fb09d15a137472> > ------------------------------------------ illumos: illumos-discuss Permalink: https://illumos.topicbox.com/groups/discuss/Tb99e88b61c690e04-M94d77193284aff4019e9be82 Delivery options: https://illumos.topicbox.com/groups/discuss/subscription
