This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

SMC SSP AD Security group change

We have a an active SMC deployment in our environment, with our users registering devices via our SSP. We have 800+ devices registered and all is working well.

When we set up the SMC environment we created a specific AD security group for SSP access, let's call it SophosMobileSSP, that all Domain Users are automatically added to. The problem is that we're seeing some staff not being able to access the SSP and our operations team believe because we've created a two step AD authentication (e.g. SophosMobileSSP AD group just looks up the DomainUsers members) it's causing problems and they recommend we just change the SMC settings so it refers to the DomainUsers group.

I had a look at the System set up menu and it looks relatively straight forward to change the group from SophosMobileSSP to DomainUsers but I do get the usual "The directory configuration can not be modified because 854 devices are still linked to the directory" message and I'm concerned that if I try and change this group that all 800+ devices may need re-enrollment. And nobody has time for that.

Has anyone made this change and experienced problems?

Tl:dr: How serious is the 'don't modify the directory configuration' message?

:55580


This thread was automatically locked due to age.
  • Good afternoon,

    I don't see anything wrong with the method you're using and if it works for one user it should work for them all.

    Are these users, who cannot authenticate to SSP, new additions to AD? If so were they added via a DC other than the one being used by SMC? If so you may need to force an AD sync before Sophos sees them as members of the relevant group or simply wait for AD replication to take place before the users are able to authenticate.

    I would also ensure these users are attempting to authenticate to the SSP and not the admin portal and are entering their user ID in the correct format.

    Regards.

    :55615
  • Thanks for the response, Neil.

    I agree, the current set up should be working and 95% of the time it does.

    Just to confirm the staff who receive errors when attempting to log into the SSP are accessing the user portal (vs. the admin portal) are using correct credentials and are a mix of existing staff and new staff. New staff accounts are 48+ hours old so replication shouldn't be an issue. The only changes made, allowing them to login to the SSP, is to manually add them to the specific SSP AD group.

    It's quite odd.

    :55629
  • Good morning,

    You say manually adding the users to the SSP group in AD clears the problem. This implies that the users, who are unable to log in, are not members of the domain users group. The next time you have a problem, before you manually add the users to the SSP group, I would check the user's group membership. Do not do this using ADUC, rather run gpresult /r on a machine the user is logged in to. This will show group membership as it is interpeted by the user's account at log on.

    Capture1.PNG

    Regards.

    :55632
  • Hi,

    another thing you could try is to use the Global Catalog of your Active Directory for the lookup.

    Behind the LDAP server in the SMC Directory conifguration, simply use the port "3268" (or 3269 for SSL) ,e.g. ldap.company.com:3268.

    Best regards

    Stefan

    :55636
  • I can confirm that all accounts that received authentication errors with the SSP (and can then access the SSP after being manually added to the SSP AD group) are members of the DomainUsers AD group when their group policies were checked.

    :55668
  • Thanks Stefan, no port is currently defined in the LDAP look up so will try this and report results.

    :55669