Sep 30 2014

Azure & Active Directory

 

  • Azure is big. It’s really big. Seriously, it’s hard to comprehend just how big it really is. (Apologies to Douglas Adams.) In July of last year, then-CEO Steve Ballmer stated that Azure data centers held “comfortably over a million physical servers.” Last year, Azure server purchases accounted for 17% of all server purchases worldwide. And Azure is only getting bigger. In May of 2013, Global Foundation Services general manager Christian Belady stated that his division was performing data center build-outs “at a scale no one has ever seen before“. At Tech Ed North America in June, Technical Fellow (and now Azure CTO) Mark Russinovich stated that Microsoft’s plan was to double Azure’s capacity in 2015…and double it again in 2016. Can you even wrap your head around how big that is?
  • Azure AD is at the center of Azure. As Active Directory director of program management Alex Simons puts it, “identity is the control plane” upon which cloud services depend. And for Azure, this control plane is Azure Active Directory.
  • Microsoft is not content to let Azure AD be just a “lowest common denominator” solution. A long-recognized Microsoft product pattern is to provide basic capabilities, and allow a rich independent software vendor ecosystem to enhance these capabilities with their own products. In contrast to this strategy, Simons has a team of 500 working on building out Azure AD with a competitive set of features to compete in the IDaaS (identity management as a service) market. 30 developers are working on machine learning-based reporting alone.

Read the Article at Windows IT Pro

Sep 29 2014

Disarming EMET 5

EMET version 5 has been out for only a few months and Offensive Security has identified bypass methods:

INTRODUCTION

In our previous Disarming Emet 4.x blog post, we demonstrated how to disarm the ROP mitigations introduced in EMET 4.x by abusing a global variable in the .data section located at a static offset. A general overview of the EMET 5 technical preview has been recently published here. However, the release of the final version introduced several changes that mitigated our attack and we were curious to see how difficult it would be to adapt our previous disarming technique to this new version of EMET. In our research we targeted 32-bit systems and compared the results across different operating systems (Windows 7 SP1, Windows 2008 SP1, Windows 8, Windows 8.1, Windows XP SP3 and Windows 2003 SP2). We chose to use the IE8 ColspanID vulnerability once again in order to maintain consistency through our research.

ROP PROTECTIONS CONFIGURATION HARDENING

The very first thing that we noticed is that the global variable we exploited to disarm the ROP Protections (ROP-P) routine is not pointing directly to the ROP-P general switch anymore. This variable, which is now at offset 0x000aa84c from the EMET.dll base address, holds an encoded pointer to a structure of 0x560 bytes (See CONFIG_STRUCT in Fig. 1). The ROP-P general switch is now located at CONFIG_STRUCT+0x558 (Fig. 1, Fig. 2)

Read the rest of the article at Offensive Security.

Sep 28 2014

PowerShell: ADSI and Case Sensitivity

In developing a custom PowerShell script which leveraged ADSI, I noticed that the script wasn’t working properly.

Here’s a sample block of the script which uses ADSI to get changes made to ExtensionAttribute11 as part of an Active Directory Convergence test script:

1
2
3
4
$ADSITarget = [ADSI]”LDAP://$DC”
$Searcher = New-Object DirectoryServices.DirectorySearcher($ADSITarget,”(sAMAccountName=$ConvergenceObject)”)
$ConvergenceObjectData = ($Searcher.FindOne()).properties
$ConvergenceObjectDataValue = (($Searcher.FindOne()).properties).ExtensionAttribute11

I usually use Title Case when typing attributes and the script block above was not populating the variable “$ConvergenceObjectDataValue” with any data even though the attribute had data. I realized after enumerating the variable $ConvergenceObjectData that the attribute name was displayed as extensionattribute11 not ExtensionAttribute11.  After changing line #1 to line #2, it worked:

Line #1:
$ConvergenceObjectDataValue = (($Searcher.FindOne()).properties).ExtensionAttribute11

Line #2:
$ConvergenceObjectDataValue = (($Searcher.FindOne()).properties).extensionattribute11

So, be careful when using ADSI (or any other API) since it may be case sensitive.

Sep 27 2014

Powershell Remote Use of Module Commandlets (Remoting Import-Module)

Practically all of my Powershell scripts use an Active Directory commandlet. Ok, so they use several.  I like to query AD to get environmental information so when I run the script, I know what I am working with from an AD perspective. I can’t help it, I’m an AD Guy.

In order to run the AD commandlets, a Domain Controller in the domain has to be running ADWS (Active Directory Web Services aka Active Directory Management Gateway Service). Windows 2008 (and Windows 2008 R2) Domain Controllers run this by default and it is available for Windows 2003 DCs.

Sometimes, the server I need to run a script on doesn’t have the AD commandlets installed.
The quick solution to this is to run the following:

powershell set-executionpolicy unrestricted
powershell import-module servermanager  ;  add-windowsfeature rsat-ad-powershell

Assuming this isn’t possible, there is a way to import-modules available on another server.  I often use this with Exchange commandlets since I rarely have them installed on servers I use for running scripts.

Here’s how this works…

# Create a Powershell remote session to a server with the #commandlets installed.
$Session = New-PSsession -Computername Server1
# Use the newly created remote Powershell session to send a #command to that session
Invoke-Command -Command {Import-Module ActiveDirectory} -Session $Session
# Use that session with the modules to add the available # commandlets to your existing Powershell command shell with a #new command name prefix.
Import-PSSession -Session $Session -Module ActiveDirectory -Prefix RM

The code above enables the use of Active Directory commandlets on a server that doesn’t have them installed.

Use AD commandlets in the Powershell command shell with modified names based on the -Prefix set above:

Get-RMAdUser  instead of the standard Get-ADUser
Get-RMAdComputer instead of the standard Get-ADComputer

You can also drop the “-Prefix RM” and it will use the native commandlets using their standard names.

Don Jones calls this Powershell implicit remoting and it is very cool.

 

Sep 25 2014

PowerShell Code: Find Active Directory Site Containing AD Subnet

Here’s a quick script that returns the site in the Active Directory forest given a subnet (ex. 10.20.30.0).

Match-Subnet2Site.ps1

 


Param
(
[string]$Subnet
)

$IPSubnetRegEx = '\b((25[0-5]|2[0-4][0-9]|1[0-9][0-9]|[1-9]?[0-9])\.){3}(25[0-5]|2[0-4][0-9]|1[0-9][0-9]|0)\b'
# $IPRegEx = '\b((25[0-5]|2[0-4][0-9]|1[0-9][0-9]|[1-9]?[0-9])\.){3}(25[0-5]|2[0-4][0-9]|1[0-9][0-9]|[1-9]?[0-9])\b'

IF ($Subnet -match $IPSubnetRegEx)
{ Write-Output "Searching the AD forest for subnet: $Subnet " }
ELSE
{ Write-Error "The provided subnet ($Subnet) is not valid. Please enter as follows #.#.#.0 (ex. 10.22.33.0)" }

$ADForestName = [System.DirectoryServices.ActiveDirectory.Forest]::GetCurrentForest().Name
$DomainDNS = [System.DirectoryServices.ActiveDirectory.Domain]::GetCurrentDomain().Name

$ADSites = [System.DirectoryServices.ActiveDirectory.Forest]::GetCurrentForest().Sites
$ADSites = $ADSites | sort-Object Name
[int]$ADSitesCount = $ADSites.Count
Write-output "Searching $ADSitesCount AD Sites in $ADForestName `r"

[string]$SearchResults = "Subnet $Subnet could not be found in the current Active Directory forest ($ADForestName)"
ForEach ($ADSitesItem in $ADSites)
{ ## OPEN ForEach ($ADSitesItem in $ADSites)
$ADSitesItemName = $ADSitesItem.Name
$ADSitesItemSubnetsCount = $ADSitesItem.Subnets.Count
IF ($ADSitesItem.Subnets.Count -gt 1)
{ ## OPEN IF ($ADSitesItem.Subnets.Count -gt 1)
$ADSitesItemSubnetsArray = $ADSitesItem.Subnets
Write-Verbose "The site $ADSitesItemName has $ADSitesItemSubnetsCount subnets "
ForEach ($ADSitesItemSubnetsItem in $ADSitesItemSubnetsArray)
{ ## OPEN ForEach ($ADSitesItemSubnetsItem in $ADSitesItemSubnets)
$ADSitesItemSubnets = $ADSitesItemSubnetsItem.Name
$ADSitesItemSubnetSite = $ADSitesItemSubnetsItem.Site
$ADSitesItemSubnetLocation = $ADSitesItemSubnetsItem.Location
Write-Verbose "Checking Site $ADSitesItemName subnet $ADSitesItemSubnets"
IF ($ADSitesItemSubnets -like "*$Subnet*")
{ [string]$SearchResults = "The subnet $Subnet is configured as part of the AD site $ADSitesItemName ($ADSitesItemSubnetLocation)" }
} ## CLOSE ForEach ($ADSitesItemSubnetsItem in $ADSitesItemSubnets)
} ## CLOSE IF ($ADSitesItem.Subnets.Count -gt 1)
ELSE
{ ## OPEN ELSE ($ADSitesItem.Subnets.Count -lt 1)
$ADSitesItemSubnets = $ADSitesItem.Subnets[0].Name
$ADSitesItemSubnetSite = $ADSitesItem.Subnets[0].Site
$ADSitesItemSubnetLocation = $ADSitesItem.Subnets[0].Location

Write-Verbose "Checking Site $ADSitesItemName single subnet $ADSitesItemSubnets"
IF ($ADSitesItemSubnets -like "*$Subnet*")
{ [string]$SearchResults = "The subnet $Subnet is configured as part of the AD site $ADSitesItemName ($ADSitesItemSubnetLocation)" }
} ## CLOSE ELSE ($ADSitesItem.Subnets.Count -lt 1)

[array]$ADSitesItemSubnetsArray = $ADSitesItemSubnets -Split(", ")

} ## CLOSE ForEach ($ADSitesItem in $ADSites)

return $SearchResults

Sep 24 2014

Azure Active Directory Stats

 

  • Over 2.9 Million Organizations are using Azure Active Directory
  • More than 10 Billion Authentications per week
  • Azure Active Directory is spread out across 14 data centers
  • Contains more than 240 million user accounts
  • Organizations using Azure Active Directory across 127 countries
  • Supports over 1400 integrated third-party apps

Azure AD Statistics

Sep 24 2014

LOL! Lingering Object Liquidator for Active Directory

Microsoft released the LOL GUI tool for removing Active Directory lingering objects. Historically, removing lingering objects from AD had been a painful process.

Note that LOL is not a straightforward download. Follow the following steps to download:

  1. Log on to the Microsoft Connect site (using the Sign in) link with a Microsoft account:: http://connect.microsoft.com
    Note: You may have to create a profile on the site if you have never participated in Connect.
  2. Open the Non-feedback Product Directory:
    https://connect.microsoft.com/directory/non-feedback
  3. Join the following program:
    AD Health
    Product Azure Active Directory Connection Join link
  4. Click the Downloads link to see a list of downloads or this link to go directly to the Lingering Objects Liquidator download. (Note: the direct link may become invalid as the tool gets updated.)
  5. Download all associated files
  6. Double click on the downloaded executable to open the tool.

 

Why you should care about lingering object removal

Widely known as the gift that keeps on giving, it is important to remove lingering objects for the following reasons

  • Lingering objects can result in a long term divergence for objects and attributes residing on different DCs in your Active Directory forest
  • The presence of lingering objects prevents the replication of newer creates, deletes and modifications to destination DCs configured to use strict replication consistency. These un-replicated changes may apply to objects or attributes on users, computers, groups, group membership or ACLS.
  • Objects intentionally deleted by admins or application continue to exist as live objects on DCs that have yet to inbound replicate knowledge of the deletes.

Lingering Object Liquidator automates the discovery and removal of lingering objects by using the DRSReplicaVerifyObjects method used by repadmin /removelingeringobjects and repldiag combined with the removeLingeringObject rootDSE primitive used by LDP.EXE. Tool features include:

  • Combines both discovery and removal of lingering objects in one interface
  • Is available via the Microsoft Connect site
  • The version of the tool at the Microsoft Connect site is an early beta build and does not have the fit and finish of a finished product
  • Feature improvements beyond what you see in this version are under consideration

 

 

From Microsoft KB 910205:

Lingering objects can occur if a domain controller does not replicate for an interval of time that is longer than the tombstone lifetime (TSL). The domain controller then reconnects to the replication topology. Objects that are deleted from the Active Directory directory service when the domain controller is offline can remain on the domain controller as lingering objects. This article contains detailed information about the events that indicate the presence of lingering objects, the causes of lingering objects, and the methods that you can use to remove lingering objects.

 

Tombstone lifetime and replication of deletions

When an object is deleted, Active Directory replicates the deletion as a tombstone object. A tombstone object consists of a small subset of the attributes of the deleted object. By inbound-replicating this object, other domain controllers in the domain and in the forest receive information about the deletion. The tombstone is retained in Active Directory for a specified period. This specified period is called the TSL. At the end of the TSL, the tombstone object is permanently deleted.

The default value of the TSL depends on the version of the operating system that is running on the first domain controller that is installed in a forest. The following table indicates the default TSL values for different Windows operating systems.

First domain controller in forest root Default tombstone lifetime
Windows 2000 60 days
Windows Server 2003 60 days
Windows Server 2003 with Service Pack 1 180 days

Note The existing TSL value does not change when a domain controller is upgraded to Windows Server 2003 with Service Pack 1 (SP1). The existing TSL value is maintained until you manually change it.

After the tombstone is permanently deleted, the object deletion can no longer be replicated. The TSL defines how long domain controllers in the forest retain information about a deleted object. The TSL also defines the time during which all direct and transitive replication partners of the originating domain controller must receive a unique deletion.

How lingering objects occur

When a domain controller is disconnected for a period that is longer than the TSL, one or more objects that are deleted from Active Directory on all other domain controllers may remain on the disconnected domain controller. Such objects are called lingering objects. Because the domain controller is offline during the time that the tombstone is alive, the domain controller never receives replication of the tombstone.

When this domain controller is reconnected to the replication topology, it acts as a source replication partner that has an object that its destination partner does not have.

Replication problems occur when the object on the source domain controller is updated. In this case, when the destination partner tries to inbound-replicate the update, the destination domain controller responds in one of two ways:

  • If the destination domain controller has Strict Replication Consistency enabled, the controller recognizes that it cannot update the object. The controller locally stops inbound replication of the directory partition from the source domain controller.
  • If the destination domain controller has Strict Replication Consistency disabled, the controller requests the full replica of the updated object. In this case, the object is reintroduced into the directory.

Causes of long disconnections

The following conditions can cause long disconnections:

  • A domain controller is disconnected from the network and is put in storage.
  • The shipment of a pre-staged domain controller to its remote location takes longer than a TSL.
  • Wide area network (WAN) connections are unavailable for long periods. For example, a domain controller onboard a cruise ship may be unable to replicate because the ship is at sea for longer than the TSL.
  • The reported event is a false positive because an administrator shortened the TSL to force the garbage collection of deleted objects.
  • The reported event is a false positive because the system clock on the source or on the destination domain controller is incorrectly advanced or rolled back. Clock skews are most common following a system restart. Clock skews may occur for the following reasons:
    • There is a problem with the system clock battery or with the motherboard.
    • The time source for a computer is configured incorrectly. This includes a time source server that is configured by using Windows Time service (W32Time), by using a third-party time server, or by using network routers.
    • An administrator advances or rolls back the system clock to extend the useful life of a system state backup or to accelerate the garbage collection of deleted objects. Make sure that the system clock reflects the actual time. Also, make sure that event logs do not contain invalid events from the future or from the past.

Removing lingering objects from the forest

Windows 2000-based forests

For more information about how to remove lingering objects in a Windows 2000-based domain, click the following article number to view the article in the Microsoft Knowledge Base:

314282 Lingering objects may remain after you bring an out-of-date global catalog server back online

Windows Server 2003-based forests

For information about how to remove lingering objects from Windows Server 2003-based forests, visit the following Microsoft Web site:

http://technet2.microsoft.com/WindowsServer/en/Library/77dbd146-f265-4d64-bdac-605ecbf1035f1033.mspx

For more information, click the following article number to view the article in the Microsoft Knowledge Base:

892777 Windows Server 2003 Service Pack 1 Support Tools

Preventing lingering objects

The following are methods that you can use to prevent lingering objects.

Method 1: Enable the Strict Replication Consistency registry entry

You can enable the Strict Replication Consistency registry entry so that suspect objects are quarantined. Then, administrations can remove these objects before they spread throughout the forest.

If a writable lingering object is located in your environment, and an attempt is made to update the object, the value in the Strict Replication Consistency registry entry determines whether replication proceeds or is stopped. The Strict Replication Consistency registry entry is located in the following registry subkey:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters

The data type for this entry is REG_DWORD. If you set the value to 1, the entry is enabled. Inbound replication of the specified directory partition from the source is stopped on the destination. If you set the value to 0, the entry is disabled. The destination requests the full object from the source domain controller. The lingering object is revived in the directory as a new object.

The default value for the Strict Replication Consistency registry entry is determined by the conditions under which the domain controller was installed in the forest.

Note Raising the functional level of the domain or the forest does not change the replication consistency setting on any domain controller.

By default, the value of the Strict Replication Consistency registry entry on domain controllers that are installed in a forest is 1 (enabled) if the following conditions are true:

  • The Windows Server 2003 version of Winnt32.exe is used to upgrade a Windows NT 4.0 primary domain controller (PDC) to Windows Server 2003. This computer creates the forest root domain of a new forest.
  • Active Directory is installed on a server that is running Windows Server 2003. This computer creates the forest root domain of a new forest.

By default, the value of the Strict Replication Consistency registry entry on domain controllers is 0 (disabled) if the following conditions are true:

  • A Windows 2000-based domain controller is upgraded to Windows Server 2003.
  • Active Directory is installed on a Windows Server 2003-based member server in a Windows 2000-based forest.

If you have a domain controller that is running Windows Server 2003 with SP1, you do not have to modify the registry to set the value of the Strict Replication Consistency registry entry. Instead, you can use the Repadmin.exe tool to set this value for one domain controller in the forest or for all the domain controllers in the forest.

For more information about how to use Repadmin.exe to set Strict Replication Consistency, visit the following Microsoft Web site:

http://technet.microsoft.com/en-us/library/cc780362(WS.10).aspx

Method 2: Monitor replication by using a command-line command

To monitor replication by using the repadmin /showrepl command, follow these steps:

  1. Click Start, click Run, type cmd, and then click OK.
  2. Type repadmin /showrepl * /csv >showrepl.csv, and then press ENTER.
  3. In Microsoft Excel, open the Showrepl.csv file.
  4. Select the A + RPC column and the SMTP column.
  5. On the Edit menu, click Delete.
  6. Select the row that is immediately under the column headers.
  7. On the Windows menu, click Freeze Pane.
  8. Select the complete spreadsheet.
  9. On the Data menu, point to Filter, and then click Auto-Filter.
  10. On the heading of the Last Success column, click the down arrow, and then click Sort Ascending.
  11. On the heading of the src DC column, click the down arrow, and then click Custom.
  12. In the Custom AutoFilter dialog box, click does not contain.
  13. In the box to the right of does not contain, type del.

    Note This step prevents deleted domain controllers from appearing in the results.

  14. On the heading of the Last Failure column, click the down arrow, and then click Custom.
  15. In the Custom AutoFilter dialog box, click does not equal.
  16. In the box to the right of does not equal, type 0.
  17. Resolve the replication failures that are displayed.

 

Sep 23 2014

PowerShell Code: Active Directory Domain Controller Discovery

There are several different ways to find AD Domain Controllers (DCs).

Here are a few:

AD PowerShell Module: Discover the closest Domain Controller running the AD web services (support PowerShell AD cmdlets):

import-module activedirectory
Get-ADDomainController -discover -forcediscover -nextclosestsite -service ADWS

  • discover – find a DC
  • forcediscover – re-discover a DC and not use a cached DC
  • nextclosestsite – if there is no DC discovered in the local site, use the AD topology to find the closest DC in another site.
  • service – the DC must support these services.


AD PowerShell Module: Discover all Domain Controller in the domain:

import-module activedirectory
Get-ADDomainController -filter *

  • filter * – find all Domain Controllers


Discover all Domain Controller in the domain using ADSI:

[System.DirectoryServices.ActiveDirectory.Domain]::GetCurrentDomain().DomainControllers

 

Discover all Global Catalogs in the forest using ADSI:

[System.DirectoryServices.ActiveDirectory.Forest]::GetCurrentForest().GlobalCatalogs

 

You can also use the Active Directory cmdlets to get computer information about Domain Controllers:

import-module activedirectory
get-ADComputer -filter { PrimaryGroupID -eq “516” } -properties PrimaryGroupID

 

 

 

Sep 22 2014

Powershell Filter Operators

Once you get used to Powershell, you will want to do more and more with it.  One of the keys to leveraging the power of PowerShell is filters.
PowerShell commandlets all support filters (well, most of them anyway).  This means you can drill down to resulting data subsets.
If you run into commandlets that don’t support the native -filter you can always pipe to where-object (aka “where”).

In other words you can do this: get-service | Where {$_.Status -eq “Running”}
This takes the results of a generic get-service request which returns a full list of system services and pares it down to only the running services.
Change “Running” to “Stopped” and you get, obviously a list of services that are stopped.

You can also pipe the service name into the get-service commandlet: “W32Time” | get-service

Here’s a great chart I found on the MSDN Blogs that describes what each filter operator does:

Logical Operator Description Equivalent LDAP operator/expression
-eq Equal to. This will not support wild card search. =
-ne Not equal to. This will not support wild card search. ! x = y
-like Similar to -eq and supports wildcard comparison. The only wildcard character supported is: * =
-notlike Not like. Supports wild card comparison. ! x = y
-approx Approximately equal to ~=
-le Lexicographically less than or equal to <=
-lt Lexicographically less than ! x >= y
-ge Lexicographically greater than or equal to >=
-gt Lexicographically greater than ! x <= y
-and AND &
-or OR |
-not NOT !
-bor Bitwise OR :1.2.840.113556.1.4.804:=
-band Bitwise AND :1.2.840.113556.1.4.803:=
-recursivematch Uses LDAP_MATCHING_RULE_IN_CHAIN (Win2k3 SP2 and above) :1.2.840.113556.1.4.1941:=

Using filters is extremely helpful is narrowing down the scope to fine-tune the data you need to work with and this chart is one I frequently reference.

Sep 21 2014

PowerShell: Parse a Large Multi-Line Text Field Based on String Value & Extract Text

Parsing a large multi-line text field (variable) for a specific string and extract text from it:

$EventMessage =
@”
An account was successfully logged on.

Subject:
Security ID:  SYSTEM
Account Name:  METCORPWKS201$
Account Domain:  METCORP
Logon ID:  0x2b5
Logon Type:10
New Logon:
Security ID:  METCORP\Administrator
Account Name:  Administrator
Account Domain:  METCORPWKS201
Logon ID:  0bc123d
Logon GUID:  {00000000-0000-0000-0000-000000000000}
Process Information:
Process ID:  0x123
Process Name:  C:\Windows\System32\winlogon.exe
Network Information:
Workstation Name: METCORPWKS201
Source Network Address: 10.10.10.201
Source Port:  1234
Detailed Authentication Information:
Logon Process:  User32
Authentication Package: Negotiate
Transited Services: –
Package Name (NTLM only): –
Key Length:  0

This event is generated when a logon session is created. It is generated on the computer that was accessed.

The subject fields indicate the account on the local system which requested the logon. This is most commonly a service such as the Server service, or a local process such as Winlogon.exe or Services.exe.

The logon type field indicates the kind of logon that occurred. The most common types are 2 (interactive) and 3 (network).

The New Logon fields indicate the account for whom the new logon was created, i.e. the account that was logged on.

The network fields indicate where a remote logon request originated. Workstation name is not always available and may be left blank in some cases.

The authentication information fields provide detailed information about this specific logon request.

The authentication information fields provide detailed information about this specific logon request.

Logon GUID is a unique identifier that can be used to correlate this event with a KDC event.
Transited services indicate which intermediate services have participated in this logon request.
Package name indicates which sub-protocol was used among the NTLM protocols.
Key length indicates the length of the generated session key. This will be 0 if no session key was requested.

“@

$EventMessageLogonNumber = $EventMessage | Select-String -Pattern “Logon Type:\w+” -AllMatches | Select -ExpandProperty matches | Select -ExpandProperty value
$EventMessageAccountNameText = $EventMessage | Select-String -Pattern “Account Name:\s+\w+” -AllMatches | Select -ExpandProperty matches | Select -ExpandProperty value
$EventMessageAccountName = (($EventMessageNameText -split “:”)[1]) -Replace(“`t”,””)
$EventMessageWorkstationNameText = $EventMessage | Select-String -Pattern “Workstation Name:\s+\S+” -AllMatches | Select -ExpandProperty matches | Select -ExpandProperty value
$EventMessageWorkstationName = (($EventMessageWorkstationNameText -split “:”)[1]) -Replace(“`t”,””)
$EventMessageSourceIPText = $EventMessage | Select-String -Pattern “Source Network Address:\s+\S+” -AllMatches | Select -ExpandProperty matches | Select -ExpandProperty value
$EventMessageSourceIP = (($EventMessageSourceIPText -split “:”)[1]) -Replace(“`t”,””)
$EventMessageLogonNumber
$EventMessageAccountName
$EventMessageWorkstationName
$EventMessageSourceIP