Securing your mailbox and other accounts

Posted on November 19, 2012

Creating a strong password is one of the most important steps for securing your computer, yet I run into weak or insecure passwords almost daily.

Here are a few guidelines I follow when creating a new, secure password:

  • Length: create a password longer than 12 characters
  • Complexity:
    • Create an alpha-numeric password; use both letters and numbers
    • Include non-standard characters. Examples are: ! @ # $ % ^ & *
    • Avoid using your name, birthday, company name, or other personal information that can be easily guessed; don’t use Sunfire in your password if you drive a Sunfire
    • Avoid using  common repeated characters such as ‘qwerty’, or ‘12345’
    • Try substituting letters for numbers, for example, 5 for S, 3 for E. An example would include ‘h3l10’ instead of ‘hello’
  • Avoid Similarity. Change your password every three months, and create a new password that is different from the old one. Do not change or just add one more character, change the whole password
  • Variation: Do not use the same password for everything. Create a completely different password for Windows, your email, your banking website. Your personal information will be more difficult to obtain if it is protected by multiple, complex passwords

It is important to keep in mind that your password is only secure as long as it remains a secret. Writing down your password can help in remembering it, however SIRKit strongly recommends that you do not keep your password written down, and do not keep your password on or in your desk, and do not place it on a sticky-note on your monitor or under your keyboard.

As well, do not share your password with anyone. If you do, while on vacation for example, ensure you change your password immediately.

Windows Domain DFS namespace – access is denied using domain FQDN, access allowed using server UNC paths directly

Posted on November 5, 2012

This was easily one of the most frustrating and ridiculous fun times I've had working with DFS.

The issue: At several client locations we run file server redundancy by offering (2) DFSR servers. A shared domain namespace with replicated folders to ensure they stay online if a server is offline for planned or unplanned good times. Within group-policy, we map folder redirection to a namespace path:

  • "documents" -> "\\\users\username\documents"
  • "desktop" -> "\\\users\username\desktop"
  • ......

By referencing the namespace, it will redirect when server A or B is offline. This should NOT be used in WAN deployments, LAN is fast and therefore replication is fast. Initially the DFS issue was identified when drives mapped to the namespace were missing. Within the client event logs, we saw "access denied" errors associated with these drive-letters.

What we checked and verified:

  • Problematic client stations could not connect to "\\\dfsroot"  (access denied)
  • Problematic client stations could not connect to "\\domain\dfsroot" (access denied)
  • Problematic client stations could connect to "\\serverA\dfsroot"
  • Problematic client stations could connect to "\\serverB\dfsroot"
  • Permissions on the shares for the DFS Root folder were correctly set to "everyone" with read/write
  • Each of these systems was removed and rejoined to the domain [no success]
  • The local profiles were completely removed from the local systems (file system and registry) and logged back in [no success]
  • Security suites were removed [no success]
  • Each user was tested on working machines and had no issues obtaining the right drives

The culprit: 

  • When we disabled the 'offline files' component and rebooted -> "\\\dfsroot" was immediately accessible
We ultimately came to this conclusion: 

The offline file cache was corrupt. When offline files are disabled, the system accesses the namespace location directly without issue. This confirms a reference to the namespace is clearly saved within offline file cache. If the cache is corrupt you end up with "Access is Denied". Another quick way to determine if the issue is corrupt cache is to simply try and access the DFS root UNC paths on each server. If you can browse the contents when bypassing the shared namespace path, and this user has no issues on other domain PCs, then it's not permissions.
The Fix:
1) Disable offline files

Control Panel -> Sync Center -> Manage Offline Files -> Disable Offline Files

2) Clear the offline file cache

This sets a temporary registry entry which is read on start-up and runs the cache wipe.
Elevated Command Prompt -> "reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Csc\Parameters /v FormatDatabase /t REG_DWORD /d 1 /f "

3) Reboot

You must reboot to successfully wipe the offline file cache

4) Test the namespace path -> "\\\dfsroot"

If you can now browse the namespace contents, you can optionally re-enable Offline Files.
We understand the Offline Files component is critical to road warriors. You should be safe to re-enable it and reboot.

Control Panel -> Sync Center -> Manage Offline Files -> Enable Offline Files -> Reboot

After you log back in, check that you can still access the namespace path "\\\dfsroot" after you run a forced sync. If there are still issues, I recommend you follow the steps we initially took "What we checked and verified:" and repeat this fix.

Good luck!