AD doesn't seem to like DNs that reference an object's UID, as is common practice for Oracle LDAP. See the AuthLDAPBindDN value.
AuthType Basic AuthName "Please log in with your DomainID and password to create a new mailing list" AuthBasicProvider ldap AuthLDAPURL "ldaps://ldap.domain.com:636/dc=domain,dc=com?uid?sub?(objectclass=Person)" AuthLDAPBindDN "uid=mailman,ou=Services,dc=domain,dc=com" AuthLDAPBindPassword "***************" Require valid-user
In this example, UID is replaced by CN for the AuthLDAPBindDN object value.
AuthType Basic AuthName "Please log in with your DomainID and password to create a new mailing list" AuthBasicProvider ldap AuthLDAPURL "ldaps://ad.domain.com:636/dc=ad,dc=domain,dc=com?samAccountName?sub?(objectclass=*)" AuthLDAPBindDN "cn=is-svc-mailman,ou=Service Accounts,ou=Unmanaged,ou=Users,ou=IS,ou=Units,dc=ad,dc=domain,dc=com" AuthLDAPBindPassword "****************************" Require valid-user
Sendmail is one of those apps where if you provide the the BaseDN of an AD domain namespace, AD provides a referral (see below) that Sendmail translates as an actual ldap server, and errors when it cannot find the object it is querying for when it uses the referral as an actual LDAP server. Many apps, including those also use ldapsearch ignore the referral given by AD when searching the base of the domain, and work as expected. To avoid the referral issue, simply provide a BaseDN value that includes a top level OU that still provides the proper directory searchbase for auth queries.
LDAP Paged Queries with subordinate referrals are not chased properly
# search reference ref: ldaps://DomainDnsZones.ad.domain.com/DC=DomainDnsZones,DC=ad,DC=domain,DC=com # ldapsearch work-around (note the DN value following '-b') ldapsearch -v -H ldaps://ad.domain.com -D "cn=is-svc-mail,OU=Service Accounts,OU=Unmanaged,OU=Users,OU=IS,OU=Units,DC=ad,DC=domain,DC=com" -w '*********' -b 'ou=Units,dc=ad,dc=domain,dc=com' -s sub '(samaccountname=gabe)' objectClass AD-EmailForwardingAddress