Troubleshooting Account Lockouts in Active Directory

In this post we will look into troubleshooting Account Lockouts in Active Directory. From my experience identifying the source of an Account Lockout can often be easy, or extremely difficult.

When an authentication attempt hits a domain controller that is incorrect, a second authentication attempt will always hit the Primary Domain Controller (PDC). This is due to Active Directory replication intervals, if you reset a users password, it may take a few hours for the password change to propagate across the network based on how you have configured your Inter-Site Transport links in AD Sites and Services. The Primary Domain Controller (PDC) always has the latest list of passwords (one of the many things the PDC emulator role performs).

The easiest way to troubleshoot Account Lockouts is simply login to the Primary Domain Controller and review the security log, as this will have a list of all account lockouts that have occured across all domain controllers. The EventID that represents an account lockout is EventID 4740.

The screenshot below shows a typical Account Lockout event on the PDC.  It will display the account name that was locked out, and the computer in which the account was locked out on.

However this is where it can get more complicated.  If the lockout came from a system not in Active Directory, the "Caller Computer Name" value will always be blank.  This can include numerous scenarios such as:

• Mobile Devices (Android / IOS) that are authenticating against an Exchange Server through Active Sync.
• Proxy Servers
• Java Applications
• UNIX/Linux Systems
• Other non-domain joined computer objects.

For these events we cannot simply only look at the PDC Emulator role, we need to look at where the "Bad Pwd Count" is incrementing the the "Last Bad Pwd" timestamp across all domain controllers in the Active Directory Domain.  Microsoft has a tool called lockoutstatus.exe that allows us to easily the domain controller which the lockout occurred so we can review the security logs on the domain controller in question.

Download this tool from here:

https://www.microsoft.com/en-au/download/details.aspx?id=15201

If you want to see it utilised, refer to this post:

https://clintboessen.blogspot.com/2018/08/troubleshooting-account-lockouts.html

The EventID Security logs you want to filter are as follows:

• Event ID 4625 - An account failed to log on
• Event ID 4776 - The computer attempted to validate the credentials for an account.
• Event ID 4771 - Kerberos pre-authentication failed

Note: The Event ID's for Windows Server 2000/2003 are different but I assume your not running this anymore!

These Events ID's will reveal the source IP address the authentication attempt failed from.

For many companies still running on-premises Exchange, Mobile Devices on Active Sync are a common cause for account lockouts.  If you have confirmed using the EventID's above that the account lockout is coming from your Exchange Server, you can utilise the IIS Logs to identify the device and external IP address that caused the lockout.  You need to check the IIS Logs on the Exchange Server for a HTTP 401 "Unauthorized" error for the user in question.  IIS Logs can easily be imported into Excel for easy formatting/review.  Also check out the following blog post that has a Logparser.exe query that lets you quickly search IIS Logs for the account lockout.  

http://messagingadmins.blogspot.com/2014/08/troubleshoot-exchange-cas-server-is-lockout-source.html

In addition to the HTTP 401 "Unauthorized" error, the Exchange IIS Logs also can provide additional information in the Sc-Win32-status code:

• 1326 - The user name or password is incorrect.
• 1330 - The password for this account has expired.
• 1331 - This user can't sign in because this account is currently disabled.
• 1909 - The referenced account is currently locked out and may not be logged on to.

Note: I have seen an account lockout event at a customer site where 4771 Event ID's were logged pointing at the Exchange Server, however I could not see the user account in the IIS Logs with the 401. 

More Reading / References:

https://www.business.com/articles/powershell-active-directory-lockouts/

https://social.technet.microsoft.com/Forums/en-US/735602f0-3ddc-4bb4-b6ba-dffcb7605ca1/account-lockout-on-windows-2008-r2-and-windows-7?forum=winserverDS

https://www.windowstricks.in/2016/06/account-lockout-caller-computer-name-blank-cisco-workstation-domain-controller.html

https://kb.netwrix.com/2744

I also recommend reading the following article "The Low Down on Password Policies".

https://clintboessen.blogspot.com/2009/12/low-down-on-password-policies.html

Hopefully this post has been informative for you in troubleshooting Account Lockouts.

Azure AD Seamless SSO - Prompts on Connecting to aadg.windows.net.nsatc.net

At a customer site when attempting to access the https://myapps.microsoft.com/companydomain.com portal to test Single Sign-on with Azure AD, we were constantly being prompted "Connecting to aadg.windows.net.nsatc.net".

 

We had gone through significant troubleshooting on the issue but could not find a resolution online.  This troubleshooting included but was not limited to:

• Confirmed that we have received the Kerberos ticket from the AZUREADSSOACC with “klist get AZUREADSSOACC”
• Added https://autologon.microsoftazuread-sso.com and https://aadg.windows.net.nsatc.net to the Trusted Sites
• Confirmed the servicePrincipalNames on the AZUREADSSOACC are correct
• Validated the Single sign-on is enabled on the Azure AD Portal and in the Azure AD Connect tool

Troubleshooting sites we went through included:

http://tiftomorrow.blogspot.com/2017/10/azure-ad-sso-troubleshooting.html

https://docs.microsoft.com/en-us/azure/active-directory/hybrid/tshoot-connect-sso

After speaking with Microsoft, they mentioned that "https://autologon.microsoftazuread-sso.com" must also be in the "Local Intranet" zone.

 

  

This is due to the default security setting "Automatic logon only in Intranet zone".  If this was set to "Automatic logon with current user name and password" this would have also fixed the issue but is not as secure.

 

 

After making this change Single Sign-On works.

Troubleshooting Account Lockout's

I often get asked by customers for assistance with troubleshooting account lockout issues, where a user constantly gets locked out but IT doesn't know how they are getting locked out or what device they are being locked out from.

Diagnosing account lockout issues can be a difficult task as you need to look at the audit logs on the domain controller for which the user attempted the failed authentication request.  For companies without audit collection software (software which pulls audit logs from multiple servers in a central place) this can be a difficult task.  There are many enterprise auditing products on the market such as Snare, Splunk, Tripwire, ManageEngine or even Microsoft ACS which is part of System Centre Operations Manager.

For companies without an enterprise auditing product, Microsoft has made a simple tool called Account Lockout Status (LockoutStatus.exe) which is free which just looks at invalid password attempts.  This tool queries the audit logs on all domain controllers.  This tool can be downloaded from the following location:

https://www.microsoft.com/en-gb/download/details.aspx?id=15201

If we look on Bentley-DC Security Logs we can see the unsuccessful login occurred from AT-LT-03.

Hope this post has been helpful.

Azure AD Domain Services Overview - Removing the need for Domain Controllers in Azure IaaS clouds

Late 2017 Microsoft released some very cool technology in Azure called Azure AD Domain Services.  This service provides Azure Customers with Virtual Machines in Azure the ability to use Domain Services such as Kerberos, NTLM and Group Policy lock down without the need for deploying Domain Controllers in the cloud.

It is important to note, Azure AD Domain Services a paid service, once enabled in your Azure Tenancy, you will be billed monthly.  Azure AD Domain Services unlike other cloud services in Azure cannot be stopped or paused, it must be deleted from the Azure Tenancy to avoid further billing.  To understand how this service is charged, please see https://azure.microsoft.com/en-au/pricing/details/active-directory-ds/

What Azure AD Domain Services offers customers is the ability to remove the need for building domain controllers in the cloud and instead utilize Domain Controllers as a service.  You essentially consume these domain functionality as a service without the need to deploy, manage and patch domain controllers in the cloud.

As companies adopt cloud technologies, we want to transition our workloads into Software as a Service (SaaS) offerings.  What I tell my customers is 95% of what your IT department maintains are the applications and services provisioned within the virtual machines.  For on-premises deployments the Virtualization Layer, Servers, Storage and Network typically get updated every 5 years as part of an Infrastructure Refresh project which is generally done by an IT Integrator.  When transitioning to cloud computing, simply moving your virtual machines from your on-premises environment to an Infrastructure as a Service platform does not generally reduce your IT expenditure and for many clients is more expensive in most cases.  For majority of companies, none of what the IT team works on in a daily basis is revolves around the Virtualization, Servers, Storage and Networking layer!

We want to transition as many services as we can onto Software as a Service offerings where we consume a service but have no need to maintain the virtual machines and the applications which run on these.  Office 365 is a prime example of a Software as a Service offering, you consume Exchange, Sharepoint and Skype for Business services without the need for maintaining anything in the back end.

Well you might have guest it, Azure AD Domain Services is a Software as a Service offering for "Domain Services" removing the need for Domain Controllers.

Azure AD Domain Services utilises the user accounts, security groups and data stored in Azure Active Directory to provision domain services.  It acts as a service which communicates with Azure Active Directory in the back-end.  Servers in an Azure IaaS offering or even on-premises via Express Route or VPN Tunnel can utilise Azure Active Directory for authentication and domain services functionality.

If you have an on-premises Active Directory environment and are looking to move some virtual machine workloads up to the cloud, you can also leverage Azure AD Domain Services which I will explain.

Through utilizing Azure AD Connect (the same tool most of you are familiar with for Office 365 migrations), you can synchronize your user accounts and password hashes up to Azure AD which then can be leveraged by Azure AD Domain Services.

Important: You must synchronize password hashes to Azure AD for Azure AD Domain Services to work correctly.  Azure AD Domain Services cannot authenticate against passwords in an Active Directory Environment using Active Directory Federation Services or Passthrough Authentication.

Important: You can only create one managed domain serviced by Azure AD Domain Services for a single Azure AD directory

Setting up Azure AD Domain Services

In this article I'm going to run through the setup process of Azure AD Domain Services.  In order to be able to setup Azure AD Domain Services you must first have an Azure Tenancy and billing setup.  You will also need setup in place a Resource Group, Virtual Network for Azure AD Domain Services to operate on within Azure and ideally a Virtual Network Gateway to provide connectivity back to on-premises.

The step is to find Azure AD Domain Services from the Azure Market place.

Like creating a real Active Directory Domain in a new Forest, specify the DNS Namespace you want for the new Azure AD Domain Services domain.  Also specify the subscription you want to use, the resource group and the Azure Datacentre.

I'm using Southeast Asia (Singapore) as I get the same latency from my Office to Singapore as what I get to the Azure Sydney datacenter - and it's cheaper to put my infrastructure in Asia!

Next specify the virtual network and server subnet you want to use within Azure.  I created this earlier for other infrastructure residing in my Azure tenancy.

Within the Azure AD Domain Services there is a group called "AAD DC Administrators".  This is our traditional "Domain Admins" we are custom to in Active Directory.  Add at least one account which exists in the Azure AD tenancy we are linking to be an administrator.

Give it some time to deploy.  It took almost an hour to provision within my tenancy.

Once it finishes provisioning, you will see it in your list of resources within the Azure portal.  Go to Azure AD Domain Services and note down the DNS servers.  These will automatically be provisioned within the IP range of your virtual network.

Find the Virtual Network resource you have provisioned earlier.

Update the DNS of the Virtual Network to use the Azure AD Domain Services DNS.

After updating the Virtual Network you will need to reboot your Azure VMs on the network.  Remember the golden rule of Azure is never configure static IP addresses on your VM's.  Use the Azure Portal to configure DNS, Gateway settings and IP addressing for everything!

You should see the DNS settings referencing that of Azure AD Domain Services.

Now you can simply just join the member servers to the Azure AD Domain Services managed domain using an administrative account in the "AAD DC Administrators" group.

Administrating Azure AD Domain Services

As mentioned previously Azure AD Domain Services is Domain Services managed by Microsoft.  As a result, it is not possible to login to the AD Domain Services via Remote Desktop like you can do with Traditional Domain Controllers.  Provided you have administrative rights and are part of the "AAD DC Administrators" group in Azure AD you can however connect to the Domain Services using the Microsoft Management Console (MMC) Active Directory snap-ins which I will show you shortly.

On a member server joined to Azure AD Domain Services, simply add the Active Directory Remote Server Administration Tools.

Then you can simply Open Active Directory Users and Computers and query what is in Azure AD Domain Services.  You will be able to see all the objects which exist in Azure AD which are automatically synchronized.  As you see, my Azure AD has lots of objects! - 2 users... :)

It is important that all changes are conducted through the Azure AD portal.  This includes creating new user accounts, changing attributes, resetting passwords, creating/deleting groups and group membership management.  Any changes you make to the objects in Azure AD Domain Services will be overwritten automatically by Azure AD which is the "authoritative source".

Azure AD Domain Services supports full Group Policy functionality and provides member servers with a SYSVOL for Group Policy Objects.

If you install Group Policy Management Console on a member server you can create and manage Group Policy against your users and member computers.  All Group Policy functionality is available in Azure AD Domain Services.

There are domain controller objects in Azure AD Domain Services.  These are automatically generated and maintained by Microsoft.  You must not touch these objects within the Domain Controllers organisational unit.

Important: Encase you were wondering, you cannot add additional domain controllers to a domain running in Azure AD Domain Services.

Limitations of Azure AD Domain Services

There are a few limitations of Azure AD Domain Services that i'm aware of which I would like to share with you.

• The Schema is administrated by Microsoft for the managed domain.  Schema extensions whilst possible are not supported by Azure AD Domain Services.  If you want to customize the Schema, create your own domain controllers using the traditional method.  This means no Microsoft Exchange, Skype for Business or other applications which change the Schema.  Use Office 365!
• Any changes made in Azure AD take approximately 20 minutes to reflect in your managed domain.  This is a bit slow and you will need to be patient.
• There is no way to pause or stop Azure AD Domain Services.  From a billing perspective make sure your aware of this and are fine paying the monthly fee for this service.  It is cheaper then creating your own virtual machines in Azure and configuring them as Domain Controllers.
• All group and user changes must be conducted through Azure AD, not Azure AD Domain Services.
• You cannot add additional domain controllers to Azure AD Domain Services.  As this service is managed by Microsoft, they will automatically provide additional servers should the number of LDAP queries be excessive or you log a support case saying its slow!

Migrating Servers to Azure AD Domain Services

If you have Azure AD Connect in place from your on-premises Active Directory Domain to Azure AD, all your user accounts and groups will be available in the cloud and can be used in Azure AD Domain Services.  This is provided your synchronizing the password hashes for the accounts and not utilizing ADFS or Passthrough authentication.

After you migrate virtual machines up to Azure, if you join them to the new Azure AD Domain Services, you will be able to continue logging into the servers using the same synchronized accounts.  Please note however, Azure AD Domain Services will provide resources with a new Security Identifier (SID) and as a result, some resource access may break.  I'm not aware of any tools at this stage that will deal with this.  In on-premises world we had the Active Directory Migration Tool (ADMT) which performed SID Translation and allowed us to utilise SID History to continue accessing old resources over a transitive forest trust during co-existance.

We can however migrate group policy objects across to Azure AD Domain Services using Group Policy with Group Policy Migration tables.  This will allow you to provide the same policies in Azure AD Domain Services as what you have on-premises without manual reconfiguration.  If you want more information on this google "Group Policy Migration Tables".

I hope this post has been helpful in giving you an understanding of Azure AD Domain Services!

Windows cannot move object because Access is denied

I came across an interesting error today when attempting to move a security group to a new location in Active Directory.

Windows cannot move object because Access is denied

This issue was caused by "Protect object from accidental deletion"

By default this feature is only enabled on organisational units however in this environment, some groups and user objects had this feature enabled as well.  I believe this was manually enabled by a sysadmin in the past.

Why my Domain Password Policy Not Applying?

Back in 2009 I published a very popular article "The Low-Down on Password Policies" which has been viewed by thousands of IT Professionals and referenced by application vendors in online documentation such as SysOp Tools Software.

http://clintboessen.blogspot.com.au/2009/12/low-down-on-password-policies.html

In this post we are going to talk about password policies further and cover off what appears to be a bug but is actually "by design".

My customer had a handful of domain controllers with a single 2008 R2 domain controller and three Server 2012 R2 domain controllers.  The PDC Emulator resides on Server 2008 R2.

The Server 2008 R2 domain controller was applying the password policy correctly however the 2012 R2 domain controllers were not (or so I thought).

Running an rsop.msc on the 2008 R2 domain controller (the PDC) shows the policy being applied from the Default Domain Policy.

 

 The 2012 R2 domain controllers the resultant set of policy displayed no policies being applied.

The same was experienced running an "gpresult /v" on the 2008 R2 or 2012 R2 domain controllers.

"gpresult /v" on 2008 R2:

 

"gpresult /v" on 2012 R2:

 

 

The account policies above are the domain Kerberos policy, not the password policy.

 

The password policy simply did not apply to the 2012 servers.  After further investigation in my test lab, I saw that only the domain controller running the PDC emulator displays the password policy when performing a Resultant Set of Policy.

 

This means every domain controller in a domain will not display the password policy from a resultant set of policy apart from the primary domain controller.

 

How do I check if the password policy is applying correctly on my domain controllers?

 

There are two commands which check the password policy:

• net accounts (checks local password policies on a server)
• net accounts /domain (checks the domain password policy on a server)

 

 

 

Domain Policy always wins over a local policy.

 

Computer Role: Backup means it is not a Primary Domain Controllers (PDC).

 

So in summary... if you see a password policy not applying to a domain controller when you check Group Policy, this is normal behaviour and is by design unless the server is the PDC emulator.

Exchange 2013 - Could not find any available Global Catalog in forest

I was contracted to redesign a companies AD Sites and Services Topology - it was never setup correctly and despite being a 500 user organisation with 13 branch sites, they were still running of the "Default-First-Site-Name" which is generated automatically by Active Directory for a new domain.

As part of the new design, I updated the Default-First-Site-Name to a name which reflects their main datacentres then went through the process creating the additional site objects, site links and subnet objects.

After renaming Default-First-Site-Name I also updated the AutodiscoverSiteScope on the Client Access Servers in the Exchange 2013 cluster to reflect the new site name (as required for correct site SCP lookups).

After approximately 30 minutes, the IT Department complained they were no longer able to work on Exchange 2013 servers - all commands in the Exchange Management Shell failed with:

Could not find any available Global Catalog in forest

Oh dear!

After a quick investigation, the issue was only isolated to Exchange 2013 management tools and Outlook clients were not affected by the Site Object rename.

In order to force Exchange Server to redetect Active Directory Sites and Services topology, a restart of the "Microsoft Exchange Active Directory Topology" service is required on all Exchange servers.  Unfortunately almost every Exchange Service is dependent on this service!

As a result, we needed to wait until after business hours where we rebooted every Exchange 2013 server in the cluster.

This resolved the problem.

Common DCDIAG Error with NCSecDesc

When running a DCDiag on 2008 or 2008 R2 domain controllers, it is very common to see the following error when running a dcdiag.exe.

Starting test: NCSecDesc
   Error NT AUTHORITY\ENTERPRISE DOMAIN CONTROLLERS doesn't have Replicating Directory Changes In Filtered Set access rights for the naming context:
   DC=DomainDnsZones,DC=domain,DC=local
   Error NT AUTHORITY\ENTERPRISE DOMAIN CONTROLLERS doesn't have Replicating Directory Changes In Filtered Set access rights for the naming context:
   DC=ForestDnsZones,DC=domain,DC=local
   ......................... DC1 failed test NCSecDesc

This is caused on Active Directory domains which have not prepared Active Directory for read only domain controllers with "adprep /rodcprep".

Server 2012 / 2012 R2 domain controllers do not receive this error for NCSecDesc.

Also it is recommended you do not prepare you domain for RODC unless you intend to deploy Read Only Domain Controllers provided you have the requirement for specific branch locations from a physical security perspective.

Active Directory Topology Diagrammer Error

I'm running Windows 10 with Visio 2016 (both x64 builds).  I needed to draw out the topology from a customers Active Directory domain however when attempting to draw the topology using the free Microsoft tool I received the following error message:

Could not open the Visio Stencil !!!
ADTD can not continue with the drawing.
The current drawing will be canceled !

 

To resolve this issue, in Visio click File --> Options.

 

Open the "Trust Center" then click "Trust Center Settings".

Untick all Open and Save boxes as shown below:

After making this change the topology should generate without issues:

 

Active Directory Issues - Network Drives Not Mapping

A customer of mine raised an issue in regards network drives not being mapped for users.  This includes drives mapped via Group Policy and Home Drives mapped via the NT4 Home Drive option of the Active Directory user account.

When users attempt to navigate to the UNC paths manually or map a drive manually it works as expected, however mapping network drives automatically upon logon simply did not work.

Also users were unable to navigate to the domain name "\\domain.local".  However users could navigate to "\\domain.local\netlogon" and "\\domain.local\sysvol".  Navigating to the domain root resulted in this error being generated:

\\domain.local is not accessible.  You might not have permissions to use this network resource.  Contact the administrator of this server to find out if you have access permissions.

Logon Failure: The target account name is incorrect.

This issue with not being able to navigate to the domain root UNC share occurred on all member workstations and servers throughout the organisation.  Domain Controllers were not effected by the issue.

The following three event logs were also found throughout the SYSTEM event log on all client workstations throughout the companies domain.

Log Name:      System

Source:        NETLOGON

Date:          26/10/2015 7:56:15 AM

Event ID:      5719

Task Category: None

Level:         Error

Keywords:      Classic

User:          N/A

Computer:      COMPUTER.domain.local

Description:

This computer was not able to set up a secure session with a domain controller in domain DOMAIN due to the following: 

There are currently no logon servers available to service the logon request. 

This may lead to authentication problems. Make sure that this computer is connected to the network. If the problem persists, please contact your domain administrator.  

Log Name:      System

Source:        Microsoft-Windows-Security-Kerberos

Date:          23/10/2015 4:02:46 PM

Event ID:      4

Task Category: None

Level:         Error

Keywords:      Classic

User:          N/A

Computer:      COMPUTER.domain.local

Description:

The Kerberos client received a KRB_AP_ERR_MODIFIED error from the server candc1$. The target name used was cifs/domain.local. This indicates that the target server failed to decrypt the ticket provided by the client. This can occur when the target server principal name (SPN) is registered on an account other than the account the target service is using. Please ensure that the target SPN is registered on, and only registered on, the account used by the server. This error can also happen when the target service is using a different password for the target service account than what the Kerberos Key Distribution Center (KDC) has for the target service account. Please ensure that the service on the server and the KDC are both updated to use the current password. If the server name is not fully qualified, and the target domain (DOMAIN.LOCAL) is different from the client domain (DOMAIN.LOCAL), check if there are identically named server accounts in these two domains, or use the fully-qualified name to identify the server.

Log Name:      System

Source:        Microsoft-Windows-GroupPolicy

Date:          28/10/2015 6:18:58 PM

Event ID:      1006

Task Category: None

Level:         Error

Keywords:      

User:          DOMAIN\UserAccount

Computer:      COMPUTER.domain.local

Description:

The processing of Group Policy failed. Windows could not authenticate to the Active Directory service on a domain controller. (LDAP Bind function call failed). Look in the details tab for error code and description.

Some computers were also receiving:

The processing of Group Policy failed. Windows attempted to read the file \\domain.local\sysvol\domain.local\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}\gpt.ini from a domain controller and was not successful. Group Policy settings may not be applied until this event is resolved. This issue may be transient and could be caused by one or more of the following: 

a) Name Resolution/Network Connectivity to the current domain controller. 

b) File Replication Service Latency (a file created on another domain controller has not replicated to the current domain controller). 

c) The Distributed File System (DFS) client has been disabled.

This GUID referenced the Default Domain Policy (the first policy in the domain).  There was nothing wrong with the Default Domain Policy on the customers network, policy was simply not applying to domain members due an issue in Active Directory.

One issue which I focused on was the Kerberos error "KRB_AP_ERR_MODIFIED".  I have seen this issue before when the same SPN was registered on at least two accounts. For example, a SPN was registered on two accounts: A and B. What happens is that KDC will generate a service ticket that may be encrypted with password of account A. Then, when the client sends that ticket to the service during authentication, the service may try to decrypt this using account B.

I searched the customers domain for duplicated SPN's using "setspn.exe -X" and found some however they were not related to the error received.  Also I have never seen the "KRB_AP_ERR_MODIFIED" error generated on EVERY domain member workstation/server in an Active Directory environment.

Looking further into the SPN's we decided to dump the entire domain with every object/attribute to a text file using:

ldifde -f out.txt -d dc=domain,dc=local

Generally SPN against a user account reference a member server on the network running a particular service account such as SQL  However as this issue was affecting the entire domain and KRB_AP_ERR_MODIFIED refers to duplicated SPN records, we looked to see if there were any SPNs set at domain level on an account by searching our output from ldifde for "host/domain.local".

We found an SPN set to the root of the domain from the search results.  Important content from output below is blurred to protect the privacy of the customer.

We went and removed the incorrectly setup SPN record from the problematic service account svc_adfs using Active Directory Users and Computers with Advanced Features turned on then forced replication with "repadmin /syncall /APeD".

After removing the incorrectly configured SPN, we purged the kerberos tickets off a workstation then attempted to start explorer at the root of the domain "\\domain.local".  We were able to navigate to this share successfully.

The issues with network drives not mapping on logon were also resolved.

The SVC_ADFS account was created as part of an AD FS deployment for federation with applications and Microsoft Cloud Services.  AD FS backend roll was installed on two corporate domain controllers and two proxy servers were deployed in a DMZ setup to process the authentication requests from external services.  This is the Microsoft Best Practice for corporate organisations under 1000 seats as it reduces the amount of servers required and provides high redundancy by leveraging NLB on both the backend and frontend AD FS servers as per:

https://msdn.microsoft.com/en-us/library/azure/dn151324.aspx

I went over the engineers build documentation who was in charge of implementing AD FS and could not see how the SPN was set, he did not manually set it.

Hope this post helps someone who experiences this same issue.

Howto Decrypting an Active Directory Password

In this post I will show a tool which makes decrypting Active Directory passwords easy.  It is important to note decrypting highly secure passwords takes a long time and is not always achievable within a reasonable period of time based on the complexity of the password however I have had success recently using this product.

Find a Windows Computer where the user has logged into recently and has their password cached.  Next obtain the Network Password Recovery Wizard (NPRW) tool from:

http://www.passcape.com/network_password_recovery

After the tool simply use the GUI for performing the password encryption.  I found this video very helpful.

http://www.passcape.com/download/swf/nprw-domain-cached-passwords.swf

How to Remove SID History from Active Directory Object

In this blog post I'm going to show you how to remove the SIDHistory from an object in Active Directory after a domain migration.  If you attempt to use standard Microsoft tools such as ADSIEdit to remove the SIDHistory from an object regardless what access rights you have been assigned, the following error will be presented.

Operation failed.  Error code: 0x5
Access is denied

00000005: SecErr: DSID-031A1256, problem 4003
(INSUFF_ACCESS_RIGHTS), data 0



To remove SIDHistory from an object you need to use the following VBScript from Microsoft KB295758.

http://support.microsoft.com/en-us/kb/295758

Simply copy and paste the script into a notepad document then run the script with the following arguments to remove the SIDHistory entries from the object in question.

 

Test Application for Group Policy Software Installation Troubleshooting

Sometimes when diagnosing problems with Group Policy software deployment, it is good to try a different application to rule out issues with the application package your trying to deploy.  One application package I have found which is great for testing Group Policy software deployment is "RealWorld Paint".  This is a lightweight MSI installer (8.7 MB) in size and deploys easy through Group Policy to Windows XP, Windows 7 and Windows 8.1 machines.

You can download this MSI installer from the following location:

http://download.rw-designer.com/2013.1/RWPaint32.msi

If you have issues deploying this with Group Policy, then the issue does not lay with the MSI package your trying to deploy but something else!

Also check out this common issue with Group Policy application deployment, it may be of help in diagnosing your Group Policy deployment issue:

http://clintboessen.blogspot.com.au/2013/01/group-policy-software-installation-not.html

Problems When Upgrading your domain and forest functional level from 2003 to 2008 R2

A customer of mine upgraded their Domain Functional Level (DFL) and Forest Functional Level (FFL) to Windows Server 2008 R2 yesterday.  Today when employees started work, they experienced lengthy login times, did not receive their network drive mapping to the file server and were unable to connect to Exchange Server 2010 with Microsoft Outlook 2010.

The first thing I did was have a look at the Active Directory replication after the functional level upgrade using the following command "repadmin /showrepl" on one of the Active Directory domain controllers.  This showed the following error:

Last error: -2146892990 (0x80090342)
The encryption type requested is not supported by the KDC

 

In 2003 functional level the Kerberos Key Distribution Centre (KDC) used either RC4-HMAC 128-bit or DES-CBC-MD5 56-bit for Kerberos Encryption however when moving to 2008 Domain Functional Level (or higher) you upgrade the Key Distribution Centre (KDC) to use Advanced Kerberos Encryption which uses AES 128 and AES 256 encryption.

 

Generally this transition is smooth and does not cause problems however in this instance the KDC did not detect the functional level change and continued to operate using the legacy 2003 functional level encryption technology.  As a result the error "The encryption type required is not supported by the KDC".

 

To resolve this problem was very simple, we simply restarted the Kerberos Key Distribution Centre on all of the Active Directory domain controllers in the domain.

 

 

Within 5 minutes of the service restart, things were back to normal.

Powershell Find and Replace the Remote Desktop Services Profile

A customer of mine has configured all roaming user profiles on a Remote Desktop Services environment through the user account in Active Directory instead of utilising Group Policy setting "Set roaming profile path for all users logging onto this computer", the Microsoft preferred method as it ensures each profile folder matches the username and prevents inconsistencies which may encore as a result of an administrator incorrectly naming a folder.  It is recommended all Remote Desktop Services environments utilise Group Policy as a means of setting roaming profile and not the Active Directory user accounts.

I am in the process of implementing a new file server into the customers environment and updating the Remote Desktop Services profiles to point to the new file server.  My customer has the remote desktop services profile specified on each user account and there are inconsistencies as to how the profile is named, it does not always match username!  As a result we are not able to simply move to Group Policy roaming profile mapping moving forward.

I need a way of performing a find and replace to update the Remote Desktop Services User Profile path to match the new file server.  I achieved this by writing a PowerShell script to perform this task which I would like to share with you - here is a copy of my code:

$erroractionpreference = “stop"

 

$pDirValueOld = "\\oldserver\rdsprofiles"

$pDirValueNew = "\\newserver\rdsprofiles"

 

$profilepath = $null

 

$searcher = New-Object adsisearcher

$searcher.Filter = "(&(objectCategory=person)(objectClass=user))"

$searcher.SearchRoot = "LDAP://OU=Users,OU=Avantgarde Technologies,OU=Companies,OU=Active Directory,DC=at,DC=local"

$searcher.PageSize = 1000

$results = $searcher.FindAll()

 

 

foreach($result in $results)

{

$ADuser = [adsi]$result.Path

        foreach($user in $ADuser)

        {

        echo $user.distinguishedName

        $profilepath = $null

        $profilepath = $user.psbase.InvokeGet(“TerminalServicesProfilePath") -replace [regex]::Escape($pDirValueOld),($pDirValueNew)

        $user.psbase.InvokeSet(“TerminalServicesProfilePath",$profilepath)

        $user.setinfo()

        }

}  

To utilise this code you want to modify the following values:

$pDirValueOld = "\\oldfileserver\share"

$pDirValueNew = \\newfileserver\share

$searcher.SearchRoot = "LDAP://OU=Users,OU=Avantgarde Technologies,OU=Companies,OU=Active Directory,DC=at,DC=local

• pDirValueOld is the value you want to search for to be replaced.
• pDirValueNew is the value you wish to set the profile to.
• $searcher.SearchRoot is the LDAP path in Active Directory you wish to run this query recursively against.

Now I have a bunch of users in the Avantgarde Technologies --> Users OU which need to be updated.  As you see I have my Remote Desktop Services profile populated below:

 

I put the code into my PowerShell ISE development environment (as an alternative from saving it as a .ps1 script).  Then I made sure the following fields were populated correctly.

 

 

Run the code and all users recursively will have the Remote Desktop Services profile updated to point to the new path through a find and replace!

 

We can see the profile was successfully updated.

 

 

You can also modify my above code to perform a fine and replace on other items in the user account!

Hope you have found this post helpful!