Since some of my test machines are a touch low on resources, having to wait for the server manager process to finish loading can be a little bit painful.
There are group policy and local policy options to suppress this in addition to editing the registry.
There is always the option to disable it directly from Server Manager, but I’d rather automate this. For completeness sake, the below shows how to manually disable Server Manager on a Windows Server 2012 R2 server.
Select “Manage” in the top right hand corner, then Server Manager properties
In the Server Manager Properties Window, you can choose to disable it from starting up automatically at logon.
The option to control via a GPO is contained here:
Computer Configuration\Administrative Templates\System\Server Manager
Using the Group Policy Management Console on Windows 2012 R2, we can set the policy as follows:
When the GPO is refreshed on the machines that fall under the scope of the policy, the settings will be applied. This then greys out the “Do not start Server Manager automatically” at logon option.
In addition we can also set a registry key automatically via a script to set the required registry key.
HKCU\Software\Microsoft\ServerManager\DoNotOpenServerManagerAtLogon REG_DWORD 0x1
HKCU\Software\Microsoft\ServerManager\DoNotOpenServerManagerAtLogon
REG_DWORD 0x1
To query this via cmd prompt:
REG.exe Query HKCU\Software\Microsoft\ServerManager /V DoNotOpenServerManagerAtLogon
To set this via cmd prompt:
REG.exe Add HKCU\Software\Microsoft\ServerManager /V DoNotOpenServerManagerAtLogon /t REG_DWORD /D 0x1 /F
(Note that the above is one line that may wrap)
We can retrieve the current configuration using the first two commands, whilst the third one sets the value:
Get-Item HKCU:\Software\Microsoft\ServerManager Get-ItemProperty -Path HKCU:\Software\Microsoft\ServerManager -Name DoNotOpenServerManagerAtLogon | select DoNot OpenServerManagerAtLogon | Ft –AutoSize New-ItemProperty -Path HKCU:\Software\Microsoft\ServerManager -Name DoNotOpenServerManagerAtLogon -PropertyType DWORD -Value "0x1" –Force
Get-Item HKCU:\Software\Microsoft\ServerManager
Get-ItemProperty -Path HKCU:\Software\Microsoft\ServerManager -Name DoNotOpenServerManagerAtLogon | select DoNot OpenServerManagerAtLogon | Ft –AutoSize
New-ItemProperty -Path HKCU:\Software\Microsoft\ServerManager -Name DoNotOpenServerManagerAtLogon -PropertyType DWORD -Value "0x1" –Force
(Note that the above are all one line that may wrap)
Cheers,
Rhoderick
Exchange 2013 CU5 has been released to the Microsoft download centre! Exchange 2013 has a different servicing strategy than Exchange 2007/2010 and utilises Cumulative Updates (CUs) rather than the Rollup Updates (RU/UR) which were used previously. CUs are a complete installation of Exchange 2013 and can be used to install a fresh server or to update a previously installed one. Exchange 2013 SP1 was in effect CU4, and CU5 is the first post SP1 release. CU5 contains AD DS schema changes so please test and plan accordingly!
This is build 15.00.0913.022 of Exchange 2013 and the update is helpfully named Exchange2013-x64-cu5.exe. Which is a great improvement over the initial CUs that all had the same file name! Details for the release are contained in KB2936880.
As Ross discussed on the Exchange team blog, CU5 changes OAB behaviour in Exchange 2013. Please read his excellent post, and the issues with OAB as discussed by Herr Brian Day at MEC 2014.
The Exchange 2007 fixes will be very welcome for some of the Dr Pepper loving customers I have recently visited where they upgraded directly from Exchange 2007 to 2013. Lync clients were not functioning correctly as Exchange 2013 mailbox was not correctly generating the Autodiscover XML for the client when the mailbox was located on Exchange 2007.
As with previous CUs, CU5 follows the new servicing paradigm that was previously discussed on the blog. The CU5 package can be used to perform a new installation, or to upgrade an existing Exchange Server 2013 installation to CU5. You do not need to install Cumulative Update 1 or 2 for Exchange Server 2013 when you are installing CU5. Cumulative Updates are well, cumulative. What else can I say,,,,
After you install this cumulative update package, you cannot uninstall the cumulative update package to revert to an earlier version of Exchange 2013. If you uninstall this cumulative update package, Exchange 2013 is removed from the server.
Note that customised configuration files are overwritten on installation. Make sure you have any changes fully documented!
CU5 contains AD Schema updates – please test and plan accordingly!
What do I mean by that? Well, you need to ensure that you are fully informed about the caveats with the CU and are aware of all of the changes that it will make within your environment. Additionally you will need to test the CU your lab which is representative of yourproduction environment.
The Exchange team today announced the availability of Update Rollup 6 for Exchange Server 2010 Service Pack 3. RU6 is the latest rollup of customer fixes available for Exchange Server 2010. The release contains fixes for customer reported issues and previously released security bulletins. For example, the security issue that was addressed in Exchange 2010 SP3 RU4 is contained in RU6.
This is build 14.03.0195.001of Exchange 2010, and KB2936871 has the full details for the release
Note that this is for the Service Pack three branch of Exchange code. Why? Exchange 2010 SP2 exited out of support on the 8th of April 2014 and will no longer receive updates.
Now, before we rush off to download and install this there are a couple of items to mention!
When I was in Seattle for some internal training in January, one of the chaps delivering a demo used a feature that I wish I’d known about previously. When he was demonstrating some of the update mechanics for Office Pro Plus he immediately skipped to the correct portion of the registry by using a shortcut feature in Registry Editor.
Yes, there is a favourites bookmark feature!
Update 20-8-2014: Added Windows 2000 information and screenshots
Update 6-9-2014: Link to other post on sharing this between machines is here
When you open up Registry Editor, and yes I still compel myself to use regedt.exe rather than regedit..exe (those NT habits die hard…..).
Look along the top, and you will see a favourites menu.
To add a key to the favourites, highlight it, and then choose “Add To Favourites”. In the case below we are adding the Exchange 2010 MSExchangeAB key as a favourite.
This allow me to easily come back, and skip directly to the section in the registry that controls how the Address Book service is configured.
Now all I have to do, is to select the MSExchangeAB entry from the Favourites menu and I get instantly teleported there – nice!
I’ve also added the MSExchangeRPC key as we typically either set both to static in Exchange 2010 enterprise deployments.
One of my AD colleagues (thanks Pierre!) mentioned that he had a Windows 2000 DC running, so I asked him to check for the feature there, and yes it was present way back un build 2195!
Just for a giggle, this is the Start screen from a Windows Server 2012 R2 server. I’m searching for regedt32.exe
And when we zoom in on the upper right hand portion of the screen, its the old school NT registry editor icon.
The young pup, Windows 95 registry editor, regedit.exe is shown here for comparison.
Security is an integral aspect of running modern IT operations. There is a clear understanding that we need to protect our IT assets, company data and personal identifiable information. So when we discuss a migration to Office 365, security is an inevitable topic. One aspect that we need to discuss is around account lockout, and how to protect our Active Directory accounts as part of the overall cloud solution.
Methods to protect user accounts can be broken down into a few categories that include:
Customers wish to look at such options to mitigate the impact from:
In a future post I'll circle back on the underlying account lockout policy discussion, so let's park that one for right now. What I do want to cover in this post is ADFS and how it can impact account lockouts should you have an aggressive lockout policy enabled.
Update 3-9-2014: Please also review this post for an issue requiring a hotfix to resolve with Extranet Account Lockout Protection
In the previous versions of ADFS there was no native mechanism within ADFS itself to prevent brute force attacks upon ADFS. If AD has a password lockout policy set, then an external entity hammering the ADFS logon page could then lockout an AD account. If an entity knew the user account name, they could access the ADFS proxy page and enter a bad password for the user account. The below is an example for ADFS 2.0 running on Windows 2008 R2.
In order to mitigate this, the external firewall in front of the ADFS server could be set to only allow HTTPS traffic to the ADFS endpoint from the IP address ranges that are part of Office 365. Since this is a manual configuration, the onus is on the on-premises firewall administrator to keep the IP ranges up to date else authentication may fail. In the traffic flow, the HTTPS traffic coming to the on-premises ADFS proxy server is initiated from Office 365. As discussed at MEC, this will have to be a planning point for the upcoming OAuth changes in Q2 this CY. As part of the authentication changes, by default clients will connect directly to the ADFS servers. Either the firewall rules will need to be changed, or modifications made to the clients to use the legacy behaviour. More on that when the team announces the details later this year! This was discussed publically at MEC in the What’s new in Authentication for Outlook 2013 session.
If you did not get to MEC, then the content is available here for your viewing pleasure!
Apart from locking down the firewall, Windows Server 2012 R2 ADFS now adds a feature to natively allow the ADFS proxy to prevent AD DS accounts from being locked out! This is the Extranet Lockout feature. This is similar to the TMG 2010 Soft Account Lockout feature that was introduced in TMG 2010 SP2. It is said to be "soft" as the AD DS account is not locked, and after a period of time the ADFS server then automatically allows the account to retry the authentication.
Only Windows Server 2012 R2 has the Extranet Lockout feature. For this and other reasons you want to look at deploying Server 2012 for your ADFS infrastructure. Some reasons include:
As mentioned above, only ADFS 2012 R2 has the Extranet Lockout feature. Thus the ADFS infrastructure must be upgraded or installed as this version. For upgrade steps, please check out the excellent ASKPFE PLAT blog!
While the Extranet Lockout feature is enabled on the ADFS server, you must also deploy an ADFS proxy.
Traffic must hit the ADFS proxy. If you publish the ADFS server instead or your network misroutes the traffic and bypasses the proxy, the Extranet Lockout feature will not work as expected. Trust me, I’ve been there – but more on that later in a separate blog post!!
The other base ADFS requirements and prerequisites are also documented on TechNet.
As with the other articles in the recent ADFS posts, this is again in the Tailspintoys.ca lab. The ADFS namespace is adfs.tailspintoys.ca. The environment looks like the diagram below. The ADFS server is deployed on the internal corporate network and is joined to AD. The ADFS proxy is deployed in the DMZ, and is in a workgroup. Since we are using ADFS 2012 R2, the ADFS proxy uses Web Application Proxy (WAP) rather than a dedicated ADFS proxy role as in older versions.
For the details in building this lab please see the previous series of three posts.
The diagram was drawn with the April 2014 Visio Stencils for Office 365.
AD DS is set with a domain account lockout policy that states an account will lock out after 10 invalid logon attempts. This can be seen in the GPO Management Console:
And for those LAN Manager freaks out there the command prompt too!
PS -- This was taken from a DC that does not have the PDC emulator role
So we know that after 10 attempts the account will lock out. What happens if we launch a mini-DOS attack on some guy called user-1@tailspintoys.ca via the ADFS sign in page?
Browse to the ADFS sign in page in IE11 at https://adfs.tailspintoys.ca/adfs/ls/idpinitiatedsignon.htm
And we enter a bad password 11 times…
Staying with the LAN Manager freak show, look what happened to that poor user, their account is now locked out.
On the ADFS server we see the 10 failed logon attempts before the account locked out:
Zooming in on one event we see that the response from AD is that this is an unknown user name and bad password. Well, that’s the generic text string. If we really want to know what is going on, then we look at the status and sub status codes. In this case 0xC0000006D maps to the bad user name response but 0xC0000006A tells us that the password was not correct. Well, that’s because I was making like Jean Michel Jar on the keyboard to make up a random string in the password entry field. Well, less the light show….
Not good! A malicious person ( moi ! ) managed to do a denial of service on this account.
AD FS Extranet Lockout to the rescue!
In the context of AD FS in Windows Server 2012 R2, Web Application Proxy functions as a federation server proxy. Web Application Proxy also serves as a barrier between the Internet and your corporate applications.
Web Application Proxy provides a number of security features to protect your corporate network, such as your users and your resources, from external threats. One of these features is AD FS extranet lockout. In case of an attack in the form of authentication requests with invalid (bad) passwords that come through the Web Application Proxy, AD FS extranet lockout enables you to protect your users from an AD FS account lockout. In addition to protecting your users from an AD FS account lockout, AD FS extranet lockout also protects against brute force password guessing attacks.
There are three ADFS settings that we need to look at with respect to the Extranet Lockout feature.
The intent is that the ADFS administrator will define a maximum number of failed authentication requests that the ADFS proxy will allow in a certain time period. Once these authentication attempts have been used up for that specific user, then the ADFS server will go into <Seinfeld> soup Nazi -- no auth for you!!! </Seinfeld>. The ADFS proxy server will then cease attempting to log the user on. By doing so, it does not hammer on the AD account thereby locking the AD account out. This protects the AD account from losing access to all resources, i.e. it is still functional on the corporate network and can get to file and print resources etc.
One thing to note. The value for the ExtranetLockoutThreshold on the ADFS server must be set to a lower value than the AD DS account lock out threshold, else the AD DS account will lock out before the ADFS proxy ceases to attempt authentication and enabling this on ADFS is pretty pointless!!
This is a global setting on the ADFS server, and the settings apply to all domains that the ADFS server can authenticate. Please plan accordingly.
To configure the AD FS extranet lockout, you must set three properties on the AD FS service object. To set the configuration, use Set-ADFSProperties and Get-ADFSProperties to verify.
For example, you can use the following oneliner PowerShell command to set the AD FS extranet lockout:
Set-AdfsProperties -EnableExtranetLockout $true -ExtranetLockoutThreshold 15 -ExtranetObservationWindow (New-Timespan -Minutes 30)
(The command is one line, please ensure that it does not word wrap)
You could split it out into multiple commands if desired:
$Timespan = New-TimeSpan -Minutes 30 Set-AdfsProperties -EnableExtranetLockout $True -ExtranetLockoutThreshold 15 -ExtranetObservationWindow $Timespan Get-AdfsProperties | Format-List *extranet*
$Timespan = New-TimeSpan -Minutes 30 Set-AdfsProperties -EnableExtranetLockout $True -ExtranetLockoutThreshold 15 -ExtranetObservationWindow $Timespan
Get-AdfsProperties | Format-List *extranet*
(Each command is one line, please ensure that it does not word wrap)
Opening up PowerShell on the ADFS server, and querying for the *Extranet* values we can see the default Extranet Lockout settings. Extranet Lockout is disabled by default.
Where is the default value for the lockout threshold coming from? Since it is disabled, 2147483647 is the maximum value in an Int32 data type. Run [int32]::maxValue in PowerShell to see.
Let’s now configure the ADFS server so that the ADFS proxy will lock out after 4 bad attempts in a 60 minute observation window.
$Timespan = New-TimeSpan -Minutes 60 Set-AdfsProperties -EnableExtranetLockout $True -ExtranetLockoutThreshold 4 -ExtranetObservationWindow $Timespan Get-AdfsProperties | Fl *extranet*
$Timespan = New-TimeSpan -Minutes 60
Set-AdfsProperties -EnableExtranetLockout $True -ExtranetLockoutThreshold 4 -ExtranetObservationWindow $Timespan
Get-AdfsProperties | Fl *extranet*
When I first tried to configure this feature, I ran into this wonderful error:
Set-AdfsProperties : A parameter cannot be found that matches parameter name 'ExtranetLockoutEnabled'. At line:1 char:20 + Set-AdfsProperties -ExtranetLockoutEnabled $True + ~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : InvalidArgument: (:) [Set-AdfsProperties], ParameterBindingException + FullyQualifiedErrorId : NamedParameterNotFound,Microsoft.IdentityServer.Management.Commands.SetServiceProperties Command
Huh???
As we saw above, there is definitely a property on the ADFS object that is called ExtranetLockoutEnabled – so why was I unable to set it?
This is probably because I have been spoilt with Exchange PowerShell since 2006. The attributes are carefully thought out and after running a get cmdlet we just change it to a set cmdlet and change what we need. For that reason I get frustrated with Windows PowerShell, especially the AD cmdlets. Why do I have to have a separate cmdlet for each tiny task? Anyway I digress…
In this case the developer changed the parameter that we use to set ExtranetLockoutEnabled. To set it we have to use the EnableExtranetLockout parameter. The two values are different:
It’s always the little things that get me……
After waiting a minute for the ADFS proxy to pickup on the change, we can test to make sure this is working!
Remember that AD DS is set to lockout after 10 invalid logons, and AD FS will cease after 4 failed authentication attempts.
Again we browse to the ADFS sign in page in IE11 at https://adfs.tailspintoys.ca/adfs/ls/idpinitiatedsignon.htm
This time we will pick on user-2@tailspintoys.ca, just so that it is easy to distinguish the two scenarios in the event logs.
Again, the account is hammered with 11 bad logon attempts.
This time however, there are only 4 failed audit events on the AD FS server:
Please note The events at from 02:10 to 02:11 were the user-1 logon attempt at the top of this blog post.
Let’s check the status of the User-2 account
Even after 11 bad logon attempts via the ADFS proxy, the account is still active – boyashaka !
Just to prove what is in the security event log of the ADFS server, let’s look for audit failure events over the last day for each of these test accounts. To look for this data, PowerShell will be the weapon of choice. Note that Get-EventLog is not used as it lame when it comes to filtering so we will use Get-WinEvent which is way more powerful. Why the difference? Get-Eventlog was in the initial PowerShell release and Get-WinEvent was added in PowerShell 2.0…..
The code used below is:
$StartTime = (Get-Date).AddDays(-1) Get-WinEvent -FilterHashtable @{Logname="Security"; ProviderName="Microsoft-Windows-Security-Auditing"; Data="user-2@tailspintoys.ca"; StartTime=$StartTime} | Measure-Object Get-WinEvent -FilterHashtable @{Logname="Security"; ProviderName="Microsoft-Windows-Security-Auditing"; Data="user-2@tailspintoys.ca"; StartTime=$StartTime}
$StartTime = (Get-Date).AddDays(-1)
Get-WinEvent -FilterHashtable @{Logname="Security"; ProviderName="Microsoft-Windows-Security-Auditing"; Data="user-2@tailspintoys.ca"; StartTime=$StartTime} | Measure-Object
Get-WinEvent -FilterHashtable @{Logname="Security"; ProviderName="Microsoft-Windows-Security-Auditing"; Data="user-2@tailspintoys.ca"; StartTime=$StartTime}
The $StartTime variable goes back 24 hours from when it was created, i.e. a day. We then create a hashtable and look for only failure security audits for accounts that match the given username. In the example above this is the user-2@tailspintoys.ca account. Measure-Object is used to save us having to count….
First up is user-1. Note that there are 10 failed logon attempts which corresponds to the AD DS account lockout policy. The timeframe of the ‘attack” was 02:10 – 02:11.
For User-2, note that there are only 4 failed logon attempts. This correlates to the AD FS Extranet Lockout protection setting. Also note that since the AD FS lockout setting is lower than the AD DS account lockout policy the AD DS account is not locked out.
In addition to the content and links in the previously published ADFS blog posts there is also the following:
Troubleshooting AD FS
AD FS 2012 R2 Extranet feature lights up a new feature to make it very easy to provide protection from AD DS account lockout scenarios where the internal AD account is locked out due to malicious or fat-fingered end user logon attempts.
One thing to note is that applications that require ADFS to federate the authentication request will not be able to do so whilst this account is in a state of Extranet Lockout. Because of this some organisations may still choose to restrict access to their ADFS proxy via firewall rules and to set “reasonable” AD account lockout policies. We can talk more next time about why locking an AD account out after 3 bad attempts is not so good…..
MEC 2014 session recordings and slides are now available for everyone’s enjoyment!
As always Ross Smith, Scott Schnoll and Brian Day deliver some great content that you must check out! If you are in the throes of deploying Exchange 2013 SP1 right now, then please do look at Brian Day’s session. You will not regret it!
Take some time to go through these 74 awesome sessions.
My MEC 2014 write-up can be found here.