Rename user store



  • Hi,
    I renamed a Kopano user in open LDAP, unfortunately “kopano-admin -l” shows the old name. Is there a preferred way how to rename the user store, so “kopano-admin -l” will display the new name?



  • Did you run “kopano-admin --sync” ?



  • Yes I did it but this did not change the name.



  • What are you using as your unique attribute?
    It is located in /etc/kopano/ldap.openldap.cfg (maybe):
    Under the # User settings
    Maybe copy that whole section here.

    I’m thinking that you might have changed the DN in LDAP but not changed the actual attribute Kopano uses to identify users.



  • User section from ldap.cfg.

    ##########
    # User settings
    
    # Extra search for users using this LDAP filter.  See ldap_search(3) or RFC
    # 2254 for details on the filter syntax.
    #
    # Hint: Use the zarafaAccount attribute in the filter to differentiate
    # between non-zarafa and zarafa users.
    #
    # Note: This filter should include contacts.
    #
    # Optional, default = empty (match everything)
    # For active directory, use:
    #   (objectCategory=Person)
    # For LDAP with posix users:
    #   no need to use the search filter.
    ldap_user_search_filter = (|(zarafaAccount=1)(objectClass=zarafa-contact))
    
    # 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
    # Note: contacts also use this field for uniqueness. If you change this,
    # you might need to update the zarafa.schema file too, and change
    # the MUST uidNumber to whatever you set here.dnl
    ldap_user_unique_attribute = GUID
    
    # Type of unique user id
    # default: text
    # For active directory, use:
    #		binary
    # For LDAP with posix user, use:
    #		text
    ldap_user_unique_attribute_type = binary
    
    # Optional, default = cn
    # For active directory, use:
    #   cn or displayName
    # For LDAP with posix user, use:
    #   cn
    ldap_fullname_attribute = fullname
    
    # Optional, default = uid
    # Active directory: sAMAccountName
    # LDAP: uid
    ldap_loginname_attribute = cn
    
    # Optional, default = userPassword
    # Active directory: unicodePwd
    # LDAP: userPassword
    ldap_password_attribute =
    
    # If set to bind, users are authenticated by trying to bind to the
    # LDAP tree using their username + password.  Otherwise, the
    # ldap_password_attribute is requested and checked.
    # Optional, default = bind
    # Choices: bind, password
    # Active directory: bind
    # LDAP: bind
    ldap_authentication_method = bind
    
    # Optional, default = mail
    # Active directory: mail
    # LDAP: mail
    ldap_emailaddress_attribute = mail
    
    # Optional, default = zarafaAliases
    # Active directory: zarafaAliases
    # LDAP: zarafaAliases
    ldap_emailaliases_attribute = zarafaAliases
    
    # Whether the user is an admin.  The field is interpreted as a
    # boolean, 0 and false (case insensitive) meaning no, all other values
    # yes.
    # Optional, default = zarafaAdmin
    # Active directory: zarafaAdmin
    # LDAP: zarafaAdmin
    ldap_isadmin_attribute = zarafaAdmin
    
    # Whether a user is a non-active user. This means that the user will
    # not count towards your user count, but the user will also not be
    # able to log in
    # Optional, default = zarafaSharedStoreOnly
    # Active directory: zarafaSharedStoreOnly
    # LDAP: zarafaSharedStoreOnly
    ldap_nonactive_attribute = zarafaSharedStoreOnly
    
    # A nonactive store, or resource, can be specified to be a user, room or equipment.
    # Set it to 'room' or 'equipment' to make such types. If set to empty,
    # or wrong word, or 'user' it will be a nonactive user.
    # Optional, default = zarafaResourceType
    # Active directory: zarafaResourceType
    # LDAP: zarafaResourceType
    ldap_resource_type_attribute = zarafaResourceType
    
    # Numeric resource capacity
    # Optional, default = zarafaResourceCapacity
    # Active directory: zarafaResourceCapacity
    # LDAP: zarafaResourceCapacity
    ldap_resource_capacity_attribute = zarafaResourceCapacity
    
    # Optional
    # The attribute which indicates which users are allowed
    # to send on behalf of the selected user
    ldap_sendas_attribute = zarafaSendAsPrivilege
    
    # Optional, default = text
    # Active directory: dn
    # LDAP: text
    ldap_sendas_attribute_type = dn
    
    # The attribute of the user and group which is listed in 
    # the ldap_sendas_attribute
    # Empty default, using ldap_user_unique_attribute
    ldap_sendas_relation_attribute = distinguishedName
    
    # Optional, default = userCertificate
    # Active directory: userCertificate
    # LDAP: userCertificate
    ldap_user_certificate_attribute = userCertificate
    
    # Load extra user properties from the propmap file
    !propmap /etc/kopano/ldap.propmap.cfg
    

    Please note, this Kopano installation runs with Zarafa attributes.
    btw. today I see the same issue with Zarafa and AD integration.



  • So what I see is:

    This looks weird?? Why are you using the contact object class for your users? It has nothing to do with anything, I’m just wondering.
    ldap_user_search_filter = (|(zarafaAccount=1)(objectClass=zarafa-contact))

    You are using the objects GUID with is great, that way when you rename a user it doesn’t lose it’s Mailstore
    ldap_user_unique_attribute = GUID

    The Fullname is the fullname attribute of the user (contact) object
    ldap_fullname_attribute = fullname
    And the login name is the cn.
    ldap_loginname_attribute = cn

    However I have seen systems where the cn is just another attribute and is not related in anyway to the LDAP DN. So my thinking is that when you create a LDAP user, it auto-generates this CN based on the name you give it, but when you renamed the user, it kept the original cn attribute value.
    Do you have a generic LDAP browser you can use to look at the objects directly? If not you can use the bash command “ldapsearch” to get the LDIF of that object and see exactly what attributes the Kopano system is seeing.


Log in to reply
 

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