Add contacts to global address book in ldap
-
Hi @tboernert,
kopano-contact shares pretty much the same attributes and object-classes that a kopano-user object would have (including the object class kopano-user).
-
Hi @fbartels ,
and what is than exactly the difference between an contact and a kopano-user ?
which attribute is different ?thanks
Thomas
-
@tboernert the contact is exactly the same as the user, but with the added
kopano-contact
objectclass. -
Hi @fbartels
so this would be right here ? All fields are shure needed ?
dn: uid=contact,ou=People,dc=domain,dc=net
objectClass: posixAccount
objectClass: top
objectClass: kopano-contact
objectClass: inetOrgPerson
gidNumber: 1000
cn: Surname Lastname
homeDirectory: /home/contact
mail: contact@domain.net
uidNumber: 1000
kopanoAliases: contactalias@domain.net
kopanoUserServer: kopano
uid: Surname
kopanoAccount: 1
kopanoAdmin: 0
sn: Lastname
userPassword: contactpassword
kopanoQuotaOverride: 1
kopanoEnabledFeatures: imap
kopanoDisabledFeatures: pop3
kopanoQuotaWarn: 1000000000
kopanoQuotaSoft: 1100000000
kopanoQuotaHard: 1200000000Thanks
Thomas
-
@tboernert that entirely depends on your ldap.cfg. The key takeaway should be that a contact has all the attributes that are required to be recognised as a user, plus the kopano-contact objectclass (or what you have configured for it on ldap.cfg).
but generally speaking there are a lot of optional attributed in your output. you don’t need kopanoadmin if the user is supposed to be a normal user. you don’t need kopanouserserver if it is no multiserver installation, no need for the features attributes unless you want to override the defaults, same for the quota ones.
-
Hi @fbartels ,
thanks, so this would be enough here ?
dn: uid=contact,ou=People,dc=domain,dc=net
objectClass: posixAccount
objectClass: top
objectClass: kopano-contact
objectClass: inetOrgPerson
gidNumber: 1000
cn: Surname Lastname
mail: contact@domain.net
uidNumber: 1000
kopanoAliases: contactalias@domain.net
uid: Surname
sn: LastnameThanks
Thomas
-
@tboernert this looks about right
-
Hi @fbartels,
i tried it:
ldap_add: Object class violation (65)
additional info: object class ‘posixAccount’ requires attribute ‘homeDirectory’Is the object class “posixAccount” needed ?
Thanks
Thomas
-
@tboernert that depends solely on your ldap.cfg
-
Hi @fbartels ,
the ldap.cfg hold 5 entries:
ldap_uri
ldap_starttls
ldap_bind_user
ldap_bind_passwd
ldap_search_basenothing else.
Is the object class “posixAccount” needed ?
Thanks
Thomas
-
the contact is exactly the same as the user, but with the added kopano-contact objectclass.
That is wrong. Contacts need only have
kopano-contact
objectClass (plus theninetOrgPerson
for obvious reasons);kopano-user
is not a requirement, nor isposixAccount
a requirement, as that would actually create a user in either the Kopano space or the POSIX user namespace, which of course is not always wanted. -
@jengelh said in Add contacts to global address book in ldap:
That is wrong
Well. the contact needs to be found with the same search filter you use to fine the other users for kopano-server. and with the
kopano-contacts
objectclass the object is then reduced to a contact.@tboernert said in Add contacts to global address book in ldap:
Is the object class “posixAccount” needed ?
No, it can be freely configured to be something else. See:
-
@fbartels said in Add contacts to global address book in ldap:
@jengelh said in Add contacts to global address book in ldap:
That is wrong
Well. the contact needs to be found with the same search filter you use to fine the other users for kopano-server.
Nonsense. Contacts are found via the objectClass set in
ldap_contact_type_attribute_value
, users via the class set inldap_user_type_attribute_value
. -
@jengelh yes, but both users and contacts need to match with
ldap_user_search_filter
, which is what I was saying all along. -
And the default value for
ldap_user_search_filter
is the empty string. It all plays together.