Tuesday, February 28, 2012

LastPass: THE Password Manager

Password managers have always been something I have stayed a way from, wrote policies against and warned others about....until I found LastPass.

With the right security configuration in place, LastPass is everything I can trust in a password manager. I have been a Premium user of LastPass for a couple of years now and here are a few highlights that make me want to tout it:

Local Encryption - The password file encrypted/decrypted is handled locally only. The only thing stored on their servers is the ecrypted payload, they have no way of decrypting your data.

Two-Factor Authentication - I started using YubiKey with LastPass and have since switched to Google Authenticator. Support for two-factor authetication is key to this. This way, no matter how long or complex my password, a second time sensitive and randomly generated pin is also required to gain access. Since I am trusing this with all my online passwords, two-factor authentication is essential.

Synchronization - The encrypted payload is shared and kept synchronized in the "cloud". LastPass offers many ways of accessing and using LastPass across mobile devices, public computers and even offline.

Password Sharing - I am able to share my password with others. I can give another LastPass user the ability to use my saved credentials to access particular sites. I can also restrict that sharing so that the other user cannot alter or even see the password if I choose.

Security/Strength - I only ever need to remember my master password and use my two-factor pin to access any website. This allows me to make sure that every password that I set on a site can be as long and complex as the site will allow and LastPass will remember it, and never using a duplicate or unsecure passwords again.

LastPass with a strong master password and two-factor authentication has changed my opinion about using a password manager. With it, my online credentials are now more secure than ever before.

Try it out:

Exchange 2010: Configuring 'Send As' permissions on Distribution Groups

There is no way in the GUI to grant a user permission to 'Send As' distribution group address.

The following Exchange Management Shell commands will accomplish this. One useful trick is to grant this permission to itself. Doing so will eliminate any need to manage these permissions in the future, if a user is a member of the Distribution Group then they also are granted the permission to send on behalf of that Group.

Add Send-On-Behalf rights to its own Distribution Group members
  • Set-DistributionGroup "Sales Team" -GrantSendOnBehalfTo "Sales Team"

Check the Send-On-Behalf rights set on a given Distribution Group
  • Get-DistributionGroup "Sales Team" | fl name,grant*

Monday, February 27, 2012

Exchange 2010: Creating a secondary OWA Site with Integrated Authentication

In some cases it may be necessary to have the default OWA site require manual authentication (forms based or basic), specifically if your users use it to access multiple Exchange accounts. At the same time, I have found myself trying to become less dependent on fat clients and try to rely on thin clients where available and functional. And having Integrated Authentication turned on for OWA makes using that interface much more convenient for daily use.

So...in that case, it is necessary to create a secondary OWA site in Exchange that can be easily pinned as a web app and not require manual authentication. 

The first step is to create a new site in IIS to host the second OWA instance, as it is not possible in 2010 to have multiple OWA instances within the same site. Therefore, the second site will either need to answer to a new URL or at minumum a different port. I chose to set it up on a different port.

  • Open the IIS Manager and drill down to Sites, right click on the site folder and choose "Add Web Site". Enter a Site Name, physical path and binding information as shown below:

The following commands will then be run from the Exchange Management Shell to configure the OWA Instance in that site.
  1. To create the new OWA instance:
    • New-OwaVirtualDirectory -WebSiteName "owa-integrated" 
  2. The ECP will need to be created seperately and is necessary to give users access to the OWA Control panel for customization, signatures, etc.
    • New-EcpVirtualDirectory -Server "SERVER" -WebSiteName "owa-integrated"
Once the sites are created, you will need to configure the authentication through the Exchange Management Console (EMC). To do this, navigate the tree to the "Server Configuration" section and select the "Client Access" option. Beneath the Outlook Web App tab, you will now see two OWA instances. Right click on the newly created owa-integrated instance, choose properties and then the Authentication tab. Configure the Integrated Authentication option as below:

Once complete, you must restart IIS using the following command from a command prompt with elevated rights: iisreset /noforce

You should now be able to access the newly created OWA site by specifying the assigned port in IIS (8443, in this case): https://owa.mydomain.com:8443

In addition to the above, I also have an Office Communications Server (OCS) and use the integrated chat client in OWA. Therefore, I needed to also perform the following commands from the Exchange Management Shell to configure the client communication:
  1. Assign the Instant Messaging Certificate Thumbprint to the new OWA instance:
    • Set-OwaVirtualDirectory -Identity "SERVER\owa (owa-integrated)" -InstantMessagingCertificateThumbprint 0C0C8590BF04B5676B6AB4A803EDF07AB73CDEC6
  2. Assign the Instant Messaging Server Name:
    • Set-OwaVirtualDirectory -Identity "SERVER\owa (owa-integrated)" -InstantMessagingServerName ocsserver.mydomain.com
  3. Set the Instant Messaging Type to Ocs:
    • Set-OwaVirtualDirectory -Identity "SERVER\owa (owa-integrated)" -InstantMessagingType Ocs