#76341 - 2003-08-1301:34 AMSIDTONAME for remote system - Possible?
NTDOCNTDOC Administrator
Registered: 2000-07-28
Posts: 11634
Loc: Space
I want to try to use SIDTONAME against a remote computer to create a group of select statements that will allow me to try a few different passwords for the Local Administrators account that we have on different systems.
I'm not sure this can be done this method or not and I'm looking to see if anyone can confirm whether or not it can be done via this method.
In cases where the Administrator account has been renamed I'd like to use SIDTONAME to check it. This is an Administrator script, not a logon script.
code:
break on
$wksta = 'computer1' ? 'Now attaching to: '+'\\'+$wksta SELECT CASE LocalAdmin('\\'+$wksta) ? 'You have admin rights on '+$wksta CASE NOT LocalAdmin('\\'+$wksta) USE V: '\\'+$wksta+'\C$' /user:$wksta+'\Administrator' /password:'password' ; The above line works but I want to use the line below in case the account ; has been renamed. $x = $wksta+'\'+sidtoname('S-1-5-32-500') USE V: '\\'+$wksta+'\C$' /user:$x /password:'password' ? 'Error mapping was: '+@ERROR+' - '+@SERROR IF @ERROR = 0 ? 'You successfully mapped the C$ share as an admin - run code' ELSE ? 'You were unable to map the C$ share as an admin - can not run code' ENDIF CASE 1 ? 'Unable to map as an Administrator' ENDSELECT
function LocalAdmin($wksta) $LocalAdmin=ingroup('$wksta\'+sidtoname('S-1-5-32-544'))-1+@inwin endfunction
LocalAdminGrp(optional $Server) Returns the name of the local BUILTIN\Administrators group on $Server.
This method is valuable when trying to locate a renamed or language localized group name. When $Server is NULL, the local computer is used. This method is valuable when trying to locate an account that has been renamed or is not 'Administrators' because of OS language localization.
#76346 - 2003-08-1302:14 PMRe: SIDTONAME for remote system - Possible?
Howard BullockHoward Bullock
KiX Supporter
Registered: 2000-09-15
Posts: 5809
Loc: Harrisburg, PA USA
Clarification for those that have an interest in the details of the SidToName() implementation.
SidToName() does resolve remote sids to names but only those that visible via a trust relation. In other words, you can resolve accounts and groups sids of your domain or a trusted domain but not those of a member server, workstation, or untrusted domain.
#76347 - 2003-08-1308:10 PMRe: SIDTONAME for remote system - Possible?
NTDOCNTDOC Administrator
Registered: 2000-07-28
Posts: 11634
Loc: Space
Howard,
This code works fine if my account is in the local administrators group on the remote system, but it does not work if my membership is only through a Universal group.
code:
break on $wksta = 'workstation1' RemoteAdmin($wksta)
function RemoteAdmin($wksta) $Win32Admin = createobject("Win32Admin") $AdminGrp = $Win32Admin.GetLocalAdminGrp($wksta) $AdminAccount = $Win32Admin.GetAdminAccount($wksta) ? 'AdminGroup is: '+$AdminGrp ? 'Admin Account is: '+$AdminAccount ? '\\'+$wksta+'\'+$AdminGrp IF INGROUP('\\'+$wksta+'\'+$AdminGrp) ? 'You are a member of Admins group on: '+$wksta+' '+@error+' - '+@serror ELSE ? 'You are NOT a member of Admins group on: '+$wksta+' '+@error+' - '+@serror ENDIF $Win32Admin = 0 endfunction
#76348 - 2003-08-1308:12 PMRe: SIDTONAME for remote system - Possible?
Howard BullockHoward Bullock
KiX Supporter
Registered: 2000-09-15
Posts: 5809
Loc: Harrisburg, PA USA
Unfortunately, I do not have any Universal groups to test in my environment. This would seem to indicate a BUG in INGROUP relative to UNVERSAL group enumeration.
#76349 - 2003-08-1308:21 PMRe: SIDTONAME for remote system - Possible?
Howard BullockHoward Bullock
KiX Supporter
Registered: 2000-09-15
Posts: 5809
Loc: Harrisburg, PA USA
I thought I read that INGROUP supported univeral groups
quote: INGROUP can be used to check for group membership of groups that exist on the domain or server where the user is logged on, or to check for group membership of groups on a specific domain or server.
When checking for a local group, INGROUP identifies that the user is indirectly a member of the group by virtue of being a member of a global group which, in turn, is a member of the local group.
#76352 - 2003-08-1308:39 PMRe: SIDTONAME for remote system - Possible?
Howard BullockHoward Bullock
KiX Supporter
Registered: 2000-09-15
Posts: 5809
Loc: Harrisburg, PA USA
I thought I read that INGROUP supported univeral groups
quote: INGROUP can be used to check for group membership of groups that exist on the domain or server where the user is logged on, or to check for group membership of groups on a specific domain or server.
When checking for a local group, INGROUP identifies that the user is indirectly a member of the group by virtue of being a member of a global group which, in turn, is a member of the local group.
Yes I thought I saw it.
quote: Previous versions of KiXtart always queried the logonserver for the group-membership information. This provided information on both local and global groups in the logondomain. As of KiXtart 2001, KiXtart retrieves group-membership information using the security token of the current user. The benefit of the new method is that KiXtart can now support universal groups as well as nested global groups.
This issue seems like a bug to me. Ruud a little help please.
Registered: 1999-05-06
Posts: 391
Loc: Amsterdam, The Netherlands
In short: InGroup supports any type of group included in the user token. This includes universal groups.
However, querying for groupmembership on a remote domain or machine does not (can not) rely on the user token, but instead directly queries the remote system. The API involved sadly does not support nested groups. The only workaround for this would be to recursively query all groups on the system, which would be much too expensive in terms of performance and network traffic.
![[Confused]](images/icons/confused.gif){kind=icon}
