Real IT Solutions from Real IT Experts.

A few days ago we had a client that was having some trouble opening a Microsoft Word Document that was sent to her via email. One of our technicians looked into the issue and was able to determine that the document could be opened from Word 2007 without issue, but for some reason, Word 2003 was not able to read the contents of the file. When we attempted to open the file, Word would give an error asking you to specify a file conversion method, i.e. (Windows Default, MS-DOS, or Other). None of the conversion methods were able to read from the file.  

After further investigation, I determined that the file had originally been a .DOCX (the new file format for Word 2007), I changed the file extension back to .DOCX and attempted to open the file again. Word was now able to open the document.  It seems that the sender of the document manually changed the file extension from .DOCX to .DOC, rather than opening the document in Word and saving it in the desired format.

This error occurs when 2 or more accounts have registered the same service principal name (SPN).

For example, I had a duplicate entry for host/cit10.xxxxdom1

1. From the domain controller, open a command prompt and then type the following string:
ldifde -f domain.txt -d dc=domain,dc=com

2. Open the text file in Notepad and then search for the SPN that is reported in the event log.
ie. host/cit10.xxxxdom1

3. Note the user accounts under which the SPN is located and the organizational unit the accounts reside in and determine which one is incorrect.  In my example, one computer had both a correct spn (host/compna0003.xxxxdom1) and a duplicate spn (host/cit10.xxxxdom1) right below it that another PC also (correctly) had.  I noted the where the offender was located in the AD hierarchy.

Then once the above has been located use the Windows Support Tools utility ADsiedit

Using ADSIEdit
1. Add ADSIEdit to the MMC and bind to the domain using the Domain well known naming context.
2. Navigate to each user account you previously documented as having a duplicate SPN registration and right click the account and select properties.
3. Scroll through the list of attributes until you see ServicePrincipalName, double click ServicePrincipalName and remove the duplicate SPN registration and click on OK and exit ADSIEdit.

A very interesting topic came up this week when I was attempting to connect to a client’s PPTP VPN from behind my Cisco ASA5505. I would attempt to make the connection and then it would drop, and I would not be able to complete the connection. At first, I thought it might have something to do with the client’s firewall being down, however, after I removed my ASA from the mix, and just used a DLINK wireless router, I was able to connect instantly.

First stop in my troubleshooting process was to look at the System Log within the ASDM for the ASA. I then tried to initialize the PPTP connection, I saw within the System Log the following error:
“regular translation creation failed for protocol 50 src inside:(Machine name) dst outside:(IP Address)”

After some research as to why this was happening, I was able to note that this is not something that is configured by default. You must put in a command within the CLI (Command Line Interface) that allows PPTP packets to be inspected. The firewall then creates dynamic GRE (generic routing encapsulation) connections and translations necessary to permit PPTP traffic. Here are a list of the commands that I had to execute within my firewall:

ASA5505> enable
Password: ********
ASA5505# conf t
ASA5505(config)# policy-map global_policy
ASA5505(config-pmap)# class inspection_default
ASA5505(config-pmap-c)# inspect pptp

After doing this, I then tested connectivity and it successfully worked. I found that this could be a big help in future firewall configurations where you must connect to various client PPTP VPN’s when you are behind a Cisco firewall.  Don’t forget to save your configuration after you have tested this successfully!

RADIUS authentication is one of the more secure ways to allow users remote access using their Active Directory credentials.  This begs the question though, how then do I disable RADIUS authentication if I only have a single domain controller within my infrastructure and it’s down?

The most simple way to go about this is to do the following after connecting to the outside interface of the PIX via Putty:

Step 1: Login to the PIX via Putty
Step 2: Enter in the username and password
Step 3: Type “enable” (without the quotations)
Step 4: Enter in the password again
Step 5: Type “conf t”
Step 6: Type “no crypto map mymap client authentication radiusauth”
Step 7: Type “write mem”
Step 8: Type “exit”

At this point, you can connect to the Cisco VPN without having to authenticate.  Once the issue has been resolved with the domain controller, put radius authentication back to the way it was configured before.

Step 1: Login to the pix via Putty
Step 2: Enter in the username and password
Step 3: Type “enable”
Step 4: Type the password again for the PIX
Step 5: Type “conf t”
Step 6: Type “crypto map mymap client authentication radiusauth”
Step 7: Type “write mem”
Step 8: Type “exit”
Step 9: Attempt to connect back to the VPN and verify that you are prompted to authenticate.

While configuring a client with a new Cisco Wireless Infrastructure (Cisco WCS 6.0 server, Cisco 4402 WLAN Controller and 8 Cisco Light-Weight Access Points), there was a need to authenticate users based on their Active Directory credentials & group membership without the use of a separate Cisco ACS server.

The solution was found by changing the IAS Framing “Service-Type” to ‘login’, as the reply needs to only be a simple yes/no response and the WCS server doesn’t understand the additional framing.

While the migration path from Windows 2000 to Windows 2008 SBS is completely unsupported by Microsoft, we were able to achieve it via the following steps:

1) Disrupt the normal SBS installation by using an ‘answer file’ stored on a USB drive; this allows you to tell it the existing domain / server information.

2) Once the new server is installed, you need to run adprep and forestprep on the Windows 2000 DC using the 2008 SBS media.

3) Once the Domain and Forest are prepared, you need to rename the ntds.dit file to sbsntds.dit (the ntds.dit file is Active Directory) on the Windows 2000 DC.

4) Now you can run ‘dcpromo’  on the new server and transfer over all of the FSMO roles.

5) Lastly, you need to Install / Configure Exchange 2007 manually, as it will not install by default when using this method.

Once step 5 is complete, you still are left with all of the normal configurations required with a new Windows 2008 SBS server; however, you won’t need to dis-join/re-join all of the machines and migrate all of the data/profiles across domains.

Good Luck!