Adding workstations to an account's allowed workstation list

For anyone that uses the Logon Workstations attribute on user accounts to restrict what machines an account logs on to, you may find that updating the list can be a bit tedious from the GUI. Updating it from command line tools isn't always easy as well. The attribute in AD is just a string value, and all of the "list" that comes from it is due to the fact that it is stored in CSV format. So you have a list with a max length of 1024 characters in this format, so adding machines to it requires that it be added to the existing list, formatted as csv and limited in length. I put together a script for managing this, though it was targeted at accounts that already have some entries in this attribute, so it may require some extra work to target accounts that don't have any values. This script will check the length and content of each entry to ensure they meet netbios name standards. It will also ignore any duplicates that you may have provided.

param (
 [string][parameter(mandatory=$true)]$targetaccount,
 [parameter(mandatory=$true)]$workstation
)
Try {
 if ($workstation -is [array]) {
   $workstation = $workstation -join ","
 }
 $UserAccount = Get-ADUser $targetaccount -properties logonworkstations
 if ($useraccount -eq $null) {
  Write-Host "We have NOT found the account $targetaccount"
  throw "Target account not found"
 }
 
 $UsrAcctArray = $UserAccount.logonworkstations.split(",")
 
 #clear out any whitespace in the user input
 if ($workstation.length -gt 15 -and $workstation -notmatch ",") {
  throw "Workstations provided are not correct.  Computer names can only be 15 characters or less."
 }

#check all provided names to ensure they meet MS netbios name standards for machines.  If they don't ignore the name provided
 foreach($entry in $Workstation.split(",")){
  $entry = $entry.trim()
  if ((([regex]::match($entry,'^[0-9a-zA-Z_-]{5,15}$')).success) -eq $true) {
   $WorkstationCDL = $WorkstationCDL + $entry.ToUpper() + ","
  } 
 }
 
 #if we have received no valid machines, quit
 if ([string]::isnullorempty($workstationCDL)) {
  throw "No Valid workstation names provided.  Please provide a name that meet Microsoft standards."
 }
 
 #remove trailing comma, change new workstations to an array, mash it with the old one and check the length.  
 $WorkstationCDL = $WorkstationCDL.substring(0,($WorkstationCDL.length -1))      
 $WKSTarray = $WorkStationCDL.split(",")
 
 #mash arrays and pull unique names
 $newWorkstations = (($UsrAcctArray + $WKSTarray |select-object -Unique) -join ",").toupper()
 
 #check length (attribute max is 1024 chars
 if ($newworkstations.length -gt 1024) { 
  throw "The account has too many computers.  Cannot add more."
 }
 
 try {
  Set-ADUser -identity $targetaccount -logonworkstations $newworkstations
 } catch {
  throw "Unable to modify user object."
 }
} catch { throw $_ }

Journey to the hereafter series - Sh Tawfique Chowdhury

This is a very beneficial series of talks on everything that happens from now until the final abode.

All episodes on youtube

Audio can be found at Muslim central audio here. The same on itunes as a podcast.

Slow smartcard logon through remote desktop (RDP)

For anyone that has deployed smartcards, you have probably noticed at some point that smartcard logons are much slower than password logons. When they are done over remote desktop using local smartcard redirection, it can be horribly slow. In my testing, it appeared that whatever the ping response time was (in milliseconds divided by 100) would directly related to how many minutes it would take for me to log onto a remote machine. 200ms being 2 minutes, 800ms being 8minutes. This can cause logons to drop while they are still being processed. If you go searching for details on this problem, there doesn't seem to be much helpful information. Some suggest driver problems can be a factor, and other results may point you to some KB articles for hotfixes such as:

A smart card logon to a terminal session stops responding server that is running Windows Server 2008 and Windows Server 2008 R2
A program that requires you to use a smart card stops responding in a remote desktop connection in Windows Server 2008, in Windows Vista, in Windows 7 or in Windows Server 2008 R2
You may wait for up to 30 seconds when you use a smart card to unlock a computer that is running Windows 7 or Windows Server 2008 R2
Windows 7-based or Windows Server 2008 R2-based Remote Desktop Services server freezes when you try to log on to or log off the server by using a smart card
RDP 8 upgrade

I tried all of these, but none seemed to help. We eventually ended up going through a microsoft support case for the issue, which gave us some more suggested hotfixes to apply in this specific order (none worked):

"0x80100065" error when you call the SCardConnect function in Windows 7, Windows Server 2008 R2, Windows 8, and Windows Server 2012
A computer that has smart card logon enabled stops responding after you remove and then reinsert a smart card in Windows 7, Windows Vista, Windows Server 2008 or Windows Server 2008 R2
"Interactive Logon: Smart card removal behavior" Group Policy setting doesn't work as expected in Windows 7 SP1 or Windows Server 2008 R2 SP1
PIN dialog box appears unexpectedly when you open an encrypted email message after you remove and reinsert a Base CSP smart card in Windows 7 or in Windows Server 2008 R2
The screen saver grace period does not work as expected if the period exceeds 60 seconds on a computer that is running Windows 7 or Windows Server 2008 R2
Number of incorrect PIN retry attempts is less than expected after you unblock a smart card on a computer that is running Windows Vista, Windows Server 2008, Windows 7, or Windows Server 2008 R2

After further debugging and log analysis, the technician told us that the redirection function happens more than 50 times during the logon, with each request being sent individually. Essentially, with all of this back and forth one by one traffic, network latency causes big impact as we had originally reported to them. This was just marked down as expected behaviour that needed to be accepted. Sadly we were left with this situation, however with some further digging around, I did find one obscure forum post for a registry value that I couldn't find documented anywhere on Microsoft (at that time). This value can be created in HKLM\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp. The value is a Dword with the name LogonTimeout, and its value is in seconds. You put this value on the server end, and it will allow the connection to stay open longer during the logon process, so you don't have the connection dropping while its showing you the "welcome" screen. Otherwise you need to provide activity into the RDP connection window to reset the default timer, which I believe is 60 seconds. This activity can be mouse clicks or any other input that would go into the remote session. There is another key that you may want to adjust, which is related to timeouts in the smartcard crypto provider. More on this can be found in this article.

Finding OU's that block GPO inheritence

import-module activedirectory
get-adobject -LDAPFilter "(&(objectclass=OrganizationalUnit)(gPOptions=1))"

Windows not fully booting after patching (black screen after windows logo)

I have noticed on several machines over different patch cycles that I come across the occasional machine that will start the boot sequence, it shows the early windows logo and then goes to the temporary black screen prior to the blue background of group policy and other OS startup items. The problem though is that it stays at the black screen without progressing. On some machines there seems to be a "normal" hang here with 0 disk activity and apparently nothing happening, but in this case the hard drive with briefly tick for a moment every few seconds. So it appears like something is happening, but the machine never boots. In the few cases I have seen this, booting to safe mode usually works to resolve the problem. Since patches install over multiple stages of shutdown and preboot, it may be something is preventing it from finishing. Safemode seems to get around this block for the OS to resolve the problem, and the next reboot is back to normal.

Powershell - Listing services with file version details

In the event that you want to inventory system services and look at version details, you can do this with a combination of WMI and get-childitem to read file version details. This can be additionally modified to try to reduce the list of services to only non-microsoft products. Company details are in the Get-ChildItem versioninfo results.

Example:

(gci  (gwmi win32_service|select -first 1 -prop *|
 select -expand pathname).replace('"','')).versioninfo|
 select *


Comments           :
CompanyName        : Adobe Systems Incorporated
FileBuildPart      : 4
FileDescription    : Adobe Acrobat Update Service
FileMajorPart      : 1
FileMinorPart      : 7
FileName           : C:\Program Files\Common Files\Adobe\ARM\1.0\armsvc.exe
FilePrivatePart    : 0
FileVersion        : 1, 7, 4, 0
InternalName       : armsvc.exe
IsDebug            : False
IsPatched          : False
IsPrivateBuild     : False
IsPreRelease       : False
IsSpecialBuild     : False
Language           : English (United States)
LegalCopyright     : Copyright © 2013 Adobe Systems Incorporated.  All rights reserved.
LegalTrademarks    :
OriginalFilename   : armsvc.exe
PrivateBuild       :
ProductBuildPart   : 4
ProductMajorPart   : 1
ProductMinorPart   : 7
ProductName        : Adobe Acrobat Update Service
ProductPrivatePart : 0
ProductVersion     : 1, 7, 4, 0
SpecialBuild       :

To collect the basic information for all services, you can run the following:

gwmi win32_service |
select name,caption,@{name="filepath";expression={$_.pathname.split("-")[0].split("/")[0].replace('"','')}} |
select name,caption,filepath,@{
 name="fileversion";
 expression={(gci $_.filepath | select -expand versioninfo).productversion}
 }

Performing diagnostic checks on domain controllers without admin rights

Since domain controller access is pretty heavily restricted for security reasons, there are often cases in large organizations where the teams who receive alerts on domain controllers may not be the team that manages them. The receiving team could be a helpdesk, server team, monitoring team, etc. With some basic tools that are part of the windows administrative tools and other microsoft provided support tools, you can perform a wide range of tests on the machine that will give you a pretty good picture of if it is functional.

First of all, DCDIAG.exe is a good command line tool for checking any domain controller's status. Even though some of the tests will not work with a non-privileged account, you can still see some of the most important status results for the server. For non privileged accounts, they can use this to avoid the access denied failures (or they can just visually ignore those):

dcdiag /s:DCServer01 /skip:frsevent /skip:kccevent /skip:systemlog /skip:sysvolcheck /skip:netlogons /skip:replications /skip:services /skip:dfsrevent

If the advertising test passes, the domain controller is likely functioning pretty well (at least soon after a boot). Other than that, you can test LDAP responsiveness. Using portqry.exe will test the port (389 and/or 3268) and dump out the server capabilities that are advertised on connection. If you don't have portqry.exe, ldp.exe (gui tool) or powershell can be used to connect. You can check to see if the SYSVOL and netlogon shares are available with a simple: dir \\dcserver01\sysvol or dir \\dcserver01\netlogon command.

For hardware, it depends on manufacturer. Personally my experience is with dell servers and open manage. Wherever I go, there seems to be this idea embedded in the heads of server support teams that they can't check hardware on a domain controller because they are not domain admins. OMSA allows anyone to log on with user level access and you can see the status of the components.

SCOM monitoring and other tools can provide details of active directory events and errors. Although some of these are based on single events and don't automatically close when everything is fine. They are an additional level of allowing status information to be available to lower level teams.