January 2009 - Posts
This is a brand new feature of SP1 of great interest in an enterprise implementation. This mimics the similar Exchange and Windows Mobile device functionality, but without the need for any Exchange requirements. With this feature end users who have forgotten their device password or PIN, can recover (without wiping the device) and set a new device password or PIN. In this posting I will dive a little deeper and show how this all works on both the server and client side.
As nicely stated in the MDM Password Reset Client v1.0 download overview:
"MDM Password Reset Client provides a .cab file that you install on Windows Mobile 6.1 devices enrolled in MDM so that users can use the password reset feature in MDM. Password reset in MDM 2008 Service Pack 1 (SP1) enables a user who has forgotten his or her Windows Mobile device password to reset it by using MDM.
Password reset is supported on Windows Mobile 6.1 devices, starting with version 6.1.4. To use the feature, you must install the .cab file on the user’s Windows Mobile device as well as enable the feature in MDM by using Group Policy.
To reset the device password, the user chooses the password reset option, resets the device password, and then enters a one-time recovery password on the device to complete the process. The recovery password is stored on MDM servers and retrieved by the user when she or he has forgotten the device password."
What is required?
Even though the client patch description mentioned above states it is first supported on Windows Mobile 6.1.4 or above device, the patch appears to install on some of my 6.1.1 devices. But "your mileage may vary" (YMMY) as they say.. The patch, available here, can be manually installed, but with MDM handy why not deploy it it out directly! Please note the installation failures on the devices that are below the 6.1.1 levels.
You also need the SCMDM 2008 SP1 installation on the back-end. Especially the changes on the DM server, SQL tables, and Self Service Portal (SSP) if you wish to use that for retrieving the reset password.
How it works:
After the client patch on the devices is installed and the device locked with a PIN, triggers a local generation of a password reset key. After 2 cycles of traffic to and from the Device Management server, that recovery password will have uploaded to the SCMDM side and be available for use. This can be verified with a cmdlet or on the MDM console by seeing that the "Display Recovery Password" action is no longer grayed out on the right hand side of the screen when a managed device is selected:
More details can also be found here on the overall user experience of this feature: http://technet.microsoft.com/en-us/library/dd252841.aspx
These are actual screen-shots of a managed device that has the client patched installed.
In a locked state, the "Reset Password" option is no longer grayed out. Suggesting that the password reset key has been uploaded and ready to use:
After the "Reset Password" option is selected, a confirmation that the user can indeed retrieve the recovery password from an administrator or help desk.
It will then let the user create a new password. Using the same requirements that might have been enforced to the device.
Now the user must contact the administrator or help desk. In this example the administrator clicks on the "Display Recovery Password" in the MDM console and is shown the 20 digit Recovery Password that the device has uploaded into the MDM database.
The user must type in the 20 digit recovery password to validate the new password.
If there is a match with the recovery password stored on the device, the new password is granted and the device is unlocked!
Instead of the MDM console, the MDM Self Service Portal (SSP) could have been used. It also has a "Display Recovery Password" button at the bottom which will display the 20 digit recovery password:
The Password Recovery feature in the SSP is selectable by the administrator to be made available on the web site just as the Device Wipe and Device Enrollment features. Please see more information available here: http://technet.microsoft.com/en-us/library/dd261796.aspx.
Password Recovery References
SCMDM Cmdlets: http://technet.microsoft.com/en-us/library/dd261726.aspx
SCMDM User Experience: http://technet.microsoft.com/en-us/library/dd252841.aspx
Windows Mobile 6.x AKUs: http://myitforum.com/cs2/blogs/mnielsen/archive/2009/01/31/windows-mobile-6-x-akus.aspx
Windows Mobile 6.1.x Upgrades and Build Levels: http://myitforum.com/cs2/blogs/mnielsen/archive/2009/01/24/windows-mobile-6-1-x-upgrades-now-available.aspx
"What is an AKU and why is it important to me?" you might ask yourself.. As stated nicely here:
"Microsoft creates updated builds of the Windows Mobile operation system called Adaptation Kit Updates (AKU). These releases are rarely intended directly for consumers, and are usually a result of some extra features or fixes required by a particular Windows Mobile device. For example, if an OEM (Original Equipment Manufacturer) decides to add a new kind of external keyboard to a Windows Mobile Pocket PC, then some extra driver code will be required - in that case, Microsoft creates an AKU to drive the hardware."
So different levels of the OS could have different features, patches and updates. For an enterprise environment this is of course very relevant to determine issues and resolutions for problems.
How to find the Build and AKU number?
On a touch screen Professional/PocketPC device go to: Start->Settings->System tab->About.
On a non-touch screen Standard/Smartphone device go to: Start->Settings->More->About.
The AKU version is also stored in this registry key: HKLM\SYSTEM\Versions\Aku.
The AKUs are numbered incrementally after the Build number. See the table below for more details and known WM 6.1 builds. It is not meant to be a complete overview.
|OS ||Build Number ||AKU ||Details|
| || || || |
|Windows Mobile 6.0 || || ||Codename: Crossbow|
|5.2.318 ||Build 15318.104.22.168 ||AKU 0 ||RTM|
|5.2.1235 ||Build 15322.214.171.124 ||AKU 0.0.1 || |
|<snip> ||<snip> ||<snip> || |
|5.2.? ||Build 185126.96.36.199 ||AKU 0.7.4 || |
| || || || |
|Windows Mobile 6.1 || || ||Codename: Crossbow "Yona" Client?|
| || || || |
|5.2.19202 ||Build 19188.8.131.52 ||AKU 1.0.0 ||RTM|
|<snip> ||<snip> ||<snip> || |
|5.2.19559 ||Build 195184.108.40.206 ||AKU 1.1.0 ||SCMDM 2008 SP1 Password Reset possibly functional w/Patch install|
|<snip> ||<snip> ||<snip> || |
| || || || |
|Windows Mobile 6.1.4 || || ||Codename: Crossbow.IE6 or 6on6?|
|5.2.20757 ||Build 207220.127.116.11 ||AKU 1.4.0 ||RTM, SCMDM 2008 SP1 Password Reset Patch included - officially supported|
| || || || |
|Windows Mobile 6.5 || || ||Codename: Crossbow.x?|
|Future ||Future ||Future || |
| || || || |
A listing of older WM 5 and WM 6 AKUs are posted here. And don't forget my previous postings of Windows Mobile 6.1.x Upgrades and Build Levels. :-) That gives a good overview of some of the devices out there and their AKU level.
What is important is knowing the AKU level for specific SCMDM features. In particular the MDM Password Reset Client feature, which can be downloaded from here: http://technet.microsoft.com/en-us/scmdm/cc304591.aspx.
I will go into more details on this feature in my next posting.
A lot of discussions within IT organizations are about security, and how the approved security policies must be executed and implemented. Traditionally it is not the same group of the staff that has mandated the security policies that has to implement tools and processes to have them executed. But I have seen how this "disjointed camp" trend is slowly becoming better in many organizations.
The focus of this posting is to highlight some of the options available that I have run across recently on the question of Windows Mobile security and encryption. In particular what Windows Mobile 6.1 brings and potential issues you might encounter depending on your security policies and requirements.
Native Device and File Encryption
Starting in the Windows Mobile 6 release there was native support for device and file encryption. In Windows Mobile 6.1 this was further enhanced with additional features to handle storage cards inserted into the device. This could be triggered from Exchange 2007, from System Center Mobile Device Manager (SCMDM) in a Group Policy Object (GPO), or even from a 3rd party tool on the device like Andreas Helland wrote (see http://mobilitydojo.net/2008/11/19/update-dojocrypt-goes-10/). Basically specific registry keys needs to be flipped to activate the appropriate features.
The encryption code is built into the Windows Mobile operating system so there is low over head. The encryption on the storage card is upon write, so existing data on the card is not encrypted unless re-written. In WM 6.1 you can also specify exclusions/inclusions of directories . This can be handy to only encrypt e-mail or critical folders with line-of-business applications.
Some companies require that the encrypted data can be retrieved. This may go against the reasoning behind encryption you say, but depending on your security mindset and corporate data ownership a necessary evil. Say some important employees have important data on an encrypted storage card or device and you need to access the data, either for support or legal reasons, with or without their co-operation.
On desktops and servers there are some processes to accomplish this with encryption Key Escrow or Recovery using storage of the encryption key elsewhere. This of course brings other security risks into effect. I know the Windows Vista/Windows 2008 BitLocker technology for example accomplishes this through the Active Directory.
But on the native Windows Mobile 6 and 6.1 operating system this was not prioritized as a necessary component of the latest OS release as it would have probably required more work and back-end integration. But who knows what the future could bring if enough enterprise customers ask for it! (hint hint, this is where you have a say back to Microsoft!)
Thus if you wipe a Windows Mobile device, either from Exchange 2007 or System Center Mobile Device Manager (MDM) or other means and the encrypted storage card that was previously encrypted within the device was taken out beforehand, there is no way to read the encrypted data on the card again. It can only be read on the device it was encrypted with.
Jason Langridge's blog entry here lays it out nicely: :-)http://blogs.msdn.com/jasonlan/archive/2007/03/16/storage-card-wipe-and-encryption-what-s-the-deal.aspx
- and a reference from the Windows Mobile product team themselves from their encryption FAQ:
If your security policies require encryption key recovery processes, you may need to look at 3rd party solutions. These will of course bring an additional cost, but may also add additional security features.
Some or most solutions work around the issue by creating their own encrypted file "volumes" and backup the known key used. Thus not using the default file encryption implementation.
Possible products and links:
Aiko Solutions SecuBox: http://www.aikosolutions.com/products/secubox-for-pocket-pc/articles/secubox-encryption-vs-windows-mobile-6-encryption/
GuardianEdge Smartphone Protection: http://www.guardianedge.com/products/smartphone-security.php
CheckPoint Pointsec Mobile: http://www.checkpoint.com/products/datasecurity/mobile/index.html
McAfee SafeBoot: http://www.mcfee.com
Mobile Armor DataArmor: http://www.mobilearmor.com/dataarmor.php
Credent Mobile Guardian: http://www.credant.com/products/cmg-enterprise-edition.html
WinMagic SecureDoc Mobile Edition: http://www.winmagic.com/solutions/securedoc-pda.html
PGP Mobile: http://www.pgp.com/products/mobile/index.html
No default workaround
Some good technical explanation and background from my colleague and resident expert Mr Dave Field (CISSP) from Enterprise Mobile on the technical aspects of using the native Windows Mobile 6.x encryption and why a workaround isn't currently possible with the default implementation of encryption:
"The problem is that both storage card encryption and device main memory encryption is performed using keys that are auto-generated and auto-encrypted by DPAPI. The DPAPI system key and user key are encrypted using device-specific entropy. The user key on WM 6.1 used for encryption adds the device lock PIN/PW as entropy. So, even if you went and found the keys in memory and uploaded them to the infrastructure, you wouldn’t be able to decrypt them using some shared password. There is no function available to decrypt the key and provide the output. DPAPI only decrypts the key into memory as part of encryption/decryption operations. DPAPI has no archiving function and is not tied into Active Directory. When using EFS or even enrolling a certificate, the keys can be archived using active directory.
Even if we found the registry keys for the auto-generated DPAPI keys and stored them centrally. We couldn’t re-use them elsewhere if we replaced them and used the same user PIN/PW on the new device. This is because there are a number of device characteristics used for entropy as well as the user PIN/Password. The entropy points are not advertised for the obvious reasons…"
Please comment if you have different experiences, feedback or interesting views on these issues!
References of possible further interest on this topic:
Why Device Lock PIN/Password must be configured with Windows Mobile 6.1 Device Encryption:
Windows Data Protection API (DPAPI): http://msdn.microsoft.com/en-us/library/ms995355.aspx
Older Mobile Encryption paper: http://www.sans.edu/resources/student_projects/200612_001.pdf
Keep Mobile Devices Safe With Encryption (Nov 2007):
Out of the box the MDM comes with a limited reporting functionality, mostly in the Deployment Console. However since the product is using SQL Server as it's data repository, there is a great value to download and use the free SCMDM 2008 Reporting Services add-on that is part of the SCMDM Resource Kit.
The SCMDM 2008 Reporting Services is based on and integrated with the SQL Server Reporting Services 2005 (SSRS)
You can download it here:
There is a handy User Guide included in the download, together with the Install Guide and various administrative documents.
I won't go into too much detail of what SSRS brings to the table, but instead encourage you to read up on the highlights here: http://msdn.microsoft.com/en-us/library/ms157304(SQL.90).aspx.
Once installed the top level reporting screen should look like this:
Drilling down into the "MDM Reports" link you will see the 13 canned reports that are included:
Common for many of the reports, is the drop down select of the "Device Domain" and "Device Organizational Unit". This makes it possible to take a high-level or very granular view of your device inventory.
A quick list of what I believe are some of the most useful reports this add-on can provide value to administrators:
Device Detail Report
Generates a detailed report on the selected device name with user information and general device information. Automated drill down links are also provided to the Device Management Activity Report, Connection History Summary by Device Report, and Group Policy Settings Report. This makes it easy to gather further details by the device name for research.
Group Policy Objects Report
Lists the success and failure of each GPO and their outcome to each managed device. This can be useful when you have to split up the devices into OUs/group based upon their model/type etc. Or to troubleshoot why specific GPOs didn't get applied on specific devices.
Group Policy Settings Report
Similar to the Objects Report, but from the device point of view instead of the GPO. You can also choose a category of specific settings and policy.
Device Lifecycle Report
This is one of the more interesting reports which can provide a quick overview and color graph of the following device groupings by month/week or day:
- Enrolled - Not managed
- Enrolled - Managed
- Wipe Pending
- Dis-Enrolled, Never Managed
- Dis-Enrolled, Wiped
- Dis-Enrolled, Not Accomplished
Another thought I have is how to make a "dashboard" view of the favorite customized reports that could be used within a portal..
A good colleague of mine, Tony Spencer, pointed out that the Microsoft Virtual Lab specifically for SCMDM is publicly posted but not easy to find. It has been listed together with the other System Center Virtual Labs currently available here: http://technet.microsoft.com/en-us/systemcenter/bb539977.aspx.
Direct link: TechNet Virtual Lab- Using System Center Mobile Device Manager 2008 Features
The link will take you to a Events page where you need to register, confirm and then click ViewOnline. It will prompt you to install the ActiveX control for the Virtual Server viewer if you don't already have it installed. After all the pre-reqs are verified it will build a fresh lab environment for you and grant you 90 minutes to use it.
A link to the 17 page lab manual is here: http://download.microsoftvirtuallabs.com/download/8/a/7/8a71365b-4c80-4e60-8185-8f12f59bf1d4/SCMDMVirtualLabManual.pdf
The lab manual will guide you through the 7 exercises prepared in the virtual lab environment:
Exercise 1: Using ISA Server to Publish the Mobile Device Manager Enrollment Web Service
Exercise 2: Creating Mobile Policies using the Group Policy Management Console Tool
Exercise 3: Installing and Using the Mobile Device Manager Self Service Portal Exercise 4: Enrolling a Mobile Device
Exercise 5: Using the System Center Mobile Device Manager to Create a Pre-Enrollment
Exercise 6: Using Mobile Device Manager Software Distribution to Deploy an Application
Exercise 7: Using the System Center Mobile Device Manager Console to Wipe a Device
The lab environment consists of 5 machines:
ISA01 - Microsoft ISA 2006 server configured as an Edge Firewall
MDMCORE - SQL 2005, SCMDM Enrollment, SCMDM Device Management
MDMCLIENT - Running a WM 6.1.4 Emulator for device testing
AD01 - CA, Active Directory, SCMDM Consoles and SCMDM PowerShell
WINXPSP3 - Not sure what this is used for!
The SCMDM Gateway server, MDMVPN is not accessible.
Screen shot on the MDMCORE server:
Please note that the lab is running SCMDM 2008 RTM, and not the newer SP1 release. Although the lab is somewhat limited in scope, it does provide an excellent experience of a working SCMDM environment upon demand. Well worth checking out if you want to take a closer look at SCMDM without spending much time!