This was one error that I couldn't find a definitive answer for after searching the error:
error code: dlg_flags_sec_cert_cn_invalid - The hostname in the website's certificate differs from the website you are trying to visit
Long story short, in my case this came down to the "Common name" or "CN" in the certificate.
I had created the cert with a CN and some SAN names like so:
CN=application.domain.lan
SAN=application.domain.lan
SAN=application
SAN=servername.domain.lan
SAN=servername
SAN=applicationalias.domain.lan
SAN=applicationalias
Internet Explorer 11, Edge, Chrome and Firefox all tripped over the Common name.
If I typed in the browser: "https://application" the error did not appear. So my conclusion is that the webserver doesn't interpret the domain suffix stated in the common name.
So I recreated the certificate with the Common name: "application".
Binded it in IIS, iisrestart and reloaded the site in IE and behold no more errors.
About: Exchange 2013-2016-2019-Online - Powershell - Windows 2012-2016-2019 - Teams - Office365 - PKI - Microsoft365
Showing posts with label IIS. Show all posts
Showing posts with label IIS. Show all posts
15 March 2019
12 March 2018
How to restore a private key in IIS 7.0 or IIS 8.0
The following instructions apply to Windows Server 2008 (IIS 7.0) & Windows Server 2012 (IIS 8.0). Perform the following steps to restore the private key.
Import SSL certificate into the Personal > Certificates folder
Create a Certificates snap-in in a MMC console, refer to solution SO9999.
From the top left-hand pane, expand the Certificates tree, expand the Personal folder
Right-click the Certificates sub folder and select All Tasks > Import
The Certificate Import Wizard opens. Click Next
Click Browse and then navigate to the SSL certificate file.
Click Open > Next
Ensure "Place all certificates in the following store" is selected, ensure that "Personal" is listed for the certificate store.
Click Next > Finish
Import the Intermediate Certificate into the Intermediate Certification Authorities > Certificates folder
Download the correct Intermediate CA certificate, refer to article INFO1421.
From the left pane, expand the Intermediate Certification Authorities folder
Right-click on the Certificates sub folder
Select All Tasks > Import - A Certificate Import Wizard will open.
Click Next
Click Browse and then navigate to the Intermediate CA Certificate file
Click Next
Select Place all certificates in the following store: Intermediate Certification Authorities
Click Next
Click Finish
Restore Private Key
With the MMC console still open, select the Certificates folder inside the Personal folder in the left-hand pane.
Double-click the newly imported SSL certificate in the right-hand pane, then select the Details tab.
Scroll down and select the Thumbprint field, then select and copy the entire thumbprint (in the bottom box) to the clipboard.
Open a command prompt, then enter the following command:
certutil -repairstore my "<thumbprint>"
Example:
certutil -repairstore my "00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f"
If successful, the response will be "CertUtil: -repairstore command completed successfully"
Assign SSL certificate in IIS
Go to > Start > Administrative Tools > Internet Information Services (IIS) Manager.
From the Connections pane on the left, expand the local server, expand the Sites folder and select the web site to be secured with SSL.
From the Actions pane on the right, select the Bindings option under Edit Site.
In the Site Bindings window, select an existing https binding and click Edit. If there are no existing https bindings, click Add.
Ensure the type is set to 'https', then select the new SSL certificate from the drop down menu.
Click the View button to confirm details of the certificate.
Click OK > Close
Labels:
Certificate,
IIS,
Private Key
Location:Utrecht
Utrecht, Netherlands
22 February 2018
Clean IIS .LOG files, .BLG and .ETL files while we're at it
Updated 19-04-2019 - Fixed an error thanks to anonymous.
This is a script I found at "The Gallery" over at Technet.
Edward van Biljon created this for his own environment and I saw a great script to be used for my environment as well. In his version it also goes through the IIS folders, but I think there are better scripts available to do this so I don't use that function and commented it out in the script.
Certain files are in constant use by Exchange or IIS so this script won't be able to delete those files.
After a reboot you can delete those files by running this script.
This is a script I found at "The Gallery" over at Technet.
Edward van Biljon created this for his own environment and I saw a great script to be used for my environment as well. In his version it also goes through the IIS folders, but I think there are better scripts available to do this so I don't use that function and commented it out in the script.
What it does is find log files, blg files and etl files.
If older than X days they get deleted.
Why would you want this? Well, disk space disk space disk space.
All the logging that Exchange 2013 and 2016 does out of the box will fill up your disks like crazy.
Running this as a scheduled task will prevent the most cases of system freezes and lockups because of full OS disks.
Certain files are in constant use by Exchange or IIS so this script won't be able to delete those files.
After a reboot you can delete those files by running this script.
The original script by Edward was missing some folders, so I added those:
$days=3 $IISLogPath="C:\inetpub\logs\LogFiles\" $ExchangeLoggingPath="C:\Program Files\Microsoft\Exchange Server\V15\Logging\" $ETLLoggingPath="C:\Program Files\Microsoft\Exchange Server\V15\Bin\Search\Ceres\Diagnostics\ETLTraces\" $ETLLoggingPath2="C:\Program Files\Microsoft\Exchange Server\V15\Bin\Search\Ceres\Diagnostics\Logs" $ETLLoggingPath3="C:\Program Files\Microsoft\Exchange Server\V15\FIP-FS\Data\ProgramLogArchive\" $ETLLoggingPath4="C:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\Logs\FrontEnd\Connectivity" $HTTPERRLoggingPath="C:\Windows\System32\LogFiles\HTTPERR" Function CleanLogfiles($TargetFolder) { write-host -debug -ForegroundColor Yellow -BackgroundColor Cyan $TargetFolder if (Test-Path $TargetFolder) { $Now = Get-Date $LastWrite = $Now.AddDays(-$days) $Files = Get-ChildItem $TargetFolder -Recurse | Where-Object {$_.Name -like "*.log" -or $_.Name -like "*.blg" -or $_.Name -like "*.etl"} | where {$_.lastWriteTime -le "$lastwrite"} | Select-Object FullName foreach ($File in $Files) { $FullFileName = $File.FullName Write-Host "Deleting file $FullFileName" -ForegroundColor "yellow"; Remove-Item $FullFileName -ErrorAction SilentlyContinue | out-null } } Else { Write-Host "The folder $TargetFolder doesn't exist! Check the folder path!" -ForegroundColor "red" } } CleanLogfiles($IISLogPath) CleanLogfiles($ExchangeLoggingPath) CleanLogfiles($ETLLoggingPath) CleanLogfiles($ETLLoggingPath2) CleanLogfiles($ETLLoggingPath3) CleanLogfiles($ETLLoggingPath4) CleanLogfiles($HTTPERRLoggingPath)
Source
Labels:
Exchange 2013,
Exchange 2016,
IIS,
Logging,
Powershell
Location:Utrecht
Utrecht, Netherlands
19 January 2017
Install the Microsoft Exchange 2013 Management Tools prerequisites on Windows 10 with PowerShell
Install the Microsoft Exchange 2013 Management Tools prerequisites on Windows 10:
IIS:
IIS:
Enable-WindowsOptionalFeature -Online -FeatureName IIS-WebServerRole Enable-WindowsOptionalFeature -Online -FeatureName IIS-WebServerManagementTools Enable-WindowsOptionalFeature -Online -FeatureName IIS-IIS6ManagementCompatibility Enable-WindowsOptionalFeature -Online -FeatureName IIS-Metabase Enable-WindowsOptionalFeature -Online -FeatureName IIS-LegacySnapIn.NET 3.5:
Write-Host "Installing .Net Framework 3.5, do not close this prompt..." DISM /Online /Enable-Feature /FeatureName:NetFx3 /All /LimitAccess /Source:$LocalSource | Out-Null $Result = Dism /online /Get-featureinfo /featurename:NetFx3 If($Result -contains "State : Enabled") { Write-Host "Install .Net Framework 3.5 successfully." } Else { Write-Host "Failed to install Install .Net Framework 3.5,please make sure the local source is correct." }In case the above doesn't work, you can try:
DISM /Online /Enable-Feature /FeatureName:NetFx3
Labels:
IIS,
Powershell,
prerequisites
Location:Utrecht
Utrecht, Netherlands
13 December 2016
Remote PowerShell session - the request needs to be sent to a different machine
Well this is a nice one as well….NOT. I keep losing hair like this.
After trying to setup a remote PowerShell session the following error occurs.
The WinRM service cannot process the request because the request needs to be sent to a different machine.
Use the redirect information to send the request to a new machine. Redirect location reported: https://mail.mydomain.com/powershell.
To automatically connect to the redirected URI, verify "MaximumConnectionRedirectionCount" property of session preference variable
"PSSessionOption" and use "AllowRedirection" parameter on the cmdlet.
+ CategoryInfo : OpenError: (System.Manageme....RemoteRunspace:RemoteRunspace) [], PSRemotingTransportRedirectException
+ FullyQualifiedErrorId : PSSessionOpenFailed
Let me tell you what is not the cause so you can skip checking all those things:
The error doesn't say a lot about the actual cause.
So remember when was the last CU you installed? Bingo, after every CU your IIS settings can get garbled and that’s exactly what happened here.
Changes are your authentication settings in IIS on the PowerShell virtual directory for the frontend website are gone/missing/set incorrectly.
In my case they were gone, no authentication option was set. After setting it al back the way it should be (see this post, you need to make note of this stuff for a working Exchange environment in cases like this) I could create a remote PowerShell session instantly.
After trying to setup a remote PowerShell session the following error occurs.
The WinRM service cannot process the request because the request needs to be sent to a different machine.
Use the redirect information to send the request to a new machine. Redirect location reported: https://mail.mydomain.com/powershell.
To automatically connect to the redirected URI, verify "MaximumConnectionRedirectionCount" property of session preference variable
"PSSessionOption" and use "AllowRedirection" parameter on the cmdlet.
+ CategoryInfo : OpenError: (System.Manageme....RemoteRunspace:RemoteRunspace) [], PSRemotingTransportRedirectException
+ FullyQualifiedErrorId : PSSessionOpenFailed
Let me tell you what is not the cause so you can skip checking all those things:
- An URL redirect in IIS
- Reinstall of WinRM
- adding “–AllowRedirect” after your connection command let
- "MaximumConnectionRedirectionCount" property setting
- Misconfigured certificate
- PowerShell version
- Invalid credentials
The error doesn't say a lot about the actual cause.
So remember when was the last CU you installed? Bingo, after every CU your IIS settings can get garbled and that’s exactly what happened here.
Changes are your authentication settings in IIS on the PowerShell virtual directory for the frontend website are gone/missing/set incorrectly.
In my case they were gone, no authentication option was set. After setting it al back the way it should be (see this post, you need to make note of this stuff for a working Exchange environment in cases like this) I could create a remote PowerShell session instantly.
Labels:
Exchange 2013,
IIS,
Powershell
Location:Utrecht
Utrecht, Nederland
29 November 2016
IIS redirect using URL Rewrite
In the following example we will redirect HTTP to HTTPs using URL Rewrite. You will need the following items completed in order for this to work correctly.
– SSL Certificate for site installed in IIS.
– Site properly installed and configured for SSL (site set up and binding in IIS configured).
– URL Rewrite 2.0 is installed on the sever.
– In the “Features View” panel, double click URL Rewrite
You will notice there are currently no rules configured for this site. Click “Add Rules…” in the Actions menu to the right of the “Features View” panel
Use the default “Blank rule” and press “OK”.
When editing a rule there are the “Name” field and 4 configuration pull down boxes.
– Enter “Redirect to HTTPS” in the name field.
– Next we will configure the first configuration pull down box called “Match URL”, on the right side of “Match URL” press the down arrow to expand the box.
Within the “Match URL” configuration box we will set the following settings:
Requested URL: Matches the Pattern
Using: Regular Expressions
Pattern: (.*)
We can now edit the next configuration pull down box which is “Conditions”, Press “Add…” to add a new condition to the configuration.
We will configure the condition with the following settings:
Condition Input: {HTTPS}
Check if input string: Matches the Pattern
Pattern: ^OFF$
Press “OK”
You should see your condition in the list of conditions.
For this setting we do not need to configure the “Server Variables” pull down box. Continue onto the “Action” configuration box and pull down the box by selecting the arrow on the right. We will configure the following settings for the “Action” configuration:
Action Type: Redirect
Redirect URL: https://{HTTP_HOST}/{R:1}
Redirect Type: See Other (303)
Press “Apply” then press “Back to Rules”
You should now see the rule configured on the main screen of the URL Rewrite module.
Test your site, it should now redirect from HTTP to HTTPS.
If we exam the web.config file we can see where the rule was entered. If we entered the rule directly into the web.config file it would show up in the GUI.
Web.Config Rule
You can also edit the web.config file of the site directly and you will be able to see the rule in the GUI. You will need to enter the following within the <system.webServer> </system.webServer> elements.
When implementing this solution you need to make sure to use relative paths for all references on your page because there is a possibility you will get a warning asking you if you want to display secure and insecure items. For example, if you have a logo on your page and the URL to this logo is http://domain/images/logo.jpg, do not use the whole path because including the http:// will hard code this image to use http and not https. Instead use /images/logo.jpg.
Replace the Redirect URL https://{HTTP_HOST}/{R:1} with https://{HTTP_HOST}{REQUEST_URI}
– SSL Certificate for site installed in IIS.
– Site properly installed and configured for SSL (site set up and binding in IIS configured).
– URL Rewrite 2.0 is installed on the sever.
GUI Version
– Select the website you wish to configure– In the “Features View” panel, double click URL Rewrite
You will notice there are currently no rules configured for this site. Click “Add Rules…” in the Actions menu to the right of the “Features View” panel
Use the default “Blank rule” and press “OK”.
When editing a rule there are the “Name” field and 4 configuration pull down boxes.
– Enter “Redirect to HTTPS” in the name field.
– Next we will configure the first configuration pull down box called “Match URL”, on the right side of “Match URL” press the down arrow to expand the box.
Within the “Match URL” configuration box we will set the following settings:
Requested URL: Matches the Pattern
Using: Regular Expressions
Pattern: (.*)
We can now edit the next configuration pull down box which is “Conditions”, Press “Add…” to add a new condition to the configuration.
We will configure the condition with the following settings:
Condition Input: {HTTPS}
Check if input string: Matches the Pattern
Pattern: ^OFF$
Press “OK”

You should see your condition in the list of conditions.
For this setting we do not need to configure the “Server Variables” pull down box. Continue onto the “Action” configuration box and pull down the box by selecting the arrow on the right. We will configure the following settings for the “Action” configuration:
Action Type: Redirect
Redirect URL: https://{HTTP_HOST}/{R:1}
Redirect Type: See Other (303)
Press “Apply” then press “Back to Rules”
You should now see the rule configured on the main screen of the URL Rewrite module.
Test your site, it should now redirect from HTTP to HTTPS.
If we exam the web.config file we can see where the rule was entered. If we entered the rule directly into the web.config file it would show up in the GUI.
Web.Config Rule
You can also edit the web.config file of the site directly and you will be able to see the rule in the GUI. You will need to enter the following within the <system.webServer> </system.webServer> elements.
Replace the Redirect URL https://{HTTP_HOST}/{R:1} with https://{HTTP_HOST}{REQUEST_URI}
Location:Utrecht
Utrecht, Netherlands
10 May 2016
Disable SSL 3.0, Weak Ciphers and enable TLS 1.1 and 1.2
Windows Server 2008 (R2) using IIS 7 allows SSL 2.0 and SSL 3.0 by default. Unfortunately, this means you will fail a PCI Compliance scan by default. To properly secure your server and ensure that you pass your PCI-DSS scans, you will need to disable SSL 2.0 and disable weak ciphers. In order to disable SSL 2.0 and SSL 3.0 in IIS 7 and make sure that the stronger TLS 1.0 is used, even better enable TLS 1.1 and TLS 1.2.
UPDATE: 27-05-2016 I found an error in the registry key settings, below are the correct settings.

In the SSL Cipher Suite Order screen select "Enabled" and under options select and delete everything in that text field.

Then copy this line in that text field:
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P521,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P256,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P521,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P256,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384_P521,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384_P521,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P521,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P384,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P521,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256,TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA256,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P521,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P256,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P521,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P521,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P521,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256,TLS_RSA_WITH_RC4_128_SHA,TLS_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA
Click "Apply" and "OK".
Now you have to reboot the server in order to activate these changes,
After the reboot go to https://www.ssllabs.com/ssltest/ and see if you get any errors or warnings.
Another way to do this is by using IISCrypto by Nartac Software, this freeware does the same but in a GUI. But for some reason it didn't do what i axpected it to do, so this way you can do it manually.
Below you can find how to disable SSL 3.0 and the weak Ciphers, and enable TLS 1.1 and TLS 1.2.
Remember that this only works after a server reboot, stopping services or IIS is not enough
Remember that this only works after a server reboot, stopping services or IIS is not enough
UPDATE: 27-05-2016 I found an error in the registry key settings, below are the correct settings.
Disable SSL3.0. and Weak Ciphers and Enable TLS 1.1 and 1.2
Copy the text below and paste in to a .reg file:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL]
"EventLogging"=dword:00000001
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\AES 128/128]
"Enabled"=dword:ffffffff
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\AES 256/256]
"Enabled"=dword:ffffffff
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\DES 56]
"Enabled"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\DES 56/56]
"Enabled"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\NULL]
"Enabled"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC2 128/128]
"Enabled"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC2 40/128]
"Enabled"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC2 56/128]
"Enabled"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 128/128]
"Enabled"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 40/128]
"Enabled"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 56/128]
"Enabled"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 64/128]
"Enabled"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\Triple DES 168/168]
"Enabled"=dword:ffffffff
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\CipherSuites]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Hashes]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Hashes\MD5]
"Enabled"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Hashes\SHA]
"Enabled"=dword:ffffffff
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Hashes\SHA256]
"Enabled"=dword:ffffffff
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Hashes\SHA384]
"Enabled"=dword:ffffffff
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Hashes\SHA512]
"Enabled"=dword:ffffffff
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\KeyExchangeAlgorithms]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\KeyExchangeAlgorithms\Diffie-Hellman]
"Enabled"=dword:ffffffff
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\KeyExchangeAlgorithms\ECDH]
"Enabled"=dword:ffffffff
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\KeyExchangeAlgorithms\PKCS]
"Enabled"=dword:ffffffff
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\Multi-Protocol Unified Hello]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\Multi-Protocol Unified Hello\Server]
"Enabled"=dword:00000000
"DisabledByDefault"=dword:00000001
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\PCT 1.0]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\PCT 1.0\Server]
"Enabled"=dword:00000000
"DisabledByDefault"=dword:00000001
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Client]
"DisabledByDefault"=dword:00000001
"Enabled"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Server]
"Enabled"=dword:00000000
"DisabledByDefault"=dword:00000001
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Server]
"Enabled"=dword:00000000
"DisabledByDefault"=dword:00000001
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server]
"Enabled"=dword:ffffffff
"DisabledByDefault"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server]
"Enabled"=dword:ffffffff
"DisabledByDefault"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server]
"Enabled"=dword:ffffffff
"DisabledByDefault"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL]
"EventLogging"=dword:00000001
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\AES 128/128]
"Enabled"=dword:ffffffff
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\AES 256/256]
"Enabled"=dword:ffffffff
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\DES 56]
"Enabled"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\DES 56/56]
"Enabled"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\NULL]
"Enabled"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC2 128/128]
"Enabled"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC2 40/128]
"Enabled"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC2 56/128]
"Enabled"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 128/128]
"Enabled"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 40/128]
"Enabled"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 56/128]
"Enabled"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 64/128]
"Enabled"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\Triple DES 168/168]
"Enabled"=dword:ffffffff
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\CipherSuites]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Hashes]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Hashes\MD5]
"Enabled"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Hashes\SHA]
"Enabled"=dword:ffffffff
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Hashes\SHA256]
"Enabled"=dword:ffffffff
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Hashes\SHA384]
"Enabled"=dword:ffffffff
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Hashes\SHA512]
"Enabled"=dword:ffffffff
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\KeyExchangeAlgorithms]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\KeyExchangeAlgorithms\Diffie-Hellman]
"Enabled"=dword:ffffffff
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\KeyExchangeAlgorithms\ECDH]
"Enabled"=dword:ffffffff
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\KeyExchangeAlgorithms\PKCS]
"Enabled"=dword:ffffffff
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\Multi-Protocol Unified Hello]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\Multi-Protocol Unified Hello\Server]
"Enabled"=dword:00000000
"DisabledByDefault"=dword:00000001
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\PCT 1.0]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\PCT 1.0\Server]
"Enabled"=dword:00000000
"DisabledByDefault"=dword:00000001
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Client]
"DisabledByDefault"=dword:00000001
"Enabled"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Server]
"Enabled"=dword:00000000
"DisabledByDefault"=dword:00000001
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Server]
"Enabled"=dword:00000000
"DisabledByDefault"=dword:00000001
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server]
"Enabled"=dword:ffffffff
"DisabledByDefault"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server]
"Enabled"=dword:ffffffff
"DisabledByDefault"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server]
"Enabled"=dword:ffffffff
"DisabledByDefault"=dword:00000000
Change cipher order and remove unsafe ciphers:
Open gpedit.msc =>> go to Administrative Templates =>> Network =>> SSL Configuration Settings =>> double click SSL Cipher Suite Order.
In the SSL Cipher Suite Order screen select "Enabled" and under options select and delete everything in that text field.

Then copy this line in that text field:
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P521,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P256,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P521,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P256,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384_P521,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384_P521,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P521,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P384,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P521,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256,TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA256,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P521,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P256,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P521,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P521,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P521,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256,TLS_RSA_WITH_RC4_128_SHA,TLS_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA
Click "Apply" and "OK".
Now you have to reboot the server in order to activate these changes,
After the reboot go to https://www.ssllabs.com/ssltest/ and see if you get any errors or warnings.
Another way to do this is by using IISCrypto by Nartac Software, this freeware does the same but in a GUI. But for some reason it didn't do what i axpected it to do, so this way you can do it manually.
Labels:
Exchange 2013,
Exchange 2016,
IIS,
Windows 10,
Windows 2012,
Windows 2012 R2
Location:Utrecht
Utrecht, Netherlands
08 March 2016
Let's Encrypt for use with IIS
There's this great thing going on in the CA world and its called "Let's Encrypt".
Let’s Encrypt is a new Certificate Authority:
Download the Let's Encrypt Windows Tool pre-release here:
https://github.com/Lone-Coder/letsencrypt-win-simple/releases
Extract to a folder and leave it there, the certificate is valid for 90 days max and the tool renews the certificate every 60 days.
Make sure you have a hostheader configured on your IIS website.
Create a the following dir in your webroot, for instance:
C:\Inetpub\wwwroot\Website1
Here you have to create in a command box or Powershell:
".well-known\acme-challenge"
Don't forget the dot in front of well. Windows can't create folder that starts with a dot so do it from commandline.
Then you have to create a web.config file in the acme-challenge folder which contains:
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.webServer>
<staticContent>
<mimeMap fileExtension="." mimeType="text/json" />
</staticContent>
</system.webServer>
<system.web>
<authorization>
<allow users="*" />
</authorization>
</system.web>
</configuration>
After this you go to the IIS manager, go to Server - Sites - Your website - Handler mappings.
Make sure you select "view ordered list" from the right pane.
And move "StaticFile" above ExtensionlessUrlHandler*.
After this you run the Tool and if all goes well, you will have a 3rd party certificate trusted by all common browsers that gives you a green bar or green Lock sign depending on which browser you use.
Every 60 days the certificate is renewed by Scheduled task automatically.
Good luck, and safe browsing :-)
Source 1
Source 2
Source 3
Source 4
Let’s Encrypt is a new Certificate Authority:
It’s free, automated, and open.
That says it all, do you want to encrypt your website, email traffic remote desktop server connections and what have you this is the change to do so, and the best part is it's free.
Okay there's a little catch, it's not really user friendly, well Windows friendly to be exact.
But there's a strong community and the support will get better in time.
For now you have to do it this way, well i did it this way:
Download the Let's Encrypt Windows Tool pre-release here:
https://github.com/Lone-Coder/letsencrypt-win-simple/releases
Extract to a folder and leave it there, the certificate is valid for 90 days max and the tool renews the certificate every 60 days.
Make sure you have a hostheader configured on your IIS website.
Create a the following dir in your webroot, for instance:
C:\Inetpub\wwwroot\Website1
Here you have to create in a command box or Powershell:
".well-known\acme-challenge"
Don't forget the dot in front of well. Windows can't create folder that starts with a dot so do it from commandline.
Then you have to create a web.config file in the acme-challenge folder which contains:
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.webServer>
<staticContent>
<mimeMap fileExtension="." mimeType="text/json" />
</staticContent>
</system.webServer>
<system.web>
<authorization>
<allow users="*" />
</authorization>
</system.web>
</configuration>
After this you go to the IIS manager, go to Server - Sites - Your website - Handler mappings.
Make sure you select "view ordered list" from the right pane.
And move "StaticFile" above ExtensionlessUrlHandler*.
After this you run the Tool and if all goes well, you will have a 3rd party certificate trusted by all common browsers that gives you a green bar or green Lock sign depending on which browser you use.
Every 60 days the certificate is renewed by Scheduled task automatically.
Good luck, and safe browsing :-)
Source 1
Source 2
Source 3
Source 4
Labels:
CA,
Certificate,
IIS,
PKI,
Windows Server
Location:Utrecht
Utrecht, Netherlands
07 December 2015
Add Private computer and Lite version options back to OWA
When searching how to brand the OWA page with a server name, i came across this post by Arjan Mensch.
It describes how to add the Lite OWA version and the Private computer options back in to OWA 2013 (and maybe even 2016, but i'm not able to test this).
As you may remember from Exchange 2010, there was an option to choose your privacy mode for the session:
After running these command-lets you need to restart IIS.
To do this for all servers you can run this:
It describes how to add the Lite OWA version and the Private computer options back in to OWA 2013 (and maybe even 2016, but i'm not able to test this).
As you may remember from Exchange 2010, there was an option to choose your privacy mode for the session:
- This is a public or shared computer
- This is a private computer
- Use Outlook Web App Light
Choosing between public or shared means different timeout values for the OWA session.
To bring the public private option back to OWA run in the Exchange powerShell:
Get-OwaVirtualDirectory | Set-OwaVirtualDirectory -LogonPagePublicPrivateSelectionEnabled $true
To bring back the Light version of OWA:
Get-OwaVirtualDirectory | Set-OwaVirtualDirectory -LogonPageLightSelectionEnabled $true
To enable both the "private public" and "Lite" option for several servers in a nice onliner:
Get-OwaVirtualDirectory | Where-Object {$_.owaversion -eq "Exchange2013"} | Set-OwaVirtualDirectory -LogonPagePublicPrivateSelectionEnabled $true -LogonPageLightSelectionEnabled $true
After running these command-lets you need to restart IIS.
To do this for all servers you can run this:
$servers = "server1","server2","server3","server4","server5","server6" foreach ($server in $servers) { restart-service -servicename "w3svc" }
Labels:
Exchange 2013,
Exchange 2016,
IIS,
OWA,
Powershell,
Virtualdirectories
Location:Utrecht
Utrecht, Nederland
Brand OWA 2013 logon page
Just like in Exchange 2007 and 2010, the Outlook web app page can be customized to your needs.
See my previous post about this here.
In my organization we use 6 multi role Exchange 2013 servers, and when logging on to OWA you can't quickly see on which server you ended up.
This can be edited fairly quickly, but keep in mind that all these changes are undone when updating the Exchange systems with a cumulative update (CU).
First you need to go to the following location:
C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\auth
In there you will find a file called "logon.aspx", open it in your editor of choice.
For me that's Notepad++, and on line 272 add the following line:
<p><span style="color: #FFFFFF;">SERVERNAME</span></p>
This will add your servername in white text. So if you want to see it you'll have to select the entire logon page by pressing CTRL + a, then you will see the servername.
Important Note: These edits are overwritten anytime an Exchange Server update is applied to the CAS servers.
This is because every update includes a complete reinstallation of the Exchange binaries, and the logon.aspx file you edited will be overwritten.
Typically, the logon.aspx page rarely changes, so you can usually make a copy of it after you've made your edits and copy it back after the update. However, there are no guarantees that the file will not be changed by an update. If so, you will need to re-edit the logon.aspx file.
After each installation of a cumulative update for Exchange 2013, remember to execute both the UpdateCas.ps1 and UpdateConfigFiles.ps1 Windows PowerShell scripts.
It will save you a lot of trouble, troubleshooting errors with OWA and ECP.
See my previous post about this here.
In my organization we use 6 multi role Exchange 2013 servers, and when logging on to OWA you can't quickly see on which server you ended up.
This can be edited fairly quickly, but keep in mind that all these changes are undone when updating the Exchange systems with a cumulative update (CU).
First you need to go to the following location:
C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\auth
In there you will find a file called "logon.aspx", open it in your editor of choice.
For me that's Notepad++, and on line 272 add the following line:
<p><span style="color: #FFFFFF;">SERVERNAME</span></p>
This will add your servername in white text. So if you want to see it you'll have to select the entire logon page by pressing CTRL + a, then you will see the servername.
Important Note: These edits are overwritten anytime an Exchange Server update is applied to the CAS servers.
This is because every update includes a complete reinstallation of the Exchange binaries, and the logon.aspx file you edited will be overwritten.
Typically, the logon.aspx page rarely changes, so you can usually make a copy of it after you've made your edits and copy it back after the update. However, there are no guarantees that the file will not be changed by an update. If so, you will need to re-edit the logon.aspx file.
After each installation of a cumulative update for Exchange 2013, remember to execute both the UpdateCas.ps1 and UpdateConfigFiles.ps1 Windows PowerShell scripts.
It will save you a lot of trouble, troubleshooting errors with OWA and ECP.
Labels:
Exchange 2007,
Exchange 2010,
Exchange 2013,
IIS,
OWA
Location:Utrecht
Utrecht, Nederland
05 January 2015
Renew Exchange 2010 certificate with internal CA and SSL offloading
Every half year this returns, and almost every time i do this something happens that i forgot from the previous one. So note to myself:
In the Exchange management console go to server configuration and select the server you wish to renew the certificate for:
These are just the basic steps, below i will continue with the strange part.
In the Exchange management console go to server configuration and select the server you wish to renew the certificate for:
These are just the basic steps, below i will continue with the strange part.
After importing the certificate and assigning the appropriate services to it something funny happens.
I think it's some kind of intelligence from Exchange it self, but after importing and assigning the services the settings in IIS are changed on the default website. The SSL setting "Require SSL" is turned on, even when it was off before.(This only applies when you have SSL offloading on your loadbalancer configured)
In my experience it's a good idea to make an excel with all off your current IIS settings.
In case something fails you will know how things where configured.
Labels:
CA,
Certificate,
Exchange 2010,
IIS,
PKI,
Powershell,
WIndows 2008 R2
Location:Utrecht
Utrecht, Nederland
27 October 2014
Exchange 2013 Password Reset Tool
Just like in Exchange 2010 there is a password reset tool, but it's not enabled by default.
See my previous post here.
In Exchange 2013 the same options is present by the change of a registry.
From Petri.com comes the following excellent post:
The configuration to allow users to change their expired passwords involves:
1) Open your Registry Editor (regedit.exe)
2) Browse to the following key:
HKey_Local_MachineSystemCurrentControlSetServicesMS Exchange OWA
3) There should be a REG_DWORD Value String of “ChangeExpiredPasswordEnabled”, and that key has a value of “1”. You can change this key manually. If the key should be active but has a value of zero (0), make sure you set it to “1”.
2) Browse to Server / Sites / Default Web Site / OWA.
3) Select “HTTP Redirect” and open its properties.
4) Make sure the HTTP redirect checkbox is not checked.
5) Browse to Server / Sites / Default Web Site / OWA.
6) Select “Authentication” and then select Basic Authentication.
7) Right-click Edit.
8) In the Default Domain field text field, enter a backslash – ““.
9) Save your settings and close the IIS Admin Console.
10) From a command prompt with Admin rights, run “IISReset /noforce” to reset the IIS services. In some scenarios the IISReset will fail, in which case you can try to manually restart the “Worldwide Web Publishing Service”. If you can’t manually restart, execute a reboot of the server as last resort.
1) From a Domain Controller in your domain (or from an admin workstation with the RSAT tools installed), open the Group Policy Management Editor.
2) Browse to Default domain policy. Right-click and select Edit. (Note: depending on your environment, it could be a best practice to create a specific GPO for the password policy settings)
3) Next, browse to Computer Configuration / Policies / Windows Settings / Security Settings / Account Policies / Password Policy.
4) Change the Minimum Password Age to “0”. This setting refers to the number of days a user must have used his password before it can be reset. In the lab environment we set this to zero to make it effective immediately. In your environment this policy setting could be different.
5) Lastly, we will force our demo mailbox user to have his or her password changed. This is done via the Active Directory Users & Computers / user account / properties / User must change password at next logon path.
Please note: Make sure that both the “user cannot change password” and “Password never expires” settings are disabled. Otherwise the change password feature in OWA won’t work.
2) Enter your AD mailbox user credentials.
3) You will receive a notification that your password has expired and will be prompted to enter your old/new password.
4) After successfully entering your new credentials, you will be informed you have to re-authenticate using the new credentials. After that, your mailbox user should have logged on to his or her OWA environment successfully.
Source
See my previous post here.
In Exchange 2013 the same options is present by the change of a registry.
From Petri.com comes the following excellent post:
The configuration to allow users to change their expired passwords involves:
- Setting the appropriate registry key on your Exchange 2013 CAS Servers
- Configuring settings within IIS on your Exchange 2013 CAS Servers
- Configuring correct password policy on AD domain level
1. Set appropriate registry key on the Exchange 2013 CAS Servers
This registry key is not terribly different from Exchange 2010.1) Open your Registry Editor (regedit.exe)
2) Browse to the following key:
HKey_Local_MachineSystemCurrentControlSetServicesMS Exchange OWA
3) There should be a REG_DWORD Value String of “ChangeExpiredPasswordEnabled”, and that key has a value of “1”. You can change this key manually. If the key should be active but has a value of zero (0), make sure you set it to “1”.
2. Configure settings in IIS on your Exchange 2013 CAS Servers
1) On your Exchange 2013 CAS Server(s), open the IIS Admin Console.2) Browse to Server / Sites / Default Web Site / OWA.
3) Select “HTTP Redirect” and open its properties.
6) Select “Authentication” and then select Basic Authentication.
7) Right-click Edit.
8) In the Default Domain field text field, enter a backslash – ““.
9) Save your settings and close the IIS Admin Console.
10) From a command prompt with Admin rights, run “IISReset /noforce” to reset the IIS services. In some scenarios the IISReset will fail, in which case you can try to manually restart the “Worldwide Web Publishing Service”. If you can’t manually restart, execute a reboot of the server as last resort.
Sponsored
3. Configure correct password policy settings at Active Directory domain level
Please note: The following settings are valid in a lab environment and updated to demonstrate the specific scenario where we want OWA to prompt a user to reset his or her password upon logon. In the lab environment this was accomplished by setting “change password at next logon.” In your environment it could be based on password expiration policy. In the lab we set it to a “zero day policy” that forces users to reset their password immediately.1) From a Domain Controller in your domain (or from an admin workstation with the RSAT tools installed), open the Group Policy Management Editor.
2) Browse to Default domain policy. Right-click and select Edit. (Note: depending on your environment, it could be a best practice to create a specific GPO for the password policy settings)
3) Next, browse to Computer Configuration / Policies / Windows Settings / Security Settings / Account Policies / Password Policy.
4) Change the Minimum Password Age to “0”. This setting refers to the number of days a user must have used his password before it can be reset. In the lab environment we set this to zero to make it effective immediately. In your environment this policy setting could be different.
5) Lastly, we will force our demo mailbox user to have his or her password changed. This is done via the Active Directory Users & Computers / user account / properties / User must change password at next logon path.
Please note: Make sure that both the “user cannot change password” and “Password never expires” settings are disabled. Otherwise the change password feature in OWA won’t work.
Final Step: Test the change password feature from within the OWA logon page
1) Open up our OWA logon page by going to https//<servername>/OWA2) Enter your AD mailbox user credentials.
3) You will receive a notification that your password has expired and will be prompted to enter your old/new password.
4) After successfully entering your new credentials, you will be informed you have to re-authenticate using the new credentials. After that, your mailbox user should have logged on to his or her OWA environment successfully.
Source
Labels:
Active Directory,
Exchange 2013,
IIS
Location:Utrecht
Utrecht, Nederland
12 January 2014
After Exchange 2010 SP3 RU4 OWA & Active Sync are messed up
After installing Exchange 2010 SP3 RU4, webmail and Active sync stopped working.
External access to our webmail page was impossible.
Turns out that the update had made some configuration changes for us, THANKS!!! not
The hardware load balancer in our environment does SSL offloading.
So the SSL options in IIS are turned off.
The RU4 update however thought it was a good idea to turn on SSL for the default web site on both CAS-HUB servers. Result, no way to get in to the webmail and get active sync to work.
Turn the SSL off and a few minutes later we were good to go.
Once again, spank you Microsoft for undocumented features and making my free sunday even shorter.
A well back to the last 2 servers that need to be updated, I got some errors in those too, so I think in about an hour or so there will be another rant from me.
External access to our webmail page was impossible.
Turns out that the update had made some configuration changes for us, THANKS!!! not
The hardware load balancer in our environment does SSL offloading.
So the SSL options in IIS are turned off.
The RU4 update however thought it was a good idea to turn on SSL for the default web site on both CAS-HUB servers. Result, no way to get in to the webmail and get active sync to work.
Turn the SSL off and a few minutes later we were good to go.
Once again, spank you Microsoft for undocumented features and making my free sunday even shorter.
A well back to the last 2 servers that need to be updated, I got some errors in those too, so I think in about an hour or so there will be another rant from me.
Labels:
Exchange 2010,
IIS
Location:Utrecht
Utrecht, Nederland
Subscribe to:
Posts (Atom)