Office for Mac – unable to access OneDrive for Business

This problem occured and caused a great deal of problems when I was trying to move forward with our own internal IT setup preventing me utilising Microsoft’s OneDrive/Sharepoint services.

After much searching I finally found the file I needed to reset in order to correct the issue I was having.

A couple of steps should however be tried first.

  1. Sign out of all Microsoft applications, i.e. Word, Excel, etc.
  2. Close ALL Microsoft applications.
  3. Removing cached/stored passwords for Microsoft’s application from the ‘Keychain’. Open Keychain and search for ‘Office’, ‘adal’ and ‘onedrive’ removing the appropriate entries.
  4. Delete the MicrosoftRegistryDB.reg:

EAP WAP Setting

Wireless Advanced Settings

  • Beacon Interval (milliseconds) WiFi routers use these “beacon” signals to help keep the network synchronized and many default to 100ms. Setting a lower (e.g. 50 or 75ms) interval might help your WiFi network to hold its connection with other devices, albeit at a cost to some battery life on other devices. By contrast raising the setting above 100ms could save power but the likelihood of connectivity problems may increase.
  • RTS Threshold (Request To Send) The RTS Threshold protocol is a tricky one to explain, but it helps to clear the channel before data is sent. A lower setting may help in busy WiFi environments as it should reduce collisions, but set it too low or incorrectly and your network performance may suffer. It’s a tricky balancing act to get right.
  • Fragmentation Threshold Any data packets larger than the size programmed in this field will be fragmented. Setting smaller packets than the default can improve reliability, especially in busy environments, albeit at the cost of performance. Again, we wouldn’t touch this or the RTS threshold unless you’re comfortable with making such tweaks and always make a note of your settings so you can swap them back if it doesn’t work.

The Hidden Sonos Web Interface

Sonos ConnectGetting started

Sonos controllers interact with the players through the HTTP protocol. It is actually possible to directly use this underlying interface to communicate with the players without being limited by the feature set made available in the controller.

In order to access this interface, you first need the IP address of the player you want to interact with. It is listed in the “about my Sonos system” menu of the Sonos controller. We’ll refer to it as <sonos_ip> below.

Status Screen

The status screen can be used to gain insight into the player setting, its hardware, and its environment. It is available at the following URL:


The screen displays a large collection of submenus that you can explore at your leasure. Many of these menus such as ‘dmesg’, ‘netstat’, and so on will be familiar to Unix users since they display the result of the corresponding command (Sonos players run the Linux operating system internally).



Support Screen

The support screen is available at the following URL:


It will print one link per player, as well as one link for the controller and one for the network matrix.

Player Name 1 (RINCON_000E5812345671400)

Player Name n (RINCON_000E5876543211400)
Network Matrix

The information available under each player name is very similar to the one provided by the status screen of that particular player. I haven’t yet looked carefully into the Controller menu.

The last link, the network matrix, is extremely useful to diagnose wireless connectivity issues. It looks like this:

Sonos network matrix

Colors in the left column denote the ambient RF noise seen by the Sonos unit. Colored cells in the body of the matrix indicate the state and strength of the ‘tunnels’ across the mesh:

  • A gray cell means that the Sonos isn’t sending data wirelessly between the 2 units. This is expected if the 2 players are connected through a network cable, as the wired connection is typically more reliable and therefore preferred to a wifi path.
  • A green, yellow, or red cell indicate an active path. The actual color is used to encode the strength of the wireless signal.

OFDM signal levels go from 0 to 5, where 5 is best and 0 is way too low to get a reliable connection. Noise floors are typically in the [-80 -110] range, where -110 is considered excellent and -80 bad.

If a unit isn’t sending or receiving data wirelessly (i.e. the corresponding row and column in the matrix are both gray) the wireless adapter can be turned off to save power and reduce wireless interference.

Rebooting the player

Accessing the following URL will trigger an immediate reboot of the player:


Troubleshooting Network Connectivity

Sonos offer 3 traditional network debugging tools (ping, traceroute and nmblookup) from this URL:


Controling the WiFi network link

The WiFi link can be enabled or disabled through the wifictfl URL. If the WiFi is turned on, it will use different frequency channels based on the region in which the player was sold. For example, the use of channels 12 through 14 is not allowed in the United States. You can update this setting at the following URL:


Fixing Exchange 2010 WinRM MaxEnvelopeSize Exceeded Error

  • The WinRM client sent a request to the remote WS-Management service and was notified that the request size exceeded the configured MaxEnvelopeSize quota
  • The response that the WS-Management service computed exceed the internal limit for envelope size.
  • The WS-Management service can not process the request. The computed response packet size < > Exceeds the maximum envelope size That is allowed < >.

Needless to say, it didn’t seem very relevant since I was using the Exchange Management Console MMC snap-in on the local server.

Long story short, I needed to adjust the MaxEnvelopeSize of WinRM and adjust it in IIS (which almost every other guide neglects to mention).

  1. Open an elevated command prompt and run winrm get winrm/config. Note what the MaxEnvelopeSizekb currently is. This is how large the command/output can be.
  2. Let’s set the MaxEnvelopeSizekb to something very large, like 8192. We can do this by running winrm set winrm/config @{MaxEnvelopeSizekb="8192"}.
  3. Based on the output of the previous command, you should now see the MaxEnvelopeSizekb set to 8192
  4. Navigate to your Exchange install directory (likely C:\Program Files\Exchange) and go to the ClientAccess\Powershell folder. Find the file named web.config and take a backup of it.
  5. Now open web.config in notepad (or Notepad++). Find the OperationsConfiguration line and add/modify the MaxEnvelopeSizeKB value to be 8192 (matching what we set WinRM to).
  6. Run IISReset from the command line.
  7. You should now be able to modify the receive connector or whatever else you were trying to do in the Exchange console!



Incoming emails or sending documents to SharePoint document libraries has been one of the most loved features of SharePoint by business users for long. This has been there since SharePoint 2007 and all on-premise versions including the latest SharePoint 2016. Even though, it requires quite some steps and infra components to do the initial setup, once running, it gives business users real ease of uploading documents to SharePoint library directly from their mail client like outlook.

With more and more companies looking to move to SharePoint Online, lack of this feature always comes as a tricky discussion between IT and business users. In on-premise system, they can just enable any document library for incoming mails and even control who can send documents via mail.

On Prem Setting

but unfortunately this feature is not available in SharePoint Online yet.

Alternate Solutions

Obviously, since this issue has been there for sometime now, SharePoint experts came up multiple workarounds like these. But none of these seem to fit the exact requirement easily, except last one which mentions Microsoft Flow.

The solution we are going to discuss today will use Microsoft Flow that can potentially provide almost similar functionality (with some drawbacks) with least efforts.

Microsoft Flow

We can make use of Microsoft Flow to create a simple flow which will read mails from a Shared Mailbox in Exchange Online, get the attached documents and upload those in the SharePoint Online document library.


  • An Office 365 account with Flow license assigned
    • This account needs to be exchange administrator and user management administrator or Global administrator of the tenant. Alternatively, you can ask an existing administrator to perform the tasks
  • A shared mailbox for each document library which needs to be mail enabled
  • A SharePoint Online Site Collection with Document Library

Create a Shared Mailbox

Our first step is to create a shared mailbox that will be used as a mailbox for one specific SharePoint document library. You can also use any personal mailbox for this purpose, but since Shared Mailboxes don’t require licenses assigned, that’s a better choice.

If your account has exchange administrator permission (or global admin of tenant), then you can follow the steps yourself or ask any admin to do it for you.

  • Go to Office 365 Admin portal
  • Browse to Exchange Admin Center
  • Select “recipients” from left nav, shared from top menu and click on the “+” icon

Mail Box Creation

  • Enter the Display name, email address to be used for the document library and the accounts under which the flow will run and click OK.

Mail Box Creation-2

Now, we have a shared mailbox created on which users will send mails with attachments to store documents in corresponding SharePoint document library.

Reset Password

To use this mailbox in Microsoft Flow, we need to get the password for this newly created mailbox.

  • Go to Office 365 Admin Portal and Click on Active Users from left menu
  • Search for the newly created mailbox

Search Mail boxes User

  • Once found, click on the name to open the properties window
  • Click on Reset Password and set a new password for this account

Reset Password

Create Flow

Now that we have the required mailbox and it’s password in place, lets go ahead and create our flow.

  • Go to Microsoft Flow and login with your Office 365 account. This account need not be the same mailbox account.
  • Click on My flows and then on Create from template

My Flow

  • In the next page, search for the required template by typing in “save my email attachment to sharepoint document library” and press enter
  • You would see one template appearing. Click on that template

Search Flow Template

  • It will show another page with source information and if with the given credentials, it could connect to those sources (exchange and sharepoint) or not.
  • If all is good, then you would see green icons next to each source. Click on Continue to create the flow

Create Flow From Template

  • At this stage the flow gets created, but the required fields do not have actual values which we want.


Configure Flow

Now that we have our flow created based on the desired template, we can configure it to read the attachments received in the mailbox that we created and upload to the document library of our choice.

Configure Source

We first need to configure the source which will trigger the flow to start. This mean, when any new mail is received. For this we want to monitor the shared mailbox created earlier. So, we need to add that account under my connections. Click on the three dots (…) and click on Add new connection.

Add New Connection

It will pop-up a credential login window. Login with the email ID of the shared mailbox and password created earlier.

Once created, you can see that added under My connections

Added New Connection

Once the connection is added, we need to configure which folder to look into the incoming mails. So, click on the folder icon next to the text box with screen tip as “mail folder to check for new emails” and select Inbox from the menu. You may also want to select Has Attachment and Include Attachment to yes to ensure this flow only triggers when the incoming mail has any attached documents.

Show Picker

So now the source is set. Let’s configure SharePoint part.

Select the Site URL either from dropdown or just by typing it in the site URL in Site Address and then the document library in the Folder Path field and click Save Now.

Select SP Lib

You will get this success screen, click Done.

Click Done

Now are flow is configured, enabled and ready to run whenever a mail is received in our shared mailbox.

Flow Created


Now that all is configured, let’s send a mail to our shared mailbox and see if our flow works as expected. From our outlook or any other mail client just attach a sample document and sent that to the email id of the shared mailbox.

Send Mail To SPO

It may take a few minutes, before you can see the flow gets triggered. wait for 5-15 minutes and then check your flow. It should come up as succeeded under Run History.

Flow Executed

Now, it’s time to look into our SharePoint document library which we had configured in the flow and find out if that attached document was uploaded. You would see the document was uploaded and modified by would appear as the same account under which the flow gets executed.

Document Uploaded

So, all good. We have a SharePoint document library to which we can send documents via mail. For each such document library, we can create a new shared mailbox and a flow. You can share this flow with your colleagues to make it a Team Flow, so that they can also monitor and manage it.


Even though this incoming mail solution for SharePoint Online works with less than 15 minutes of effort, it still lacks many features which are there in on-premise version out of the box.

  • For simplest implementation, a separate shared mailbox needs to be created for each library, so there is a dependency of exchange administrator.
  • To reset the password, there is a dependency of User management administrator
  • Either some admin needs to configure all flows for all required email enabled libraries or corresponding site admins should have the technical knowledge to be able to do it themselves.
  • It is not easy to restrict permissions to the users who have permissions to upload in the corresponding document libraries. Specially, if there are large number of such users are there.


I will just summarize by saying Microsoft Flow provides a really easy and useful way to configure incoming mail feature in SharePoint Online. For me this is a preferred solution, as it doesn’t require users to move to Microsoft Groups, Teams etc. and provides the same document upload experience as in their existing SharePoint sites.


Creating Custom Secure LDAP Certificates for Domain Controllers with Auto Renewal

with Thanks to Russell Tomkins [MSFT]

Working with customers each week on securing their Active Directories, there are some procedures you end up doing regularly. Installing and configuring custom certificates onto Domain Controllers to enable LDAP over TLS for me is one of them. The primary reason for enabling this functionality is to allow third-party applications that aren’t capable of performing secure binds or encrypted LDAP sessions (over TCP 389) to connect securely. Trust me, there are plenty of applications that need it.

Example Deployment Scenario

Along with deploying these certificates, most customers like to place some form of load balancer in-front of these DCs to ensure applications will always have high-availability access. This method generally involves a custom alias such as “” targeted at the load balancers with connections then forwarded to a subset of DCs.

Important Note: The load balancer method of enabling highly available LDAP access is NOT supported by Microsoft, but it does work. To be fully supported, applications need to be using our documented methods to locating and binding to DC’s. If an application is misbehaving, be ready to abandon this configuration if deeper application troubleshooting is required.

As with all TLS connections, if you attempt to connect to any server where the subject name mismatches, the connection will fail validation. Most admins are familiar with the errors associated with this scenario when deploying HTTPS. So to allow our application servers to bind securely to a custom LDAP DNS name and ensure connections are valid with the correct name, we need to ensure the custom LDAP DNS name is present in our Domain Controller certificates. Easy enough to do with some prep, impossible to do automatically. But that’s why your here right?

Our Domain Controllers by default will use one of the 3 built-in certificate templates for LDAP over TLS purposes. These templates were introduced consecutively with each OS release. The templates are the:

  • Domain Controller (Windows Server 2000)
  • Domain Controller Authentication (Windows Server 2003)
  • Kerberos Authentication (Windows Server 2008 and above)

Our modern domain controllers can use any one these 3 certificate templates, however we really want your DC’s to be using the Kerberos Authentication template. By default, it includes multiple SAN entries that represent the Domain Controller, Active Directory Domain FQDN and the Active Directory NetBIOS name. Additionally it contains a new Enhanced Key Usage to allow strict KDC validation to be enabled on all modern clients that are performing smart-card based (PKINIT) logons.

This walk through is going to leverage a fairly unknown feature of the auto enrollment component in Windows that allows certificates requested from an Offline Template (that is one where you provide the subject names in the Certificate Signing Request or CSR) to be automatically renewed without CA certificate manager intervention. The method described can actually be used for any certificate template where you want the auto enrollment component to automatically renew certificates and keep the existing subject names.

Note. This procedure only works for machines and Enterprise Issuing CA’s that are at least Windows 7 /2008 R2 or above.

Lets get started.

Certificate Authority – Certificate Template Prep

To make this work, we need a slightly modified version of the “Kerberos Authentication” template. In this example, we are going to configure a custom template for our “Special DCs” DC’s that are going to be targeted by our load balancers. All other DC’s will continue to use standard Kerberos Authentication template.

  1. On your Enterprise Issuing CA, open “certsrv.msc” and right-click the “Certificate Templates” folder and select “Manage”. This will show you all the templates present in the Active Directory forest.
  2. Scroll down until your find “Kerberos Authentication. Right-click it and select “Duplicate”
  3. If you are on 2012/2012R2, you will be presented with the compatibility screen. Unless you know what you’re doing with version 3/4 templates, simply select “Windows Server 2008 R2” and “Windows 7/Windows Server 2008 R2” for both of the options and select OK on the confirmation prompts.
  4. On the “General” tab, give your new template the name “Kerberos Authentication (Offline Request)”. In production environments, prefixing the name with a few letters can help group your active templates together in the UI, recommended but optional.
  5. Now, to make it an Offline Template, simply head over the “Subject Name” tab and select the top radio box “Supply in the Request”. Click OK on the security warning prompt. Please read an understand this prompt. In our scenario, only DCs have the ability to request this certificate, but with other certificate templates, the ticking of this box should be done only if restricted and trusted users can request the template.

    Use Subject in Auto Enrollment Renewals

    Use Subject in Auto Enrollment Renewals

  6. Also on the “Subject Name” tab, tick the “Use subject information from existing certificate for autoenrollment renewal requests”. This tick box is critical to the “magic sauce” that allows the CA Policy engine to reuse the existing certificate subject name values instead of being provided as brand new ones in the CSR. (This is an offline request, the names can’t be built from Active Directory)
  7. Next, open the “Security” tab and remove the “Enroll” security right from “Domain Controllers”,”Enterprise Domain Controllers” and “Enterprise Read-only Domain Controllers”.
  8. Add new ACE’s for each of the special DC’s (or possibly a security group with them in) that are to receive the custom certificates and ensure they have the “Read” and “Enroll” security right only. Check that no other entries include Enroll or Autoenroll except administrative user groups. Make sure you enable “Computer Objects” in the select objects prompt.
  9. Optional. For advanced players, head over to the “Superseded Templates” tab and add the “Domain Controller”, “Domain Controller Authentication” and “Kerberos Authentication” templates to the list. This will “archive” any certificates from those templates when this new one is enrolled. Note. Archived = hidden, not deleted.
  10. Close the new template to save it.
  11. Now that our new template for the “special” DC’s is ready to go, open the original “Kerberos Authentication” template and the security tab. Add the Deny “Enroll” and “Auto Enroll” right to the special DC’s you are giving custom certificates to. This will stop them from getting the standard Kerberos Authentication certificates during the auto enrolment process.
  12. As per normal, we need to actually issue the template. Right-Click “Certificate Templates” again and select “New” and “Certificate Template to Issue”
  13. From the list, select your newly minted “Kerberos Authentication (Offline Request)” template and click OK.
  14. Optional – If both the original “Online” and our new “Offline Kerberos Authentication” templates are present in the issuance list, remove the older “Domain Controller” and “Domain Controller Authentication” templates. Simply right-click them and select “Delete”. This doesn’t remove template itself from Active Directory, just their issuance from this particular CA. If you have multiple CAs, it’s a good idea to remove their issuance form them as well. Should you issue the “Kerberos Authentication” templates from multiple CAs? You can, but not really required.

Domain Controller – GPO Prep

OK, so I’m not going to into to much depth on this one as it’s pretty simple. Auto Enrollment is usually configured in a Domain Controller Policy by the GPO settings at this location ” \Computer Configuration\Windows Settings\Security Settings\Public Key Policies\Certificate Services Client – Auto-Enrollment”. Most orgs already have this enabled and you simply need to confirm that both the first and second check box “Update certificates that use certificate templates” is enabled.

It’s completely up to you if you want this GPO purely targeted at your special DCs or all of your DCs

Warning. If you are enabling Auto Enrollment for the first time, you may receive other “unexpected” certificates on your DC’s. You can prevent this by analysing the security tab of all certificate templates currently being issued by your CAs and ensuring that any of the “Domain Controller” computer groups have not been granted the “Auto Enroll” security right. But that wouldn’t happen because you know the security DACLS of all your templates right? No? … well pencil some time for a quick review in the near future.


Auto Enrollment Group Policy Settings

 Domain Controller – Initial Enrollment

Because we need to provide the extra subject names, the initial certificate enrollment for our special DCs must be performed manually.

  1.  On one of our special Domain Controllers, Open “certlm.msc”. If it’s a 2008 R2 DC, you will need to open “mmc.exe” and add the “Certificates” snap-in targeting the local computer.
  2. Right-Click the “Personal” store and select “Request New Certificate”. Click “Next” twice until the screen with available templates appears. Select the check box next to our “Kerberos Authentication (Offline Request)” Template and then click the hyperlink “More Information is required ….” below the name.
  3. Leave the “Subject Name” blank, but add the following to the alternative name section. The first 3 are the names that are added automatically with the built-int template. The last one is our new custom name. They are all of the type “DNS”FQDN of the AD Domain Controller
    FQDN of the AD Domain
    NetBIOS name of the AD Domain
    Your new custom secure LDAP DNS name

    Subject Alternative Names

    Subject Alternative Names


  4. Click “OK” once you have finished adding the names and then “Enroll” to send the CSR to the Enterprise Issuing CA for issuance.
  5. When complete, expand the Personal -> Certificates folder and check out your shiny new cert. Double-click the certificate to open it and confirm the names present in the Subject Alternate Name extension. If there are multiple certificates, you can scroll the console window to the right to see the template names.
  6.  Repeat the process on the other special DCs you wish to create a custom secure LDAP certificate for.

Domain Controller – Verifying renewal will work

So at this point, your special DCs should have the appropriate certificate, but we want to make sure our new automatic enrollment renewal plumbing works. We don’t want auto enrollment renewal to fail in ~11 months’ time due to a slight mis-configuration. We can easily confirm that everything is configured well by increasing the “major version” of the certificate template. When we increase this value, it’s a signal to the Auto Enrollment client on the machine that the CA administrator has requested re-issuance of certificates based on that particular template.

This is where the first and second tick boxes in the auto enrollment client GPO configuration is critical, without it, this particular logic branch will never execute. You may also remember we didn’t initially allow auto enrollment for our special DCs from our new template, this was to stop them from attempting auto enrollment, we need to enable this now. (Sidenote, it’s perfect valid configuration to enable auto enrollment for offline templates. The machines will simply show a balloon pop-up when an administrator logs requesting intervention to provide the subject names)

  1. Open “certsrv.msc” on your Enterprise Issuing CA and right-click the “Certificate Template” folder and select “Manage” to open the Certificate Templates Console.
  2. Open the security tab of our “Kerberos Authentication (Offline Request)” template and simply add the “Auto-Enroll” security right/flag to the existing ACEs for our special DCs. This will allow the auto enrollment client on our special DCs to now consider this template as part of its automatic renewal process and also monitor the template version for update requests. Close the certificate template properties to save it.
  3. Right-click our “Kerberos Authentication (Offline Request)” template and select “Reenroll All Certificate Holders”. If you have a keen eye, you will notice the version will change from something like 100.2 to 101.0. The minor version (the second number) will increase every time you make a change to the certificate template. Increasing the minor version won’t affect already issued certificates. Increasing the major however instructs clients with the second auto enrolment client check box enabled to renew this certificate at their next update cycle. We want to trigger this to ensure everything works a treat.
  4. Back on your DC, feel free to wait around until this occurs or you can run “certutil -pulse”. If you really love your GUI, in the certificates console, right-click “Certificates – Local Computer” at the top of the left-hand tree and select “All Tasks” -> “Automatically Enroll and Retrieve Certificates”
  5. It may take a few minutes, but once it’s completed (all going well), you should be able to analyse the “Certificate Template” field in your “Kerberos Authentication (Offline Request)” certificate and see the major version field matches the increased version of your certificate template. If the version hasn’t increased, confirm your GPO and certificate template settings. See below on how to view your older archived certificates (including any superseded ones)
  6. Once again, validate all your subject names are correct and expected. The next section can make things a little easier.

    Old and New Template Versions

    Old and New Template Versions

 LDAP/S (TCP 636) Validation

One of the good (or possibly bad?) functions of Domain Controllers is that they will pretty much immediately start using the brand new “Kerberos Authentication” certificates for their LDAP/S connections. Because of this, you can check immediately if the certificate is being presented correctly. The easiest way is to download my Domain Controller LDAP/S Certificate Audit script and directly query all of your DC’s. The script will output both to screen and a .CSV for easy analysis.

We primarily want to check that our special DCs have the appropriate updated Subject, V2 Template and EKU extensions with our new values. Not a bad time to confirm the remainder of our DCs are using Kerberos Authentication template certificates as well.

Some Pre-emptive Q&A’s

Q: I only have a few Domain Controllers, can I simply apply this guide to all of them?
A. Yup, even if you have 300 DCs, you can perform this guide on all of them if you wish. It will just take you a while.

Q. What if I want a number of custom LDAP DNS names? Say a unique one for multiple DCs in each of my data-centre locations?
A: Simple. The renewal will simply follow whatever name you enrol in the original enrolment, so simply configure the appropriate custom name on the appropriate DCs

Q: I’m feeling nostalgic and want view my older archived certificates, how can I see them?
A: In the certificates console, right-click the root of the tree then select “view” -> “options”. Tick the “Archived Certificates” button. They will now show up in the personal store again with an “A” in the “Status” column. If you configured supersedence, those certificates will also be flagged as archived.

Q: OK, I’m feeling both nostalgic AND I really want to reactivate my old certificates (for various reasons)
A: No problems, open up a PowerShell prompt and do the following. You should also prevent the template from being re-issued otherwise it will just come back.

cd Cert:\LocalMachine\My
ls -force
$Cert = Get-Item <ThumbprintOfNewCert>
$Cert.Archived = $True
$Cert = Get-Item <ThumbprintOfOldCert>
$Cert.Archived = $False

 Wrapping Up

Not much more to it then that. Your special DCs will now have TLS certificates that have your extra secure LDAP DNS name included and your remaining DCs will have a vanilla Kerberos Authentication certificate with names automatically generated from Active Directory. The critical part of this process is to confirm that the renewal component works as expected. If this section fails, your going to have an outage in 12 months when your certificates expire because they don’t renew correctly.

If you have gotten this far, you should also check out my other blog post on CRL-Freshness for ensuring the CRLs that support your Domain Controllers certificates are always fresh and up to date.

As always, leave a comment if you found this useful or something doesn’t work as expected


Identifying Clear Text LDAP binds to your DC’s

Thanks to Russell Tomkins [MSFT]

If I told you that there was a 90% plus chance that your Domain Controllers allowed receiving credentials in clear text over your network, you would probably wouldn’t believe me. If I went a step further and told you that nearly half of the customers I visit for AD security assessments not only allowed them, but had extremely privileged accounts such as Domain Admins credentials traversing the network in clear text, you would probably think “that wouldn’t happen on my network”, well that’s what they all told me too ?

With a little bit of effort, you can reveal this common scenario very easily.

[Update] If you have 2008 R2, you need this hotfix to ensure the events have the flag which identifies Simple vs Unsigned binds.

A Simple Check

The first step to understanding if your affected is to look for Event ID 2886 and 2887 in your Directory Service log. If any of your Domain Controllers have the 2886 event present, it indicates that LDAP signing is not being enforced by your DC and it is possible to perform a simple (clear text) LDAP bind over a non-encrypted connection. This configuration is controlled by the security option “Domain controller: LDAP server signing requirements”. I nearly always find this setting set to “None”.

Our next port of call is the 2887 event. This event occurs every 24 hours and will report how many unsigned and clear text binds have occurred to this DC. If you have any numbers greater than zero, you have some homework to do. Luckily, the rest of this post will help you do just that.

The core of the issue is this, when an application performs a simple LDAP bind, the username and password is transmitted in clear text in the very first packet. The DC doesn’t even have a chance to prevent this exposure from occurring.  If this connection is notencrypted at a lower layer such as TLS or IPSec, it may be intercepted and a bad day may soon follow.

 OK, how badly am I affected?

Thankfully, we have the ability to increase our “LDAP Interface Events” diagnostic levels on a DC to report when these insecure binds occur. The commands for enabling and disabling are below. Warning: This setting has the ability to create a large number of events into the Directory Service event log. It will also log a number of other LDAP interface errors which may seem extremely alarming, these are normal and don’t freak out too much when you see them. I highly recommend enabling this diagnostic level for a very short period of time (like 1o minutes) during your initial discovery phase. Once you have identified (and remediated) the noisiest offenders, you can begin enabling it for longer periods each time.

# Enable Simple LDAP Bind Logging 
Reg Add HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics /v "16 LDAP Interface Events" /t REG_DWORD /d 2
# Disable Simple LDAP Bind Logging.
Reg Add HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics /v "16 LDAP Interface Events" /t REG_DWORD /d 0

Note: You may need replace the double quotes after copy+paste.

Once we have the 2889 events logged, we can examine them and determine which IP addresses and user accounts are binding insecurely. Looking through them all one by one may take awhile, the following are some resources to help you along.

Custom Event View

Download here -> LDAP Signing Events Custom View (XML)

This custom event view that can help you easily isolate “LDAP Signing Events” on your DC’s Once imported, it will create a nice filtered view of all of the relevant LDAP signing events (2886 through 2889). Follow these steps to import it.

  1. Open Event Viewer.
  2. Right-click “Custom Views” then select “Import Custom View”.
  3. Provide a path to the downloaded .xml file. Feel free to rename it/change the description and location as you see fit.
  4. If you are doing this on a management server (and you should be) you will get an error about the service channel being missing. Once you bind to the appropriate Domain Controller, it will show the appropriate events.

If there are no events, awesome! But as per above, if we have 2886 and 2887 events, we need to investigate. With diagnostics enabled, the 2889 events will also show up (possibly in large quantities) in this view.

Insecure LDAP Binds Query Script

Download here -> Query-InsecureLDAPBinds (PowerShell Script)

The second resource is a simple PowerShell script that will parse and extract the relevant data from the logged 2889 events on your DC into a nice .csv By default, it will only query for 2889 events that occurred in the past 24 hours. You can override this if you wish to go further (or shorter if there is lots of noise)

.\Query-InsecureLDAPBinds.ps1 -ComputerName -Hours 24

The output .CSV will include IP Addresses, Ports, Username and the binding type. This can help quickly narrow down the affected user accounts and begin your remediation. It should look the following:


Fixing Your Applications

Sometimes fixing the offending applications is as simple as ticking a “Secure Connection” or “Secure Bind” checkbox inside the applications config. Sometimes this may require the use of certificates on your DC to allow TLS binds to them over TCP 636.

If the application has no way binding securely, throw it out. OK, sometimes thats not always possible, but if your application vendor won’t provide a secure way to do LDAP binds, you will need to get a little extreme and encrypt the whole TCP stream between the application and DC using IPSEC with ESP. Thankfully most modern applications have some kind of ability to perform secure LDAP connections and we don’t need to go this far.

Once you have cleaned up the main offenders (both by privilege and total count) you can repeat the diagnostics process for a little longer each time to track down the overnight scheduled tasks and processes and other connections that happen only periodically. It’s a slow process but required before you block these binds entirely.


Hopefully you stop reading reading this post because your DC’s “Require Signing” for their LDAP configuration. If not, you should now be well aware of the culprits in your environment and on your way to remediating them. In a future post I will explain the process of actually preventing these weak LDAP binds and also monitoring for applications still attempting them (and exposing their credentials in the process)

Outlook AutoDiscover v2

If you are trying to Setup Office 365 account sin Outlook in an environment which still has exchange complete the above changes and then complete the below.

Open an administrative command line

Run notepad c:\windows\system32\drivers\hosts\etc

Ping the auto-discover address required

Place the IP at the bottom of the document press tab and type autodiscover

Save the document

Configure new profile with Office 365 account

SolarWinds- Change Threads

1) From the Backup Manager | Overview, open the Restore Tab and select Run Command Prompt (Do this 3 times to ensure you have ample command prompt windows available)
2) Type the command ‘Notepad.exe’
3) In the Notepad go to File > Open | Change from .TXT to see All Files
4) Open X:\Program Files\Backup Manager\config.ini
5) Add the following line: RestoreDownloadThreadCount=20 (Default is 4, max is 40)
6) Close and Save

7) The BackupFP process needs to be restarted to allow changes to take effect – From the command Prompt type Taskmgr
8) In Processes Stop BackupFP.exe (Should immediately restart)
9) In Command Prompt > Taskmgr > Processes > Stop ChromiumEmbedded process
10) Wait ~30 seconds
11) In Command Prompt type initwebui (to relaunch the browser)

5 Phases of Check Disk utility- The internal working

CHKDSK is a command in the Windows command line to run a program, or utility, known as Check Disk. The Check Disk program is there to make sure that the computer’s files and file system are in order. It checks the file system and metadata of a volume for logical and physical errors then displays the correction of errors. In this article we discuss about 5 phases which are performed by CHKDSK during it verifies the file for errors.

CHKDSK Stages: How CHKDSK Preform its operation?

We have to understand first that how Check disk performs in command window. The whole activity of Chkdsk is divided in 3 major phases where it examine all metadata on the volume, where metadata is data about data. NTFS protects the metadata by using transaction log.

First Stage of CHKDSK- Verify Files

During First phase Check disk perform the operation of verifying files, in this stage CHKDSK analyze each file record segment (FRS) in volume master file table (MFT). File and directories on NTFS formatted volumes are identified by its own file record segment (FRS) in MFT and the percent which calculate that how much MFT has been verified.  In the end of this phase CHKDSK shows what spaces is in use in MFT and on volume. It also knows what space is available for MFT as well as on volume.

Second stage of Check Disk tool- Verify Indexes

Performing its second phase CHKDSK verifies indexes and count 0 to 100 in percent. In this stage CHKDSK examines all NTFS directories and calculation in percent which shows that those remaining directories which have to be checked. Here CHKDSK examines that each file and directory represented by FRS in MFT is referenced by at least one directory, and then it checks the various time stamps and size information of the file are updated or not. At the end of this stage CHKDSK confirms that there is no ‘Orphaned’ file, files which are listed in FRS but not listed in directories. If CHKDSK found the directory holds a file which is no longer exists then CHKDSK create a root directory and place the file there. If directory listings are found those FRSs which are not correspond to the file listed in directory, then CHKDSK remove that directory.

Third Stage of CHKDSK utility- Security Descriptor

In the third pass of check disk it verifies about the security descriptors and count from 0 to 100 in percent. In this phase CHKDSK examines each of the files and directories which are associated with security permissions. Check Disk examines in this stage that every security descriptors are working properly or not with all given permissions in an appropriate way.

Fourth & Fifth Stage of CHKDSK

This phase in check disk is only generated by using /R switch. /R is used to locate the bad sectors in volume’s free space and recovers the readable information. CHKDSK reads every sector on the volume to confirm stability. In fourth stage it verifies the clusters which are used and in Fifth pass it examines those clusters which are not in use.