Jorge's Quest For Knowledge!

All About Identity And Security On-Premises And In The Cloud – It's Just Like An Addiction, The More You Have, The More You Want To Have!

Archive for the ‘Windows Client’ Category

(2019-08-01) Moving Towards The Password-Less Concept – One Heck Of Journey And Badly Needed

Posted by Jorge on 2019-08-01


Current passwords are potentially weak and any use of those in general further weakens an infrastructure. Preferably any org needs to move away from using passwords as much as possible. This means for example preventing the usage of passwords, and instead use SSO and/or other more secure authentication mechanisms. In other words, the adoption of the "Password-Less" concept. However, for those scenarios that cannot adopt “Password-Less" (yet), passwords must be strengthened or better secured at rest and in transport. In today’s world “identity” is the key control plane. Therefore protecting the “identity” and everything related is of utmost importance. Usage of weak passwords presents unacceptable security risks to any org. We all know that, don’t we?! Now you need to act to secure yourself as best as possible.

Going password-less is a journey on its own and implementing that concept could mean for example (NOT an exhaustive list and also in random order!):

  • Ban “weak/common” words from being used in weak passwords using Azure AD Password Protection and/or LithNet Password Protection For Active Directory (LPP) (last one is free and the feature set is huge!)
  • Check AD for weak passwords and weak accounts configurations and follow up with risk mitigating actions. Can be done through LPP and DS Internals and generic LDAP queries
  • Help and educate users in terms of using, storing, generating, uniqueness, sharing/distributing, etc. for less frequent (complex and long) and regular used (pass phrases) passwords. Preferably use machine generated passwords as those have no human logic in them, or use (long) passphrases or bang your head against the keyboard multiple times while on and off holding the SHIFT key (last one, kidding!) (people tend to implement logic or sequences somehow in passwords to not forget those long passwords and to make them unique)
  • Move service accounts in AD from regular service accounts to:
    • Group Managed Service Accounts if possible
    • …and if that’s not possible have a password vault store, manage and change passwords on a regular basis
    • …and if that’s not possible keep using regular service accounts with long and unique passwords
  • If possible, increase the password length to a minimum of 15 characters for users
  • Move away from periodic password changes to risk based password changes (e.g. through Azure AD Identity Protection)
  • Using strong and unique passwords for every individual system/site not supporting SSO (the strength of a password is mostly determined by its length, the longer the better!);
  • Securely store passwords in an MFA enabled password manager/vault that is available on both your desktop and mobile device(s)
  • Make Self-Service Password Reset available to users for those occasions where the password is needed but the user has forgotten the password or has locked itself out
  • When using ADFS, implement extranet lockout policy
  • Only use HTTPS connections (at least TLS1.2) in your environment and do not use HTTP
  • Update systems, tools, scripts to NOT set weak/generic/well-known password or account configurations (e.g. LM Hashes, Password Not Required, Password Never Expires, etc)
  • Decrease the use of passwords as much as possible by:
    • Implementing SSO
    • Implement password-less authN for Windows computers (e.g. Windows Hello for Business) and remove password based authN if possible
    • Implement password-less authN for mobile devices (e.g. Azure AD MFA + AuthNtor App Notifications And OTPs) as primary authN, preferably with at least 2 factors during that primary authN, or implement password authN as secondary authN (when using ADFS)

Additional Resources:

Hope this helps you!

Cheers,

Jorge

————————————————————————————————————————————————————-
This posting is provided "AS IS" with no warranties and confers no rights!
Always evaluate/test everything yourself first before using/implementing this in production!
This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years!
DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
————————————————————————————————————————————————————-
########################### Jorge’s Quest For Knowledge ##########################
####################
http://JorgeQuestForKnowledge.wordpress.com/ ###################
————————————————————————————————————————————————————-

Advertisements

Posted in Active Directory Domain Services (ADDS), Active Directory Federation Services (ADFS), Azure AD MFA Adapter, Azure AD Password Protection, Kerberos AuthN, Microsoft Authenticator App, Multi-Factor AuthN, NTLM AuthN, Password-Less, Security, Self-Service Password Reset, SSO, WH4B, Windows Azure Active Directory, Windows Client, Windows Integrated AuthN | Leave a Comment »

(2019-05-28) Windows Hello For Business – Certificate Template For DCs

Posted by Jorge on 2019-05-28


When implementing Windows Hello for Business, either using the “Hybrid AAD Joined Certificate Trust” method or the “Hybrid AAD Joined Key Trust” a PKI infrastructure is needed to at least implement a certificate template for DCs to support WH4B. When already having a (Microsoft) PKI infrastructure you may already have a certificate template for DCs that may have a provider and algorithm (Cryptography TAB) configured as or similar to as displayed below.

clip_image002

Figure 1: Existing Cryptography Settings In Legacy DC Certificate Template

When deploying WH4B, the following cryptography settings are required. You will only be able to configure this when in the compatibility TAB the certification authority is set to at least Windows Server 2012.

 clip_image004

Figure 2: Cryptography Settings In New DC Certificate Template Required By WH4B

Now a question may be: what is the impact on DCs when configuring a new certificate template and deploying that to the DCs to replace the existing certificate template?

A good question, might I say!

Important to note is that autoenrollment is configured and it is configured correctly, for this to succeed, then at least following high-lighted settings must be set and targeted against DCs in AD. See below.

You may also want to read: Troubleshooting Autoenrollment and Configuring Autoenrollment

image

Figure 3: Autoenrollment Settings

In addition, make sure to supersede the old certificate templates in the newest certificate template, as displayed below.

With regards to PKI, the WH4B documentation says the following:

By default, the Active Directory Certificate Authority provides and publishes the Kerberos Authentication certificate template. However, the cryptography configuration included in the provided template is based on older and less performant cryptography APIs. To ensure domain controllers request the proper certificate with the best available cryptography, use the Kerberos Authentication certificate template a baseline to create an updated domain controller certificate template

image

Figure 4: Superseded Settings

From what I have understood, it changes the storage provider from CSP to KSP and it keeps the RSA algorithm. After doing this myself in multiple environments and asking around for experiences, the answer to the “impact” question is:

No negative impact anticipated or experienced

Nevertheless, make sure to test in your representative test environment!

Enjoy and have fun!,

Jorge

————————————————————————————————————————————————————-
This posting is provided "AS IS" with no warranties and confers no rights!
Always evaluate/test everything yourself first before using/implementing this in production!
This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years!
DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
————————————————————————————————————————————————————-
########################### Jorge’s Quest For Knowledge ##########################
####################
http://JorgeQuestForKnowledge.wordpress.com/ ###################
————————————————————————————————————————————————————-

Posted in Active Directory Certificate Services (ADCS), Active Directory Domain Services (ADDS), Certificate Templates, Certificates, WH4B, Windows Client | Leave a Comment »

(2019-05-25) Windows Hello For Business (WH4B) Bootstrapping

Posted by Jorge on 2019-05-25


A few months ago I configured and implemented Windows Hello For Business (WH4B) using the “Hybrid AAD Joined Certificate Trust”. I chose this method over the “Hybrid AAD Joined Key Trust” because we did not have W2K16 DCs yet and we did have an ADFS deployment. This choice was really easy due to the lack of W2K16 DCs, otherwise we most likely would have chosen “Hybrid AAD Joined Key Trust” over “Hybrid AAD Joined Certificate Trust”.

Before going all crazy, we decided to start easy and implement it on a very limited scale scoped to specific Windows 10 computers and specific users. We created a small list of users (less than 10) and that list contained users logging on through username and password and users logging on through smartcard and pin.

To be able to implement this, we had to satisfy the following prerequisites:

  • AAD subscription
  • AD
    • W2K8R2 DCs or higher (+DFL/FFL)
    • W2K16 AD schema
    • Configuration to support Hybrid Azure AD Domain Join
    • Security group to scope computers and permission computer based GPO
    • Security group to scope usersand permission user based GPO

  • PKI infrastructure running on W2K12 or higher as trust anchor
    • Certificate Template to issue Kerberos AuthN certificate for DCs through auto enrolment (and therefore correct permissioning!)
    • Certificate Template to issue Registration Authority certificate for ADFS through auto enrolment (and therefore correct permissioning!)
    • Certificate Template to issue WH4B AuthN certificate for clients by ADFS through auto enrolment  (and therefore correct permissioning!)
    • DCs need certificate to be trusted by clients
    • Users need authentication certificates distributed through ADFS registration authority (RA)
    • Certificate Templates need to be configured with at least W2K12 or higher certificate authority support to be able to configure the correct provider and algorithm in the cryptography TAB

  • AAD Connect, no DirSync and no AAD Sync
    • Configuration to support Hybrid Azure AD Domain Join
    • Device writeback
      • To writeback the values in "msDS-KeyCredentialLink" on AD user account, RP/WP permissions are needed on that attribute. That can be done in a custom manner like assigning a custom group those permissions whereas that custom group may already have other permissions to read/write, or the AD connector account is added to the "KeyAdmins" group in AD

  • ADFS
    • Configuration to support Hybrid Azure AD Domain Join
    • ADFS 2016 or higher as a registration authority
    • Device authentication enabled at global level
    • Configured as registration authority with the correct certificate templates for RA and WH4B

  • Enrolment through username/password AND some form of MFA (AAD MFA Cloud, ADFS with AAD MFA Cloud/On-prem, ADFS with 3rd party MFA, etc)
  • Windows 10 v1703 or higher
  • Win10 Devices joined to AD and AAD, a.k.a. Hybrid Azure AD Domain Joined

While everything was in place, we were good to go!

Users logging on with username and password should see the following screen:

image

Figure 1: Windows Hello For Business Initial Provisioning Screen After Logging On With Username And Password

Users logging on with smartcard and pin should also see the same screen right after logging on, but they did not. Damn!

Let the troubleshooting begin! Smile

After provisioning, looking at the PRTs through DSREGCMD /STATUS

SNAGHTML4235b5

Figure 2: SSO State: Azure AD PRT = YES And EnterprisePRT (ADFS PRT) = NO

image

Figure 3: NGC Prerequisite Check: No ADFS Refresh Token

OK, it is clear there is no ADFS PRT, which IS a requirement for WH4B, hence why it fails

On the client in the “Applications And Services Log\Microsoft\Windows\AAD\Operation” Event Log you may notice the following error or similar with some correlation ID. Save the correlation ID somewhere as you will need that later!

image

Figure 4: Client Side: Error In The “Applications And Services Log\Microsoft\Windows\AAD\Operation” Event Log

Http request status: 401. Method: POST Endpoint Uri: https://fs.iamtec.nl/adfs/oauth2/token/ Correlation ID: A9820E01-5D3A-4138-BCFF-72B454B67F1B

On the client in the “Applications And Services Log\Microsoft\Windows\AAD\Operation” Event Log you may notice the following error or similar with no correlation ID and a small hint of where things might be wrong. Nevertheless, still not clear enough!

image

Figure 5: Client Side: Error In The “Applications And Services Log\Microsoft\Windows\AAD\Operation” Event Log

OAuth response error: interaction_required
Error description: MSIS9699: GlobalAuthenticationPolicy on the Server doesn’t allow this OAuth JWT Bearer request. Please contact the administrator to update the GlobalAuthenticationPolicy.
CorrelationID:

On the client in the “Applications And Services Log\Microsoft\Windows\AAD\Operation” Event Log you may notice the following error or similar with some correlation ID. If you look carefully, you will see it is the same correlation ID and in figure 4. Save the correlation ID somewhere as you will need that later, if you have not done that already!

image

Figure 6: Client Side: Error In The “Applications And Services Log\Microsoft\Windows\AAD\Operation” Event Log

Enterprise STS Logon failure. Status: 0xC0000250 Correlation ID: A9820E01-5D3A-4138-BCFF-72B454B67F1B

In your face, no WH4B for you as authN against ADFS failed for some reason!

image

Figure 7: Client Side: Error In The “Applications And Services Log\Microsoft\Windows\User Device Registration\Admin” Event Log

Windows Hello for Business provisioning will not be launched.
Device is AAD joined ( AADJ or DJ++ ): Yes
User has logged on with AAD credentials: Yes
Windows Hello for Business policy is enabled: Yes
Windows Hello for Business post-logon provisioning is enabled: Yes
Local computer meets Windows hello for business hardware requirements: Yes
User is not connected to the machine via Remote Desktop: Yes
User certificate for on premise auth policy is enabled: Yes
Enterprise user logon certificate enrollment endpoint is ready: Yes
Enterprise user logon certificate template is : Yes
User has successfully authenticated to the enterprise STS: No
Certificate enrollment method: enrollment authority
See
https://go.microsoft.com/fwlink/?linkid=832647 for more details.

On the ADFS server you will most likely find events similar to the ones below. Look at the event with the same correlation ID. If you have multiple ADFS servers, either check all ADFS servers for events with the same correlation ID, or check some central SIEM solution, or use PowerShell to query all ADFS servers, or configure your client to point to one specific ADFS server by temporarily configuring the HOSTS file.

image

Figure 8: ADFS Server Side: Errors In The “Applications And Services Log\AD FS\Admin” Event Log

And there is the reason! Certificate Authentication is NOT enabled on the intranet for primary authN! What the heck. Did not expect this one. I would expect that Windows Authentication on the intranet as primary authN would be enough for this to work, Apparently it explicitly needs the authN method to be enabled that is being used at logon.

image

Figure 9: ADFS Server Side: Error In The “Applications And Services Log\AD FS\Admin” Event Log

Encountered error during OAuth token request.

Additional Data

Exception details:
Microsoft.IdentityServer.Web.Protocols.OAuth.Exceptions.OAuthInteractionRequiredException: MSIS9462: Interaction is required by the token broker to resolve the issue. Enable CertificateAuthentication in the Global Policy.
   at Microsoft.IdentityServer.Web.Protocols.OAuth.OAuthToken.OAuthJWTBearerRequestContext.ValidateAuthPolicy()
   at Microsoft.IdentityServer.Web.Protocols.OAuth.OAuthToken.OAuthJWTBearerRequestContext.ValidateJWTBearer()
   at Microsoft.IdentityServer.Web.Protocols.OAuth.OAuthToken.OAuthJWTBearerRequestContext.ValidateCore()

And there is the reason again! Certificate Authentication is NOT enabled on the intranet for primary authN!

image

Figure 10: ADFS Server Side: Error In The “Applications And Services Log\AD FS\Admin” Event Log

Encountered error during OAuth token request.

Additional Data

Exception details:
Microsoft.IdentityServer.Web.Protocols.OAuth.Exceptions.OAuthInteractionRequiredException: MSIS9462: Interaction is required by the token broker to resolve the issue. Enable CertificateAuthentication in the Global Policy.
   at Microsoft.IdentityServer.Web.Protocols.OAuth.OAuthToken.OAuthJWTBearerRequestContext.ValidateAuthPolicy()
   at Microsoft.IdentityServer.Web.Protocols.OAuth.OAuthToken.OAuthJWTBearerRequestContext.ValidateJWTBearer()
   at Microsoft.IdentityServer.Web.Protocols.OAuth.OAuthToken.OAuthJWTBearerRequestContext.ValidateCore()
   at Microsoft.IdentityServer.Web.Protocols.ProtocolContext.Validate()
   at Microsoft.IdentityServer.Web.Protocols.OAuth.OAuthToken.OAuthTokenProtocolHandler.ProcessJWTBearerRequest(OAuthJWTBearerRequestContext jwtBearerContext)

It will not get more explicit than this! If all error were like this!

In this case when logging on with smartcard and pin and to be able to start WH4B provisioning, Certificate Based Authentication needs to be enabled at the INTRANET level in ADFS.

For that you can use the following PowerShell commands:

Get-AdfsGlobalAuthenticationPolicy
$currentListOfProvidersForPrimaryAuthNForIntranet = (Get-AdfsGlobalAuthenticationPolicy).PrimaryIntranetAuthenticationProvider
If ($currentListOfProvidersForPrimaryAuthNForIntranet -notcontains "CertificateAuthentication") {
    $newListOfProvidersForPrimaryAuthNForIntranet = $currentListOfProvidersForPrimaryAuthNForIntranet + "CertificateAuthentication"
    Set-AdfsGlobalAuthenticationPolicy -PrimaryIntranetAuthenticationProvider $newListOfProvidersForPrimaryAuthNForIntranet
}
Get-AdfsGlobalAuthenticationPolicy

image

Figure 11: Configuring The ADFS Global Authentication Policy – Providers For Primary Authentication For The Intranet

Now logging off and logging back on again, you should see the following screen:

image

Figure 12: Windows Hello For Business Initial Provisioning Screen After Logging On With Smartcard And PIN

PS: Look for differences when a user logs on with username and password!

After provisioning, looking at the PRTs through DSREGCMD /STATUS

image

Figure 13: SSO State: Azure AD PRT = YES And EnterprisePRT (ADFS PRT) = YES

image

Figure 14: NGC Prerequisite Check: No ADFS Refresh Token

At PRT level, everything is looking good now!

Enjoy and have fun!,

Jorge

————————————————————————————————————————————————————-
This posting is provided "AS IS" with no warranties and confers no rights!
Always evaluate/test everything yourself first before using/implementing this in production!
This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years!
DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
————————————————————————————————————————————————————-
########################### Jorge’s Quest For Knowledge ##########################
####################
http://JorgeQuestForKnowledge.wordpress.com/ ###################
————————————————————————————————————————————————————-

Posted in Active Directory Federation Services (ADFS), Certificate Based AuthN, WH4B, Windows Client | Leave a Comment »

(2018-10-22) Cloning Windows 10 Or Windows Server 2016 May Break Hybrid Azure AD Domain Join

Posted by Jorge on 2018-10-22


When cloning Windows computers you are basically copying everything from some source computer to one or more target computers. One of the benefits is the speed in deployment and the time you same to have to configure stuff every single time. Are there downsides? Yes, there are, at least if you do not take some risk mitigating measures. One of those is the SID of the local computer. Every time you deploy a cloned version of Windows you MUST execute SYSPREP to make the clone gets its own unique SID. If you don’t at the beginning and along the way things may appear to be correct. However, at some point in time you may find yourself with a huge headache trying to understand why something does not work or shows weird behavior.

Recently I found another downside of cloning, that in the end can be mitigated with some post-deployment actions.

For more info about Hybrid Azure AD Domain Join (HAADJ) please also have a look at

I was trying to Hybrid Azure AD Domain Join (HAADJ) a AD domain joined Windows Server 2016 by logging on and waiting for the scheduled task to kick in and checking the correct Event Logs, and later on under the context of “NT AUTHORITY\SYSTEM” by running DSREGCMD.EXE /DEBUG. When running that last command I kept seeing the following error at the end:

DsrDeviceAutoJoinFederated failed with -2146893802
wmain: failed with error code 0x80090016.

After some troubleshooting I discovered that Windows was a cloned deployment. One of the thing that is also cloned is the key material. The key material is in the folder “C:\ProgramData\Microsoft\Crypto\Keys” to “C:\ProgramData\Microsoft\Crypto\Keys”. The solution therefore is to get rid of the old key material and start fresh from the beginning. You can do that by running the following PowerShell commands:

# Rename The “Keys” Folder To “KeysOLD”

Rename-Item -Path "C:\ProgramData\Microsoft\Crypto\Keys" -NewName "KeysOLD"

# Create A New “Keys” Folder

New-Item -Path "C:\ProgramData\Microsoft\Crypto\Keys" -ItemType Directory

# Copy The ACL From The “KeysOLD” Folder To The New “Keys” Folder

Get-Acl -Path "C:\ProgramData\Microsoft\Crypto\KeysOLD" | Set-Acl -Path "C:\ProgramData\Microsoft\Crypto\Keys"

Now retry HAADJ by rebooting the Windows computers and logging on, or executing DSREGCMD.EXE /DEBUG under the context of  “NT AUTHORITY\SYSTEM”. It should work now!

REMARK: If you did not know it yet, you can get into the context of “NT AUTHORITY\SYSTEM” by using PSEXEC and running the following command: PSEXEC –i –s CMD.EXE

Cheers,
Jorge

————————————————————————————————————————————————————-
This posting is provided "AS IS" with no warranties and confers no rights!
Always evaluate/test everything yourself first before using/implementing this in production!
This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years!
DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
————————————————————————————————————————————————————-
########################### Jorge’s Quest For Knowledge ##########################
####################
http://JorgeQuestForKnowledge.wordpress.com/ ###################
————————————————————————————————————————————————————-

Posted in Azure AD Join, Windows Azure Active Directory, Windows Client, Windows Server | 3 Comments »

(2018-10-21) Grant, Revoke Or Get DCOM Permissions Using PowerShell

Posted by Jorge on 2018-10-21


Have you ever needed to script granting or revoking DCOM Permissins, or maybe just retrieving DCOM Permissions? If the answer is “Yes”, then look no further! It is a pitty there is no native PowerShell way to manage stuff like this. But, it is a good thing there are MVPs like Tony who has created a PowerShell module that does some interesting things around DCOM Permissions on Windows systems. All credits for this PowerShell module of course go to Tony as he build and owns it.

The PowerShell Module to manage DCOM Permissions can be downloaded from here.

Benefits:

  • No dependency on external files
  • Can change permissions on DCOM objects where Administrator doesn’t have access
  • Does not remove callback permissions (Using the Component Services GUI often does)
  • Doesn’t write temporary files during operation
  • Pure PowerShell implementation
  • Fully documented and self contained
  • No code hidden in DLL files or other compiled libraries; fully transparent

Requirements:

  • PowerShell 4.0
  • Elevated administrative rights on local computer
  • Tested on Windows 10, Server 2012 R2, Server 2016

Available Cmdlets:

  • Get-DCOMPermission
  • Grant-DCOMPermission
  • Revoke-DCOMPermission 

Cheers,
Jorge

————————————————————————————————————————————————————-
This posting is provided "AS IS" with no warranties and confers no rights!
Always evaluate/test everything yourself first before using/implementing this in production!
This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years!
DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
————————————————————————————————————————————————————-
########################### Jorge’s Quest For Knowledge ##########################
####################
http://JorgeQuestForKnowledge.wordpress.com/ ###################
————————————————————————————————————————————————————-

Posted in Windows Client, Windows Server | Leave a Comment »

(2018-10-20) Grant, Revoke Or Query For User Rights (Privileges) Using PowerShell

Posted by Jorge on 2018-10-20


Have you ever needed to script granting or revoking user rights, or maybe just querying for user rights? If the answer is “Yes”, most likely you have had to use NTRIGHTS from the good old Windows Server 2003 Resource Kit or do some funky magic around SECEDIT. It is a pitty there is no native PowerShell way to manage stuff like this. But, it is a good thing there are MVPs like Tony who has created a PowerShell module that does some interesting things around user rights locally and remotely on Windows systems. All credits for this PowerShell module of course go to Tony as he build and owns it.

The PowerShell Module to manage user rights can be downloaded from here.

Benefits:

  • No dependency on external files
  • Can modify any user right; is not limited to "Logon as a Service"
  • Can add/remove rights from the current process token
  • Doesn’t write temporary files during operation
  • Fully pipeline-able
  • Pure PowerShell implementation
  • Supports changing user rights on remote machines
  • Fully documented and self contained
  • No code hidden in DLL files or other compiled libraries; fully transparent

Requirements:

  • PowerShell 3.0
  • Administrative rights on target computer, or elevation on local computer
  • Tested on Windows 10, Server 2012 R2, Server 2016, Server Core 1709

Available Cmdlets:

  • Grant-UserRight
  • Revoke-UserRight
  • Get-UserRightsGrantedToAccount
  • Get-AccountsWithUserRight
  • Grant-TokenPrivilege
  • Revoke-TokenPrivilege

 

Cheers,
Jorge

————————————————————————————————————————————————————-
This posting is provided "AS IS" with no warranties and confers no rights!
Always evaluate/test everything yourself first before using/implementing this in production!
This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years!
DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
————————————————————————————————————————————————————-
########################### Jorge’s Quest For Knowledge ##########################
####################
http://JorgeQuestForKnowledge.wordpress.com/ ###################
————————————————————————————————————————————————————-

Posted in User Rights, User Rights, Windows Client, Windows Server | Leave a Comment »

(2014-02-07) Windows 8.1 Does Not Have Network Connectivity In VMware Workstation After Installation

Posted by Jorge on 2014-02-07


Today I was installing Windows 8.1 Pro in my test environment, which runs on VMware Workstation v9.x. The installation of Windows 8.1 Pro went quite smooth. However, right after the installation, to my surprise I did not have any network connectivity as you can see in figure 1.

image

Figure 1: No Network Connectivity In A Windows 8.1 Pro VM Running On VMware Workstation

I have installed WXP, W2K3(R2), WVT, Win7, W2K8(R2), Win8 and W2K12(R2) and none showed similar behavior. I have to admit I did not have the VMware Tools installed. However, after installing the VMware Tools I still did not have network connectivity. That’s weird. It has been years ago I had issues with VMware Workstation in combination with Windows.

You can read more about those issues in the following blog posts:

So, now back to this new issue…. Some details first. I installed this Windows 8.1 Pro VM:

  • In VMware Workstation v9.0.3 (It might occur in other version too!)
  • With VMware Workstation v8.x compatible hardware
  • I configured the guest VM as "Microsoft Windows 8" (REMARK: Only VMware Workstation v10.x officially support Windows 8.1 and Windows Server 2012 R2)

After installing the VMware Tools, the VM still did not have any network connectivity. Damn!

After comparing the VMX file (the file containing the VM config) one thing caught my attention when I compared it with another, but working, VM. See figure 2 below

image

Figure 2: No Network Connectivity In A Windows 8.1 Pro VM Running On VMware Workstation

For whatever reason the VMX file of the Windows 8.1 Pro VM was missing the following two lines (also highlighted in figure 2):

  • ethernet0.connectionType = "bridged"
  • ethernet0.virtualDev = "e1000"

Now the solution? Make sure the VM is shutdown, and not in a saved/resumed stated. Close VMware Workstation, edit the VMX file and add the two lines, if they are missing somehow. Save and close the VMX file. Open the Windows 8.1 VM again and start it up. Voila!

The result of these actions can be seen in figure 3 below

image

Figure 3: Network Connectivity Restored In The Windows 8.1 Pro VM Running On VMware Workstation

Awayyyyyy Silver! Smile

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
#########
http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

Posted in Virtualization, Windows Client | Leave a Comment »

(2013-10-20) Remote Server Administration Tools (RSAT) For Windows 8.1 x86/x64

Posted by Jorge on 2013-10-20


Remote Server Administration Tools for Windows 8.1 includes Server Manager, Microsoft Management Console (MMC) snap-ins, consoles, Windows PowerShell cmdlets and providers, and command-line tools for managing roles and features that run on Windows Server 2012 and Windows Server 2012 R2. In limited cases, the tools can be used to manage roles and features that are running on Windows Server 2008 R2 or Windows Server 2008. Some of the tools work for managing roles and features on Windows Server 2003.

The following tools can be used to manage roles and features that are running on Windows Server 2012 R2, but are not supported for managing roles and features on Windows Server 2012:

  • IP Address Management console
  • Hyper-V tools: Although you are not blocked from using Hyper-V cmdlets for Windows PowerShell in this release of Remote Server Administration Tools to manage Hyper-V running on Windows Server 2012, this scenario is not officially supported. Managing Hyper-V on Windows Server 2012 by using GUI-based tools in this download is supported.

For more details and to download the tools, follow this link.

To manage server roles and features remotely on Windows Client 8.1 you need to download and install the Remote Server Administration Tools. After installing the binaries for RSAT you need to enable the tools you want to use through "Program and Features" in the Control Panel.

image

Figure 1: Default Configuration Of RSAT Right After Installation

PS: wouldn’t it be very interesting if an RSAT version was made available for Windows RT (Surface)?

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
#########
http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

Posted in Remote Server Administration Tools, Windows Client | Leave a Comment »

(2013-09-11) Follow-Up On “AD DB Becomes Corrupted When W2K12 Hyper-V Host Server Crashes”

Posted by Jorge on 2013-09-11


The guys from the AskPFE Team Blog have written a great follow-up article about the corruption of Active Directory databases in virtualized domain controllers running on Windows Server 2012 Hyper-V host computers. Kudos and credits of course go to the writer of the post on the AskPFE Team Blog. BE AWARE THAT THIS NOW ALSO APPLIES TO W2K8R2 HYPER-V HOSTS AND OTHER HYPER-V GUEST!

SOURCE: Clarifications on KB 2853952, Server 2012 and Active Directory error c00002e2 or c00002e3

<QUOTE SOURCE=”Clarifications on KB 2853952, Server 2012 and Active Directory error c00002e2 or c00002e3”>

Hey y’all, Mark and Tom here to clear up some confusion on MSKB 2853952, that describes the corruption of Active Directory databases in virtualized domain controllers running on Windows Server 2012 Hyper-V host computers.

The article was released in July 2013 with title “Active Directory database becomes corrupted when a Windows Server 2012-based Hyper-V host server crashes” but has sense since been renamed to “Loss of consistency with IDE-attached virtual hard disks when a Windows Server 2012-based Hyper-V host server experiences an unplanned restart” Confused already?  Please continue reading!!

The Problem

Following “hard” shutdowns (i.e. the plug is pulled) on Windows Server 2012  Hyper-V hosts, virtualized Domain Controller role computers may experience boot failures with error 2e2.

2e2 boot failures have occurred for years on DCs running on physical hardware when some specific guidelines (we’ll get to those in a minute) were not being followed. Deploying Active Directory – and therefore, AD databases, which are really just Jet databases, (as discussed in our AD Internals post) in a virtual environment introduces another additional root cause which is mitigated by MSKB 2853952.

The KB tells us that Jet databases placed on virtual IDE drives on virtual guests are vulnerable to corruption when the underlying Windows Server 2012 hyper-V host computer experiences an unplanned shutdown. Possible causes for such unscheduled shutdowns might include a loss of power to the data center or simply the intern tripping on the power cable in the data center. It has happened before and it will happen again.

Domain controller log files or database files that are damaged by an unscheduled shutdown may experience normal mode boot failures with a stop c00002e2 or c00002e3 error. If auto reboot is enabled on your domain controllers following a blue screen, DCs may continually reboot once their hyper-V host restarts.

Text and graphical examples of the c00002e2 are shown below

c00002e2 Directory Services could not start because of the following error: %hs Error Status: 0x%x. Please shutdown this system and reboot into Directory Services Restore Mode, check the event log for more detailed information.”

image

Figure 1: Uh oh…

The KB goes on to explain that this behavior occurs because the Hyper-V virtual IDE controller reports incorrectly “success” if the guest requests to disable the disk cache. Consequently, an application, like Active Directory, may think an I/O was written directly to disk, but was actually written to the disk cache. Since the power was lost, so was contents of the disk cache.

The Fix

There are four fundamental configuration changes to lessen the possibility from this occurring (whether DCs are deployed on physical or virtual machines):

  1. Make sure you are running on Server class hardware. That means that physical hard drives hosting Active Directory databases and other jet-dependent server roles (DHCP, FRS, WINS, etc) reside on SAS drives as opposed to IDE drives. IDE drives may not support forced unit access that is needed to ensure that critical writes by VM guests get transitively committed through the virtual hosts to underlying disk.
  2. Drive controllers should be configured with battery-backed caching controllers so that jet operations can be replayed when the hyper-V hosts and guests are restarted.
  3. If Hyper-V hosts can be configured with UPS devices so that both the host and the guest enjoy graceful shutdowns in the event of power losses, all the better.
  4. If you feel like the auto-reboot behavior masks the 2e2 or 2e3 boot errors, then disable the “automatically restart” option by going to the advanced tab on system properties under startup and recovery.

Next, MSKB 2853952 or the July 2013 cumulative rollup 2855336 (we’ve detailed these rollups in an earlier post) which includes standalone QFE 2853952 should be installed on Windows Server 2012 Hyper-V hosts and Windows Server 2012 guests.

A pending update, currently scheduled for release today (September 10th, 2013) will update 2853952 to apply to

  • Windows Server 2008 R2 Hyper-V hosts.
  • Windows 7 and Windows Server 2008 R2 virtual guests running on either Windows Server 2008 R2 or Windows Server 2012 Hyper-V hosts.

In summary, the updated version of KB 2853952 should be installed on both Windows Server 2008 R2 and Windows Server 2012 Hyper-V hosts (using the existing version of KB 2853952), and Windows 7 / Windows Server 2008 R2 virtual guests utilizing a jet-based store like Active Directory.

A workaround that can be deployed NOW, is to deploy jet databases, including the Active Directory  database and log files on virtual SCSI drives when Windows Server 2008 R2 and Windows Server 2012 virtual guests resides on Windows Server 2012 virtual hosts.

The reason SCSI or Virtual SCSI is recommended is that SCSI controllers will honor forced unit access or requests to disable write cache. Forced Unit Access (FUA) is a flag that NTFS uses to bypass the cache on the disk – essentially writing directly to the disk. SCSI has supported this via the t10 specification but this support was not available in the original t13 ATA specifications. While FUA support was added to the t13 ATA specifications after the original release, support for this has been inconsistent. More importantly, Windows does not support FUA on ATA drives.

Active Directory uses FUA to perform un-buffered writes to preserve the integrity of the database in the event of a power failure. AD will behave this way on physical and virtual platforms. If the underlying disk subsystem does not honor the FUA write, there could be database corruption and/or a “USN Bubble”. Further, some SCSI controllers feature a battery backed cache, just in case there are IOs still in memory when power is lost. (Thanks to fellow PFE Brent Caskey for doing some digging on this)

Applying the July update rollup and the pending September updates on the relevant Hyper-V hosts and virtual guests will greatly reduce the likelihood of damage to jet files when Hyper-V guests reside on virtual IDE disks. However the recommendation is still to use virtual SCSI disks for jet-based workloads and other critical data.

FAQ about this update

This update probably sent many of your admin spidey sense tingling and for good reason. Let’s try to answer ones that you are thinking about.

Does this only affect Active Directory?

By reading the actual problem you’ll notice it’s not a problem with Active Directory itself so the answer is no. The title of the KB has been updated to reflect this and hopefully provide some clarity. The problem is with applications that require I/O guarantee. IDE doesn’t provide I/O guarantee and neither does Virtual IDE.

 

How Should I Be Configured?

You are going to want to have your data stored on Virtual SCSI (vSCSI) disks for the reasons stated above.

What about physical machines on IDE drives, are they at risk too?

Yes. If you still have physical machines that are running on IDE drives, you will want to try to move the server data to SCSI disks as well.

I have all my data on the boot drive, can I boot off Virtual SCSI?

You cannot. In Server 2012 R2 we actually have Virtual SAS which you can use for both boot and data. For now you’ll need to use a separate virtual SCSI disk for data.

Is only Server 2012 affected by this?

No this also affects 2008 R2. However the new update is now for both 2008 R2 and 2012.

Where do I apply this update, host, guest or both?

The update should be applied to Windows Server 2012 hosts, and in a post July 2013 update, Windows Server 2008 R2 Hyper-V hosts, and Windows Server 2012/Windows Server 2008 R2 / Windows 7 virtual guests.

Anything else we should be doing for this?

You’ll want to make sure any operational and configuration changes are in place to avoid any unscheduled down time until you are able to move the data to a virtual SCSI disk and apply the appropriate updates.

 

I have a lot of DCs that are set up improperly, a little help?

Tom recently helped out a customer with moving their DB and logs to SCSI disks. Thanks to PowerShell and his powershell-fu, this is all pretty simple but it does take the AD service down on the target DC for a period of time.

First, on the Hyper-V host, you’ll need to attach a new disk to the virtual machine. Launch PowerShell as an admin on the host. Pre-identify the VM name and the physical location where you’ll create the new VHDX file.

Then run:

$vhd = New-VHD -Path [PATH TO VHDX] -SizeBytes 10GB -Dynamic:$false Add-VMHardDiskDrive -path $vhd.path -ControllerType:SCSI -ControllerNumber 0 -VMName [VMNAME]

Obviously, replace the bracketed parameters with your parameters. Also modify the disk size to something appropriate for your database. 10GB will cover most customers.

After, you need to log on to the guest VM to create the volume and move the DB. In the example below, we’ve used drive letter E. Modify this based on your company standards or configuration.

First, check to see if the disk is offline, and set it to online if it is.

Get-Disk | Where { $_.OperationalStatus -eq "Offline" } | Set-Disk -IsOffline:$false

Once it’s online, you just need to create the volume. PowerShell makes this very easy on Windows Server 2012. If you’re using 2008, you will need to replace this part with diskpart commands. For the sake of brevity, we’ll just cover PowerShell.

Get-Disk | Where { $_.PartitionStyle -eq "RAW" } | Initialize-Disk -PartitionStyle:GPT -PassThru | New-Partition -UseMaximumSize -DriveLetter E | Format-Volume -Full:$false -FileSystem:NTFS -NewFileSystemLabel "NTDS" -Force

Ok, that doesn’t look easy, but it’s all one line, making use of the PowerShell pipeline. As we complete each task, we pass the result to the next cmdlet. Finally, we end up with an E drive. Next, we need to move the database and logs. We’ll use ntdsutil to do this.

First, stop NTDS. Then, run ntdsutil. Modify the paths below to fit the drive letter you chose above.

#stop NTDS Stop-Service NTDS -Force #use NTDSutil to move logs/db ntdsutil activate instance ntds files move db to e:\NTDS move logs to e:\NTDS quit quit

Verify the output from ntdsutil. If you’re scripting this out, I recommend extensive testing ahead of time. You may be able to use Test-Path to figure out if the database and logs moved successfully or not. Assuming everything checked out, run Start-Service NTDS to restart NTDS. Congrats, you’re made it to SCSI disks.

Any questions please let us know in the comments.

Mark “Crash test dummy #1” Morowczynski and Tom “Crash test dummy #2” Moser

</QUOTE SOURCE=”Clarifications on KB 2853952, Server 2012 and Active Directory error c00002e2 or c00002e3”>

Cheers,

Jorge

———————————————————————————————

* This posting is provided "AS IS" with no warranties and confers no rights!

* Always evaluate/test yourself before using/implementing this!

* DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/

———————————————————————————————

############### Jorge’s Quest For Knowledge #############

######### http://JorgeQuestForKnowledge.wordpress.com/ ########

———————————————————————————————

Posted in Active Directory Domain Services (ADDS), Updates, Updates, Virtualization, Windows Client, Windows Server | Leave a Comment »

(2013-09-09) Windows 8.1 And Windows Server 2012 R2 Available For Subscribers

Posted by Jorge on 2013-09-09


Windows 8.1 RTM and Windows Server 2012 R2 RTM are available today for TechNet and MSDN Subscribers!

More info: Download Windows 8.1 RTM, Visual Studio 2013 RC and Windows Server 2012 R2 RTM Today

Downloads:

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
#########
http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

Posted in Windows Client, Windows Server | Leave a Comment »

 
%d bloggers like this: