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>* / 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-M67a9b8083b668e6ca647d4ec>
>
------------------------------------------
illumos: illumos-discuss
Permalink:
https://illumos.topicbox.com/groups/discuss/Tb99e88b61c690e04-M1a798b898d0087a4d6402b99
Delivery options: https://illumos.topicbox.com/groups/discuss/subscription
