Please help to find the solution to the following issue (I got it in test-laboratory and in customer’s environment):
Mwg does not know about all membership of domain’s user. (Below is the example for domain - “qwe.local”, user – “admin”, and the one of domain local group – “test2”).
MWG successfully does the users authentication by Kerberos (used the following articles for authentication deployment - https://community.mcafee.com/docs/DOC-6449 ) – now we know every users for every requests.
However, we have a trouble when checking user membership in groups because mwg does not parse the Kerberos ticket to the end. Mwg stops on the SID S-1-18-1. Such summary we have got after investigation of the issue:
- Proxy configuration (Model WG5000-C)
- Disabled “replay cache”
- Disabled “authentication cache”
- Enabled “extract group membership IDs from the ticket”
- Disabled “lookup group names via NTLM”
2. User preferences
- User membership on AD side
group policy creator owners
- User membership on client-system side
see attached table in excel-file.
- User membership on mwg side
There is no the SID of group as “test2” in mwg-core__Auth.debug.log (test2 SID is S-1-5-21-80214499-1554138238-4006517166-1151):
[2015-04-07 11:04:13.724 +03:00]  Kerberos (3703, 192.168.31.53) Method: Kerberos
[2015-04-07 11:04:13.724 +03:00]  Kerberos (3703, 192.168.31.53) Realm: QWE.LOCAL
[2015-04-07 11:04:13.725 +03:00]  Kerberos (3703, 192.168.31.53) User: admin
[2015-04-07 11:04:13.725 +03:00]  Kerberos (3703, 192.168.31.53) Groups: S-1-5-21-80214499-1554138238-4006517166-1150, S-1-5-21-80214499-1554138238-4006517166-513, S-1-5-21-80214499-1554138238-4006517166-512, S-1-5-21-80214499-1554138238-4006517166-520, S-1-5-21-80214499-1554138238-4006517166-1110, S-1-5-21-80214499-1554138238-4006517166-519, S-1-5-21-80214499-1554138238-4006517166-518, S-1-5-21-80214499-1554138238-4006517166-1112, S-1-18-1
see attached log.
MWG blocks legitimate user based on the policy of checking User.Groups because there is no SID of group in mwg-core__Auth.debug.log at time when user is the member of the group for the client-system and AD. This information is shown in the rule tracing analysis:
Authentication.Usergroups S-1-5-21-80214499-1554138238-4006517166-1150,S-1-5-21-80214499-1554138238-40065 17166-513,S-1-5-21-80214499-1554138238-4006517166-512,S-1-5-21-80214499-15541382 38-4006517166-520,S-1-5-21-80214499-1554138238-4006517166-1110,S-1-5-21-80214499 -1554138238-4006517166-519,S-1-5-21-80214499-1554138238-4006517166-518,S-1-5-21- 80214499-1554138238-4006517166-1112,S-1-18-
Block.Reason Authorization failed
see attached rule tracing.
Therefore, the last group which sees mwg is S-1-18-1. S-1-18-1 is a new type of group that came with AD of Windows 2012 level. The name of S-1-18-1 is “Authentication authority asserted identity”.
After coming of this group some systems are not able to map this SID (Unknown SID type <-> S-1-18-1) so vendors releases the hotfix (for example, Microsoft hotfix - https://support.microsoft.com/en-us/kb/2830145 ) .
Did anybody get such problem? How did you fix it?
P.S.: I think that we need to upgrade mwg Authentication engine for solving this issue.