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 

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,

strange. Can't say what particular API SEC uses but it shouldn't make a difference in this simple scenario (your domain accounts are direct members as is your local test account that encounters the same error).

An inconsistency in the database would also be strange given that two independent (if I understand correctly) installs show the same behaviour. After SEC install the Users table should have a row with ID=1, Name=Sophos Full Administrators, in UserSubEstates there should be a row UserID=1, SubEstateID=1, and the same in UserRoles. And of course there must be a (the default) subestate with ID=1 in SubEstates.

Christian

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

Hello, 

The entries in the dbo's are inline with what you have stated with the addition in the dbo.users of a second line for my domain account, in the dbo.subestates of an additional sub-estate named "test" and with the creation of a second row in dbo.userestates with "2 2" in order to assign my account to this additional subestate that I have created.

what is also straneg is that if i manually remove the my domain account form the Sophos Full Administartors ...at the next logon he is automatically added back ....I have looked at RSOP on the machine and cant find any GPO setting with that effect.

Could that be a result of the entries that exists in the Sophos databases? ANd could that also play a role in this strange behavior?

Mihai

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 

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