Navigation

    Kopano
    • Register
    • Login
    • Search
    • Categories
    • Get Official Kopano Support
    • Recent
    Statement regarding the closure of the Kopano community forum and the end of the community edition

    kopanoSendAsPrivilege bug

    Kopano Groupware Core
    2
    6
    1373
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • Michael Niehren
      Michael Niehren last edited by

      Hi,

      after switching from Zarafa to Kopano, we got a problem with SendAs. You can reproduce it
      as follow’s:

      • create a kopano group
      • add an kopano user to that group
      • chose another user and set the sendasprivilage attribute of the user to the group

      –> the members of that group could NOT send as the chosen user

      in zarafa this was functional

      We are using Kopano V8.3.2.

      best regards
      Michael

      fbartels 1 Reply Last reply Reply Quote 0
      • fbartels
        fbartels Kopano @Michael Niehren last edited by

        Hi @Michael-Niehren ,

        at first i thought you were talking about https://jira.kopano.io/browse/KC-763, but this actually should only exist in 8.4.x.

        I just did a test of this with Kopano 8.3.3 on Ubuntu 16.04 and was able to sendas the specified user, when I was the member of the allowed group.

        Which user backend do you use?
        can your groups be properly resolved from kopano-admin?
        does kopano-admin show the sendas permissions?

        Regards Felix

        Resources:
        https://kopano.com/blog/how-to-get-kopano/
        https://documentation.kopano.io/
        https://kb.kopano.io/

        Support overview:
        https://kopano.com/support/

        Michael Niehren 2 Replies Last reply Reply Quote 0
        • Michael Niehren
          Michael Niehren @fbartels last edited by

          Hi Felix,

          Which user backend do you use?
          as backend we are using LDAP

          can your groups be properly resolved from kopano-admin?
          no, kopano-admin only shows everybody

          does kopano-admin show the sendas permissions?
          it only show’s the users in sendas not any group

          It seem’s to be something in LDAP, i will check that and give feedback back.

          thanks,
          Michael

          1 Reply Last reply Reply Quote 0
          • Michael Niehren
            Michael Niehren @fbartels last edited by fbartels

            Hi Felix,

            i find a solution. In the old zarafa schema the zarafa-group is defined as follows

            objectclass     ( 1.3.6.1.4.1.26278.1.2.0.0
                    NAME 'zarafa-group'
                    DESC 'Zarafa: a group of Zarafa'
                    SUP top AUXILIARY
                    MUST ( cn $ uid )
            

            the kopano-group is definded as

            objectclass     ( 1.3.6.1.4.1.47732.1.2.0.0
                    NAME 'kopano-group'
                    DESC 'KOPANO: a group of Kopano'
                    SUP top AUXILIARY
                    MUST ( cn )
            

            In our config we don’t set ldap_sendas_relation_attribute, so ldap_user_unique_attribute,
            which is uid , should be used. After changing the kopano-group definition to the old
            zarafa-group definition and also setting the uid in the LDAP group entry , everything work’s
            as expeced.

            Why was the uid field in the kopano-group definition gone ?
            Or what is the right way to configure that ?
            I only have 1 ldap_sendas_relation_attribute for user and group, right. So in my understanding,
            it has to be the same. It would be nice if you can explain …

            best regards and thanks for your help
            Michael

            fbartels 1 Reply Last reply Reply Quote 0
            • fbartels
              fbartels Kopano @Michael Niehren last edited by fbartels

              @Michael-Niehren said in kopanoSendAsPrivilege bug:

              Why was the uid field in the kopano-group definition gone ?

              When looking at zarafa.schema as included in the source then it looks like this:

              objectclass	( 1.3.6.1.4.1.26278.1.2.0.0
              	NAME 'zarafa-group'
              	DESC 'Zarafa: a group of Zarafa'
              	SUP top	AUXILIARY
              	MUST ( cn )
              	MAY (
              		zarafaAccount $ zarafaHidden $ mail $ zarafaAliases $ zarafaSecurityGroup $ zarafaSendAsPrivilege $
              		gidNumber
              		)
              	)
              

              So my guess is you modified it yourself and forgot about it. Setting a userid for a group (which normally has a g(roup)id sounds weird. In my test I have set it like the following (at least as far as i remember, already disposed the system) this works, but there may be other solutions to this:

              # 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 = mail
              

              Regards Felix

              Resources:
              https://kopano.com/blog/how-to-get-kopano/
              https://documentation.kopano.io/
              https://kb.kopano.io/

              Support overview:
              https://kopano.com/support/

              Michael Niehren 1 Reply Last reply Reply Quote 0
              • Michael Niehren
                Michael Niehren @fbartels last edited by

                Hi Felix,

                you are absolutly right. I’ve checked that back and it was me, who insert the uid field.
                I am very sorry for that.

                thanks again for your help
                Michael

                1 Reply Last reply Reply Quote 0
                • First post
                  Last post