@morrow without logs this will be hard to track down. can you ask your administrator to open up a support case for this?
I am using Active Directory for user information for Zarafa. With the commando ‘zarafa-admin –l’ can I retrieve a list with Zarafa users, however it is not possible for (certain) users to log in into the webaccess or Outlook, what is wrong?
In Active Directory it is possible to set, for every user on which computer he/she may login. For verification of the username and password of a user, a computer will bind to the Active Directory. When the name or ip-address is not in the list of computers, the username and password is not verified by the Active Directory. The same would happen when the name or ip-address of the Zarafa server is not available in the list of computers, so the user cannot login to Zarafa.
For checking/changing this, you can take the following steps:
To integrate Zarafa with an Active Directory server, you need to specify the LDAP search queries in the ldap.cfg file. From these search queries, Zarafa can locate the users and groups in the ADS.
To ensure the LDAP search queries are as fast as possible, we advise you to specify a subfolder in the LDAP structure, where all users are located. By specifying the subfolder in the ADS, the LDAP search does not need to search the complete tree.
By default, Zarafa generates an Outlook store for every found user in the LDAP tree. When users in the ADS do not use Zarafa, you should put them in a separate folder in the ADS, where Zarafa does not search for users.
To specify groups for Zarafa, we advise you to create a separate folder in the LDAP tree and create all the Zarafa groups in this folder. By creating a specific folder for groups, not all the Windows system groups are visible in Zarafa.
An example ADS configuration file is found in /usr/share/zarafa/ads.cfg. This file can be used as a template for ADS servers.
Read more about Active Directory integration in the Zarafa LDAP whitepaper.
When the data from LDAP is used for Zarafa, only the value of the unique LDAP attribute is stored in the Zarafa database. When other user data is needed, Zarafa retrieves this from LDAP by searching on the value of the unique LDAP attribute. When a user is removed from LDAP, that value of the unique LDAP attribute will also be removed from LDAP. To make sure that the users which are removed from LDAP will also be removed from Zarafa, Zarafa will look to the existing values of the unique LDAP attribute. When one of those values is removed from LDAP the user will also be removed from Zarafa. When there is a new value, a new user would be created in Zarafa.
When the value of the unique attribute is changed, for Zarafa this means that the user is deleted and a new user is created. This will result in deleting the ‘old’ store of the user and creating a new store. The old store will move to the Admin folder in the public store.
In the LDAP documentation you can find the solution to change the unique attribute for groups, as well as for users.
The default behavior of Microsoft Windows Server 2003 is to remember old passwords for one hour after a password change.
It is noted by Microsoft that no security weakness is caused by this kind of behavior, as long as only one user knows both passwords.
Existing components that are designed to use Kerberos for authentication are not affected.
Unofficially it is done for replication between 2 or more domain controllers. Standard domain controllers replicate every 15 minutes.