While i'm not exactly an expert on ApacheDS, I work with other OpenDS based Directories and Access products all the time. So let me give you some general knowledge as there seems to be some confusion as how these things work.. Afaik from what I have looked at in ApacheDS, it doesn't support any type of LDAP proxy or mechanism to send bind credentials to another LDAP server during the bind operation, which is what I would expect from a true passthrough. However you mentioned the use of GSSAPI, which is basically a Java implementation of Kerberos, which is possible using a SASL mechanism. Its pretty rare to use Kerberos for LDAP authentication, so i'm not sure how much info you are gonna find specific to this use case. But technically you could use SASL GSSAPI to take in a kerberos ticket from AD that is mapped to the user. Java should be able to pull the userPrincipalName out of the kerberos token so you can look up their entry in ApacheDS. Assuming you have a way to send the kerberos token using the LDAP protocol, you need to configure ApacheDS to map the incoming token principal to the user account.
So these are some things you need in order for this to work. 1. The client needs to access the ldap server directly in some way. basically using the TGT to get a service ticket it can send to the ApacheDS 2. ApacheDS needs a service account and keytab to be able to verify the service ticket. You will also need to configure a krb5.conf file 3. You need to configure some kind of Identity Mapper that will match the incoming token to the user entry. I'm not sure how to configure this part in ApacheDS. note that no authentication actually happens here. Authn for kerberos happens when the user logs into their workstation. AD gives the user a TGT which is used when the user goes to access a service defined by the SPN set on the service account. the SASL GSSAPI mechanism will simply verify the service token with the AD server and grant access based on the third party verification. This is the basic principal of kerberos. using the other SASL mechanisms such as MD5 aren't going to give you any Authn to AD. Those just provide additional security by sending a digest of the password instead of plain text password. Some docs that explain the different mechanisms. https://docs.pingidentity.com/r/en-us/pingdirectory-92/pd_sec_standard_sasl_mech On Tue, May 16, 2023 at 10:11 PM Nick Couchman <vn...@apache.org> wrote: > Hello, everyone, > I have a use-case where I'd like to configure ApacheDS to store some > information, > including user accounts, but I'd like authentication for those user > accounts to be passed through to my company's Active Directory system. I > believe, from what I'm reading, this is possible, > either via SASL or GSSAPI. > > I'm currently trying to configure SASL, but hitting a couple of blocks, and > could use some help getting past them. Here's what I've got so far... > > * A server running Rocky Linux onto which I've installed ApacheDS > (ldap1.example.com) > > * On this server, I've also installed and configured realmd, adcli, and > saslauthd. > > * I've joined this server to my AD domain, and added > ldap/ldap1.example.com to servicePrincipalName. > > * I can successfully authenticate using testsaslauthd with "ldap" as the > service, EXAMPLE.COM <http://example.com/> as the realm, and a valid AD > user. > > * In ApacheDS, I've configured the following settings: > SASL Host: ldap1.example.com (hostname of the server ApacheDS is running > on) > SASL Principal: ldap/ldap1.example....@example.com > Search Base DN: OU=ApacheDS,DC=example,DC=com (The root OU of my > ApacheDS install.) > SASL Realms: EXAMPLE.COM <http://example.com/> > > * I created a user within the OU=ApacheDS,DC=example,DC=com container > in ApacheDS, account1, which matches a user that already exists in Active > Directory. > > * I now try to authenticate to ApacheDS in Directory Studio, for example, > using variations of this user account (RDN, account1, accou...@example.com > , > etc.), and get various errors: > > - [LDAP result code 49 - invalidCredentials] INVALID_CREDENTIALS: > DIGEST-MD5: digest response format violation. Nonexistent realm: > EXAMPLE.COM <http://example.com/> > - [LDAP result code 49 - invalidCredentials] INVALID_CREDENTIALS: > CRAM-MD5: username not found: accou...@example.com > - [LDAP result code 49 - invalidCredentials] INVALID_CREDENTIALS: > CRAM-MD5: username not found: > cn=account1,OU=ApacheDS,DC=example,DC=com > > I'm sure I'm just missing something basic, here, but can someone point me > in the right direction for what I need to do to finish tying this together? > > Thanks, > Nick > -- Thanks, Brian Wolfe https://www.linkedin.com/in/brian-wolfe-3136425a/
