No dynamicGroups and addresslists with samba AD

Hi there,
with zarafa 7.1 we use some dynamicGroups and addresslist with openLDAP. Now we want to switch to kopano 8.3.3. with samba 4 AD.
The kopano-dynamicGroups and kopano-addresslists where created with the ADS extension and mmc plugin
The ldap_group_search_filter was set to empty. No change.
The samba 4 AD integration works for my users and i can list all users and groups from AD, but i can not see any dynamicGroup or addresslist.

has anyone a solution for me?

Hi @emttom ,

can you share some more information about your setup. maybe some of your searchfilter and some ldaif example users that should be matched. and your ldap.cfg configuration of course.

Hi @fbartels

ok some more informations.
kopano-admin -l lists all my users from AD successfully
kopano-admin -L lists all my groups from AD succesfully, but no dynamic groups or addresslists

the file /etc/openldap/ldap.conf

BASE    dc=emtdom,dc=intern
URI     ldap://10.10.101.193 ldap://10.10.101.194
TLS_CACERTDIR   /etc/openldap/certs
TLS_REQCERT     allow
SASL_NOCANON    on

the file /etc/kopano/ldap.cfg

!include /etc/kopano/ldap.active-directory_kopano.cfg
ldap_host=10.10.101.193
ldap_port = 636
ldap_protocol = ldaps
ldap_bind_user =  CN=svc-plm-ldapquery,OU=emt-service,OU=emt-users,DC=emtdom,DC=intern
ldap_bind_passwd = <some password>
ldap_authentication_method = bind
ldap_search_base = dc=emtdom,dc=intern

in ldap.active-directory.cfg i changed only two settings

ldap_user_search_filter = (&(objectCategory=Person)(kopanoAccount=1))
ldap_group_search_filter =

The Kopano AD Extension 1.0 only gives two options when creating new objects.
The kopanoAddressList and the kopanoDynamicGroup are nearly identical, exept the objectclass differs :-(

0_1502461983955_b54712c2-bab0-4e9d-8513-14a29dee04ab-grafik.png

0_1502462081767_e94990e0-1e3e-4028-8d91-99ecd3b19dbc-grafik.png

With the ADSI-Editor i can watch my dynamic group and addresslist LDAP attributes…

here are some ldifde exports

here my addresslist example

dn: CN=grp-kopano-list,OU=emt-group,DC=emtdom,DC=intern
changetype: add
objectClass: top
objectClass: kopanoAddresslist
instanceType: 4
whenCreated: 20170809070558.0Z
uSNCreated: 27263
objectGUID:: Q4xXNKcmnkqgpSUeiVcRHw==
objectCategory: 
 CN=Kopano-Addresslist,CN=Schema,CN=Configuration,DC=emtdom,DC=intern
kopanoFilter: (physicalDeliveryOfficeName=Abenberg)
cn: grp-kopano-list
name: grp-kopano-list
kopanoAccount: 1
kopanoBase: DC=emtdom,DC=intern
whenChanged: 20170810065226.0Z
uSNChanged: 27310
distinguishedName: CN=grp-kopano-list,OU=emt-group,DC=emtdom,DC=intern

and the example for the kopanoDynamicGroup

dn: CN=grp-emt-abg,OU=emt-group,DC=emtdom,DC=intern
changetype: add
objectClass: top
objectClass: kopanoDynamicGroup
cn: grp-emt-abg
instanceType: 4
whenCreated: 20170809065801.0Z
uSNCreated: 27260
name: grp-emt-abg
objectGUID:: Quf69RmUhUS3DTSA0PiGow==
objectCategory: 
 CN=Kopano-Dynamic-Group,CN=Schema,CN=Configuration,DC=emtdom,DC=intern
kopanoAccount: 1
mail: emt-abg@emt-penzberg.de
kopanoFilter: (physicalDeliveryOfficeName=Abenberg)
kopanoBase: DC=emtdom,DC=intern
whenChanged: 20170810070220.0Z
uSNChanged: 27313
distinguishedName: CN=grp-emt-abg,OU=emt-group,DC=emtdom,DC=intern

And one user the dynamicGroup and the addresslist should match

dn: CN=goetz,OU=emt-users,DC=emtdom,DC=intern
changetype: add
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: user
sn:: R8O2dHo=
givenName: Christian
instanceType: 4
whenCreated: 20170405081523.0Z
uSNCreated: 23427
objectGUID:: OMwM/Yp2eE2KGJuK0HEiYw==
badPwdCount: 0
codePage: 0
badPasswordTime: 0
lastLogoff: 0
lastLogon: 0
primaryGroupID: 513
objectSid:: AQUAAAAAAAUVAAAAg32W7FEIx4TYMboFzAQAAA==
accountExpires: 9223372036854775807
logonCount: 0
sAMAccountName: goetz
sAMAccountType: 805306368
userPrincipalName: goetz@emtdom.intern
objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=emtdom,DC=intern
userAccountControl: 66048
cn: goetz
name: goetz
mail: christian.goetz@emt-penzberg.de
streetAddress:: Qm9zY2hzdHJhw59lIDc=
l: Abenberg
st: Bayern
c: DE
countryCode: 276
co: Deutschland
postalCode: 91183
memberOf: CN=grp-plm,OU=emt-group,DC=emtdom,DC=intern
displayName:: R8O2dHosIENocmlzdGlhbg==
telephoneNumber: +49 (0) 8856 9225 125
lockoutTime: 0
pwdLastSet: 131438134670000000
kopanoAccount: 1
physicalDeliveryOfficeName: Abenberg
whenChanged: 20170811144401.0Z
uSNChanged: 27344
distinguishedName: CN=goetz,OU=emt-users,DC=emtdom,DC=intern

@emttom said in No dynamicGroups and addresslists with samba AD:

in ldap.active-directory.cfg i changed only two settings

Bear with me, I still using the Zarafa attribute names in our AD but it should be very similar.
My ldap.activedirectory.cfg looks like this:

##########
# Object settings

# Top level search base, every object should be available under this tree
ldap_search_base =

# attribute name which is/(should: was) used in ldap_user_search_filter
ldap_object_type_attribute = objectClass
ldap_user_type_attribute_value = user
ldap_group_type_attribute_value = group
ldap_contact_type_attribute_value = contact
ldap_company_type_attribute_value = organizationalUnit
ldap_addresslist_type_attribute_value = zarafaAddresslist
ldap_dynamicgroup_type_attribute_value = zarafaDynamicGroup

##########
# Dynamicgroup settings

# Add a filter to the dynamicgroup search
# Hint: Use the zarafaAccount attribute in the filter to differentiate
# between non-zarafa and zarafa dynamic groups.
# Optional, default = empty (match everything)
ldap_dynamicgroup_search_filter = 

# This is the unique attribute of a dynamicgroup which is never going
# to change, unless the dynamicgroup is removed from LDAP. When this
# value changes, Zarafa will remove the previous dynamicgroup from the
# database, and create a new dynamicgroup with this unique value
ldap_dynamicgroup_unique_attribute = cn

# This value can be 'text' or 'binary'. For OpenLDAP, only text is used.
ldap_dynamicgroup_unique_attribute_type = text

# This is the name of the attribute on the dynamicgroup object that
# specifies the filter to be applied for this dynamicgroup. All users
# matching this filter AND matching the default
# ldap_user_search_filter will be included in the dynamicgroup
ldap_dynamicgroup_filter_attribute = zarafaFilter

# This is the name of the attribute on the dynamicgroup object that
# specifies the search base to be applied for this dynamicgroup.
ldap_dynamicgroup_search_base_attribute = zarafaBase

# The attribute containing the name of the dynamicgroup
ldap_dynamicgroup_name_attribute = cn

With those settings, you should see the Dynamic Group with kopano-admin -L

@robertwbrandt
I did the same changes in ldap.activedirectory.cfg without success.
Because we use TLS for LDAP in AD i can not debug LDAP queries :-(

You can debug on the Kopano end.

Change the log_level in the server.cfg to 131078 for full LDAP logging

This will fill up your logs Fast, but it will show you all the ldap queries that the server is sending.

Bob

from man kopano-server:

DIAGNOSTICS
       If you run into problems, check the log for any errors. If you made a mistake in the configuration of the log method, this will be reported on standard error. You can also
       restart the server with a higher log level. Also, before starting the server, always make sure the database server is running at the right location and no other server is
       listening on the configured TCP port.

       For extended diagnostics, there are special extended log options available for enhanced debugging capabilities. The parameter log_level has special or-ed values which can be set
       to investigate different modules within the server process:

       SQL: 0x00010000, User backend: 0x00020000, Server cache: 0x00040000, SOAP: 0x00100000, ICS: 0x00200000

       For example, if you are using LDAP as the user plugin, you can set the log_level to 0x00020006 for extended LDAP logging (the last digit 6 enables extended verbose logging). To
       enable SQL and LDAP logging at the same time, set log_level to 0x00030006

       WARNING: The log options create huge amounts of log entries in production environments, this results in abnormal large logfiles which can fill up available disk space very fast.
       Only use this with extreme caution.

So by setting log_level to 0x00020006 you will see the individual queries being executed.

@robertwbrandt and @fbartels
Thank you for your help, i was watching the query filter and everything was like i expected.

It has to do with the security settings of the dynamic Group when using the kopano ADS extension.

For security reasons we are using a “read only” user for LDAP queries. A Member of “Domain Users” not a member of “Domain Admin”.

When using the kopano ADS extension for dynamicGroup creation you will get only limited access rights.

0_1503482603705_a50a0fcd-1036-4a7e-9f3e-2bb23e5403ba-grafik.png

Using the dangerous ADSI editor you can Add the missing “authenticated Users” with read only rights.

0_1504681326167_9de48240-826e-405f-8b6c-50948ed9aa8d-grafik.png

I do not understand why kopano does not set this right per default!?!

never the less, with the correct rights it works :-)

Log in to reply

Looks like your connection to Kopano Community Forum was lost, please wait while we try to reconnect.