3 Replies Latest reply on Jul 24, 2007 10:43 AM by ajy

    Stealing a Contribute Connection

    OgleWeb
      I'm in the process of rolling out Contribute to my userbase, and while testing it I have run into an interesting problem. I hope that it's a configuration or file permissions issue that can be fixed rather than a bug in the product.

      Running: IIS6, either WebDav or Local Connection, Contribute 3.11, and CPS with Active Directory

      The issue:

      I create the site and set myself up as the administrator. (Slightly offtopic question: why do I need to enter a WebDav username/password, if I'm using CPS w/AD?) I don't need to set an administrator password, as CPS handles everything through AD. I assign appropriate users and setup the permissions. Everything works fine.

      JOE USER, who has access to Contribute, browses over to a page that he does not have edit privileges for (the button at the top changes appropriately from EDIT/NEW PAGE to NEW CONNECTION. If JOE USER clicks the "New Connection" button, he can then steal the administration of the site by clicking yes in the "Do you want to remove the administration for this site" dialogue box. Now JOE USER is in control of the site. This isn't good.

      Like I said earlier, it's possible that it's a configuration issue. I know that Contribute does a funky read/write during the connection to see if the user has rights to that area, which may be why this is happening. On an IIS server, how should the site be setup permissions-wise? I'm going to guess the following, but I'm seeing conflicting information in the documentation and in various online postings and book references:

      - sitewide: users have read/execute access only
      - the _mm, _notes, and _baks folders should be.... read/write for everyone? or just read/write for those with permission to edit that area?
      - do I need to create a special CONTRIBUTE user? Or a CONTRIBUTE group in AD?

      Advice appreciated. Thx.
        • 1. Re: Stealing a Contribute Connection
          Level 7
          Did you set up an administrative password in Contribute?

          - Kevin


          OgleWeb wrote:
          > I'm in the process of rolling out Contribute to my userbase, and while testing
          > it I have run into an interesting problem. I hope that it's a configuration or
          > file permissions issue that can be fixed rather than a bug in the product.
          >
          > Running: IIS6, either WebDav or Local Connection, Contribute 3.11, and CPS
          > with Active Directory
          >
          > The issue:
          >
          > I create the site and set myself up as the administrator. (Slightly offtopic
          > question: why do I need to enter a WebDav username/password, if I'm using CPS
          > w/AD?) I don't need to set an administrator password, as CPS handles
          > everything through AD. I assign appropriate users and setup the permissions.
          > Everything works fine.
          >
          > JOE USER, who has access to Contribute, browses over to a page that he does
          > not have edit privileges for (the button at the top changes appropriately from
          > EDIT/NEW PAGE to NEW CONNECTION. If JOE USER clicks the "New Connection"
          > button, he can then steal the administration of the site by clicking yes in the
          > "Do you want to remove the administration for this site" dialogue box. Now JOE
          > USER is in control of the site. This isn't good.
          >
          > Like I said earlier, it's possible that it's a configuration issue. I know
          > that Contribute does a funky read/write during the connection to see if the
          > user has rights to that area, which may be why this is happening. On an IIS
          > server, how should the site be setup permissions-wise? I'm going to guess the
          > following, but I'm seeing conflicting information in the documentation and in
          > various online postings and book references:
          >
          > - sitewide: users have read/execute access only
          > - the _mm, _notes, and _baks folders should be.... read/write for everyone?
          > or just read/write for those with permission to edit that area?
          > - do I need to create a special CONTRIBUTE user? Or a CONTRIBUTE group in AD?
          >
          > Advice appreciated. Thx.
          >
          >
          • 2. Re: Stealing a Contribute Connection
            OgleWeb Level 1
            >
            quote:

            Originally posted by: Newsgroup User
            > Did you set up an administrative password in Contribute?



            Yes, I set an administrative password. However, when you are using Contribute Publishing Server, you are not required to use an admin password at all (the option to set or change it is greyed out, even if you set a password before activating CPS).

            I just re-verified the issue on a brand-new website with all standard permissions and setup with the same result. I do know that when setting up Contribute to connect as LOCAL/SHARE that you need to set the SHARE PERMISSIONS to allow FILE CHANGE permissions on the entire share for the user who is trying to connect. Minor item perhaps, but that's the only security change I've made to the files/directories on the server.

            To recreate, here's what I did:
            - new directory, pointed IIS to that folder. IIS security set to READ.
            - SHARING turned on for the new directory. Contribute users usergroup added to share permissions, CHANGE.
            - New Contribute connection created with administration password set. Connection-type LOCAL/NETWORK points to the share. CPS turned on, with myself set as the administrator.
            - JOE USER logs onto Contribute and initiates a New Connection to the same site. JOE USER is immediately asked if JOE would like to remove the administrative settings. 3 clicks later, JOE USER is now the administrator.

            Just to be sure I crossed all my t's, I tried the exact same thing without turning on CPS. In this case, JOE USER was unable to assign themselves to the administrative role (being prompted for a password) -- which is a good thing and as expected -- but JOE USER could assign themselves the PUBLISHER role without needing to be verified.

            So, any more thoughts? Thx again.
            • 3. Re: Stealing a Contribute Connection
              ajy
              This thread came up in a search but I dont see any resolution has there been and is this still an issue?

              Thanks