SEC 5.5.1 launch error : The user "domain\account" is not assigned to any subestates.

Hello Mihai,

The simplest possible reason behind this transient error is often communication issues between SEC and the AD server. If you can check for any potential issues faced by SEC while communicating with the AD, this might help resolve this once and for all.

Thanks,

Vikas

Hello Mihai and Vikas,

as far as I understand it the issue is 1. not transient but permanent and 2. was observed on two different servers.

I assume that the error is logged in the DirectoryService.log (%ProgramData%\Sophos\ManagementServer\log\) but can't say if it contains any additional useful information. Hm ... you have perhaps some other user that can log in to the server, if not create one and make it a member of the Sophos Full Administrators group. Wonder if you get the same error. Or did you already try with another user?

Christian 

Hello, 

the logs in the %ProgramData%\Sophos\ManagementServer\log\ do not seem to contain any info related to our issue.

Performing a test with a newly created local user ( not domain) that i then added to the local admin group and Sophos Full Administrators grup on the server i have exeperienced a different error message:

" in order to be able to execute the SEC you must be a member of the Sophos Console Administrators group and have a DCOM access on the "servername" "

Making the account a member of the Console Admins doesn't change the error :)

Thanks, 

Mihai

Hello Mihai,

you must be a member of the Sophos Console Administrators group
sorry, forgot to mention the SCA group. DCOM membership should only be necessary for a Remote Console. Excuse me for mentioning the obvious: A logoff/logon is required after changing group membership. 
Anyway, the newly created user should either be able to open the console or encounter the no subestate error.

Christian

Hello, 

Last test shows that using the newly created local test user ...the console opens OK.

On the other hand I still have the same subestate errors for all the existing domain accounts  although the group membership on the Sophos machine is identical between the local and domain accounts ( moreover the domain accounts should have even more permissions as they are members of several domain and exchange admin groups) 

One thing that maybe it's important to mention is that some time ago the domain controllers of our domain have been replaced..so I dont know if that could impact the authentication of domain accounts on the Sophos machine ( i mean if anywhere in the registry for example there might be the name of an old DC that is no longer available referenced)

Bottom line is that we need to use the domain accounts and given that the permission look the same between those and the local test account that works....I don't know where to go next from here.

Thank you, 

Mihai

Hello Mihai,

so Vikas was more or less correct.

SEC shouldn't be aware of AD specifics like DCs. It uses Windows APIs and names (not SIDs) whenever possible. It seems to be some issue with the Sophos Full Administrators security group. You can log on with the domain account, you are also able to start the Console - i.e. you get as far as the no sub-estates that suggests that membership for the Sophos Console Administrators group is correctly seen. You can test this assumption by removing a domain account from this group (watch for inheritance) - you should then get the must be a member error.
Does net localgroup "sophos full administrators" output the expected members?

Christian

HEllo, 

Removing the domain account from the Sophos Console Administrators does indeed produce the "must be a member of " error ...instead of the sub-estates one.

The net localgroup on the Sophos Full Administrators provides the correct output with the domain accounts and the test local one as members of this group.

Mihai

Additionally , taking the test local account from the Sophos Full Administartors group and leaving him a member only of the Sophos Console Admins group yields the same "sub-estate" error like for the domain account.

So it looks like it is a problem with the membership of domain accounts in the local Sophos Full Admins group. I should add that in the past i have removed and replaced the domain accounts in the group, deleted the group altogether and recreated it , deleted the group/uninstalled sophos/reinstalled sophos /verifyied the group is there with correct membership.....but in then end only to get the same sub-estates error.

Mihai 

Additionally , taking the test local account from the Sophos Full Administartors group and leaving him a member only of the Sophos Console Admins group yields the same "sub-estate" error like for the domain account.

So it looks like it is a problem with the membership of domain accounts in the local Sophos Full Admins group. I should add that in the past i have removed and replaced the domain accounts in the group, deleted the group altogether and recreated it , deleted the group/uninstalled sophos/reinstalled sophos /verifyied the group is there with correct membership.....but in then end only to get the same sub-estates error.

Mihai 

Hello Mihai,

forget my previous post ... you said it works with the local account. What was I thinking ....???

I have no idea why it should affect just this particular group. Perhaps Vikas has some idea and can suggest a further course of action.

Christian

Yeah...really strange behavior. Tried with a new domain account that I added to the correct groups on the Sophos server only to get again the sub-estates error.

It's like the Sophos Full Admins local group doesn't take into account any domain identities. 

More interesting, opening the console with the local account we can see the subestates ( the default one assigned to the Sophos Full Admins group and the test one assigned to my domain account) ...but that doesnt really change the error we are getting for the domain accounts.

Thanks, 

Mihai

Hello Mihai,

only Support (perhaps they have to consult Development) can tell whether the Sophos Full Administrators is special in some way. And referring to your previous post - I'm not aware that a Sophos component would "manipulate" Windows groups or users after install.

Medium-term the puzzle must be solved. The following could be a short-term workaround: Create a local group (perhaps Sophos Accepted Administrators), assign it to the System Administrator role and the Default sub-estate. If the behaviour w.r.t. local vs. domain accounts added to this group is the same the you should contact Support directly.

Christian

Hello, 

Unfortunately the issue is the same with a newly created local group in which I add a local account and the domain account ( after assigning to this group the sysadmin role and the default subestate) . The local account can open the console ...but the domain one has the same sub-estate error.

Thank you for you time and dedication.

MIhai

Hello Mihai,

I think you need to contact Support.
But before that - you said that with the Sophos Console Administrators group it works as intended? That is, if you remove a domain account from this group you get the must be a member? If you assign the role and sub-estate to the SCA group - same no sub-estate error?

Christian

If you assign the role and sub-estate to the SCA group - same no sub-estate error?

Answer : yes, for the domain accounts same error. If I use a local account in this group ...it works for the local group.

It's like no matter what local group I use on the server, Sophos only knows or takes into account local accounts. It cannot process domain accounts. 

If I add a domain account only in the Full Admin or the Test Admin groups without adding the account also in the SCA group...then i have the other error message with " must be a memmber of the SCA group". Then I add it also to SCA...and voila....i get again the sub-estate error for this domain account.

Mihai

Hello Mihai,

aha! Looks like the sub-estate logic uses a different function to assess group membership. Only Support (or Development) could tell if this is indeed the case - and what the cause for the failure could be. There's a trace/debug functionality that could give more insight but last time I used it was years ago and I no longer have the details how to enable it. Support should be able to provide them.

Christian