Please let others know how useful this tip is via the rating scale at the end of it. Do you have a useful Exchange...
or Outlook tip, timesaver or workaround to share? Submit it to our tip contest and you could win a prize.
VIEW MEMBER FEEDACK TO THIS TIP
The concept of a passphrase as opposed to a password is getting renewed attention in IT circles as a way to toughen security. A passphrase is functionally the same as a password, just longer -- using four or five words instead of a short combination of numbers and letters.
Passphrases are alleged to have several security benefits over conventional passwords. For one, they're intended to be easier to remember, since a short phrase isn't as difficult to recall as an eight-character password that has no inherent mnemonic. (Example: Toto Not In Kansas is probably a lot easier to recall than xw2mn5r.) Second, their length makes them many orders of magnitude more difficult to crack than regular passwords, especially if an attacker is using a fairly conventional dictionary attack.
(It has been theorized that a cracker who knows that passphrases are in use on a particular account could attack that account by using a more sophisticated dictionary attack, but the odds of them getting through before being detected are probably no better than a crack attempt on a conventional password.)
Active Directory (and by extension Exchange) can support a password length of up to 127 characters. This makes it easy enough to set policies that enforce a minimum password length of, say, 16 characters, and support fairly long passphrases. Note also that while AD does support passwords with Unicode characters, it may not be a good idea to use any non-ASCII characters in a password if, for instance, users attempt to use Outlook Web Access. Unicode characters may not get sent correctly during the remote validation process and may make a remote login impossible.
The main problem with using passphrases is not actually an issue with Exchange (since all of its password validation is done courtesy of AD), but with users themselves. They may not be inclined to type a whole phrase, where before they only had to type a word. Administrators should discuss the benefits and problems of moving to a passphrase scheme with management and users before putting anything into action.
For more information on building strong passwords, check out SearchWindowsSecurity.com's 10 tips in 10 minutes: Password policy considerations.
About the author: Serdar Yegulalp is the editor of the Windows 2000 Power Users Newsletter and a regular contributor to SearchExchange.com.
MEMBER FEEDBACK TO THIS TIP
It is interesting that this concept should merit an article in 2005. I have been recommending the use of passphrases for about 20 years!
My example of a passphrase for new users is MyDogSmells (that seems to strike a chord with them!) and I recommend that they use a phrase because it is easier to remember and harder to guess. That is important in a school environment when somedays I seem to spend all my time resetting passwords for students!
I started off in 1986 in a large local business (1000+ users) supporting the computer systems -– mainframe and then personal computers as they became more common. I then started work as a consultant, using the skills I had learned in my job. About eight years ago, I showed a client with about 30 users how easy it was to crack their passwords (most of them within the first five seconds!) and how much harder it was if they used passphrases.
So you are preaching to the converted here!
I just had an instance where someone authenticating through Outlook Web Access had a longer than normal password -- we require seven characters but he had about 12. He was unable to get logged in until I shortened the password to seven or eight characters. We have no maximum password length set in our domain security policies. So, what's up with that?
One major possibility that comes to mind is there could be a conflict of policies -- local, domain and domain controller policies might be clashing or overriding with each other. This could be exacerbated if OWA was itself running on a domain controller rather than on the server hosting the Exchange box (or on its own standalone IIS box).
Also, see if logging in as DOMAIN\username changes anything; that might force a recognition of where to inherit the policy from if the policy topology is a bit complex.
A third possibliity might be if there's a proxy or something else intercepting or diddling with HTTP traffic from the user.
Serdar Yegulalp, tip author
Do you have comments on this tip? Let us know.