WinBatch Tech Support Home

Database Search

If you can't find the information using the categories below, post a question over in our WinBatch Tech Support Forum.

TechHome

ADSI
plus

Can't find the information you are looking for here? Then leave a message over on our WinBatch Tech Support Forum.

Check for Admin Access

 Keywords: isadmin   

Although there are better ways to check for Admin access, this example shows one way to do it via ADSI. For other ways search the tech support database for isadmin.

;While the solution of checking write-access to the registry is a good way to
;check local administrator membership, I came up with code that could work for
;any local group, across NT4 and AD domains. The only caveat is that it does
;not check very deeply into group membership. For example, if the user is in
;the local admins group or is in a group in the local admins group, this
;finds it. If they are in a group that is in a group that is in the local
;admins group, it doesn't.

AddExtender("wwwnt34i.dll")
AddExtender("wwads34i.dll")

#DefineFunction IsLocalAdmin()
   Val=@FALSE
   CurrentUser=wntUserInfo(0)
   CurrentDomain=wntUserInfo(1)
   Groups=wntMemberGrps("","%CurrentDomain%\%CurrentUser%",@LOCALGROUP,1)
   If StrIndex(Groups,"Administrators",1,@FWDSCAN) <> 0
       Val=@TRUE
   EndIf
   If Val==@FALSE && dsIsObject("LDAP://rootDSE")==@TRUE
       LocalAdminMembers=wntMemberList("","Administrators", @LOCALGROUP)
       ;Message("wntMemberList",LocalAdminMembers); list of groups in the local admins group
       ServerDn=dsGetProperty("LDAP://rootDSE", "serverName")
       ServerName=ItemExtract(1, ServerDn, ",")
       ServerName=ItemExtract(2, ServerName, "=")
       ServerDn=dsGetProperty("LDAP://rootDSE", "defaultNamingContext")
       ServerPath="LDAP://%ServerName%/%ServerDN%"
       UserPath=dsFindPath(ServerPath, "(&(objectCategory=person)(sAMAccountName=%CurrentUser%))")
       LDAPUserGroups=dsGetUsersGrps(UserPath)
       ;Clean up results, getting rid of LDAP info
       For i=1 To ItemCount(LDAPUserGroups,@TAB)
           TmpGroup=ItemExtract(i,LDAPUserGroups,@TAB)
           x=StrIndex(TmpGroup,"=",1,@FWDSCAN)+1
           y=StrIndex(TmpGroup,",",1,@FWDSCAN)-1
           TmpGroup=StrSub(TmpGroup,x,y-x+1)
           LDAPUserGroups=ItemReplace(TmpGroup,i,LDAPUserGroups,@TAB)
       Next
       ;Message("dsGetUsersGrps",LDAPUserGroups) ; list of groups of which the current user is a member
       For i = 1 To ItemCount(LocalAdminMembers,@TAB)
           If ItemLocate(ItemExtract(i,LocalAdminMembers,@TAB),LDAPUserGroups,@TAB)>0
               Val=@TRUE
               ;Message("Match",ItemExtract(i,LocalAdminMembers,@TAB))
               Break
           End If
       Next
   End If
   Return Val
#EndFunction



Notes:

Beyond membership in the local "Administrators" group, you also have to consider any user or member of a group that has been granted a set of LSA privileges that are comparable to the ones granted to the local "Administrators" group. Aside from the command line "NET" command, the typical management tools you would use to perform these two sets of tests would be the Computer Management [compmgmt.msc] and Local Security Policy [secpol.msc] MMC snap-ins. With Computer Management, you would be able to examine the membership list of the local "Administrators" group. With Local Security Policy, you would be able to examine the LSA privileges that exist and who they have been granted to.

With WinBatch, one way is to make use of the Win32 Network [a.k.a "NT"] extender to perform these same examination via program code. The wntMemberList() function is used to list all members of a [local] group. The wntPrivList(), wntPrivUsers() and wntPrivGet() functions are used to query the LSA privilege database in various ways to find out what accounts have been granted which LSA privileges.

In a nutshell, use wntPrivList() to find out which LSA privileges have been granted to the local "Administrators" group. Then, use wntPrivUsers() to find out which accounts have been granted those same privileges. Any user or group that has been granted the same full set of privileges as the local "Administrators" group can be considered to have administrative capabilities even if the use or group is not actually a member of the local "Administrators" group. In fact, only a subset of those LSA privileges are necessary to escalate an account's access level to administrative level, so the test itself could be even more discriminating in that regard. Don't forget that users can obtain LSA privileges by having them directly granted and via membership in a group, either local or domain, which has been granted specific LSA privileges. This makes it necessary to do further testing w/wntMemberList() and wntMemberGet() to ensure that the complete set of effective LSA privileges available to any given account are properly identified.

Finally, there are a few Win32 API functions in the networking category that can only be used in certain ways if you are a member of the local "Administrators" group regardless of what LSA privileges you have been granted. These API functions actually test for membership in this group before they perform an operation or fail it due to an access-denied condition. When determining if a user is an administrator, it may well be necessary to keep track of membership in the local "Administrators" group independently of whatever LSA privileges the user has granted to them [either directly or indirectly] if you are preparing a very thorough security audit.


Article ID:   W15805
File Created: 2010:03:11:13:37:14
Last Updated: 2010:03:11:13:37:14