Remko Weijnen's Blog (Remko's Blog)

About Virtualization, VDI, SBC, Application Compatibility and anything else I feel like

Archive for the ‘Programming’ Category

AD Internals: Display RID Allocation Pools

In my previous post I wrote about a problem I had with duplicate RID Allocation pools.

But how do we get more insight into these RID Allocation pools?

The DCDIAG tool can display this information per domain controleler using the following syntax

Example output:

DCDiag Ridmanager Test

But where in Active Directory is this information stored and can we display it for all Domain Controllers at once for larger environments?


Determining stack size

I just read an answer on StackOverflow with this code:

Unfortunately it lacked explanation, so what does this code do?

It reads offset $4 from the Thread Information Block (the top of stack) into eax and then offset $8 (stack base) into ebx.

Then it substracts the two and moves that into variable eu, that’s all!

How Outlook and Exchange handle Timezones

Again an old war story, this time about timezone handling in Outlook/Exchange.

I am not sure which year it was but I had just started to work for a new company and inherited an Exchange 5.5 Server.

The mail had been migrated from an earlier version and calendar data was migrated from Schedule+.

On the first change to Daylight Savings (DTS) all recurring appointments where shown one hour later (or earlier can’t remember) in Outlook. A manual change was not an option: there were over 2000 mailboxes each with a lot of appointments.

We first tried a workaround by disabling DTS on the the workstations and then manually change the time when changing from and to DTS. 

But this influenced the timestamps on externals mails and of course appointments with external parties.

After a lot of (and I really mean a lot) of researching I found that Outlook stores all times in an appointment as relative (UTC) time.

Upon display it uses an undocumented TimeZone descriptor field to convert to Local Time.



Stuff from an ancient past

I just found a very old backup file containing old source code for a few tools I wrote ages ago.

This was in 1997 on my first job for a company called PTT Telecom (the Dutch Telecoms) and I wrote some tools to make life easier.

They were all written in Turbo Pascal and supported Long Filenames when running under Windows ’95 (there was a trick to do that under DOS).

The first tool was called Retreive Tool, it parsed a backup file from a private branch exchange (PBX) and could make reports about Licensing, the hardware in the PBX, Extension numbers and their hardware positions and so on.




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:

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:

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:

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!


As you may know, you can enumerate processes of a specific Terminal Server or Citrix session using the NtQuerySystemInformation function.

On x86 system the code below works fine:

While this works fine on Windows XP and 2003 x86, it fails to work correctly on the x64 versions of Windows XP and 2003 (or maybe even higher).

The problem is that RetLength is always SizeOf(SYSTEM_SESSION_PROCESS_INFORMATION) and thus we are in an endless loop!


SasLibEx Screencast

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