We recently ran into an issue where we should not get a Meraki Security Appliance (MX) to integrate with Microsoft’s Active Directory. The Meraki dashboard was not particularly helpful in identifying why the connection was not working. The Event log just kept repeating the following error:
Unable to connect to Domain Controller. user: <username>, domain: <short name>, server: <server’s IP>
We did identify that the Username, Password, and IP were correct and that the MX could ping the Domain Controller.
Our next step was to perform a packet capture of the traffic between the MX and the Domain Controller. In the output of the .pcap file, you can see a client hello packet that’s trying to negotiate with the server trying to use 65 different supported cipher suites. The Server is responding with an immediate RESET response, which normally indicates that these suites are not supported.
Our Domain Controllers were Server 2012 R2 systems, during our search for a solution to the issue, We came across this KB: KB2919355
It’s important to note that this KB is actually a collection of 6 files that all need to be run, but in a specific order. During the running of the file for 2919355, we ran into another seperate issue where that file would not install. That problem was solved by running the following two hotfixes: Hotfix 2939087 and Hotfix 2975061. We then were able to install 2919355, as well as the remaining updated in the first KB article. Post reboot we were able to see the Meraki Dashboard report that it was now able to communicate with the Domain Controllers.
We ran another packet capture, and the output of the .pcap is displayed below. You can see that the Client Hello is now met with a Server Hello response packet instead of a RESET. If we dig down and view the cipher suite of the response we see that AES 256 SHA384 is being used, which apparently was not supported on Server 2012R2 before the above KB was installed.
I recently ran into an issue were a capture wim image created from a windows 8.1 (x64) and Server 2012 R2 install.wim imaged repeatedly failed on boot with the error:
Windows failed to start. A recent hardware or software change might be the cause. to fix the problem:
- Insert your windows installation disc and restart your computer.
- Choose your language settings, and then click “Next.”
- Click “Repair your computer.”
if you do not have this disc, contact your system administrator or computer manufacturer for assistance.
Info: The application or operating system couldn’t be loaded because a required filed is missing or contains errors.
I was able to solve this issue be mounting the wim with imagex, changing nothing, and then unmounting the wim using the /commit argument.
Follow these steps (assuming your file is located c:\capture.wim and your mount directory is c:\mount)
imagex /mountrw c:\capture.wim 1 c:\mount
imagex /unmount /commit c:\mount
Once the image was committed, I opened the WDS console, selected the current Capture image, and selected “Replace Image…”. I then pointed to the c:\capture.wim file previously edited.
I then rebooted the client, and tried the capture image again, this time it worked without issue. I’m not sure what mounting and unmounting the image did, but i suspect perhaps it validates or changes certain files during the mounting and unmounting that are required for the image to be bootable.
I’ve been migrating some of our slower customers away from Exchange 2003 recently, and I ran into a issue that took me 3 days to figure out. I was getting the following erorr on the 2010 Server:
Couldn't find an Exchange 2010 or later public folder server with a replica for the free/busy folder: EX:/O=FIRST ORGANIZATION/OU=FIRST ADMINISTRATIVE GROUP despite successfully running the AddReplicaToPFRecursive.ps1 on the \NON_IPM_SUBTREE\ Top Public Folder. On the 2003 server, all folders, including the Free/Busy folders displayed two replicas, one for 2003 and one for 2010.
I eventually moved all replicas from the 2003 server and removed the PF database hoping that it would force any replicas that remained and perhaps weren’t being displayed properly over to the 2010 server, and I was prompted to do just that, but still I continued to receive the error stated above.
The reason that I’m posting this is not that it’s a new issue, it seems like it’s a pretty common problem, but rather the hard time I had finding the correct resolution online. Perhaps my search terms were off, but in case The way to solve this is as follows:
On the 2010 server, run the following commands:
Set-PublicFolder -Replicas '2010 Public Folder Database' -Identity '\NON_IPM_SUBTREE\SCHEDULE+ FREE BUSY\EX:/o=First Organization/ou=First Administrative Group'
and then verify it worked:
Get-publicfolder -recurse '\Non_IPM_SubTree\SCHEDULE+ FREE BUSY\EX:/o=First Organization/ou=First Administrative Group' |fl
3) restart the “Microsoft Exchange Mailbox Assistants” service
Over this past weekend I ran into an issue with Exchange 2010 Service Pack 3. Even though my Exchange server’s clock was sync’d with my Domain Controller the Exchange server was unable to start the Exchange IS service, and instead was logging the error:
Event 5003: Unable to initialize the Information Store service because the clocks on the client and server are skewed. This may be caused by a time change either on the client or on the server, and may require a restart of that computer. Verify that your domain is correctly configured and is currently online.
After a few reboots, and verification that the windows clocks were actually in sync, I thought to check that the clock in the BIOS was properly configured. Since these machines are VMs on VMWare ESXi, I logged into vCenter and checked my ESXi host. Sure enough one of the three hosts was not configured to use an NTP server, and it’s local clock was off. I fixed that setting and rebooted the exchange server one more time, the server was then able to start the Information store service.
I recently ran into an issue on Server 2012 R2 with installing .net. I could not install the feature regardless of whether or not a source was sacrificed.
I attempted to redirect the GUI wizard to install sources on DVD, but that failed.
The command line:
dism.exe /online /enable-feature /featurename:NetFX3 /all /Source:D:\sources\sxs Also failed.
I finally stumbled upon a forum where a user had success by removing these two Windows Updates: KB2966826 and KB2966828 and then attempting to run the command line install again.
This worked for me very well, and i wanted to make sure this was shared, as i had been banging my head against a wall for a few hours with this one.
Assumptions: SonicOS 5.8+ and Windows Server 2008 R2 Enterprise running as a domain controller.
- On the Domain Controller: Open “Server Manager”, click “Roles”, click “Add Roles”.
- Click “Next >”, ensure there is a check mark next to “Active Directory Certificate Services”, click “Next >”, Click “Next >”, Ensure there is a check mark in the boxes “Certification Authority”, “Certification Authority Web Enrollment”, and “Online Responder” (Certification Authority Web Enrollment” and “Online Responder” are not technically needed, but are common parts of a CA infrastructure that should also be installed if you are installing a CA), Click “Next >”, Approve the installation of the IIS components that are required to run the Web Enrollment, Select the “Enterprise” radio button and click “Next >”, Select the “Root CA” radio button and then click “Next >”, Select the “Create a new private key” radio button and then click “Next >”, Select “RSA#Microsoft Software Key Storage Provider”, “4096”, and “SHA512” from the drop down boxes, click “Next >”, Edit the Common Name for the CA if desired, and then click “Next >”, Change the validity period if desired, and then click “Next >”, Click “Next >” to leave the database in its default location, click “Next >” to install IIS, Leave default IIS installation options checked, and click “Next >”, click “Install”, Click “Close”.
- From the Domain Controller, open Internet Explorer, and go to http://127.0.0.1/certsrv, when prompted login with the Domain Administrator account.
- Click the link “Download a CA Certificate, certificate chain, or CRL”
- Select the certificate with the common name from step 2, and then ensure the radio button “DER” is selected, click “Download CA Certificate”.
- Rename this certificate to match that of the common name and save it on the desktop.
- Login to the SonicWALL.
- Expand “System” from the left hand pane, and then click “Certificates”.
- Click “Import…” at the bottom.
- Select the radio button “Import a CA certificate from a PKCS#7 (.p7b), PEM (.pem), or DER (.der or .cer) encoded file.” Is selected, and then click “Browse…” Select the certificate with the common name that you set in step 2. Click “Open”, Click “Import”.
- Expand “Users” from the left hand pane of the SonicWALL, click “Settings”.
- Change the drop down box titled “Authentication method for login: “ to “LDAP + Local Users”.
- Ensure that the check box “Case-sensitive user names” is UnChecked.
- Click “Accept” at the top.
- Click the “Configure…” button next to the “Authentication method for login: “ drop down box.
- On the “Settings” tab enter the IP address of the Domain controller in the box titled “Name or IP Address:”, Change “Port Number:” to “636”, change the radio button selection to “Give login name/location in tree”, Enter a Active Directory user account( a service account with “Domain Guest” group membership will suffice) in the “Login user name:” field, enter the password for the account in the “Login password:” field, UnCheck “require valid certificate from server”.
- On the “Directory” tab enter the following: In the “Primary Domain:” field enter the DNS active Directory Domain Name, change the “User tree for login to server:” to the full path of where the service account (used on the Settings tab) is located in Active Directory (spaces are okay), click “Apply”.
- Click “Auto-Configure” to test populate the directories in AD which contain Users or Groups.
So long as your list populated with OUs you should be good, this is everything you need to do in order to secure the connection between your SonicWALL and your domain controller.
I guess I wasn’t paying attention. It’s now November 2012, and I’m just now realizing that Group Policy Loopback, with Merge selected, no longer works as I’d expect with Windows 7 and Server 2008(R2)
It used to work like this:
Replace mode would ignore all GPOs applied to the user up until it got to the OU with the loopback policy, and then apply ONLY the GPOs with user settings in the OU with the loopback policy. This still works as expected in 2008/win7.
Merge mode would ADD the additional GPOs to what was already applied to the user, overriding any existing settings as needed, effectively merging them. This is what no longer works as expected.
Here is what I’ve found:
Microsoft published this KB, 953786, which says that the PCs now need to have a entry in the ACL of the GPO allowing them to read the settings of said GPO. What I’ve done to make this easier for myself is added the “Domain Computers” Active Directory group to any GPO which contains the user settings that I wish to apply via loopback merge.
In my testing, this added ACL entry has solved the issue, and allowed it to work as I expected, which is the way that 2003/xp behaved.
I ran into a problem today where a Server 2008 R2 FTP Server was working fine internally, but when you tried to access it from the internet it would not work. I checked the firewall rules, in this case a Sonicwall NSA, and the NAT and firewall rules were created properly, and they were passing traffic, but the connection was still failing.
The problem appears to be on the windows firewall, for some reasons the traffic is not making it through the windows firewall. Here is how we resolved the problem:
- Create a new Firewall in the Windows Firewall
- Allow a Program through the firewall, c:\windows\system32\svchost.exe
- Allow this rule for all traffic types, Public, Domain, Private
- Give the rule a name and click Finish.
- Now test again externally and you should be able to access the FTP site.
You’ll need a .pfx certificate in this guide, so once you have your certificate and any intermediates that need to be installed, export the certificate and include the entire chain the export, assign a password and then save the .pfx somewhere where you can access it from the terminal server.
On the Terminal Server in Question:
- Click “Start” and then “Run”.
- Enter “mmc” and then click “OK”.
- Click on the “File” menu and then select “Add/Remove Snap-in…”.
- Click “Certificates” and then click “Add >”, when prompted choose option “Computer Account” and then click “Next >”.
- Select “Local Computer” and then click “Finish”.
- Click “OK” to complete the add snap-in wizard and then expand “Certificates (Local Server)”.
- Right click on the “Personal” folder and then select “All Tasks”, then “Import…”.
- Click “Next >” and then locate the .pfx you’ve saved earlier. Click “Next >”
- Enter your password, and then click “Next >”, click “Next >”, click “Finish”.
- Now open “Remote Desktop Session Host Configuration”.
- Right click on “RDP-tcp” in the center of the window and select “Properties”.
- On the “General” tab, click the “Select” button, Select your certificate, and then click “OK”.
- Click “OK” one more time, and then all future connections will be secured by the certificate.
Ran into a problem today with an Outlook 2010 client that would not leave the “disconnected” state. I restarted the computer, verified the mailbox was still active in Exchange 2003, and verified that this problem was not effecting other users, even ones on the same PC. I tried to create a new outlook profile, but during the setup I kept getting the same error:
“Microsoft Exchange Server reported error: The server is
not available. Contact your administrator if this condition persists”
It appears that just this one user cannot connect to exchange, the way that we solved this problem was by increasing the maximum number of connections that each user can make to Exchange 2003. Follow these steps on your Exchange server:
- Open Regedit
- Navigate to HKLM\CurrentControlSet\Services\MicrosoftExchangeIS\ParametersSystem
- Create a new DWORD called “Maximum Allowed Sessions Per User” and set it to decimal 64.
- Restart the “Microsoft Exchange Information Store” service
- Attempt to reconnect with the user’s outlook.
Hopefully this took care of your problem user.