16

Given a pair of a user and a privilege I need to determine if a user has the privilege on the server. The following is true in my setup:

  • The server is a part of a domain but not a domain controller
  • There are several domains with trust relationship in the infrastructure
  • Sometimes users (local, domain, or from a different domain) can belong to a local group by a merit of them being in some other group (domain or local) that belongs to a local group, as opposed to belonging to the group directly.

Example scenario for the last point:

  • User1 belongs to group TeamA in the DomainA
  • DomaimA\TeamA is a member of DomainB\SpecialAccess
  • DomainB\SpecialAccess is a member of DomainB\DomainAdmins
  • Finally DomainB\DomainAdmins belong to local Administators group
  • Local Administators group has SeRemoteInteractiveLogonRight privelege

Now If I have on the input DomainA\User1 and SeRemoteInteractiveLogonRight I need to arrive to Yes or No answer. So I open the Local Policy on the machine, note what groups are listed against the right I'm interested too then go to the server managers and see what at the group members and then I need to see what members of any groups in these groups and so on.

I have a gut feeling that it can be easier. I was really excited when I found AccessChk utility It lasted whole three minutes that took me to discover that it only lists direct relationship, so user within a group won't be listed.

Now I'm guessing that it would be possible to combine results from AccessChk some how so that I can check if a user belongs to any of the groups that AccessChk return, but given that it's not a single domain but several of them I'm not sure how to approach this. Also AccessChk output does not seem to distinguish between a group and a user.

EDIT: In the spirit of not falling into XY problem trap, what I really need to do is to make sure that on a group of servers no specific user accounts that are used as IIS application pool identities have SeInteractiveLogonRight or SeRemoteInteractiveLogonRight privileges. I have no problem with the IIS part, but the last step of checking an account against a privilege is something that I'm struggling finding a straightforward way to check. I also would like to automate the check because this is something that will need to be done regularly.

HBruijn
  • 77,029
  • 24
  • 135
  • 201
Andrew Savinykh
  • 526
  • 2
  • 7
  • 21
  • 6
    This sounds like a job for... Resultant Set of Policy (RSoP)! http://technet.microsoft.com/en-us/library/cc758010%28v=WS.10%29.aspx – Davidw Jul 07 '14 at 04:50
  • 1
    @zespri - My answer was garbage and I deleted it. The SeInteractiveLogonRight and SeRemoteInteractiveLogonRight user rights are handled differently than "normal" privileges and it looks like reporting on them is going to be problematic. If I come up with a solution for you I'll post another answer but, for now I've got nothing. – Evan Anderson Jul 09 '14 at 03:20
  • 1
    @Davidw - RSoP is problematic in that the Local Security Policy defaults won't be reflected in the output. So, any "Not Configured" entries will just show up as "Not Configured" and you won't actually see what principals are granted the right by Local Security Policy. Finally, even if you do get a list of principals from Group Policy you'll be stuck expanding group memberships (potentially cross-domain, too) to replicate OS functionality. This has actually turned out the a much more challenging question than I expected it to be. – Evan Anderson Jul 09 '14 at 03:27
  • 1
    @EvanAnderson Exactly! When I was asked to estimate how long it was going to take me, it seemed to be a straightforward task. And after a couple of days of googling and trying different things... nothing. Currently my plan is to pinvoke [GetTokenInformation](http://msdn.microsoft.com/en-us/library/windows/desktop/aa446671%28v=vs.85%29.aspx) with TokenPrivileges [token information class](http://msdn.microsoft.com/en-us/library/windows/desktop/aa379626%28v=vs.85%29.aspx) Of course I need to figure out first how to get hold of the token itself. This route seems the most promising at the moment. – Andrew Savinykh Jul 09 '14 at 05:37
  • @zespri - NtOpenProcessToken() is probably the best way to get at the token. (Have a look at http://www.leeholmes.com/blog/2006/07/21/get-the-owner-of-a-process-in-powershell-%E2%80%93-pinvoke-and-refout-parameters/) – Evan Anderson Jul 09 '14 at 12:58
  • Are you using entirely 'real' user accounts, or are there some managed service accounts in there too? IIS will accept either in Win2008R2+, but you might have harder time getting the token of an MSA. – jimbobmcgee Apr 08 '16 at 19:15
  • One option to get the token might be to scan for processes owned by that user, then call `OpenProcessToken`... – jimbobmcgee Apr 08 '16 at 19:41
  • This should be easy with Powershell, expect Powershell is bad dealing with local groups. But if you can manage to get the members of the local group, a loop in Powershell expanding the AD groups until you get just users, and compare with your given user should be the way to go... – curropar May 23 '16 at 16:28
  • Related: http://www.tomshardware.com/forum/224643-46-detect-user-logon-rights-win2k – Andrew Savinykh Jun 16 '16 at 11:08
  • Related: http://www.informit.com/articles/article.aspx?p=474649&seqNum=6 – Andrew Savinykh Jun 16 '16 at 11:53
  • @EvanAnderson, just FYI I think I cracked this (see below). Also: [my related SO question](http://stackoverflow.com/a/37858949/284111) – Andrew Savinykh Jun 16 '16 at 12:19
  • @zespri - It took me a few minutes to get the context back (since it has been two years since we last talked about this), but that looks legit to me! (I remember being frustrated at having *just* learned, by answering your question and subsequently deleting my answer, that user rights and privileges are handled differently in NT. That was a real "today I learned" moment...) – Evan Anderson Jun 21 '16 at 14:49

1 Answers1

1

Access tokens do not have information about rights, only about privileges.

What you need to do is this:

  • Find the IIS worker process that corresponds to your app pool. Since you know the app pool identity that should be easy by enumerating all the processes with the worker process name, and filtering the one that has the identity. If there are more than one, you can use any.
  • Use GetTokenInformation with TokenGroup information class, not the TokenPrivilege on the process token. The result will give you all the transitive groups the identity belongs too. This means even indirect ones.
  • Now you can loop through these groups and call LsaEnumerateAccountRights on each one and collate the information. This will give you what you want.

The above relies on the existence of the process (and token) corresponding to the account identity. In your scenario this should not be a problem. In scenarios when this is a problem, you can try and use Active Directory lookup for Token-Groups computed attribute. This article lists a few approaches how to pull this off.

Andrew Savinykh
  • 526
  • 2
  • 7
  • 21