Add contacts to global address book in ldap

tboernert

Hi @fbartels ,

and what is than exactly the difference between an contact and a kopano-user ?
which attribute is different ?

thanks

Thomas

fbartels

@tboernert the contact is exactly the same as the user, but with the added kopano-contact objectclass.

tboernert

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: 1200000000

Thanks

Thomas

fbartels

@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.

tboernert

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: Lastname

Thanks

Thomas

fbartels

@tboernert this looks about right

tboernert

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

fbartels

@tboernert that depends solely on your ldap.cfg

tboernert

Hi @fbartels ,

the ldap.cfg hold 5 entries:

ldap_uri
ldap_starttls
ldap_bind_user
ldap_bind_passwd
ldap_search_base

nothing else.

Is the object class “posixAccount” needed ?

Thanks

Thomas

jengelh

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 then inetOrgPerson for obvious reasons); kopano-user is not a requirement, nor is posixAccount 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.

fbartels

@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:

jengelh

@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 in ldap_user_type_attribute_value.

fbartels

@jengelh yes, but both users and contacts need to match with ldap_user_search_filter, which is what I was saying all along.

jengelh

And the default value for ldap_user_search_filter is the empty string. It all plays together.