|
|
|||||||
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. |
||||||||
|
|
|||||||
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 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 |
||||||||
|
|
|||||||
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. |
||||||||
|
|
|||||||
A simple work around... Code: If Open(1,"%windir%\testfile.txt",5) = 5 ? "Not Admin" Else ? "Admin" Endif get $ |
||||||||
|
|
|||||||
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 |
||||||||
|
|
|||||||
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 Code: Detected O/S: Windows 7 Professional Edition / Version 6.1 Privelege: USER Local Privelege: 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') Glenn |
||||||||
|
|
|||||||
And you have UAC turned on at the default level on that computer? |
||||||||
|
|
|||||||
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. |
||||||||
|
|
|||||||
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 ? Code: LPriv: Admin Priv: USER IsAdmin: 5 My workstation is Win-7 x64, FYI. Glenn |
||||||||
|
|
|||||||
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? |
||||||||
|
|
|||||||
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) Glenn |
||||||||
|
|
|||||||
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") |
||||||||
|
|
|||||||
On is the default, and turning it off for a particular reason should be followed by turning it back on. Glenn |