Remko Weijnen's Blog (Remko's Blog) » Terminal Server

NTVDM encountered a hard error

Remko — Wed, 14 Dec 2011 20:41:22 +0000

Today I troubleshooted an old DOS application that needed to run on a 32 bit Citrix XenApp Server. The last time I saw an actual DOS application in a production environment must be years ago.

When starting the application, the WOW subsystem (NTVDM) crashed with the message: “NTVM encountered a hard error.”:

After spending some time troubleshooting I remembered a similar issue from a few years ago where a DOS application worked fine from the Console but refused to work from an RDP or ICA session.

And indeed the application works perfectly when run from the Console but not from a Console session. I noticed that the application switched to full screen mode after it was launched (even when I set it to Windowed mode) and presumably this is why ntvdm errors: full-screen mode is disallowed for DOS apps in RDP (and ICA) sessions as documented in Q192190.

I looked for a way to force the application to run in windowed mode but I was unable to find such a solution. So I decided to test the application in DOSBox, an x86 PC emulator.

And that worked perfectly, no changes were needed at all to make the application run.

As an added bonus, DOSBox takes care of typical issues with DOS applications running on Citrix XenApp such as keyboard polling and 100% cpu usage.

I was even more impressed that the application runs fine with DOSBox on my Windows 7 64 bit machine!

There is one thing I didn’t like though, DOSBox always shows a Splashscreen that fades in and out:

This is typically something that is not desirable on a XenApp (or RDS) environment because it causes many unnecessary screen updates. This may be a non issue on a fast LAN but on a slower WAN or high latency connection it may matter. Do how do we get rid of it?

There is no commandline argument or config setting that disables the splash so I figured that my only option would be to compile the DOSBox source and leave out the splash screen.

So I downloaded the source files from the sourceforge project page and launched Visual Studio 2010.

The Splashscreen is in sdlmain.cpp but I noticed this comment:

/* Please leave the Splash screen stuff in working order
in DOSBox. We spend a lot of time making DOSBox. */

This presented me with a dilemma: I really think the creators deserve their credit but at the same time I want to get rid of the splash.

So I decided to change the code in a way that the Splash screen is shown when run from the Console but not when run from an RDP or ICA session. This change was very easy, I surrounded the Splash screen code with a conditional statement:

/* We will ignore the splashscreen when in a remote session */

if (!GetSystemMetrics(SM_REMOTESESSION))
{
// Splash screen code
}

In order to compile the code with Visual Studio I followed the Building DOSBox with Visual C 2008 Express article from the Wiki.

Below you will find two downloads:

A binary package, containing my compiled DOSBox.exe and it’s dependancies.
A source code package, containing the modified source and the SDL Development Libraries. The modified source is licensed under the GNU GPL license.

If you are going to use DOSBox I highly encourage you to make a donation to Support the DOSBox project.

A few other causes for the “NTVM encountered a hard error” message may be:

The %TEMP% or %TMP% variable point to a directory that is not in a short (8.3) format. See also CTX110996.
Error message when you run a 16-bit program in Windows Server 2003: "NTVDM has encountered a hard error” (Hotfix KB937932).
Check that HKLM\System\CurrentControlSet\Control\WOW\DisallowedPolicyDefault is set to 0
Check that HKLM\SYSTEM\CurrentControlSet\Control\VirtualDeviceDrivers\VDD doesn’t contain non existing files.

DOSBox 0.74 (23)

DOSBox 0.74 Source Code (8)

SSL Certificates in termsrv.dll

Remko — Mon, 02 May 2011 12:54:39 +0000

I was digging around in termsrv.dll yesterday when I noticed that there are some (well 372 to be exact) SSL certificates inside the Terminal Server binary (termsrv.dll):

Two of them seem to actually contain the private keys as well, but I am not 100% sure it may be just a certificate in another format.

I wrote a small PowerShell script to import these certificates into the personal certificate store so I could inspect them easily:

[void][System.Reflection.Assembly]::LoadWithPartialName("System.Security")

$store = New-Object System.Security.Cryptography.X509Certificates.X509Store
$store.Open([System.Security.Cryptography.X509Certificates.OpenFlags]::ReadWrite)

foreach ($file in dir -Path c:\Tools\dumper\*.txt)
{
$cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2 $file
try
{
$store.Add($cert)
}
catch
{
Write-Error ("Error Adding $certfile") -ErrorAction:Continue
}

}

$store.close

The certificates appear to be public certificates of root CA’s, I have no idea of their intended purpose (why they need to be inside the termsrv.dll):

The keys that were marked as private are these two:

Autologon user on Windows XP/2003 using AutoReconnect pipe – part 3 (implementation details)

daNIL — Thu, 03 Mar 2011 12:00:46 +0000

In the previous parts (part 1 part 2) i’ve described the theoretical part and implementation problems. So, now we can write the code:

1) In case we login the user, we just call LsaLogonUser to get the token:

function CopyString(const Source : WideString; const Buffer : Pointer; var CurrentPosition : Pointer; LengthInBytes: Cardinal = $FFFFFFFF) : Pointer;
begin
if (Source <> ” ) then
begin
Cardinal(Result) := Cardinal(CurrentPosition) – Cardinal(Buffer);
if (LengthInBytes = $FFFFFFFF) then
LengthInBytes := (Length(Source) + 1) * SizeOf(Source[1]);

CopyMemory(CurrentPosition, PWideChar(Source), LengthInBytes);
Cardinal(CurrentPosition) := Cardinal(CurrentPosition) + LengthInBytes;
end
else
Result := nil;
end;

procedure CopyUnicodeString(const Target : PUnicodeString; const Source : PUnicodeString; const Buffer : Pointer; var CurrentPosition : Pointer);
begin
Target^ := Source^;
Target^.Buffer := CopyString(Target^.Buffer, Buffer, CurrentPosition, Target^.MaximumLength);
end;

procedure CreateLsaLogonPackageBuffer(const UserName, Domain, Password : WideString;
out Result : PMSV1_0_INTERACTIVE_LOGON; out ResultLength : Cardinal);
var
LogonCurrentPointer : Pointer;
begin
ResultLength := SizeOf(Result^) + (Length(UserName) + Length(Domain) + Length(Password) + 3) * SizeOf(UserName[1]);
Result := GetMemory(ResultLength);
try
ZeroMemory(Result, ResultLength);

Cardinal(LogonCurrentPointer) := Cardinal(Result) + SizeOf(Result^);

Result^.MessageType := MsV1_0InteractiveLogon;

RtlInitUnicodeString(@Result^.UserName, PWideChar(UserName));
CopyUnicodeString(@Result^.UserName, @Result^.UserName, nil, LogonCurrentPointer);

RtlInitUnicodeString(@Result^.LogonDomainName, PWideChar(Domain));
CopyUnicodeString(@Result^.LogonDomainName, @Result^.LogonDomainName, nil, LogonCurrentPointer);

RtlInitUnicodeString(@Result^.Password, PWideChar(Password));
CopyUnicodeString(@Result^.Password, @Result^.Password, nil, LogonCurrentPointer);
except
FreeMemory(Result);
Raise;
end;
end;

procedure LoginUser;
var
LsaHandle : THandle;
LsaName : LSA_STRING;
PackageName : LSA_STRING;
AuthenticationPackage : ULONG;
LogonPackageBuffer : PMSV1_0_INTERACTIVE_LOGON ;
LogonPackageBufferLength : Cardinal;
TokenSource : JwaWindows.TTokenSource;
SubStatus : Integer;
SecurityMode : LSA_OPERATIONAL_MODE;
begin
RtlInitUnicodeString(@LsaName, ‘AutoLogonXP login’);
NtCheck(LsaRegisterLogonProcess(LsaName, LsaHandle, @SecurityMode));
try
RtlInitString(@PackageName, PCSZ(PChar(MSV1_0_PACKAGE_NAME)));
LsaLookupAuthenticationPackage(LsaHandle, PackageName, AuthenticationPackage);

JwaWindows.AllocateLocallyUniqueId(TokenSource.SourceIdentifier);
TokenSource.SourceName := ‘AUTOLGON’;

CreateLsaLogonPackageBuffer(UserName, Domain, Password, LogonPackageBuffer, LogonPackageBufferLength);
try
NtCheck(
LsaLogonUser(
LsaHandle,
LsaName,
Interactive,
AuthenticationPackage,
LogonPackageBuffer,
LogonPackageBufferLength,
TokenGroups,
@TokenSource,
Pointer(Profile),
ProfileLength,
JwaWindows.LUID(Result^.LogonId),
Result^.UserToken,
JwaWindows.QUOTA_LIMITS(Result^.Quotas),
SubStatus
));
finally
FreeLsaLogonPackageBuffer(LogonPackageBuffer);
end;
finally
LsaDeregisterLogonProcess(LsaHandle);
end;
end;

2) In case we need to create a token, we call NtCreateToken. If there are no groups, we create a single group with the Primary SID in this group :

procedure CreateToken;
var
ExpirationTime : LARGE_INTEGER;
User : JwaWindows.TOKEN_USER;
TokenSource : TOKEN_SOURCE;
PrimaryGroup : JwaWindows.TOKEN_PRIMARY_GROUP;
EmptyTokenGroups : JwaWindows.TTokenGroups;
begin
ExpirationTime.QuadPart := 0;

User.User.Sid := PrimarySID;
User.User.Attributes := 0;

TokenSource.SourceName := ‘AUTOLGON’;
Win32Check(AllocateLocallyUniqueId(TokenSource.SourceIdentifier));

Result^.LogonId := SYSTEM_LUID;

PrimaryGroup.PrimaryGroup := PrimarySID;

if (nil = TokenGroups) then
begin
EmptyTokenGroups.GroupCount := 1;

EmptyTokenGroups.Groups[0].Sid := PrimarySID;
EmptyTokenGroups.Groups[0].Attributes := SE_GROUP_MANDATORY or SE_GROUP_ENABLED or SE_GROUP_ENABLED_BY_DEFAULT or SE_GROUP_LOGON_ID;

TokenGroups := @EmptyTokenGroups;
end;

EnableToken(SE_CREATE_TOKEN_NAME);
NtCheck(
NtCreateToken(
@Result^.UserToken,
TOKEN_ALL_ACCESS,
nil,
TokenPrimary,
@Result^.LogonId,
@ExpirationTime,
@User,
TokenGroups,
Privs,
nil,
@PrimaryGroup,
nil,
@TokenSource
));

try
Profile := AllocEmptyProfile(ProfileLength);
except
CloseHandle(Result^.UserToken);
Raise;
end;

end;

3) In case we want to use a “current” system token, we need to do some adjustments with it – we need to add the group with SE_GROUP_LOGON_ID flag to it:

function GetFromToken(TokenHandle : THandle; Info : TOKEN_INFORMATION_CLASS) : Pointer;
var
Res : DWORD;
begin
Result := nil;
GetTokenInformation(TokenHandle, info, nil, 0, Res);
if GetLastError = ERROR_INSUFFICIENT_BUFFER then
begin
Result := GetMemory(Res);
Win32Check(GetTokenInformation(TokenHandle, info, Result, Res, Res));
end else
RaiseLastOSError;
end;

procedure AsSystem;
var
SystemToken : THandle;

Statistics : PTokenStatistics;
User : JwaWinNT.PTokenUser;
Priviledges : JwaWindows.PTokenPrivileges;
Owner : PTokenOwner;
Groups : JwaWindows.PTokenGroups;
PrimaryGroup : PTokenPrimaryGroup;
DefaultDacl : PTokenDefaultDacl;
TokenSrc : PTokenSource;

TokenNewGroups : JwaWindows.PTokenGroups;
I : Integer;
begin
Win32Check(OpenProcessToken(GetCurrentProcess, TOKEN_ALL_ACCESS, SystemToken));

EnableToken(SE_CREATE_TOKEN_NAME);

Statistics := nil;
User := nil;
Priviledges := nil;
Owner := nil;
PrimaryGroup := nil;
DefaultDacl := nil;
TokenSrc := nil;
Groups := nil;
TokenNewGroups := nil;

try
Statistics := GetFromToken(SystemToken, TokenStatistics);
User := GetFromToken(SystemToken, TokenUser);
Priviledges := GetFromToken(SystemToken, TokenPrivileges);
Owner := GetFromToken(SystemToken, TokenOwner);
PrimaryGroup := GetFromToken(SystemToken, TokenPrimaryGroup);
DefaultDacl := GetFromToken(SystemToken, TokenDefaultDacl);
TokenSrc := GetFromToken(SystemToken, TokenSource);
Groups := GetFromToken(SystemToken, JwaWinNT.TokenGroups);

TokenNewGroups := GetMemory(SizeOf(TokenNewGroups^) + SizeOf(TokenNewGroups^.Groups) * Groups^.GroupCount);

TokenNewGroups^.GroupCount := Groups^.GroupCount + 1;

for I := 0 to Groups^.GroupCount – 1 do
TokenNewGroups^.Groups[I] := Groups^.Groups[I];

TokenNewGroups^.Groups[Groups^.GroupCount].Sid := Pointer(User^.User.Sid);
TokenNewGroups^.Groups[Groups^.GroupCount].Attributes := SE_GROUP_MANDATORY or SE_GROUP_ENABLED or SE_GROUP_ENABLED_BY_DEFAULT or SE_GROUP_LOGON_ID;

NtCheck(
NtCreateToken(
@Result^.UserToken,
TOKEN_ALL_ACCESS,
nil,
Statistics^.TokenType,
@Statistics^.AuthenticationId,
@Statistics^.ExpirationTime,
User,
TokenNewGroups,
Priviledges,
Owner,
PrimaryGroup,
DefaultDacl,
TokenSrc
));

finally
if (Statistics <> nil) then
FreeMemory(Statistics);

if (User <> nil) then
FreeMemory(User);

if (Priviledges <> nil) then
FreeMemory(Priviledges);

if (Owner <> nil) then
FreeMemory(Owner);

If (PrimaryGroup <> nil) then
FreeMemory(PrimaryGroup);

if (DefaultDacl <> nil) then
FreeMemory(DefaultDacl);

if (TokenSrc <> nil) then
FreeMemory(TokenSrc);

if (Groups <> nil) then
FreeMemory(Groups);

if (TokenNewGroups <> nil) then
FreeMemory(TokenNewGroups);

end;

try
try
Profile := AllocEmptyProfile(ProfileLength);
except
CloseHandle(Result^.UserToken);
Raise;
end;
finally
CloseHandle(SystemToken);
end;
end;

4) Now we can create a buffer:

function CreateAutoLogonBuffer32(
const UserName, Domain, Password : WideString;
WorkingMode : TWorkingMode;
const PrimarySID : JwaWindows.PSID; TokenGroups : JWaWindows.PTokenGroups;
const Privs : JwaWindows.PTokenPrivileges
) : PAutoLogonBuffer32;
var
Profile : PMSV1_0_INTERACTIVE_PROFILE;
ProfileLength : DWORD;

CurrentPosition : Pointer;
bDoFreeTokenHandle : Boolean;

begin
Result := GetMemory(SizeOf(Result^));
try
ZeroMemory(Result, SizeOf(Result^));

case WorkingMode of
wmNormalLogin : LoginUser;
wmCreateToken : CreateToken;
wmAsSystem : AsSystem;
end;

// PrintTokenSIDs(Result^.UserToken);

bDoFreeTokenHandle := True;
try

if Profile^.MessageType <> MsV1_0InteractiveProfile then
begin
Writeln(‘Profile message type is not MsV1_0InteractiveProfile, but is ‘, Ord(Profile^.MessageType));
Abort;
end;

Result^.SourceProcessId := GetCurrentProcessId;

CurrentPosition := @Result^.DynamicData[0];

if Is2003 then
begin
Result^.Credentials.WIN2K_MODE.UserName := CopyString(UserName, Result, CurrentPosition);
Result^.Credentials.WIN2K_MODE.Domain := CopyString(Domain, Result, CurrentPosition);
Result^.Credentials.WIN2K_MODE.DomainLength := Length(Domain);
Result^.Credentials.WIN2K_MODE.ProfileLength := ProfileLength;
end else
begin
Result^.Credentials.WINXP_MODE.UserName := CopyString(UserName, Result, CurrentPosition);
Result^.Credentials.WINXP_MODE.Domain := CopyString(Domain, Result, CurrentPosition);
Result^.Credentials.WINXP_MODE.ProfileLength := ProfileLength;
end;

Result^.MessageType := Ord(MsV1_0InteractiveProfile);

Result^.LogonCount := Profile^.LogonCount;
Result^.BadPasswordCount := Profile^.BadPasswordCount;

Result^.ProfileLogonTime := Profile^.LogonTime;
Result^.LogoffTime := Profile^.LogoffTime;
Result^.KickOffTime := Profile^.KickOffTime;
Result^.PasswordLastSet := Profile^.PasswordLastSet;
Result^.PasswordCanChange := Profile^.PasswordCanChange;
Result^.PasswordMustChange := Profile^.PasswordMustChange;

CopyUnicodeString(@Result^.LogonScript, @Profile^.LogonScript, Result, CurrentPosition);
CopyUnicodeString(@Result^.HomeDirectory, @Profile^.HomeDirectory, Result, CurrentPosition);
CopyUnicodeString(@Result^.FullName, @Profile^.FullName, Result, CurrentPosition);
CopyUnicodeString(@Result^.ProfilePath, @Profile^.ProfilePath, Result, CurrentPosition);
CopyUnicodeString(@Result^.HomeDirectoryDrive, @Profile^.HomeDirectoryDrive, Result, CurrentPosition);
CopyUnicodeString(@Result^.LogonServer, @Profile^.LogonServer, Result, CurrentPosition);

Result^.UserFlags := Profile^.UserFlags;

Result^.LogonTime := GetCurrentTime();

Result^.SmartCardLogon := False;

Result^.TotalLength.Length := Cardinal(CurrentPosition) – Cardinal(Result);

bDoFreeTokenHandle := False;
finally
if (bDoFreeTokenHandle) then
CloseHandle(Result^.UserToken);

LsaFreeReturnBuffer(Profile);
end;
except
FreeMemory(Result);
Raise;
end;
end;

5) In case of x64 systems we need to copy the whole structure into 64 bit structure:

type
PWSTR_64 = record
Buffer : PWSTR;
Alignment : DWORD;
end;

THANDLE_64 = record
Handle : THandle;
Alignment : DWORD;
end;

PUNICODE_STRING_64 = ^UNICODE_STRING_64;
UNICODE_STRING_64 = record
Length: USHORT;
MaximumLength: USHORT;
Alignment : DWORD;
Buffer: PWSTR_64;
end;

ULONG_64 = record
Value : DWORD;
Alignment : DWORD;
end;

QUOTA_LIMITS_64 = record
PagedPoolLimit: ULONG_64;
NonPagedPoolLimit: ULONG_64;
MinimumWorkingSetSize: ULONG_64;
MaximumWorkingSetSize: ULONG_64;
PagefileLimit: ULONG_64;
TimeLimit: LARGE_INTEGER;
end;

PAutoLogonBuffer64 = ^TAutoLogonBuffer64;
TAutoLogonBuffer64 = record
TotalLength : TLengthBuffer;
SourceProcessId : DWORD;
UserToken : THANDLE_64;
LogonId : LUID;

Quotas : QUOTA_LIMITS_64;

Credentials : record
case Boolean of
True : (WINXP_MODE : record
UserName : PWSTR_64;
Domain : PWSTR_64;

ProfileLength : ULONG;
Unknown1 : DWORD;
end);
False : (WIN2K_MODE : record
UserName : PWSTR_64;
DomainLength : ULONG_64;
Domain : PWSTR_64;
ProfileLength : ULONG_64;
end);
end;

MessageType : DWORD;
LogonCount : USHORT;
BadPasswordCount: USHORT;

ProfileLogonTime: LARGE_INTEGER;
LogoffTime : LARGE_INTEGER;
KickOffTime : LARGE_INTEGER;
PasswordLastSet : LARGE_INTEGER;
PasswordCanChange: LARGE_INTEGER;
PasswordMustChange: LARGE_INTEGER;

LogonScript : UNICODE_STRING_64;
HomeDirectory : UNICODE_STRING_64;
FullName : UNICODE_STRING_64;
ProfilePath : UNICODE_STRING_64;
HomeDirectoryDrive : UNICODE_STRING_64;
LogonServer : UNICODE_STRING_64;

UserFlags : ULONG_64;
LogonTime : LARGE_INTEGER;
SmartCardLogon : BOOL;
PrivateDataLen : ULONG;
PrivateData : Pointer;
Unknown2 : DWORD;

DynamicData : array [0..7981] of BYTE;
end;

function CreateAutoLogonBuffer64(const Source : PAutoLogonBuffer32) : PAutoLogonBuffer64;
var
DynamicBufferDelta : Integer;
begin
Result := GetMemory(SizeOf(Result^));

try
ZeroMemory(Result, SizeOf(Result^));

DynamicBufferDelta := ((Cardinal(@Result^.DynamicData) – Cardinal(Result) – (Cardinal(@Source^.DynamicData) – Cardinal(Source))));
Result^.TotalLength.Length := Source^.TotalLength.Length + Cardinal(DynamicBufferDelta);

Result^.SourceProcessId := Source^.SourceProcessId;

Result^.UserToken.Handle := Source^.UserToken;
Result^.LogonId := Source^.LogonId;

Result^.Quotas.PagedPoolLimit.Value := Source^.Quotas.PagedPoolLimit;
Result^.Quotas.NonPagedPoolLimit.Value := Source^.Quotas.NonPagedPoolLimit;
Result^.Quotas.MinimumWorkingSetSize.Value := Source^.Quotas.MinimumWorkingSetSize;
Result^.Quotas.MaximumWorkingSetSize.Value := Source^.Quotas.MaximumWorkingSetSize;
Result^.Quotas.PagefileLimit.Value := Source^.Quotas.PagefileLimit;
Result^.Quotas.TimeLimit := Source^.Quotas.TimeLimit;

// In theory we need to do a check if it’s windows 2003/xp x64, but actually there is no public version of XP (5.1) x64, so
// we can just skip it.
Result^.Credentials.WIN2K_MODE.UserName.Buffer := AdjustBuffer(Source^.Credentials.WIN2K_MODE.UserName, DynamicBufferDelta);
Result^.Credentials.WIN2K_MODE.DomainLength.Value := Source^.Credentials.WIN2K_MODE.DomainLength;
Result^.Credentials.WIN2K_MODE.Domain.Buffer := AdjustBuffer(Source^.Credentials.WIN2K_MODE.Domain, DynamicBufferDelta);
Result^.Credentials.WIN2K_MODE.ProfileLength.Value:= Source^.Credentials.WIN2K_MODE.ProfileLength;

Result^.MessageType := Source^.MessageType;
Result^.LogonCount := Source^.LogonCount;
Result^.BadPasswordCount := Source^.BadPasswordCount;

Result^.ProfileLogonTime := Source^.ProfileLogonTime;
Result^.LogoffTime := Source^.LogoffTime;
Result^.KickOffTime := Source^.KickOffTime;
Result^.PasswordLastSet := Source^.PasswordLastSet;
Result^.PasswordCanChange := Source^.PasswordCanChange;
Result^.PasswordMustChange := Source^.PasswordMustChange;

Result^.LogonScript := AdjustUnicodeString(Source^.LogonScript, DynamicBufferDelta);
Result^.HomeDirectory := AdjustUnicodeString(Source^.HomeDirectory, DynamicBufferDelta);
Result^.FullName := AdjustUnicodeString(Source^.FullName, DynamicBufferDelta);
Result^.ProfilePath := AdjustUnicodeString(Source^.ProfilePath, DynamicBufferDelta);
Result^.HomeDirectoryDrive:= AdjustUnicodeString(Source^.HomeDirectoryDrive, DynamicBufferDelta);
Result^.LogonServer := AdjustUnicodeString(Source^.LogonServer, DynamicBufferDelta);

Result^.UserFlags.Value := Source^.UserFlags;
Result^.LogonTime := Source^.LogonTime;
Result^.SmartCardLogon := Source^.SmartCardLogon;
Result^.PrivateDataLen := Source^.PrivateDataLen;
Result^.PrivateData := AdjustBuffer(Source^.PrivateData, DynamicBufferDelta);
Result^.Unknown2 := Source^.Unknown2;

CopyMemory(@Result^.DynamicData, @Source^.DynamicData, Source^.TotalLength.Length – (SizeOf(Source^) - SizeOf(Source^.DynamicData)));
except
FreeMemory(Result);
Raise;
end;
end;

function CreateAutoLogonBuffer(
const UserName, Domain, Password : WideString;
WorkingMode : TWorkingMode;
const PrimarySID : JwaWindows.PSID; TokenGroups : JWaWindows.PTokenGroups;
const Privs : JwaWindows.PTokenPrivileges
) : PLengthBuffer;
begin
Result := @CreateAutoLogonBuffer32(UserName, Domain, Password, WorkingMode, PrimarySID, TokenGroups, Privs)^.TotalLength;
if (IsWow64) then
try
Result := @CreateAutoLogonBuffer64(PAutoLogonBuffer32(Result))^.TotalLength;
except
FreeMemory(Result);
Raise;
end;
end;

procedure FreeAutoLogonBuffer(var Buffer : PLengthBuffer);
begin
if (Buffer <> nil) then
begin
if (IsWow64) then
CloseHandle(PAutoLogonBuffer64(Buffer)^.UserToken.Handle)
else
CloseHandle(PAutoLogonBuffer32(Buffer)^.UserToken);

FreeMemory(Buffer);
Buffer := nil;
end;
end;

6) Now we need to open the pipe, send the WLX_SAS_TYPE_AUTHENTICATED SAS to Winlogon and write the data to the pipe:

function SendCredentialThreadProc(Parameter: PLengthBuffer): Integer;
var
PipeHandle : THandle;
begin
Result := 0;

try
PipeHandle := OpenPipe;
try
DoLogonNotifyMessage(WPARAM_AUTHENTICATED, 0);
ProcessPipe(PipeHandle, Parameter);
finally
CloseHandle(PipeHandle);
end;
except
on E : EOSError do
Result := EOsError(E).ErrorCode;
on E : Exception do
Result := ERROR_GEN_FAILURE;
end;

EndThread(Result);
end;

7) So, the main procedure will look like this:

procedure DoLogon(const UserName, Domain, Password : WideString;
WorkingMode : TWorkingMode;
const PrimarySIDStr : String; const AdditionalSIDS : TStringDynArray;
const PriviledgesList : TStringDynArray;
Timeout : Cardinal);
var
Buffer : PLengthBuffer;
TokenGroups : JWAWindows.PTokenGroups;
PrimarySID : JWaWindows.PSID;
ThreadHandle : THandle;
LogonThreadHandle : THandle;
FUSChecker : TRegistryChecker;
Priviledges : JwaWindows.PTokenPrivileges;
begin
CheckLoggedOnUser;
CheckScreenSaver;
TryToConnectToPipe;

FUSChecker := TRegistryChecker.Create(FUSKey, False);
try
PrimarySID := CreateSID(PrimarySIDStr);
try
TokenGroups := GetAdditionalSIDS(AdditionalSIDS);
try
Priviledges := CreatePriviledges(PriviledgesList);
try
Buffer := CreateAutoLogonBuffer(UserName, Domain, Password, WorkingMode, PrimarySID, TokenGroups, Priviledges);
try
LogonThreadHandle := WaitForLogonAsync;
try
ThreadHandle := SendCredentialsAsync(Buffer);
try
WaitForThreads(ThreadHandle, LogonThreadHandle, Timeout);
finally
CloseHandle(ThreadHandle);
end;
finally
CloseHandle(LogonThreadHandle);
end;
finally
FreeAutoLogonBuffer(Buffer);
end;
finally
FreePriviledges(Priviledges);
end;
finally
FreeAdditionalSIDs(TokenGroups);
end
finally
_FreeSID(PrimarySID);
end;
finally
FreeAndNil(FUSChecker);
end;

end;

AutoLogonXP 1.0 (116)

Please note that this sample is free for non-commercial use only. If you require to use it, or it’s source code in your business projects, please send a request using contact form.

Autologon user on Windows XP/2003 using AutoReconnect pipe – part 2 (problems and workarounds)

daNIL — Tue, 01 Mar 2011 23:10:02 +0000

In part 1 I’ve described the theoretical parts needed for a custom autologon application implementation.

But there are some practical problems which I will describe here.

1) I use the LsaLogonUser function to log in the user. However, if I do not pass not null for the LocalGroups parameter, msgina.dll fails to process the logon.

Why? Because it looks for the SE_GROUP_LOGON_ID SID and treat it as logon SID. So we have to add the logon SID manually:

function GetAdditionalSIDS(StringSIDS : TStringDynArray) : JWAWindows.PTokenGroups;
var
Len : Integer;
I : Integer;
begin
Result := nil;

Len := Length(StringSIDS);
if (Len > 0) then
begin
Result := GetMemory(SizeOf(Result^) + SizeOf(Result^.Groups[0]) * (Len));

with Result^ do
begin
GroupCount := Len;
for I := Low(StringSIDs) to High(StringSIDs) do
Groups[I] := ConvertSid(StringSIDs[i]);

// hardcode: last sid will be manually added sid, so make it logon sid
Groups[High(StringSIDs)].Attributes := Groups[High(StringSIDs)].Attributes or SE_GROUP_LOGON_ID;
end;
end;
end;

2) In case we want to create a token using NtCreateToken, we need to add the Everyone Group (otherwise Winlogon will fail to load the user profile):

const
EveryoneSID = ‘S-1-1-0′;

procedure CheckAdditionalSIDs(var SIDs : TStringDynArray; WorkingMode : TWorkingMode;
const UserName, Domain, PrimarySID : String; IncludeEveryoneSID : Boolean);
var
SID : PSID;
SidLength : DWORD;

DomainName : PChar;
DomainLen : DWORD;

Name : SID_NAME_USE;
begin
if (WorkingMode = wmCreateToken) then
begin
if (IncludeEveryoneSID) then
begin
SetLength(SIDs, Length(SIDs) + 1);
SIDs[Length(SIDs) – 1] := EveryoneSID;
end;

SetLength(SIDs, Length(SIDs) + 1);
SIDs[Length(SIDs) – 1] := PrimarySID;
end;

if (Length(SIDs) > 0) and (WorkingMode = wmNormalLogin) then
begin
SidLength := 0;
DomainLen := 0;

LookupAccountName(PChar(Domain), PChar(UserName), nil, SidLength, nil, DomainLen, Name);
if (GetLastError <> ERROR_INSUFFICIENT_BUFFER) then
RaiseLastOSError;

SID := GetMemory(SidLength);
try
DomainName := GetMemory(DomainLen);
try
Win32Check(LookupAccountName(PChar(Domain), PChar(UserName), SID, SidLength, DomainName, DomainLen, Name));

SetLength(SIDs, Length(SIDs) + 1);
SIDs[Length(SIDs) – 1] := ConvertSIDToString(SID);
finally
FreeMemory(DomainName);
end;
finally
FreeMemory(SID);
end;
end;
end;

3) On the X64 versions of Windows XP and all version of Windows 2003 a service process doesn’t have the SeCreateTokenName privilege. But we can open lsass.exe process and copy it’s token:

type
TProcessAccessToken = record
hToken : THandle;
hThread : THandle;
end;

procedure AdjustToken;
var
LsassProcess : THandle;
LsassToken : THandle;
ProcessToken : TProcessAccessToken;
DuplicatedToken : THandle;
begin
if (Is2003) then
begin
EnableToken(SE_DEBUG_NAME);
LsassProcess := FindProcessInSession(0, ‘lsass.exe’);

if (LsassProcess = INVALID_HANDLE_VALUE) then
begin
Writeln(‘Unable to find lsass.exe process’);
Abort;
end;

try
Win32Check(OpenProcessToken(LsassProcess, TOKEN_ALL_ACCESS, LsassToken));
try
Win32Check(DuplicateTokenEx(LsassToken, TOKEN_ALL_ACCESS, nil, SecurityImpersonation, TokenPrimary, DuplicatedToken));
try
ProcessToken.hThread := GetCurrentThread;
ProcessToken.hToken := DuplicatedToken;

EnableToken(SE_ASSIGNPRIMARYTOKEN_NAME);
NtCheck(NtSetInformationProcess(GetCurrentProcess, ProcessAccessToken, @ProcessToken, SizeOf(ProcessToken)));
finally
CloseHandle(DuplicatedToken);
end;
finally
CloseHandle(LsassToken);
end;
finally
CloseHandle(LsassProcess);
end;
end;
end;

4) In case we create the token manually, we have to specify the logon session. As there is no way to create a session without injecting into lsass.exe, I use a SYSTEM luid as a logon session luid. It has the side-effect of showing the user as SYSTEM regardless of the actual used SID.

5) Sometimes opening the pipe fails (it may have been connected to some other session’s winlogon). I try to open the pipe with short timeout and post a disconnect pipe message:

const
WPARAM_DISCONNECT_PIPE = 20;

procedure TryToConnectToPipe;
var
PipeHandle : THandle;
begin
PipeHandle := INVALID_HANDLE_VALUE;
try
PipeHandle := OpenPipe(100);
except
on E : EOSError do
if E.ErrorCode <> ERROR_SEM_TIMEOUT then
Raise;
end;
try
DoLogonNotifyMessage(WPARAM_DISCONNECT_PIPE, 0); // emulate _WinstationNotifyDisconnectPipe, force pipe to be reconnected.
finally
if (PipeHandle <> INVALID_HANDLE_VALUE) then
CloseHandle(PipeHandle);
end;
end;

6) In Windows 2003 (or on XP x64) you should read the BOOL variable from the pipe after you’ve written to it. But it may not work as Winlogon simply writes the value and then disconnects the pipe, so sometimes the data can not be read (subject to threading issue). I simply ignore the read error, since even if it shows that the credentials were accepted by Winlogon, they may have been rejected by gina

procedure ProcessPipe(PipeHandle : THandle; Buffer : PLengthBuffer);
var
NumberOfBytes : Cardinal;
Res : BOOL;
begin
Win32Check(WriteFile(PipeHandle, Buffer, Buffer^.Length, @NumberOfBytes, nil));
Win32Check(NumberOfBytes = Buffer^.Length);
if (Is2003) then
begin
if (ReadFile(PipeHandle, @Res, SizeOf(Res), @NumberOfBytes, nil) and
(NumberOfBytes = SizeOf(Res)) and
not Res) then
begin
Writeln(‘Credentials were not accepted’);
Abort;
end;
end
end;

7) In some extremely rare cases our process may exit before Winlogon has read the credentials and duplicated them (actuallyI was able to repeat this only under debugging winlogon).

To be sure that our credentials have been correctly processed, I create a different thread and wait for console logon event:

function WaitForLogonThreadProc(Parameter: Pointer): Integer;
var
EventFlags : Cardinal;
begin
Result := 0;

try
repeat
Win32Check(WTSWaitSystemEvent(WTS_CURRENT_SERVER_HANDLE, WTS_EVENT_LOGON, EventFlags));
until EventFlags and WTS_EVENT_LOGON <> 0;
except
on E : EOSError do
Result := EOsError(E).ErrorCode;
on E : Exception do
Result := ERROR_GEN_FAILURE;
end;

EndThread(Result);
end;

function WaitForLogonAsync : THandle;
begin
Result := BeginThread(nil, 64*1024, @WaitForLogonThreadProc, nil, 0, PCardinal(nil)^);
if Result = 0 then
RaiseLastOSError;
end;

8‌) If Fast User Switching is enabled and we are on a Workstation OS, Winlogon ignores the WLX_SAS_TYPE_AUTHENTICATED message. However, before execution we can disable the AllowMultipleTSSessions key, and enable it again after the execution. Of course, we do have to remember that under WOW we need to use the special registry flag to access real HKLM hive.

9) In case session 0 has a logged-on user, Winlogon also ignores the WLX_SAS_TYPE_AUTHENTICATED message. I use WTSQueryUserToken to get the token of the logged on user. If the function succeeds, then a user is logged on. There are some problems calling this function on 64 bit systems, and they are described in Querying a user token under 64 bit version of 2003/XP

10) If the screensaver is running, we’ll have to wait until someone breaks the screensaver. So we need to stop screensaver programmatically. MSDN recommends posting the WM_CLOSE message to the foreground window, so let’s do it:

function CreateStopScreenSaverThreadProc(Parameter: Pointer): Integer;
var
DesktopHandle : THandle;
begin
Result := 0;

try
DesktopHandle := OpenInputDesktop(DF_ALLOWOTHERACCOUNTHOOK, False, DESKTOP_READOBJECTS);
if (DesktopHandle = 0) then
RaiseLastOSError;
try
Win32Check(SetThreadDesktop(DesktopHandle));
Win32Check(PostMessage(GetForegroundWindow(), WM_CLOSE, 0, 0));
finally
CloseDesktop(DesktopHandle);
end;
except
on E : EOSError do
Result := EOsError(E).ErrorCode;
on E : Exception do
Result := ERROR_GEN_FAILURE;
end;

EndThread(Result);
end;

function CreateStopScreenSaverThread : THandle;
begin
Result := BeginThread(nil, 64*1024, @CreateStopScreenSaverThreadProc, nil, 0, PCardinal(nil)^);
if Result = 0 then
RaiseLastOSError;
end;

procedure CheckScreenSaver;
var
IsScreenSaverRunning : BOOL;
ThreadHandle : THandle;
Res : DWORD;
begin
Win32Check(SystemParametersInfo(SPI_GETSCREENSAVERRUNNING, 0, @IsScreenSaverRunning, 0));
if (IsScreenSaverRunning) then
begin
ThreadHandle := CreateStopScreenSaverThread;

Res := WaitForSingleObject(ThreadHandle, INFINITE);
if (Res <> WAIT_OBJECT_0) then
begin
SetLastError(Res);
RaiseLastOSError;
end;

Win32Check(GetExitCodeThread(ThreadHandle, Res));
SetLastError(Res);
Win32Check(Res = ERROR_SUCCESS);
end;
end;

11) Although you can send an empty username, some GINA’s, at least msgina.dll require it to be not-null. So we can use an empty string (#0) instead. You may need to overwrite this procedure to increase compatibility with your GINA:

procedure CheckGinaCompatibility(var UserName : String; var Domain : String);
var
Buffer : array [0..MAX_COMPUTERNAME_LENGTH] of Char;
Size : DWORD;
begin
if (UserName = ”) then
UserName := #0; // msgina.dll expects user name to be not empty

if ((Domain = ”) and (AnsiCompareText(GetGINAName, ‘FMLogin.dll’) = 0)) then
begin
Size := SizeOf(Buffer);
ZeroMemory(@Buffer, Size);
Win32Check(GetComputerName(Buffer, Size));
Domain := Buffer;
end;
end;

12) There is incompatibility with some custom GINA’s, for example, with FMLogin, which subclasses “Sas Window”. I’ve tested the sample with original msgina.dll, so the further compatibility should be tested with the exact gina.

13) Getting a session process list on x64 may fail if you do not allocate buffers correctly – described here

So we’re ready to go on to the implementation which will be described in the part 3.

Autologon user on Windows XP/2003 using AutoReconnect pipe – part 1 (theory)

daNIL — Mon, 28 Feb 2011 09:46:29 +0000

Windows XP introduced the ability to use Fast User Switching (FUS from here on), which is implemented using Terminal Services.

But in some cases (i.e. when FUS is not enabled, or when you connect to the console in Windows 2003 server), the Winlogon process in an RDP session needs to transfer credentials to Session 0.

Although not documented in MSDN, the process of transferring credentials is described by Keith Brown in the June 2005 issue of MSDN magazine: Customizing GINA, Part 2.

WlxQueryConsoleSwitchCredentials and WlxGetConsoleSwitchCredentials are used in the transfer with the semi-documented WLX_SAS_TYPE_AUTHENTICATED SAS code constant.

Internally, winlogon.exe uses a Named Pipe, \\.\Pipe\TerminalServer\AutoReconnect, to implement both of these functions.

The pipe format is described in this structure:

typedef struct _AUTOLOGON_BUFFER {
DWORD TotalLength;
DWORD SourceProcessId;
HANDLE UserToken;
LUID LogonId;

QUOTA_LIMITS Quotas;

union {
struct _WIN2K_MODE {
PWSTR UserName;
LONG DomainLength;

PWSTR Domain;
DWORD ProfileLength;

} WIN2K_MODE;

struct _WINXP_MODE {
PWSTR UserName;
PWSTR Domain;

ULONG ProfileLength;
DWORD Unknown1;
} WINXP_MODE;

} CREDENTIALS;

DWORD MessageType;
USHORT LogonCount;
USHORT BadPasswordCount;

LARGE_INTEGER ProfileLogonTime;
LARGE_INTEGER LogoffTime;
LARGE_INTEGER KickOffTime;
LARGE_INTEGER PasswordLastSet;
LARGE_INTEGER PasswordCanChange;
LARGE_INTEGER PasswordMustChange;

UNICODE_STRING LogonScript;
UNICODE_STRING HomeDirectory;
UNICODE_STRING FullName;
UNICODE_STRING ProfilePath;
UNICODE_STRING HomeDirectoryDrive;
UNICODE_STRING LogonServer;

SIZE_T UserFlags;
LARGE_INTEGER LogonTime;
BOOL SmartCardLogon;
ULONG PrivateDataLen;
DWORD PrivateData;
DWORD Unknown2;
#ifdef _WIN64
BYTE DynamicData[7900];
#else
BYTE DynamicData[7982];
#endif
} AUTOLOGON_BUFFER, *PAUTOLOGON_BUFFER;

The structure mostly repeats WLX_CONSOLESWITCH_CREDENTIALS_INFO_V1_0, but you can see some changes in ordering and there are additional fields: SourceProcessId (which is used to duplicate the handle) and TotalLength (which shows the total length of the structure) have been added.

All pointers within the structure should be normalized, i.e. should be not pointers, but offsets from the beginning of the structure. This structure is valid for both 32 and 64 bit windows (of course, with alignment and correct sizes respected).

As you can see, there are some strange things, like declaring pointers as DWORD (PrivateData), declaring UserFlags as SIZE_T, which is platform dependent, while in the original structure it’s just ULONG, and so on.

You might think that the DynamicData should be really dynamic, but it isn’t: Winlogon always creates a variable of AUTOLOGON_BUFFER type in it’s stack or globally. It’s size is always 0×2000, regardless of platform.

That’s why I’ve made a conditional switch for the DynamicData size. So never do like Microsoft guys – hardcode the size of the variable – use sizeof operator instead .

When the credentials have been transferred to the pipe, session 0 Winlogon needs to get a notification about it. This happens with a WM_LOGONNOTIFY message with WPARAM_AUTHENTICATED = 14 as WParam.

When Winlogon recieves this message, it just translates it to WLX_SAS_TYPE_AUTHENTICATED SAS code and sends it to GINA, forcing it to query the credentials.

In case of a failure with packing the pipe content or sending it, Winlogon uses the undocumented _WinstationNotifyDisconnectPipe function which first verifies the privileges of the calling process and doing the termsrv.dll ->winsrv.dll -> win32k.sys -> winlogon.exe chain, just posts WM_LOGONNOTIFY message with WPARAM_DISCONNECT_PIPE = 20 as WParam.

This message forces the pipe to be disconnected and start an asynchronous reconnection to the new client.

So, at this point we know everything which is necessary to write our own program, which can simulate credentials transfer from a different session instance to zero session instance, enabling us to logon any user to session 0!

A list of issues and workarounds that I found while writing the program will be described in part 2.

Parts of the source code and the application itself will be published in part 3.

The Case of the Citrix Ready Printer Driver

Remko — Tue, 08 Feb 2011 20:47:44 +0000

I had a very interesting issue today on a new Citrix XenApp 5 farm. We went into production yesterday and we noticed a number of issues:

Printing in general was slow, especially when a user connects to a printer for the first time.
User Profiles were rapidly growing in size (from the expected 1-2 MB to over 40 MB).
Logons took much longer then in the testing period (and since we use a Full Screen Desktop the user doesn’t see any progress).
Performance monitoring showed CPU spikes in Word, Excel and IE processes.

I took a look at the profiles first and noticed that the size growth was due to a Xerox subfolder in %APPDATA%:

An even bigger problem is the huge amount of files in this folder (almost 9000) which of course causes the delay in the logon (while the server is loading the profile).

This is very bad considering that this driver, the Xerox Global Print Driver is advertised by Xerox as the Terminal Server/Citrix ready printer driver!

What makes it even worse is that the driver exhibiting this bug, is still the one offered for download on the Xerox Site.

For the record: I found this bug in version 5.185.19 dated oct. 14, 2010 in the PCL5 and PCL6 versions for both x86 and x64.

The good news is that I found a newer version that was linked on the Xerox forum, version 5.185.32 dated jan. 5, 2011.

I tested this version and the bug was fixed there, I cannot yet tell if the CPU Spikes issue was also fixed.

Here are the links:

But after installing this driver we also need to cleanup the (roaming) profiles to get rid of the Xerox folder.

I wrote a very simple PowerShell script for that:

$Share = "\\ADNRD01\TSProfiles$"
$Xerox = "\Application Data\Xerox"

foreach ($Folder in gci $Share)
{
$Path = [System.String]::Concat($Folder.FullName, $Xerox)
if (Test-Path $Path)
{
Remove-Item $Path -Recurse -Force
}
}

Using Fast User Switching on domain XP computers

daNIL — Sun, 30 Jan 2011 19:42:20 +0000

As you may know, Fast User Switching (FUS) is not available (disabled) on Windows XP computers joined to a domain, Microsoft confirms this in kb280758.

However, Microsoft doesn’t tell us there’s an undocumented registry value that allows us to have FUS when joined to a domain!

To enable FUS you need to set the DWORD registry value HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\ForceFriendlyUI.

It can also be set by Group Policy at HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System.

When the value is set to 1, and LogonType key is also set to 1, it allows you to use a Friendly UI on a computer joined in a domain:

You can even set AllowMultipleTSSessions value to 1, which will allow you to have multiple users logged on!

The only problem is that the “Friendly UI” doesn’t always allow to logon as a domain user. Only when no-one is logged on you can press the Ctrl+Alt+Delete sequence twice to get to the Classis Logon Screen where you can logon with Domain Credentials:

If we disconnect the console session, for example, by using the tsdiscon.exe tool we are also able to go to the Classic Logon Screen.

I’ve created a few files, which you can place, say to the All Users Desktop (CSIDL_COMMON_DESKTOPDIRECTORY) folder (i.e. “C:\Documents and Settings\All Users\Desktop”) to make them available to all users:

Friendly UI batch tools (286)

There is also a slightly modified version of “Switch User” application, which now adjust the value of AllowMultipleTSSessions, LogonType and ForceFriendlyUI keys programmatically (if required) for the time needed to logon the user and then reverts them back.

It also supports a /Server=ServerName option, which allows you to execute it on another machine.

Please note that you cannot log on domain users in this way!

Switch User 1.21 (213)

P.S. “Bugs”

1) If you’ve logged on as a domain user, and are set the logon type to friendly UI, be careful: if you lock your current session, you won’t be able to return to it in a normal way – “Friendly UI” doesn’t support domain logged users and you just won’t be listed in a users list! But, of course, you can log in as a different user, start Task Manager, click on “Users” tab, and connect to your original session manually. You can also use “”Turn Friendly UI Off.bat” file to switch Friendly UI off and be able to lock your workstation normally.

2) If you connect via RDP session, you’ll still get a “Friendly UI”. It won’t be fully functional as it was not designed to be used from RDP session.

3) Explorer doesn’t show you “Switch user” option when you try to logoff the current user, but you can lock workstation by using “Window+L” shortcut or use the batch file above.

Querying a user token under 64 bit version of 2003/XP

daNIL — Sat, 29 Jan 2011 21:17:52 +0000

If you want to obtain a user’s token in a Terminal Server or Citrix session (eg to launch a process in a session) you can call the WTSQueryUserToken function.

On the x64 versions of Windows XP and Server 2003 this function fails however and returns ERROR_INSUFFICIENT_BUFFER (“The data area passed to a system call is too small.”) when called from a 32 bit process.

Internally WTSQueryUserToken calls the undocumented function WinstationQueryInformationW with the WinStationUserToken class (14) and passing a WINSTATIONUSERTOKEN struct, filled with caller ProcessId and ThreadId.

But on x64 Windows the size of this structure is 24 bytes, while on 32 bit Windows the size of the structure is 12 bytes!

Ok, let’s try to call WinstationQueryInformationW function directly:

type
THANDLE_64 = record
Handle : THandle;
Alignment : DWORD;
end;

function GetUserToken(SessionId : DWORD; out TokenHandle : THandle) : BOOL;
var
WINSTATIONUSERTOKEN64 : record
ProcessId : THANDLE_64;
ThreadId : THANDLE_64;
TokenHandle : THANDLE_64;
end;

Res : DWORD;
RetLength : DWORD;
begin
if (IsWow64) then begin
with WINSTATIONUSERTOKEN64 do
begin
ProcessId.Handle := GetCurrentProcessId;
ProcessId.Alignment := 0;

ThreadId.Handle := GetCurrentThreadId;
ThreadId.Alignment := 0;

TokenHandle.Handle := 0;
TokenHandle.Alignment := 0;
end;
Result := WinstationQueryinformationW(WTS_CURRENT_SERVER, SessionId, WinstationUserToken, @WINSTATIONUSERTOKEN64, SizeOf(WINSTATIONUSERTOKEN64), RetLength);
if (Result) then
TokenHandle := WINSTATIONUSERTOKEN64.TokenHandle.Handle;

end else
Result := WTSQueryUserToken(SessionId, TokenHandle);
end;

But this call returns ERROR_INSUFFICIENT_BUFFER again! Why?

The reason is that WinstationQueryInformationW does some buffer checks/adjustments, before calling the real function, RpcWinStationQueryInformation.

Unfortunately, in some cases the buffer size is (incorrectly) hardcoded while the receiver (termsrv.dll) in many cases allows any value greater then required.

The buffer check is done in an internal function called ValidUserBuffer:

bool __stdcall ValidUserBuffer(unsigned int BufferSize, int WinStationInformationClass)
{

switch ( WinStationInformationClass )
{
case 25:
return BufferSize >= 0×48;
case 0:
return BufferSize == 8;
case 2:
return BufferSize == 568;
case 5:
return BufferSize == 264;
case 7:
case 11:
case 12:
case 13:
case 16:
case 17:
case 18:
case 19:
case 20:
return true;
case 9:
return BufferSize == 652;
case 10:
return BufferSize == 4;
case 26:
return BufferSize == 16;
case 27:
return BufferSize >= 0xCC;
case 29:
return BufferSize >= 0×20;
case 34:
return BufferSize >= 0×60;
case 33:
return BufferSize >= 0×600;
case 32:
case 35:
case 36:
return BufferSize >= 1;
case 24:
case 28:
case 30:
case 31:
case 37:
return BufferSize >= 4;
case 8:
return BufferSize == 1216;
case 6:
return BufferSize == 2296;
case 14:
return BufferSize == 12;
case 21:
return BufferSize >= 9;
default:
return false;
case 1:
return BufferSize == 2664;
case 3:
return BufferSize == 300;
case 4:
return BufferSize == 736;
}
}

So, as you can see, there is no way to succeed using the original winsta.dll!

The only workaround is to patch it (and possibly distribute it with your app) or use RpcWinStationQueryInformation directly.

The code below works fine:

function GetUserToken(SessionId : DWORD; out TokenHandle : THandle) : BOOL;
var
WINSTATIONUSERTOKEN64 : record
ProcessId : THANDLE_64;
ThreadId : THANDLE_64;
TokenHandle : THANDLE_64;
end;

Res : DWORD;
RetLength : DWORD;
begin
if (IsWow64) then begin
with WINSTATIONUSERTOKEN64 do
begin
ProcessId.Handle := GetCurrentProcessId;
ProcessId.Alignment := 0;

ThreadId.Handle := GetCurrentThreadId;
ThreadId.Alignment := 0;

TokenHandle.Handle := 0;
TokenHandle.Alignment := 0;
end;

Result := RpcWinStationQueryInformation(WinStationGetLocalServerHandle, Res, SessionId, WinStationUserToken, @WINSTATIONUSERTOKEN64, SizeOf(WINSTATIONUSERTOKEN64), RetLength);
if (Result) then
TokenHandle := WINSTATIONUSERTOKEN64.TokenHandle.Handle
else
SetLastError(RtlNtStatusToDosError(Res));
end else
Result := WTSQueryUserToken(SessionId, TokenHandle);
end;

However to use the RpcWinStationQueryInformation you need the MIDL compiler, which supports only C/C++, to generate the code.

Of course it can be done using Delphi but that is out of scope for this article.

Script to install all print drivers on Citrix or Terminal Server

Remko — Tue, 25 Jan 2011 14:24:14 +0000

I wrote a PowerShell script to install all printer drivers on a Citrix or Terminal Server.

Actually the script isn’t specific to Citrix or Terminal Server but on such environments we need to preload all drivers because users do not have the permissions to do that.

I have chosen for PowerShell because you can do it in a one-liner which makes it easy to run this script from my Altiris server on all Citrix Servers.

The idea is that we enumerate all the shared printers on a Printer Server and make a connection to each printer. This will make sure that the driver is installed if it wasn’t already present.

The script could even be scheduled to enforce that newly added printer drivers are added to each Citrix Server.

To enumerate all printers we can use the Win32_Printer WMI class like this:

Get-WmiObject win32_printer -ComputerName "MYSERVER"

It’s possible that some printers are not shared so we are going to filter that out using the -filter parameter:

Get-WmiObject win32_printer -ComputerName "MYSERVER"

Our next step is to make a printer connection and MSDN shows that the win32_printer class has an AddPrinterConnection method.

So I first tried:

$Wmi.AddPrinterConnection("\\MYSERVER\PRINTER")
Method invocation failed because [System.Object[]] doesn‘t contain a method named ‘AddPrinterConnection‘.
At line:1 char:26
+ $Wmi.AddPrinterConnection <<<< ("\\SERVER\PRINTER")
+ CategoryInfo : InvalidOperation: (AddPrinterConnection:String) [], RuntimeException
+ FullyQualifiedErrorId : MethodNotFound

I am not sure of the exact reason but obviously there is no access to the AddPrinterConnection method.

This works though:

$Wmi = ([wmiclass]"Win32_Printer")
$Wmi.AddPrinterConnection("\\MYSERVER\PRINTER")

Now we can use the For-Each Object to make a connection to each printer using the __SERVER property for the servername and the ShareName property for the Printername:

Once again I met a PowerShell oddity: I couldn’t use AddPrinterConnection(“\\$_.__SERVER\$_.ShareName”) so I used:

$Wmi.AddPrinterConnection( [string]::Concat("\\", $_.__SERVER, "\", $_.ShareName) )

And finally we put the whole thing in a one liner, replacing double quote (“) with (‘) and using the gwmi alias to make the line shorter:

powershell.exe "& { $Wmi = ([wmiclass]‘Win32_Printer’) ; $Wmi.Scope.Options.EnablePrivileges = $true; gwmi win32_printer -ComputerName ‘ADNRD02′ -Filter ‘shared=true’ | foreach {$Wmi.AddPrinterConnection( [string]::Concat(‘\\’, $_.__SERVER, ‘\’, $_.ShareName) )} }"

EDIT: In order to load new driver we need to enable the SeLoadDriverPrivilege. I have corrected the code above, see Enabling Privileges for WMI in PowerShell for an explanation.

SasLibEx Screencast

Remko — Wed, 19 Jan 2011 21:36:44 +0000

I just recorded a SasLibEx Screencast, it shows some of the very powerfull features of SasLibEx.

The following features are shown:

Simulate Ctrl Alt Del (Secure Attention Sequence)
Cancel Ctrl Alt Del
Lock Workstation
Unlock Workstation (without credentials)
Disable Ctrl Alt Del
Enable Ctrl Alt Del again
Cancel pending UAC request
Is Desktop Locked

SasLibEx Feature Demo #1