Archive

Archive for November, 2007

Why does Windows XP generate so many logon failure events?

November 10th, 2007 No comments

I got the question last week, why there are so many logon failure events on Windows XP when it is not domain joined.


The short answer is, by design.  (Yes, bad design.)


The longer answer is that the shell team is working around the fact that there is no “tell me if this user account has a blank password” API.


When in a workgroup (not domain joined), Windows XP displays a welcome screen that has little pictures (called “tiles”) for each user who is permitted to log on to the computer.


The shell team wanted the experience that when you click on a tile, that you will immediately be logged on if your password is blank (we have good data that a large percentage of home users have blank passwords).  They only want you to be prompted for a password if you actually have a password.  Fair enough, and it also helps with accessibility for people for whom typing is challenging.


The XP Welcome Screen, when it is initialized each time it is to be displayed, attempts to log on each user for which a tile will be displayed, using a blank password.  Users with non-blank passwords will cause failures in this case (other users will cause logon success events followed by logoff success events). [2007-11-21 correction]


The Welcome Screen uses the result of these logon attempts to decide whether to display a password box when you select a user’s tile.  If the user has a blank password, they will be logged on instead of being prompted for a password.


Why are they logging on the account?  Well it turns out to be the easiest way to tell if your password is blank.  We don’t have a “is your password blank” API- that would be a security disaster- and we would prefer that the shell team not go mucking about in the SAM, retrieving hashes and computing the blank password hash for each account so that it could compare them. 


I asked for this behavior to be changed prior to XP’s release.  Specifically I asked that the blank password check be moved from Welcome screen initialization to tile selection- this would still cause logon failures but many fewer of them.  I was declined.  I asked for fixes to it in SP1 and SP2 and was declined.  At this point we will not be revisiting this “feature”; the Welcome Screen was redesigned to eliminate this problem.


The shell team who designed the Welcome Screen did not feel that auditing was a common scenario for workgroup machines, and I didn’t (and still don’t) have any business case to dispute that.

Categories: Descriptions, Tips Tags:

Why does Windows XP generate so many logon failure events?

November 10th, 2007 No comments

I got the question last week, why there are so many logon failure events on Windows XP when it is not domain joined.


The short answer is, by design.  (Yes, bad design.)


The longer answer is that the shell team is working around the fact that there is no “tell me if this user account has a blank password” API.


When in a workgroup (not domain joined), Windows XP displays a welcome screen that has little pictures (called “tiles”) for each user who is permitted to log on to the computer.


The shell team wanted the experience that when you click on a tile, that you will immediately be logged on if your password is blank (we have good data that a large percentage of home users have blank passwords).  They only want you to be prompted for a password if you actually have a password.  Fair enough, and it also helps with accessibility for people for whom typing is challenging.


The XP Welcome Screen, when it is initialized each time it is to be displayed, attempts to log on each user for which a tile will be displayed, using a blank password.  Users with non-blank passwords will cause failures in this case (other users will cause logon success events followed by logoff success events). [2007-11-21 correction]


The Welcome Screen uses the result of these logon attempts to decide whether to display a password box when you select a user’s tile.  If the user has a blank password, they will be logged on instead of being prompted for a password.


Why are they logging on the account?  Well it turns out to be the easiest way to tell if your password is blank.  We don’t have a “is your password blank” API- that would be a security disaster- and we would prefer that the shell team not go mucking about in the SAM, retrieving hashes and computing the blank password hash for each account so that it could compare them. 


I asked for this behavior to be changed prior to XP’s release.  Specifically I asked that the blank password check be moved from Welcome screen initialization to tile selection- this would still cause logon failures but many fewer of them.  I was declined.  I asked for fixes to it in SP1 and SP2 and was declined.  At this point we will not be revisiting this “feature”; the Welcome Screen was redesigned to eliminate this problem.


The shell team who designed the Welcome Screen did not feel that auditing was a common scenario for workgroup machines, and I didn’t (and still don’t) have any business case to dispute that.

Categories: Descriptions, Tips Tags:

Why does Windows XP generate so many logon failure events?

November 10th, 2007 Comments off

I got the question last week, why there are so many logon failure events on Windows XP when it is not domain joined.


The short answer is, by design.  (Yes, bad design.)


The longer answer is that the shell team is working around the fact that there is no “tell me if this user account has a blank password” API.


When in a workgroup (not domain joined), Windows XP displays a welcome screen that has little pictures (called “tiles”) for each user who is permitted to log on to the computer.


The shell team wanted the experience that when you click on a tile, that you will immediately be logged on if your password is blank (we have good data that a large percentage of home users have blank passwords).  They only want you to be prompted for a password if you actually have a password.  Fair enough, and it also helps with accessibility for people for whom typing is challenging.


The XP Welcome Screen, when it is initialized each time it is to be displayed, attempts to log on each user for which a tile will be displayed, using a blank password.  Users with non-blank passwords will cause failures in this case (other users will cause logon success events followed by logoff success events). [2007-11-21 correction]


The Welcome Screen uses the result of these logon attempts to decide whether to display a password box when you select a user’s tile.  If the user has a blank password, they will be logged on instead of being prompted for a password.


Why are they logging on the account?  Well it turns out to be the easiest way to tell if your password is blank.  We don’t have a “is your password blank” API- that would be a security disaster- and we would prefer that the shell team not go mucking about in the SAM, retrieving hashes and computing the blank password hash for each account so that it could compare them. 


I asked for this behavior to be changed prior to XP’s release.  Specifically I asked that the blank password check be moved from Welcome screen initialization to tile selection- this would still cause logon failures but many fewer of them.  I was declined.  I asked for fixes to it in SP1 and SP2 and was declined.  At this point we will not be revisiting this “feature”; the Welcome Screen was redesigned to eliminate this problem.


The shell team who designed the Welcome Screen did not feel that auditing was a common scenario for workgroup machines, and I didn’t (and still don’t) have any business case to dispute that.

Categories: Descriptions, Tips Tags:

Script to configure SharePoint to use ADFS authentication

November 1st, 2007 No comments

More great tools by the ADFS team…


Problems with the web.config files are one of the more common issues we see with ADFS/MOSS cases in PSS.  Now there is a script with will make the modifications for you.


It is located on the SharePoint team blog and can be accessed here.

Script to configure SharePoint to use ADFS authentication

November 1st, 2007 No comments

More great tools by the ADFS team…


Problems with the web.config files are one of the more common issues we see with ADFS/MOSS cases in PSS.  Now there is a script with will make the modifications for you.


It is located on the SharePoint team blog and can be accessed here.

Script to configure SharePoint to use ADFS authentication

November 1st, 2007 No comments

More great tools by the ADFS team…


Problems with the web.config files are one of the more common issues we see with ADFS/MOSS cases in PSS.  Now there is a script with will make the modifications for you.


It is located on the SharePoint team blog and can be accessed here.

Script to configure SharePoint to use ADFS authentication

November 1st, 2007 No comments

More great tools by the ADFS team…


Problems with the web.config files are one of the more common issues we see with ADFS/MOSS cases in PSS.  Now there is a script with will make the modifications for you.


It is located on the SharePoint team blog and can be accessed here.

Script to configure SharePoint to use ADFS authentication

November 1st, 2007 Comments off

More great tools by the ADFS team…


Problems with the web.config files are one of the more common issues we see with ADFS/MOSS cases in PSS.  Now there is a script with will make the modifications for you.


It is located on the SharePoint team blog and can be accessed here.

ADFS Diagnostic Tool

November 1st, 2007 No comments

A huge thanks to the ADFS test team for developing such a great tool. 


 


Here is a quick “how to”


 


The tool is very simple to use and provides a graphical UI. In order to perform distributed diagnosis, i.e. diagnose failures based on the configuration of multiple machines in the scenario, it’s necessary to copy the out file generated by the tool each time it’s run and use it as an input/output file when running the tool on the next machine.


 


For example, to debug a scenario with an FS at the account role (FS-A), an FS at the resource role (FS-R) and a Web Server (WS), first run the tool on the FS-A selecting a new file, say adfsdiag.out. After the tool is run, this file will now contain configuration information relative to the FS-A. Copy the file to the FS-R machine and run the tool there, this time selecting the existing adfsdiag.out file. The tool will detect it already contains information relative to other roles and will execute extra configuration checks, for example, a claim flow check that verifies the outgoing claims sent by the FS-A match the incoming claims expected by the FS-R. After this second run, adfsdiag.out will contain information relative to both the FS-A and FS-R. Finally, copy the out file to the WS machine and run the tool again following the same steps. When running the tool for a role for which there’s already information present in the selected file, the old data for that role will be overwritten with the new information, making it possible to fix errors on a machine and re-run the tool without having to start the whole process all over again. There’s no “right order” to run the tool, all of them should give the same output, except for some certificate checks that will only be executed at the WS in case the information from the FS-R is available beforehand


 


Please give this tool a try and provide any feedback to this blog.

ADFS Diagnostic Tool

November 1st, 2007 No comments

A huge thanks to the ADFS test team for developing such a great tool. 


 


Here is a quick “how to”


 


The tool is very simple to use and provides a graphical UI. In order to perform distributed diagnosis, i.e. diagnose failures based on the configuration of multiple machines in the scenario, it’s necessary to copy the out file generated by the tool each time it’s run and use it as an input/output file when running the tool on the next machine.


 


For example, to debug a scenario with an FS at the account role (FS-A), an FS at the resource role (FS-R) and a Web Server (WS), first run the tool on the FS-A selecting a new file, say adfsdiag.out. After the tool is run, this file will now contain configuration information relative to the FS-A. Copy the file to the FS-R machine and run the tool there, this time selecting the existing adfsdiag.out file. The tool will detect it already contains information relative to other roles and will execute extra configuration checks, for example, a claim flow check that verifies the outgoing claims sent by the FS-A match the incoming claims expected by the FS-R. After this second run, adfsdiag.out will contain information relative to both the FS-A and FS-R. Finally, copy the out file to the WS machine and run the tool again following the same steps. When running the tool for a role for which there’s already information present in the selected file, the old data for that role will be overwritten with the new information, making it possible to fix errors on a machine and re-run the tool without having to start the whole process all over again. There’s no “right order” to run the tool, all of them should give the same output, except for some certificate checks that will only be executed at the WS in case the information from the FS-R is available beforehand


 


Please give this tool a try and provide any feedback to this blog.

ADFS Diagnostic Tool

November 1st, 2007 No comments

A huge thanks to the ADFS test team for developing such a great tool. 


 


Here is a quick “how to”


 


The tool is very simple to use and provides a graphical UI. In order to perform distributed diagnosis, i.e. diagnose failures based on the configuration of multiple machines in the scenario, it’s necessary to copy the out file generated by the tool each time it’s run and use it as an input/output file when running the tool on the next machine.


 


For example, to debug a scenario with an FS at the account role (FS-A), an FS at the resource role (FS-R) and a Web Server (WS), first run the tool on the FS-A selecting a new file, say adfsdiag.out. After the tool is run, this file will now contain configuration information relative to the FS-A. Copy the file to the FS-R machine and run the tool there, this time selecting the existing adfsdiag.out file. The tool will detect it already contains information relative to other roles and will execute extra configuration checks, for example, a claim flow check that verifies the outgoing claims sent by the FS-A match the incoming claims expected by the FS-R. After this second run, adfsdiag.out will contain information relative to both the FS-A and FS-R. Finally, copy the out file to the WS machine and run the tool again following the same steps. When running the tool for a role for which there’s already information present in the selected file, the old data for that role will be overwritten with the new information, making it possible to fix errors on a machine and re-run the tool without having to start the whole process all over again. There’s no “right order” to run the tool, all of them should give the same output, except for some certificate checks that will only be executed at the WS in case the information from the FS-R is available beforehand


 


Please give this tool a try and provide any feedback to this blog.

ADFS Diagnostic Tool

November 1st, 2007 No comments

A huge thanks to the ADFS test team for developing such a great tool. 


 


Here is a quick “how to”


 


The tool is very simple to use and provides a graphical UI. In order to perform distributed diagnosis, i.e. diagnose failures based on the configuration of multiple machines in the scenario, it’s necessary to copy the out file generated by the tool each time it’s run and use it as an input/output file when running the tool on the next machine.


 


For example, to debug a scenario with an FS at the account role (FS-A), an FS at the resource role (FS-R) and a Web Server (WS), first run the tool on the FS-A selecting a new file, say adfsdiag.out. After the tool is run, this file will now contain configuration information relative to the FS-A. Copy the file to the FS-R machine and run the tool there, this time selecting the existing adfsdiag.out file. The tool will detect it already contains information relative to other roles and will execute extra configuration checks, for example, a claim flow check that verifies the outgoing claims sent by the FS-A match the incoming claims expected by the FS-R. After this second run, adfsdiag.out will contain information relative to both the FS-A and FS-R. Finally, copy the out file to the WS machine and run the tool again following the same steps. When running the tool for a role for which there’s already information present in the selected file, the old data for that role will be overwritten with the new information, making it possible to fix errors on a machine and re-run the tool without having to start the whole process all over again. There’s no “right order” to run the tool, all of them should give the same output, except for some certificate checks that will only be executed at the WS in case the information from the FS-R is available beforehand


 


Please give this tool a try and provide any feedback to this blog.

ADFS Diagnostic Tool

November 1st, 2007 Comments off

A huge thanks to the ADFS test team for developing such a great tool. 


 


Here is a quick “how to”


 


The tool is very simple to use and provides a graphical UI. In order to perform distributed diagnosis, i.e. diagnose failures based on the configuration of multiple machines in the scenario, it’s necessary to copy the out file generated by the tool each time it’s run and use it as an input/output file when running the tool on the next machine.


 


For example, to debug a scenario with an FS at the account role (FS-A), an FS at the resource role (FS-R) and a Web Server (WS), first run the tool on the FS-A selecting a new file, say adfsdiag.out. After the tool is run, this file will now contain configuration information relative to the FS-A. Copy the file to the FS-R machine and run the tool there, this time selecting the existing adfsdiag.out file. The tool will detect it already contains information relative to other roles and will execute extra configuration checks, for example, a claim flow check that verifies the outgoing claims sent by the FS-A match the incoming claims expected by the FS-R. After this second run, adfsdiag.out will contain information relative to both the FS-A and FS-R. Finally, copy the out file to the WS machine and run the tool again following the same steps. When running the tool for a role for which there’s already information present in the selected file, the old data for that role will be overwritten with the new information, making it possible to fix errors on a machine and re-run the tool without having to start the whole process all over again. There’s no “right order” to run the tool, all of them should give the same output, except for some certificate checks that will only be executed at the WS in case the information from the FS-R is available beforehand


 


Please give this tool a try and provide any feedback to this blog.

Script to configure SharePoint to use ADFS authentication

November 1st, 2007 No comments

More great tools by the ADFS team…


Problems with the web.config files are one of the more common issues we see with ADFS/MOSS cases in PSS.  Now there is a script with will make the modifications for you.


It is located on the SharePoint team blog and can be accessed here.

ADFS Diagnostic Tool

November 1st, 2007 No comments

A huge thanks to the ADFS test team for developing such a great tool. 


 


Here is a quick “how to”


 


The tool is very simple to use and provides a graphical UI. In order to perform distributed diagnosis, i.e. diagnose failures based on the configuration of multiple machines in the scenario, it’s necessary to copy the out file generated by the tool each time it’s run and use it as an input/output file when running the tool on the next machine.


 


For example, to debug a scenario with an FS at the account role (FS-A), an FS at the resource role (FS-R) and a Web Server (WS), first run the tool on the FS-A selecting a new file, say adfsdiag.out. After the tool is run, this file will now contain configuration information relative to the FS-A. Copy the file to the FS-R machine and run the tool there, this time selecting the existing adfsdiag.out file. The tool will detect it already contains information relative to other roles and will execute extra configuration checks, for example, a claim flow check that verifies the outgoing claims sent by the FS-A match the incoming claims expected by the FS-R. After this second run, adfsdiag.out will contain information relative to both the FS-A and FS-R. Finally, copy the out file to the WS machine and run the tool again following the same steps. When running the tool for a role for which there’s already information present in the selected file, the old data for that role will be overwritten with the new information, making it possible to fix errors on a machine and re-run the tool without having to start the whole process all over again. There’s no “right order” to run the tool, all of them should give the same output, except for some certificate checks that will only be executed at the WS in case the information from the FS-R is available beforehand


 


Please give this tool a try and provide any feedback to this blog.

ADFSDiag.zip