4 Replies Latest reply on Jun 19, 2009 6:23 AM by colyewg

    SafeBoot Connector Manager & Multiple Groups

    colyewg
      Previously we had 1 AD group in to which we added users needing to use an encrypted laptop, one group of users and 1 group of devices.

      Now both groups are too large and less secure so we intend to break it down into 4 identifiable groups of users, and they will only be able to logon to laptops in their department.

      Currently as things are setup if I move users from the original group into their new group, the next time a sync occurs they are put back in to the original group.

      What is the best way to do this? Have 4 seperate AD groups too and 4 connectors setup, or is it possible to stick with the 1 AD group and during sync put them into the correct group? Or carry on as we have been, move all accounts manually and set the sync to ignore users if no mapping exists so it doesn't keep putting them back into the original group?

      Comments welcome.
        • 1. RE: SafeBoot Connector Manager & Multiple Groups
          One temporary solution you can use while deciding however is to remove the bindings from the user key (Properties > Bindings > Remove the two that are there). This means when the connector next runs it wont pull those keys back to the original group.

          We raised a call with McAfee support about this awhile back but the call got closed as I couldn't provide enough information (I was unable to provide a screenshot of a key being moved....). In the end we created what you suggested; a new group with a new connector but Im relatively sure that there is an easier way. Im also relatively sure that this problem only started happening recently as I dont recall having keys being moved like this at the beginning of this year. happy
          • 2. RE: SafeBoot Connector Manager & Multiple Groups
            woodsjw
            I'm currently doing this with technician groups so that techs at each site are automatically placed into a group in MEE that can only manage their devices.

            I setup each of the groups in the connector's "Search groups" list to find the users. Then under "Group mappings" I've mapped each of the gouips to a tech group in MEE based on the users' "memberof" attribute.
            • 3. RE: SafeBoot Connector Manager & Multiple Groups
              if you use the connector, you need to get the connector to do any moves in the EEM for you - otherwise the connector will keep putting users back where IT thinks they should be (as you found).

              by clearing the bindings, you are disconnecting the user from their AD counterpart - that may be ok, but remember, if you disable/delete them in AD now, that won't affect their EEM counterpart.

              Best to change the group mapping rules in your connector to move users into groups based on their AD profile, rather than trying to fudge things.
              • 4. RE: SafeBoot Connector Manager & Multiple Groups
                colyewg
                Group mappings definitely proved the best option for us based upon the 'Directory' attribute of the user AD profile.

                It works a treat and means we only need to manage the one AD group, we've tidied user AD profiles where the department data was missing or incorrect and it all runs through the one connector too.

                These changes also helped identify SafeBoot user accounts that were troublesome, i.e. passwords not updating the same as the users network password, and we also isolated these as being accounts that were created manually rather than automated through the connector.

                The big issue we had as a result and something for other to be aware of, is despite creating our new user containers and adding these in as allowed to logon to our single group of laptops (thinking the changes would be seamless).... when user accounts were moved to their new container they were removed from the machine by the client and the machines kept locking up until we could force another sync to see the user account put back on.

                Worst case scenario were users who rebooted and we had to give out our technical support user account details to get them back on (done remotely) and change this password at a later date. Maybe this was because the original single user group was also still granted access to the machines, it looked at this group and removed the account because it was not there, then next sync it saw the new group and re-added the account.