You are not logged in. [Log In] KiXtart.org website » Forums » KiXtart » Basic Scripting » INGROUP - Windows 7 Pro 64bit - AD Domain
Register User       Forum List       Calendar       FAQ
Page 1 of 1 1
Topic Options
#205675 - 2012-09-06 10:06 PM INGROUP - Windows 7 Pro 64bit - AD Domain
syntax53 Offline
Fresh Scripter

Registered: 2004-11-17
Posts: 33
Loc: Pennsylvania
I'm trying to determine if the user logging in has admin rights, mainly for tracking purposes. Since we have UAC turned on, even when an admin signs in @priv reports "user" or "guest." I've tried using the alternative mentioned here: http://www.kixtart.org/forums/ubbthreads.php?ubb=showflat&Number=84156 but it's not working when executed during the logon. The event log reports the following:

"Failed to get API pointers Error : The specified procedure could not be found. (0x7f/127)"

However, if I run the script from a command line once the user is logged in it works fine (even without elevated permissions). Here is the test script:

 Code:
function LocalAdmin()
    IF INGROUP(UCASE(@WKSTA) + "\Administrators")
        $LocalAdmin=1
    ELSE
        $LocalAdmin=0
    ENDIF
endfunction

if @PRIV = "ADMIN"
    $priv = "ADMIN"
else
    if LocalAdmin = 1
        $priv = "ADMIN"
    else
        $priv = "USER"
    endif
endif


edit: Just wanted to add that the script also works fine on XP pro (32bit) computers.

Edited by syntax53 (2012-09-06 10:08 PM)
Top
#205676 - 2012-09-07 12:04 AM Re: INGROUP - Windows 7 Pro 64bit - AD Domain [Re: syntax53]
Allen Administrator Online shocked
KiX Supporter
*****

Registered: 2003-04-19
Posts: 4542
Loc: USA
Is this a traditional logon script or a GPO Startup Script?

I can't remember exactly what is about @priv, but I know I remember that it doesn't work as advertised any more. If I remember correctly @priv is a carry over from Win9x days.
Top
#205677 - 2012-09-07 12:06 AM Re: INGROUP - Windows 7 Pro 64bit - AD Domain [Re: Allen]
Allen Administrator Online shocked
KiX Supporter
*****

Registered: 2003-04-19
Posts: 4542
Loc: USA
It also appears you are using an old or altered version of LocalAdmin... here is the link to UDF... http://www.kixtart.org/forums/ubbthreads.php?ubb=showflat&Number=84156
Top
#205678 - 2012-09-07 04:56 AM Re: INGROUP - Windows 7 Pro 64bit - AD Domain [Re: Allen]
syntax53 Offline
Fresh Scripter

Registered: 2004-11-17
Posts: 33
Loc: Pennsylvania
 Originally Posted By: Allen
Is this a traditional logon script or a GPO Startup Script?
I can't remember exactly what is about @priv, but I know I remember that it doesn't work as advertised any more. If I remember correctly @priv is a carry over from Win9x days.

It's a traditional logon script. How can it be a carry over from win9x? Administrators didn't exist in 9x.

 Originally Posted By: Allen
It also appears you are using an old or altered version of LocalAdmin... here is the link to UDF... http://www.kixtart.org/forums/ubbthreads.php?ubb=showflat&Number=84156

I modified the script, but it's the same difference. The sid "S-1-5-32-544" is the SID for the local administrators group. So sidtoname('S-1-5-32-544') == "Administrators" and therefor '@wksta\'+sidtoname('S-1-5-32-544') == @WKSTA + "\Administrators." Regardless though, I did try it the first way first and later changed it to my way thinking something was going on the with sidtoname function.

Edited by syntax53 (2012-09-07 04:57 AM)
Top
#205679 - 2012-09-07 05:11 AM Re: INGROUP - Windows 7 Pro 64bit - AD Domain [Re: syntax53]
ShaneEP Moderator Offline
MM club member
*****

Registered: 2002-11-29
Posts: 2125
Loc: Tulsa, OK
A simple work around...

 Code:
If Open(1,"%windir%\testfile.txt",5) = 5
   ? "Not Admin"
Else
   ? "Admin"
Endif

get $
Top
#205680 - 2012-09-07 02:24 PM Re: INGROUP - Windows 7 Pro 64bit - AD Domain [Re: ShaneEP]
syntax53 Offline
Fresh Scripter

Registered: 2004-11-17
Posts: 33
Loc: Pennsylvania
 Originally Posted By: ShaneEP
A simple work around...

 Code:
If Open(1,"%windir%\testfile.txt",5) = 5
   ? "Not Admin"
Else
   ? "Admin"
Endif

get $

Unfortunately that doesn't work through UAC either \:\(
Top
#205685 - 2012-09-07 07:53 PM Re: INGROUP - Windows 7 Pro 64bit - AD Domain [Re: syntax53]
Glenn Barnas Administrator Offline
KiX Supporter
*****

Registered: 2003-01-28
Posts: 4395
Loc: New Jersey
Odd.. made me go back and check our Login script as we use the @PRIV macro for generic privelege checking, mostly to display a message to users with admin rights.

I logged into 3 servers as an admin and @PRIV detected me being a domain admin and displayed an "Admin Alert" message. I then logged into a dev server with my non-admin account and did not get the message. Logging into my local workstation (where I am a local admin) with my regular account, the script used the logic in the LocalAdmin UDF to properly detect that I was a local admin. These are Win7, Server 2003 and Server 2008r2 systems, and @PRIV seems to work for all Domain Admin logins, and LocalAdmin() UDF works as well. Here's the Debug Dump from the login script on the DC:
 Code:
NAC Checking is ENABLED.
=========================================================
2012/09/07  -  13:41:06
          Kixtart: 4.62
          Version: 2.8.1_ts
         INI File: C:\Temp\2\login.ini (cached)
             User:  / Administrator
         Language: (1) / English (United States)
           Locale: 1033
      LoginServer: \\ICDCP01
           Domain: CORP
       User OU DN: DC=corp,DC=itcg,DC=lan
   User OU Offset: 0
          User OU: corp
  Wkstn OU Offset:
      Wkstn OU DN: OU=Domain Controllers,DC=corp,DC=itcg,DC=lan
         Wkstn OU: Domain Controllers
       Logon Mode: 0
           Laptop: 0
     Detected O/S: Windows Server 2008 R2  / Version 6.1
        Privelege: ADMIN
  Local Privelege: Admin
        ScriptDir: \\corp\netlogon / \\corp\netlogon
         StartDir: \\corp\netlogon
     User Process: 0
     Session Type: RDP-Tcp#0
      LP Hard Map:
      Debug Level: 1
The results from my workstation are slightly different:
 Code:
     Detected O/S: Windows 7 Professional Edition / Version 6.1
        Privelege: USER
  Local Privelege: Admin
This shows that my @PRIV is USER, but local privelege is Admin.

The code I use in our login script is something like:
 Code:
If InGroup(@WKSTA + '\' + SIDtoName('S-1-5-32-544')) - 1 + @INWIN
  $LPRIV = 'Admin' 
Else
  $LPRIV = 'User' 
EndIf
$IsAdmin = InStr(@PRIV + $LPRIV, 'Admin')
This sets $IsAdmin to true if either Local ($LPRIV) or Domain (@PRIV) admin rights were detected.

Glenn
_________________________
Actually I am a Rocket Scientist! \:D

Top
#205687 - 2012-09-07 09:14 PM Re: INGROUP - Windows 7 Pro 64bit - AD Domain [Re: Glenn Barnas]
syntax53 Offline
Fresh Scripter

Registered: 2004-11-17
Posts: 33
Loc: Pennsylvania
And you have UAC turned on at the default level on that computer?
Top
#205688 - 2012-09-07 10:09 PM Re: INGROUP - Windows 7 Pro 64bit - AD Domain [Re: syntax53]
syntax53 Offline
Fresh Scripter

Registered: 2004-11-17
Posts: 33
Loc: Pennsylvania
Well... couple of notes. #1) UAC seems to have 0 effect. I just turned it off on one machine and during logon it still fails to detect admin.

#2) The API error I reported earlier gets tripped when @PRIV is referenced OR InGroup(@WKSTA + '\' + SIDtoName('S-1-5-32-544')) is used. But only during the logon. If I run the script after it's logged on I get no API error and the result is as expected.
Top
#205689 - 2012-09-07 10:23 PM Re: INGROUP - Windows 7 Pro 64bit - AD Domain [Re: syntax53]
Glenn Barnas Administrator Offline
KiX Supporter
*****

Registered: 2003-01-28
Posts: 4395
Loc: New Jersey
I just turned UAC back on and it worked as usual during logon. UAC is enabled on servers, but set to a lower level by policy.

Did you try my code example? When I add
 Code:
'  LPriv: ' $LPriv ?	
'   Priv: ' @PRIV ?
'IsAdmin: ' $IsAdmin ?
I get the following result:
 Code:
  LPriv: Admin
   Priv: USER
IsAdmin: 5
IsAdmin is set to the position in the string where "Admin" was found, and would be 0 if not found. This works fine for true/false testing. (If $IsAdmin).

My workstation is Win-7 x64, FYI.

Glenn
_________________________
Actually I am a Rocket Scientist! \:D

Top
#205691 - 2012-09-08 04:57 AM Re: INGROUP - Windows 7 Pro 64bit - AD Domain [Re: Glenn Barnas]
syntax53 Offline
Fresh Scripter

Registered: 2004-11-17
Posts: 33
Loc: Pennsylvania
I did try your version and had the same results. Is there any way I can debug what is happening during the logon that makes it different from when it's run after the logon?
Top
#205701 - 2012-09-08 09:38 PM Re: INGROUP - Windows 7 Pro 64bit - AD Domain [Re: syntax53]
Glenn Barnas Administrator Offline
KiX Supporter
*****

Registered: 2003-01-28
Posts: 4395
Loc: New Jersey
You could run my login script with no resource records configured. Put "kix32.exe kixtart.kix --D" in your profile. It will create a LoginDebug.log file in your %USERPROFILE% directory as shown above, which will have the PRIV and LPRIV values. If they are correct during login AND after login, the logic is correct and there's an issue somewhere in your code.

Our script has extensive debug and perflog messages throughout the code. You'd have to do something similar to your script.

There's a fMSG UDF library on my web site.. I use it for all kinds of output in scripts. The command
 Code:
$Msg = 'The value of X is ' + $X + '.'
fMsg($Msg, , 0, 20)
This will write the message to the log file defined in $MSG_LOG_ only if $DEBUG is true. Both of these are Global vars. If DEBUG is false, no output is written. fMsg allows you to write one message to both screen and log or separate screen/log messages. You can suppress newlines to continue writing on the same line, and the "20" is a mode value that controls how and where the message is displayed - 20 is Log Only and Debug Only. You can even change the 0 to a different value so the value of DEBUG must be greater than that value, permitting terse to verbose debug messages. \:\)

Glenn
_________________________
Actually I am a Rocket Scientist! \:D

Top
#205723 - 2012-09-10 08:29 PM Re: INGROUP - Windows 7 Pro 64bit - AD Domain [Re: Glenn Barnas]
syntax53 Offline
Fresh Scripter

Registered: 2004-11-17
Posts: 33
Loc: Pennsylvania
So I can't believe I spent so much time on this and this is the final culprit:

$Result = SetOption("Wow64FileRedirection", "OFF")

That was being turned off in a script that executed before this one. And for some reason that option is breaking a lot of stuff. Not only does it break everything I was trying to do with the logon logging, it also breaks the @FULLNAME macro (which I subsequently found a fix for with the TranslateName UDF).

Amazing.

The the fix is...

$Result = SetOption("Wow64FileRedirection", "ON")

Edited by syntax53 (2012-09-10 08:29 PM)
Top
#205726 - 2012-09-11 01:37 AM Re: INGROUP - Windows 7 Pro 64bit - AD Domain [Re: syntax53]
Glenn Barnas Administrator Offline
KiX Supporter
*****

Registered: 2003-01-28
Posts: 4395
Loc: New Jersey
On is the default, and turning it off for a particular reason should be followed by turning it back on. \:D

Glenn
_________________________
Actually I am a Rocket Scientist! \:D

Top
Page 1 of 1 1


Moderator:  Jochen, Allen, Radimus, Glenn Barnas, ShaneEP, Ruud van Velsen, Arend_, Mart 
Hop to:
Shout Box

Who's Online
0 registered and 465 anonymous users online.
details
Newest Members
KeithDTX, WuterHoestee, shootnhack, got2begin, Compu
17853 Registered Users
My Cookies · Mark all read Powered by UBB.threads™ Contact Us · KiXtart.org website · Top

Generated in 0.07 seconds in which 0.025 seconds were spent on a total of 13 queries. Zlib compression enabled.
Search the board with:
superb Board Search
or try with google:
Google
Web kixtart.org