Security-Kerberos Event ID 4‏

Hi guys, had a recent issue at a site where we couldn't access the root domain via the FQDN path. Accessing SYSVOL, NETLOGON and DFS shares were okay though.

Here's the message you get in Event Viewer when it errors:

The Kerberos client received a KRB_AP_ERR_MODIFIED error from the server <ComputerName>$. The target name used was cifs/<DomainName>. This indicates that the target server failed to decrypt the ticket provided by the client. This can occur when the target server principal name (SPN) is registered on an account other than the account the target service is using.

This error message would occur on any domain joined computer.

To fix this, find an account which may have the SPN ‘host/<DomainName>’. This was our case as it was populated on our ADFS service account (not sure if this was manually added or automatically during the ADFS setup). Removing this had resolved the problem and we were able to browse to the root domain again.

Hope that helps!

-A

Securing your Windows server for secure web server publishing

I have been looking into securing our published websites for our newer builds quite recently. Found a neat site - Qualys SSL Labs which provides a SSL testing service.

I used this site to test our published HTTPS sites and found that most of them are insecure, and some scoring very badly :(. You can test your website at https://www.ssllabs.com/ssltest/. This will grade your site from A+ to F.

Generally with the newer versions of IIS (provided with 2012 onwards are generally okay), but it still leaves a lot to be desired. Running the test on my site provided feedback that we were supporting weak ciphers which can compromise secure communications. Currently with default settings our servers were scoring B-.

To remedy this, you should disable the following weak cipher suites on your published server:

  TLS_RSA_WITH_RC4_128_SHA
  TLS_RSA_WITH_RC4_128_MD5
  TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P256
  TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384_P384

To disable the weak ciphers, you will need to go into the local Group Policy editor, or create a new domain Group Policy, browse to 'Computer Configuration\Administrative Templates\Network\SSL Configuration Settings' and enable the 'SSL Cipher Suite Order'. This will populate the string with the default set of cipher suites. Copy this out to notepad and remove the weak cipher suites from the comma delimited string. This will enable the listed cipher suites in a preferred order.

There are a few references online for a preferred order. I'm personally using the list at hass.de (reference at bottom of post) to configure the cipher suite order. In the PowerShell script is the list of cipher suites, just copy this out and put it into the Group Policy.

Once you have enabled the policy and linked to the published server you will need to gpupdate and reboot the server. Once rebooted, you should be able to test your server at the Qualys SSL Labs server test page and score an A- grade.

To get A grading you will need to enable Perfect Forward Secrecy. This is where the great work done at hass.de comes into play. Use the script provided at hass.de (reference at bottom of post) and run it. This should disable the weak cipher suites and enable the secure ones. Coupled with the Group Policy this should get your published server to get an A rating on the server test.

One of the warning/errors you may receive is: Downgrade attack prevention No, TLS_FALLBACK_SCSV not supported, this cannot be currently resolved for IIS as TLS_FALLBACK_SCSV is not supported by IIS apparently, we will need to wait for this to be supported in the future.

Hope this helps in securing your servers! 

-HTTPS everywhere supporter.

Reference: https://www.hass.de/content/setup-your-iis-ssl-perfect-forward-secrecy-and-tls-12

Windows 10 Search not working after sysprep

I have recently been on a project rolling out Windows 10 to a client. A problem that we faced after building our Windows 10 image was the search function not working - or Cortana Search!

Our environment was setup with 2K12R2 servers and a WDS setup with unattend XMLs for configuration.

Everything went well until we tried searching after imaging a whole lab of machines... What a mistake that was.. Luckily after some Googlefu and urgent searching a result showed up for unattend XMLs and Cortana Search not working.

Long story short, don't use the CopyProfile parameter in your unattend XMLs as this somehow breaks the Cortana Search app and stops your search from working!

Good luck out there!

TLDR; Don't use the CopyProfile switch in your unattend XMLs. This breaks Cortana Search, only fix is to re-image the machine.

Windows OS lost it's product code/activation status

Ever had the problem where your Windows OS lost it's activation status and product code? Well I have, its happened a few times but were easily fixed by using slmgr and the -ipk switch to reinstall the KMS client key or MAK key... Except this one stubborn server...

One of our servers had lost it's activation status and dropped it's product code. We tried the usual slmgr -ipk to reinstall the product code but that didn't work. Also tried the slmgr -upk, slmgr -cpk, slmgr -ato to no success. There was a slmgr switch that looked very promising, slmgr -rilc which should reinstall all the last known good keys. rebooting the server and trying to activate afterwards still didn't work...

Out of some obscure corner in Google I managed to find something that actually worked.

  DISM /Online /Cleanup-Image /RestoreHealth

This apparently fixed a component store corruption (which probably was something to do with the Software Protection service). I then ran a sfc /scannow for good measure (probably not needed). Bounced the server and all was good.

The product code was showing up and we could then use slmgr /ipk to reinstall the KMS client and get our server activated. Remember to keep your servers happy, when they aren't all sorts of weird stuff goes down!

TLDR; Use 'DISM /Online /Cleanup-Image /RestoreHealth' to fix the component store corruption which broke the activation process.

Office 365 Smart Links!!!

21/8/2015 UPDATE: Added in a forced redirect to the portal landing page smart link.

We have been using Office 36 smart links for a while on our client sites (they want things simple!). I had a look into this a few years ago and managed to get the smart links working to all the tabs that are usually required in Office 365. 

One of our clients had complained that the smart links no longer worked (I double checked these and there was an intermittent failure). Double backing on my research I found that something happened recently that stopped the old smart links from initiating properly.

If you are here, you probably know that the smart links pointed you to your federation service for SSO then redirected you back to the wreply address in the smart link itself. Here is an example of the old smart links that recently broke:

https://login.microsoftonline.com/login.srf?wa=wsignin1.0&whr=<SSO FQDN>&wreply=https:%2F%2F<Tenant ID>-my%2Esharepoint%2Ecom%2F%5Flayouts%2F15%2FMySite%2Easpx?MySiteRedirect=AllDocuments

<SSO FQDN>, e.g. sso.yourdomain.com, idp.yourdomain.com

The link above, if correctly populated would initiate a Single Sign On to federation service then take you into your OneDrive for Business page.

This link no longer worked. After some testing and remembering that something obscure about portal redirection for a custom themed portal page, I figured out the new smart links! The <SSO FQDN> needed to be changed to <Domain Name>. Once updated, it started working again :) success!

Here is a list of my currently working smart links. Just populate it with your required domain name and Office 365 Tenant ID.

<SSO FQDN>: e.g. sso.yourdomain.com, idp.yourdomain.com

<Domain Name>: e.g. yourdomain.com, microsoft.com

<Tenant ID>: e.g. myoffice365tenant.onmicrosoft.com - the bold part if your tenant ID

Office 365 Portal

https://<SSO FQDN>/adfs/ls/?wa=wsignin1.0&wtrealm=urn:federation:MicrosoftOnline

Forced redirect to portal landing page
https://login.microsoftonline.com/login.srf?wa=wsignin1.0&whr=<Domain Name>&wreply=https:%2F%2Fportal.office.com%2Flanding.aspx%3Ftarget%3D%252fHome

Outlook

outlook.com/owa/<Domain Name>

OneDrive for Business

https://login.microsoftonline.com/login.srf?wa=wsignin1.0&whr=<Domain Name>&wreply=https:%2F%2F<Tenant ID>-my%2Esharepoint%2Ecom%2F%5Flayouts%2F15%2FMySite%2Easpx?MySiteRedirect=AllDocuments

Sites

https://login.microsoftonline.com/login.srf?wa=wsignin1.0&whr=<Domain Name>&wreply=https:%2F%2F<Tenant ID>-my%2Esharepoint%2Ecom%2F%5Flayouts%2F15%2FMySite%2Easpx?MySiteRedirect=AllSites

Personal SPO/Newsfeed

https://login.microsoftonline.com/login.srf?wa=wsignin1.0&whr=<Domain Name>&wreply=https:%2F%2F<Tenant ID>-my%2Esharepoint%2Ecom%2Fdefault%2Easpx

Happy smart linking!

Office 2016 for OSX not signing in/activating with and Office 365 account

Hey all, just had a recent problem with our OSX clients being unable to activate the latest Office 2016 suite with their Office 365 accounts. I had seen this problem before but there are so many other variables to look into when trying to fix sign in problems.

Your first step should be the https://testconnectivity.microsoft.com/ website which is good for determining most problems with your setup.

I thought this may have been an infrastructure problem where the ADFS 2.0 server was not updated with the latest Roll Up. Apparently that was not the case this time round.

Another problem would have been the time, but no problem there! Time was perfectly in sync.

Just having a wonder around and I found something that was interesting. Apparently Forms Based Authentication needed to be turned on for the intranet domain in ADFS 3.0. It was working perfectly well before but it looks like something had changed with how Office 2016 on Mac was trying to authenticate.

The problem is indicated with this error on the OSX client:

And these errors show up in the ADFS 3.0 logs:

Error AD FS 364
Encountered error during federation passive request.

Additional Data

Protocol Name:
wsfed

Relying Party:
urn:federation:MicrosoftOnline

Once you enable Forms Based Authentication for the Intranet this problem should disappear! Only minor problem with this is that it's not truly single sign on as you are still prompted for credentials inside the domain.

To enable Forms Based Authentication open your ADFS 3.0 server management console > Authentication Policies > Edit Global Settings then enable Forms Based Authentication for the Intranet,

Hope that helps :)


TLDR; Enabled Forms Based Authentication for the Intranet on the ADFS 3.0 management console.

ActiveSync not working through Web Application Proxy after certificate renewal

I've recently had a hairy problem with a ActiveSync on Exchange 2010. Funnily enough this happened after a certificate renewal...

Just some background on this so you know where I'm coming from. Our client had decommissioned Forefront TMG (may it rest in peace/pieces) and was in need of a reverse proxy server. Luckily they had an ADFS 3.0 server setup for Office 365 domain federation so we made use of the Web Application Proxy.

Initially the transition worked great! Everything was hunky-dory, everything just worked.

Then came a notification for a certificate renewal... Cert gets renewed, applied to services, and tested for everything except ActiveSync... (bad oversight, this is now in my to check list when working with certificates).

A few weeks later after the renewal the problem becomes more apparent as people actually used the ActiveSync (funnily enough it took them that long to realise this). Wondering what went wrong I tried running through an ActiveSync setup on an Android phone and iPhone... neither worked. Then I tried on a Windows Phone... a miracle, it worked! But why not on the others?!?! Started testing 3rd party clients, Outlook for Android failed while the Nine mail client worked... More anger and frustration ensues...

Thinking it could possibly be something to do with Exchange, I patched it to CU9 in hopes that this would automagically correct the problem. No kudos. After taking a break and freshening up my thinking I eliminated the web application proxy from the equation by directing requests directly to the Exchange server, and wah-lah, ActiveSync is working! Put the requests back through the web proxy and sad faces, not working.

This left the web application proxy server as the culprit. After doing some Google-fu something interesting popped up. This command:

  netsh http show sslcert

Running this it returned something that was gone, a certificate bound to 0.0.0.0:443 that no longer existed! Find the binding with the bad certificate and make a note of the appid as you'll need to rebind the port with this appid.

To fix this I removed the binding for 0.0.0.0:443

  netsh http delete sslcert ipport=0.0.0.0:443

Then recreate the binding with:

  netsh http add sslcert ipport=0.0.0.0:443 appid={xxxx} certhash=xxxx

xxxx is the GUID of the appid and certhash is the thumbprint of the new certificate.

I had some problem in getting this to execute so I completed the same command inside the netsh CLI.

Once bound the ActiveSync started working on Android and iPhone with the native mail clients.

My life was spared - mail could now be had on mobile devices for all!

TLDR: Remove old SSL binding that references an old/removed certificate then re-create the SSL binding with the new certificate.