User Management with Active Directory Best Practice request

michaelschefczyk

Dear All,

To replace a SOHO Microsoft Exchange Setup, I did install Kopano based on current Debain Buster packages.

Currently, I am trying to use user_plugin = ldap with active directory instead of db.Given the complexity of that matter, I think I came remarkably far. Nevertheless, three best practices questions remain. Feedback would be very welcome.

I did take the following steps:

Prepared by inspecting my active directory with an ldap browser. My setup is 4 DCs, two Windows Server 2016 instances and root Samba 4.9.5-Debian (Debian Buster Packages). My non generic users (i.e., no guest …) are in one folder and confirmed that I did find most attributes I was seeking.
Ran Kopano AD extension and set up the users I willing to activate in Kopano.
Added /etc/kopano/ldap.cfg with the following key values:
!include /usr/share/kopano/ldap.active-directory.cfg
ldap_uri = ldap://192.168.[X.Y]:389 [four times in a row]
ldap_bind_user = [administrator@domain.local]
ldap_bind_passwd = [plain text]
ldap_search_base = OU=[non generic user folder],DC=[domain],DC=[local]
ldap_user_search_filter = (kopanoAccount=1)
ldap_emailaddress_attribute = mail
ldap_emailaliases_attribute = kopanoAliases
ldap_fullname_attribute = cn
ldap_isadmin_attribute = kopanoAdmin
ldap_loginname_attribute = sAMAccountName [different from documentation]
ldap_nonactive_attribute = kopanoSharedStoreOnly
ldap_password_attribute = userPassword
ldap_user_unique_attribute = sAMAccountName [different from documentation]
That creates users from those within my AD folder, for which kopanoAccount checked.

The following questions remain:

I had no luck with ldap_loginname_attribute = uid and ldap_user_unique_attribute = uidNumber suggested in the documentation (KC Adminiatrator Manual 5.11). Is it correct to use sAMAccountName for both instead??
What do the following errors imply:
kopano-server[…]: Command “/usr/lib/kopano/userscripts/createuser” exited with non-zero status 127
kopano-server[…]: Command “/usr/lib/kopano/userscripts/creategroup” exited with non-zero status 127
When trying to use the webapp for the newly created users, one gets “Unknown MAPI Error: MAPI_E_NOT_FOUND”. The reason seems to be that the users do not have a store. The error goes away after hooking orphaned stores which remain from before switching to ldap (difficult without a guessed username). That corresponds to the documentation: “There is no way to trigger a store creation event on the Kopano server whenever a user is added in the LDAP server.” (KC Adminiatrator Manual 8.5.1). Is this related to the previous question and what is the best practice to deal with this?

Regards,

Michael Schefczyk

fbartels

Hi @michaelschefczyk,

@michaelschefczyk said in User Management with Active Directory Best Practice request:

I had no luck with ldap_loginname_attribute = uid and ldap_user_unique_attribute = uidNumber suggested in the documentation (KC Adminiatrator Manual 5.11). Is it correct to use sAMAccountName for both instead??

I think I found the block that you are referring to. this also has the sentence “(example values taken from the openLDAP configuration):” right above it. The default values for these two options in the configuration file (/usr/share/kopano/ldap.active-directory.cfg) are:

# unique user id for find the user
# Required
# For active directory, use:
#    objectGUID ** WARNING: This WAS: objectSid ** Updates *WILL* fail! **
# For LDAP with posixAccount, use:
#    uidNumber
ldap_user_unique_attribute = objectGUID

[...]

# Optional, default = uid
# Active directory: sAMAccountName
# LDAP: uid
ldap_loginname_attribute = sAMAccountName

@michaelschefczyk said in User Management with Active Directory Best Practice request:

What do the following errors imply:

they mean that the script located (or expected) at /usr/lib/kopano/userscripts/createuser failed to run. this is also related with your “3.” as this script creates the store that is now missing when logging into WebApp.

michaelschefczyk

Dear Felix,

Thank you very much for your response!

Regarding the first question:

Indeed, the only differences between /usr/share/kopano/ldap.active-directory.cfg and the values in the documentation seem to be:

ldap_emailaliases_attribute = kopanoAliases
ldap_password_attribute = userPassword
ldap_user_unique_attribute = sAMAccountName

Regarding the second and third question:

It does not seem to make a difference if createuser_script = /usr/lib/kopano/userscripts/createuser and the subsequent lines are commented out or not. Also, the scripts seem to have adequate permissions.

Nevertheless, the store creation seems to work under no circumstances.

Calling the createuser script manually from the command line, I get “KOPANO_USER and KOPANO_STOREGUID is not set.”

When it runs by itself with maximum log level, the mail.log output contains:

… kopano-server[808]: Auto-creating user from external source
… kopano-server[808]: Running script /usr/lib/kopano/userscripts/createuser
… kopano-server[808]: Running command: “/usr/lib/kopano/userscripts/createuser”
… kopano-server[808]: /usr/lib/kopano/userscripts/createuser[1390]: /usr/lib/kopano/userscripts/createuser: 20: exec: /usr/libexec/kopano/kscriptrun: not found
… kopano-server[808]: Command “/usr/lib/kopano/userscripts/createuser” exited with non-zero status 127

A file kscriptrun does not seem to exist at all. Is it likely that this is a Debian Buster packaging bug??

Regards,

Michael

fbartels

@michaelschefczyk said in User Management with Active Directory Best Practice request:

A file kscriptrun does not seem to exist at all. Is it likely that this is a Debian Buster packaging bug??

Yes, it seems so. I would recommend reporting this to the Debian package maintainers. I don’t think they are active here on the forum.

michaelschefczyk

Sorry, my mistake, I did check again. The following file seems to exist:

/usr/lib/x86_64-linux-gnu/kopano/kscriptrun

That does look like the location would be different. I will try to see what happens if I modify the scripts before just reporting.

michaelschefczyk

Well, it is not that easy. For a Debian report to be most helpful, I should probably understand the issue as best as possible.

If I modify the last line of the createuserscript to:

exec “/usr/lib/x86_64-linux-gnu/kopano/kscriptrun” /usr/lib/kopano/userscripts/createuser.d /etc/kopano/userscripts/createuser.d

That results in no error message anymore. Furhtermore, new stores do get created. Hence, the basic problem seems to be solved.

What I do also notice is that “/etc/kopano/userscripts/createuser.d” is empty.

Does this imply something or is this just a secondary option to save script basics?

fbartels

@michaelschefczyk said in User Management with Active Directory Best Practice request:

What I do also notice is that “/etc/kopano/userscripts/createuser.d” is empty.

In our packaging users can place additional script to be run on user/group/company creation/deletion into these folders.