external auth issue - and log/mailbox.log lies!

Discuss your pilot or production implementation with other Zimbra admins or our engineers.
Post Reply
bloom
Posts: 21
Joined: Sat Sep 13, 2014 3:01 am

external auth issue - and log/mailbox.log lies!

Post by bloom »

Hi

Code: Select all

$ zmcontrol -v
Release 8.8.9_GA_2055.RHEL7_64_20180703080917 RHEL7_64 FOSS edition, Patch 8.8.9_P1.
A brief description of the problem: Zimbra seems to ignore zimbraAuthLdapSearchFilter: (userPrincipalName=%n) setting making it impossible to auth against AD when login <> sAMAccountName in the AD.

And here goes the longer story: I am trying to setup ZCS 8.8.9 with intergration to AD (Samba4 based) with AutoProvisioning. I am almost done but...

In my AD I have more than one UPN suffixes. I am going to create a few domains in Zimbra. There will be a few users where the default sAMAccountName will be different from the local part of their email address. For example
  • user1@domainA.com - inside AD it is login: user1 UPN suffix: domainA.com with sAMAccountName user1
    user2@domainA.com - inside AD it is login: user2 UPN suffix: domainA.com with sAMAccountName user2
    user3@domainA.com - inside AD it is login: user3 UPN suffix: domainB.com with sAMAccountName user3b
So I would like ZCS to autoprovision the account in LAZY mode.

I have the following:

Code: Select all

zimbraAuthLdapSearchBase: OU=employers,DC=LOCAL,DC=DOMAIN,DC=NET
zimbraAuthLdapSearchBindDn: CN=Administrator,CN=Users,DC=LOCAL,DC=DOMAIN,DC=NET
zimbraAuthLdapSearchBindPassword: SECRET
zimbraAuthLdapSearchFilter: (userPrincipalName=%n)

zimbraAutoProvAccountNameMap: description
zimbraAutoProvAttrMap: description=description
zimbraAutoProvAttrMap: cn=displayName
zimbraAutoProvAttrMap: givenName=givenName
zimbraAutoProvAttrMap: sn=sn
zimbraAutoProvAttrMap: userPrincipalName=zimbraAuthLdapExternalDn
zimbraAutoProvAuthMech: LDAP
zimbraAutoProvBatchSize: 40
zimbraAutoProvLdapAdminBindDn: CN=Administrator,CN=Users,DC=LOCAL,DC=DOMAIN,DC=NET
zimbraAutoProvLdapAdminBindPassword: SECRET
zimbraAutoProvLdapSearchBase: OU=employers,DC=LOCAL,DC=DOMAIN,DC=NET
zimbraAutoProvLdapSearchFilter: (userPrincipalName=%n)
zimbraAutoProvMode: LAZY
I cannot get Zimbra AutoProvision the account for user3 . When there is no zimbraAuthLdapBindDn, the log/mailbox.log throws FATAL:

Code: Select all

account - one of the following attrs must be set zimbraAuthLdapBindDn, zimbraAuthLdapSearchFilter
which is wrong, because zimbraAuthLdapSearchFilter is set, but is ignored. When I set:

Code: Select all

zmprov md DOMAIN.NET zimbraAuthLdapBindDn "%u@local.domain.net"
Zimbra will authenticate against AD only when local login part = sAMAccountName. If it is different, I need to create account manually and setup zimbraAuthLdapExternalDn to UPN of the user. After it is set up, it works. I am using a hack with setting zimbraAutoProvAccountNameMap to description (source: https://community.spiceworks.com/how_to ... -provision). When zimbraAutoProvAccountNameMap is empty, the result is the same which is explained by the docs/autoprov.txt :
zimbraAutoProvAccountNameMap
type="string" max="256" cardinality="single" optionalIn="domain"
Exposed in admin console: NO
Description:
EAGER mode: required
LAZY mode: optional
MANUAL mode: optional

Attribute name in the external directory that contains localpart of the account name.
If not specified, localpart of the account name is the principal user used to authenticated to
Zimbra.
Summary: when doing auth to AD, Zimbra is ignoring the zimbraAuthLdapSearchFilter: (userPrincipalName=%n) setting. That is why it won't authenticate me BEFORE the account is created making it impossible to Auto Provision.

Everything works perfect when login = sAMAccountName . In that case, account is AutoProvisioned and even zimbraAuthLdapExternalDn is set to userPrincipalName. Then I can change the sAMAccountName and it still works OK.

Please excuse my explanation of the problem is so long. I've been working on that for the last 3 days and now I feel I got to the point I cannot resolve.

With regards,
Piotr
Post Reply