Certifications
Categories
RSS
Monday, January 18. 2010
Noteworthy Windows 7 post-RTM / pre-SP1 hotfixes
KB 977346 - Welcome screen may be displayed for 30 seconds during the logon process after you set a solid color as the desktop background in Windows 7 or Server 2008 R2
Tuesday, January 12. 2010
OCS 2007, NTLM, and Edge server login problems
I have come across this situation a few times now out in the field so I thought it might be a good time to describe the problem and some easy ways to mitigate or avoid the issue. The January 2010 OCS Server updates related to NTLM reminded me about this issue.
It is pretty common place to lock down, with a GPO or registry setting, the NTLM settings on member servers, domain controllers and client computers. Although uncommon, there are scenarios where you can effectively break any NTLM negotiation between domain controllers, member servers and clients.
Thankfully, these are well documented in KB 823659, “Client, service, and program incompatibilities that may occur when you modify security settings and user rights assignments”.
Consider this scenario:
OCS servers and internal network (local LAN) clients are Active Directory domain joined.
Non-domain joined clients connect through an OCS Edge.
If NTLMMINCLIENTSEC and/or NTLMMINSERVERSEC differ between clients and servers, for the internal clients and servers, Kerberos authentication will still be functional, assuming you haven't set the pool to only accept NTLM.
Clients that connect through the Edge will be rely entirely on NTLM because Kerberos is not available as an authentication method, as noted in the excellent OCS 2007 R2 Resource Kit.
If NTLM is “broken” inside the domain between domain controllers and OCS servers (front End/edge), the Office Communicator client will act as if the user entered an invalid username or password. The error message on the client computer is very misleading and everyone external will not be able to log in.
As noted in TechNet here, OCS is very particular about the NTLMv2 settings.
These settings, for server and client, can be set in a group policy under Network security: Minimum session security for NTLM SSP based (including secure RPC), or by use of a registry setting.
To directly quote Technet:
Sometimes the server will be configured to require encryption, and the client will not. In this case, the client NTLM request is not passed on by the front-end server. This situation primarily affects external users, because NTLM is the only authentication protocol that external clients can use to sign in. For example, if the server key is configured to have a value of 0x20080030, which specifies 128-bit encryption, and clients are not, clients will be unable to sign in. You should ensure that this key on the client is configured to match the server’s setting.
As operating systems have evolved, the default security settings for NTLMMINCLIENTSEC and NTLMMINSERVERSEC have been changed, which is a good thing.
By default, anything older than Windows 7 and Server 2008 R2, these registry settings will be configured to not require 128-bit encryption and not require NTLMv2 session security.
Windows 7 and Server 2008 R2 require 128-bit encryption by default, only.
As Microsoft de-emphasizes NTLM in favor of Kerberos and other plug-in authentication methods, you most likely will want to raise the minimum for NTLM for everyone as legacy operating systems are retired from your environment.
You might even want to follow the Server 2008 Security Guide (http://www.microsoft.com/downloads/details.aspx?FamilyID=5534bee1-3cad-4bf0-b92b-a8e545573a3e) when setting up your policies, which specifies requiring 128-bit encryption and NTLMv2 session security.
In a misconfigured environment, the packets going back and forth between the OCS Edge and OCS Front End will look normal except that the NTLM negotiations will always fail.
The obvious fix is to make sure you have these settings consistent across your organization to begin with and you will never see this problem. It can be problematic if you configure all the servers without configuring all clients with identical settings because clients will be unable to connect to your OCS servers through the Edge without modifying their default operating system settings.
In particular, if you have an unmanaged client environment outside of the office (a very common scenario), you might want to provide the following registry file as a way to help secure your environment and enable unmanaged clients to connect:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0]
"NtlmMinClientSec"=dword:20080000
"NtlmMinServerSec"=dword:20080000
Those registry settings above are equivalent to configuring the following group policy with these options, for client and server:
On a somewhat related note, since we are touching upon NTLM, one of the best tutorials about NTLM gotchas appeared in the August 2006 Security Watch article by Jesper Johansson.
In particular, pay attention to the section detailing the specifics of LMCompatibilityLevel.
In group policy, LMCompatibilityLevel, has a description that looks promising as a potential “most compatible secure” setting but does not behave like the description might lead you to believe.
If you set LMCompatibilityLevel to 1 (Send LM and NTLM – use NTLMv2 session security if negotiated), LM, NTLM and NTLMv2 will be accepted but NTLMv2 will never be sent from the client.
Using 1 might look appealing in a debugging scenario but I would use LMCompatibilityLevel set to 5 to eliminate use of the LM and NTLMv1 protocols.
The gory details are best explained in the above mentioned Security Watch article.
Overall, assuming all your software and operating systems on your network work properly with NTLMv2, I recommend using the recommendations from the Server 2008 Security Guide and setting NTLMMINCLIENTSEC and NTLMMINSERVERSEC to 0x20080000 for all servers and clients. You’ll avoid the OCS Edge headache and you will help avoid older l0phtcrack attacks.
Windows 7 and Server 2008 R2 add some handy NTLM auditing policies that can be used to restrict NTLM but also audit NTLM usage. You can configure the restrictions in audit only mode to see what servers and clients are using NTLM for authentication. It can be handy as a debugging tool and I used it originally when I initially ran into this issue. A good writeup about this can be found here on the Microsoft site. Using these new tools, you might be find applications you never knew that were using NTLM and potentially verify that you can enable NTLMv2 only everywhere.
It is pretty common place to lock down, with a GPO or registry setting, the NTLM settings on member servers, domain controllers and client computers. Although uncommon, there are scenarios where you can effectively break any NTLM negotiation between domain controllers, member servers and clients.
Thankfully, these are well documented in KB 823659, “Client, service, and program incompatibilities that may occur when you modify security settings and user rights assignments”.
Consider this scenario:
OCS servers and internal network (local LAN) clients are Active Directory domain joined.
Non-domain joined clients connect through an OCS Edge.
If NTLMMINCLIENTSEC and/or NTLMMINSERVERSEC differ between clients and servers, for the internal clients and servers, Kerberos authentication will still be functional, assuming you haven't set the pool to only accept NTLM.
Clients that connect through the Edge will be rely entirely on NTLM because Kerberos is not available as an authentication method, as noted in the excellent OCS 2007 R2 Resource Kit.
If NTLM is “broken” inside the domain between domain controllers and OCS servers (front End/edge), the Office Communicator client will act as if the user entered an invalid username or password. The error message on the client computer is very misleading and everyone external will not be able to log in.
As noted in TechNet here, OCS is very particular about the NTLMv2 settings.
These settings, for server and client, can be set in a group policy under Network security: Minimum session security for NTLM SSP based (including secure RPC), or by use of a registry setting.
To directly quote Technet:
Sometimes the server will be configured to require encryption, and the client will not. In this case, the client NTLM request is not passed on by the front-end server. This situation primarily affects external users, because NTLM is the only authentication protocol that external clients can use to sign in. For example, if the server key is configured to have a value of 0x20080030, which specifies 128-bit encryption, and clients are not, clients will be unable to sign in. You should ensure that this key on the client is configured to match the server’s setting.
As operating systems have evolved, the default security settings for NTLMMINCLIENTSEC and NTLMMINSERVERSEC have been changed, which is a good thing.
By default, anything older than Windows 7 and Server 2008 R2, these registry settings will be configured to not require 128-bit encryption and not require NTLMv2 session security.
Windows 7 and Server 2008 R2 require 128-bit encryption by default, only.
As Microsoft de-emphasizes NTLM in favor of Kerberos and other plug-in authentication methods, you most likely will want to raise the minimum for NTLM for everyone as legacy operating systems are retired from your environment.
You might even want to follow the Server 2008 Security Guide (http://www.microsoft.com/downloads/details.aspx?FamilyID=5534bee1-3cad-4bf0-b92b-a8e545573a3e) when setting up your policies, which specifies requiring 128-bit encryption and NTLMv2 session security.
In a misconfigured environment, the packets going back and forth between the OCS Edge and OCS Front End will look normal except that the NTLM negotiations will always fail.
The obvious fix is to make sure you have these settings consistent across your organization to begin with and you will never see this problem. It can be problematic if you configure all the servers without configuring all clients with identical settings because clients will be unable to connect to your OCS servers through the Edge without modifying their default operating system settings.
In particular, if you have an unmanaged client environment outside of the office (a very common scenario), you might want to provide the following registry file as a way to help secure your environment and enable unmanaged clients to connect:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0]
"NtlmMinClientSec"=dword:20080000
"NtlmMinServerSec"=dword:20080000
Those registry settings above are equivalent to configuring the following group policy with these options, for client and server:
On a somewhat related note, since we are touching upon NTLM, one of the best tutorials about NTLM gotchas appeared in the August 2006 Security Watch article by Jesper Johansson.
In particular, pay attention to the section detailing the specifics of LMCompatibilityLevel.
In group policy, LMCompatibilityLevel, has a description that looks promising as a potential “most compatible secure” setting but does not behave like the description might lead you to believe.
If you set LMCompatibilityLevel to 1 (Send LM and NTLM – use NTLMv2 session security if negotiated), LM, NTLM and NTLMv2 will be accepted but NTLMv2 will never be sent from the client.
Using 1 might look appealing in a debugging scenario but I would use LMCompatibilityLevel set to 5 to eliminate use of the LM and NTLMv1 protocols.
The gory details are best explained in the above mentioned Security Watch article.
Overall, assuming all your software and operating systems on your network work properly with NTLMv2, I recommend using the recommendations from the Server 2008 Security Guide and setting NTLMMINCLIENTSEC and NTLMMINSERVERSEC to 0x20080000 for all servers and clients. You’ll avoid the OCS Edge headache and you will help avoid older l0phtcrack attacks.
Windows 7 and Server 2008 R2 add some handy NTLM auditing policies that can be used to restrict NTLM but also audit NTLM usage. You can configure the restrictions in audit only mode to see what servers and clients are using NTLM for authentication. It can be handy as a debugging tool and I used it originally when I initially ran into this issue. A good writeup about this can be found here on the Microsoft site. Using these new tools, you might be find applications you never knew that were using NTLM and potentially verify that you can enable NTLMv2 only everywhere.
Monday, January 11. 2010
OCS 2007 R2 (Client Side - Office Communicator) - January 2010 - 3.5.6907.83
Tuesday, November 17. 2009
GPU acceleration of Flash 10.1 with new ATI/AMD drivers (Nvidia too)
Thursday, November 5. 2009
Find out if current and formerly current Microsoft products are supported on Server 2008 R2
Wednesday, November 4. 2009
Windows 7 and using Intel Turbo Memory (Robson) as a persistent RAM disk or TEMP drive
What I am about to describe below definitely falls under the 'unsupported' and 'not-an-intended-use' category for Intel Turbo Memory. I debated about posting this for a few months but it has worked well enough for me that I feel secure in describing how to do this. Of course, if something breaks, please let me know in the comments section and we'll get it documented.
Typically Intel Turbo Memory is included as a mini-PCIe option on laptops and some desktops, and provides an embedded version of ReadyBoost and/or ReadyDrive. Most computers have enough RAM these days so the boost from ReadyBoost is pretty minimal.
With that in mind, I figured I would try to see if I could re-purpose the Turbo Memory. In Windows 7 (as of driver version 1.10.0.1012), the memory is exposed to the OS as a Storage Controller with a disk volume of IMD-0.
By default, it will automatically enable and control the entire volume.
What you want to do is open diskmgmt.msc and look for a volume that is about 75% of advertised size of the RAM. In my case, I have 2GB which shows up as 1.37GB due to some of the space being used for ReadyDrive.
If you set the View to Disk List, the Device Type will be listed as UNKNOWN instead of IDE or USB or SCSI.
You'll want to delete this volume but make sure it is the Turbo Memory! After deleting the volume, create a new simple MBR volume from what you just deleted. Format the drive as FAT16 with 64KB cluster size. You can use other block sizes if you want less waste on smaller files. NTFS is a bit of an overkill for most scenarios too. Feel free to experiment and report your findings.
After formatting, assign it a drive letter and enjoy a persistent RAM disk, as long as you don't rebuild your computer or upgrade your Turbo Memory driver.
The end result will look something like this:
![R:\](/aaron/uploads/RDrive.png "R:\")
Uses for this new drive
1. Store your Windows Search index on the new drive. In my case, under R:\TEMP\INDEX\. You can easily move your index by going into the Control Panel, under Indexing Options, under Advanced and selecting Select New. After restarting the Windows Search service, the index will move from the original location to the newly created Turbo Memory drive.
Why do this? Less hard drive thrashing overall and faster search results inside Windows and Outlook. Instead of the index and the content residing on the same drive spindle, you have a 'pseudo' SSD dedicated to your Windows Search index. The old joke about making Vista faster was to do net stop wsearch, but this is no longer needed using this method.
2. Set your TEMP and TMP environment variables to use the drive for temporary storage/scratch space. In my case, I set my user TEMP and TMP variables to R:\TEMP\USER and my system TEMP and TMP variables to R:\TEMP\SYSTEM. Make sure to create these directories on the drive before applying the settings.
3. Internet Explorer disk cache location - I set IE to store cache inside R:\TEMP\IE and limit the size to a small amount.
4. Firefox disk cache location - Using about:config, I set browser.cache.disk.parent_directory to R:\TEMP\FF. In order to avoid stalls on fsync on Firefox 3.x due to SQLite, you can also add toolkit.storage.synchronous set to 0 in about:config. I know this quirk is being addressed in Firefox 3.5+, so it will soon be a non-issue. You do have a slight risk of corruption of Firefox SQLite tables, but in practice, I have not experienced any.
Things to watch out for
If you do upgrade the Turbo Memory driver in the future, you will want to reset your TEMP and TMP variables back to the original values in order to ensure that you can log in properly into your computer. The Windows Search index and IE/FF caches can be dynamically regenerated after you redo the drive setup.
I have experienced scenarios/programs that required more than 1.3GB of free temporary space so I sometimes set the variables back to the original hard drive location on a case by case basis.
Conclusion
Please let me know if you think of new uses for this and I will add them to this blog entry. It has worked well for me since W7 RC and it should work well for you too. It has even inspired me into looking into cheap 4GB Robson modules or a secondary bay SSD.
Typically Intel Turbo Memory is included as a mini-PCIe option on laptops and some desktops, and provides an embedded version of ReadyBoost and/or ReadyDrive. Most computers have enough RAM these days so the boost from ReadyBoost is pretty minimal.
With that in mind, I figured I would try to see if I could re-purpose the Turbo Memory. In Windows 7 (as of driver version 1.10.0.1012), the memory is exposed to the OS as a Storage Controller with a disk volume of IMD-0.
By default, it will automatically enable and control the entire volume.
What you want to do is open diskmgmt.msc and look for a volume that is about 75% of advertised size of the RAM. In my case, I have 2GB which shows up as 1.37GB due to some of the space being used for ReadyDrive.
If you set the View to Disk List, the Device Type will be listed as UNKNOWN instead of IDE or USB or SCSI.
You'll want to delete this volume but make sure it is the Turbo Memory! After deleting the volume, create a new simple MBR volume from what you just deleted. Format the drive as FAT16 with 64KB cluster size. You can use other block sizes if you want less waste on smaller files. NTFS is a bit of an overkill for most scenarios too. Feel free to experiment and report your findings.
After formatting, assign it a drive letter and enjoy a persistent RAM disk, as long as you don't rebuild your computer or upgrade your Turbo Memory driver.
The end result will look something like this:
Uses for this new drive
1. Store your Windows Search index on the new drive. In my case, under R:\TEMP\INDEX\. You can easily move your index by going into the Control Panel, under Indexing Options, under Advanced and selecting Select New. After restarting the Windows Search service, the index will move from the original location to the newly created Turbo Memory drive.
Why do this? Less hard drive thrashing overall and faster search results inside Windows and Outlook. Instead of the index and the content residing on the same drive spindle, you have a 'pseudo' SSD dedicated to your Windows Search index. The old joke about making Vista faster was to do net stop wsearch, but this is no longer needed using this method.
2. Set your TEMP and TMP environment variables to use the drive for temporary storage/scratch space. In my case, I set my user TEMP and TMP variables to R:\TEMP\USER and my system TEMP and TMP variables to R:\TEMP\SYSTEM. Make sure to create these directories on the drive before applying the settings.
3. Internet Explorer disk cache location - I set IE to store cache inside R:\TEMP\IE and limit the size to a small amount.
4. Firefox disk cache location - Using about:config, I set browser.cache.disk.parent_directory to R:\TEMP\FF. In order to avoid stalls on fsync on Firefox 3.x due to SQLite, you can also add toolkit.storage.synchronous set to 0 in about:config. I know this quirk is being addressed in Firefox 3.5+, so it will soon be a non-issue. You do have a slight risk of corruption of Firefox SQLite tables, but in practice, I have not experienced any.
Things to watch out for
If you do upgrade the Turbo Memory driver in the future, you will want to reset your TEMP and TMP variables back to the original values in order to ensure that you can log in properly into your computer. The Windows Search index and IE/FF caches can be dynamically regenerated after you redo the drive setup.
I have experienced scenarios/programs that required more than 1.3GB of free temporary space so I sometimes set the variables back to the original hard drive location on a case by case basis.
Conclusion
Please let me know if you think of new uses for this and I will add them to this blog entry. It has worked well for me since W7 RC and it should work well for you too. It has even inspired me into looking into cheap 4GB Robson modules or a secondary bay SSD.
Tuesday, September 15. 2009
West Michigan NT User Group - come see Matt Hester present Windows 7 and Server 2008 R2 - Sept 16th starting at 6pm
Saturday, September 5. 2009
Windows 7 House Party
Monday, August 10. 2009
Mobile Broadband Stack Changes for Windows 7
Tuesday, August 4. 2009
Just in time for Windows 7 RTM downloads off MSDN and TechNet - Windows 7 XP Mode RC and Virtual PC RC
Thursday, July 30. 2009
Noteworthy post-SP2 Outlook 2007 update for Windows 7 users and those experiencing slow performance after installing Office 2007 SP2
Friday, July 24. 2009
ATI/AMD Catalyst 9.7 - first unified Vista and Windows 7 WHQL driver
Monday, June 29. 2009
As seen on the Stephen Rose TechNet blog, win a copy of Windows 7 Ultimate
Search this blog
Links
My e-mail address
Exchange:
Hotfix Tracker (All products)
OCS:
OCS 2007 R2 Documentation Collection
Office:
Office Cumulative Updates Site
Windows:
Other:
FriendFeed
IM me on Live Messenger
Translate this page
Calendar
|
February '20 | |||||
| Mon | Tue | Wed | Thu | Fri | Sat | Sun |
| 1 | 2 | |||||
| 3 | 4 | 5 | 6 | 7 | 8 | 9 |
| 10 | 11 | 12 | 13 | 14 | 15 | 16 |
| 17 | 18 | 19 | 20 | 21 | 22 | 23 |
| 24 | 25 | 26 | 27 | 28 | 29 | |
