I'm making progress with ldapclient. By narrowing the group lookup to only
the OU we use for assigning file permissions lookups are now a reasonable
speed.
However, nested groups might be the real dead end with this approach. From
the ldapclient man page for attributeMap: "Note that nested groups are not
currently supported, and unexpected results may be obtained if they are
used."
----
I was able to join the system to the domain with smbadm. It's not clear
how to get uid & gid resolution with this. It seems more focused on
serving to Windows via SMB.
In the past, I have used compiled samba to join the AD domain with winbind
to server our Windows desktop users. Kind of messy to maintain.
I was hoping to utilize something that I don't have an additional stack to
maintain. It appears that out-of-the-box Illumos is not suited to handle
our environment.
----
Right now I'm considering any direct join of the domain a dead end. I'm
focusing now on looking at OpenLDAP and OpenDJ as a way to consolidate the
LDAP directory to only the users and groups we are concerned with on our
ZFS storage systems.
Thanks, everyone for your input!
-Chip
On Wed, Mar 23, 2022 at 7:02 PM Ian Kaufman <ikauf...@eng.ucsd.edu> wrote:
> 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 <c...@innovates.com> 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 <brian.benn...@joyent.com>
>> 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 <c...@innovates.com> 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 <brian.benn...@joyent.com>
>>> 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 <jason.brian.k...@gmail.com>
>>>> 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 <ikauf...@eng.ucsd.edu>
>>>> *Date: *Friday, March 18, 2022 at 2:36 PM
>>>> *To: *omnios-discuss <omnios-disc...@lists.illumos.org>
>>>> *Cc: *illumos-discuss <discuss@lists.illumos.org>
>>>> *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 <c...@innovates.com>
>>>> 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-M52d936aa4bf9a3bfa78a209a>
>
------------------------------------------
illumos: illumos-discuss
Permalink:
https://illumos.topicbox.com/groups/discuss/Tb99e88b61c690e04-Md5f737553a700c69e3406dbb
Delivery options: https://illumos.topicbox.com/groups/discuss/subscription
