SYSKEY and using Sysprep to issue new SID (XP Pro)
Oops- didn't think about this... am migrating to a new laptop and wanted to use sysprep and issue new SIDs (both laptops will be on my network for awhile, so I want unique SIDs). However, I've used syskey to lock down the SAM - and I believe the password is tied to the SID(?)
I also recall that I cannot undo syskey once I activate it.
So my question: How can I use sysprep to prepare my current laptop for imaging so that it will issue new SIDs - (keeping in mind that syskey requires a startup password)? When I tested the image, an error occured after I provided the system password (setup unable to change password for user account Administrator because of the following error: SamChangePasswordUser returned status c000006a. Fatal error: windows is unable to start because the registry could not be updated).
Oh - and I should mention that My Documents is encrypted - I don't think that should be an issue (worst case, I just need to restore my encryption key).
I am curious to see how many gurus out there have worked with syskey and sysprep...
I also recall that I cannot undo syskey once I activate it.
So my question: How can I use sysprep to prepare my current laptop for imaging so that it will issue new SIDs - (keeping in mind that syskey requires a startup password)? When I tested the image, an error occured after I provided the system password (setup unable to change password for user account Administrator because of the following error: SamChangePasswordUser returned status c000006a. Fatal error: windows is unable to start because the registry could not be updated).
Oh - and I should mention that My Documents is encrypted - I don't think that should be an issue (worst case, I just need to restore my encryption key).
I am curious to see how many gurus out there have worked with syskey and sysprep...
ASKER
Hi maotx
Using XP Pro.
>> Windows 2K and up already have it enabled by default.
I had to enable syskey on XP Pro; it was not enabled by default.
I set the admin password to null - I did receive one less error message, however, it still failed and I am still believing it has to do with syskey. Here is the setuperr.log file:
Warning:
Setup was unable to change the password for user account AdminSam because of the following error:
SamChangePasswordUser returned status c000006a.
***
Warning:
Setup was unable to change the password for user account AdminSam because of the following error:
SamChangePasswordUser returned status c000006a.
***
Warning:
LookupAccountName Administrator (1332)
***
Warning:
Setup failed to get user profile directory. (SystemMyGetUserProfileDir
***
Warning:
Setup failed to update server profile directory.
***
Error:
Setup failed to update user(s) profiles. (UpdateServerProfileDirect
***
Fatal Error:
Windows is unable to start because the registry could not be updated. To address this problem, please contact your computer manufacturer. Windows must now Shut Down.
***
Fatal Error:
Windows is unable to start because the registry could not be updated. To address this problem, please contact your computer manufacturer. Windows must now Shut Down.
***
Using XP Pro.
>> Windows 2K and up already have it enabled by default.
I had to enable syskey on XP Pro; it was not enabled by default.
I set the admin password to null - I did receive one less error message, however, it still failed and I am still believing it has to do with syskey. Here is the setuperr.log file:
Warning:
Setup was unable to change the password for user account AdminSam because of the following error:
SamChangePasswordUser returned status c000006a.
***
Warning:
Setup was unable to change the password for user account AdminSam because of the following error:
SamChangePasswordUser returned status c000006a.
***
Warning:
LookupAccountName Administrator (1332)
***
Warning:
Setup failed to get user profile directory. (SystemMyGetUserProfileDir
***
Warning:
Setup failed to update server profile directory.
***
Error:
Setup failed to update user(s) profiles. (UpdateServerProfileDirect
***
Fatal Error:
Windows is unable to start because the registry could not be updated. To address this problem, please contact your computer manufacturer. Windows must now Shut Down.
***
Fatal Error:
Windows is unable to start because the registry could not be updated. To address this problem, please contact your computer manufacturer. Windows must now Shut Down.
***
You could try exporting the syskey to floppy, but it's really of no real use, the SAM is just as vulnerable as it ever was with or without syskey. Syskey only run's when the PC is booted, so if someone used a floppy to read the SAM "offline" while the PC isn't booted with widows, the SAM has no additional encryption from syskey, even in XP, or 2003. Also, using any one of the modern SAM hash readers, Pwdump3, Pwdump3e, Pwdump3v2, or NTDump- syskey has no effect on them.
http://www.microsoft.com/resources/documentation/Windows/XP/all/reskit/en-us/Default.asp?url=/resources/documentation/windows/xp/all/reskit/en-us/prnb_efs_zbxr.asp
Now depedning on what method you encrypted you My Doc's folder with, you may have other issues. if you use M$ EFS, you definatly need to export your encryption key's to floppy or other media.
http://www.microsoft.com/resources/documentation/Windows/XP/all/reskit/en-us/Default.asp?url=/resources/documentation/windows/xp/all/reskit/en-us/prnb_efs_kcef.asp
http://www.microsoft.com/technet/prodtechnol/winxppro/deploy/cryptfs.mspx
The problem with the syskey in XP is this, once the password is entered... then there is no more "extra" encryption- it's decoded because you entered the right password.
You might also look at this SID reader program from sysinternals
http://www.sysinternals.com/ntw2k/freeware/psgetsid.shtml
http://www.microsoft.com/resources/documentation/Windows/XP/all/reskit/en-us/Default.asp?url=/resources/documentation/Windows/XP/all/reskit/en-us/prnb_efs_jskn.asp
-rich
http://www.microsoft.com/resources/documentation/Windows/XP/all/reskit/en-us/Default.asp?url=/resources/documentation/windows/xp/all/reskit/en-us/prnb_efs_zbxr.asp
Now depedning on what method you encrypted you My Doc's folder with, you may have other issues. if you use M$ EFS, you definatly need to export your encryption key's to floppy or other media.
http://www.microsoft.com/resources/documentation/Windows/XP/all/reskit/en-us/Default.asp?url=/resources/documentation/windows/xp/all/reskit/en-us/prnb_efs_kcef.asp
http://www.microsoft.com/technet/prodtechnol/winxppro/deploy/cryptfs.mspx
The problem with the syskey in XP is this, once the password is entered... then there is no more "extra" encryption- it's decoded because you entered the right password.
You might also look at this SID reader program from sysinternals
http://www.sysinternals.com/ntw2k/freeware/psgetsid.shtml
http://www.microsoft.com/resources/documentation/Windows/XP/all/reskit/en-us/Default.asp?url=/resources/documentation/Windows/XP/all/reskit/en-us/prnb_efs_jskn.asp
-rich
ASKER
Thanks richrumble-
Although interesting, I don't see how your posts help me resolve my problem.
>> the SAM has no additional encryption from syskey, even in XP,
According to the following link, syskey does add additional encryption to sensitive contents of the SAM (mostly master keys): link, http://www.microsoft.com/resources/documentation/Windows/XP/all/reskit/en-us/Default.asp?url=/resources/documentation/windows/xp/all/reskit/en-us/prnb_efs_zbxr.asp
A startup key (also called the syskey) can be used to protect all master keys as well as a variety of other secrets that are stored on computers. At system startup, the startup key is used to encrypt all of the private keys on the computer, including private keys that are used for EFS. Startup keys are automatically generated and used for computers in a domain but must be manually configured on stand-alone computers. Startup key security can be increased by storing the key on removable media or by requiring a system startup password.
My problem is I am trying to create a sysprep'd image with new SIDs. See my earlier post for the error mesages during bootup after the restore. I think it has to do with syskey and am looking for someone knowledgeable with both syskey and sysprep.
Although interesting, I don't see how your posts help me resolve my problem.
>> the SAM has no additional encryption from syskey, even in XP,
According to the following link, syskey does add additional encryption to sensitive contents of the SAM (mostly master keys): link, http://www.microsoft.com/resources/documentation/Windows/XP/all/reskit/en-us/Default.asp?url=/resources/documentation/windows/xp/all/reskit/en-us/prnb_efs_zbxr.asp
A startup key (also called the syskey) can be used to protect all master keys as well as a variety of other secrets that are stored on computers. At system startup, the startup key is used to encrypt all of the private keys on the computer, including private keys that are used for EFS. Startup keys are automatically generated and used for computers in a domain but must be manually configured on stand-alone computers. Startup key security can be increased by storing the key on removable media or by requiring a system startup password.
My problem is I am trying to create a sysprep'd image with new SIDs. See my earlier post for the error mesages during bootup after the restore. I think it has to do with syskey and am looking for someone knowledgeable with both syskey and sysprep.
I believe you are correct about the SID changes affecting your Imaged computers. However, despite syskey's intentions- with the tools available today- syskey offers no additional protection from these tools obtaining the information syskey aim's to protect.
That said, http://support.microsoft.com/?kbid=288348 states the the encryption key's for EFS should be exported, then restored to an imaged PC. I'll bet the same might hold true for syskey, it is able to be exported to removable media, and it is possible to restore to the imaged pc. I've not seen this issue with syskey and sysprep, I can test again to see. I assume your using the latest version of sysprep- actually for XP you should use the sysprep from the XP Service Pack1 Deployment tools http://www.microsoft.com/downloads/details.aspx?FamilyID=7a83123d-507b-4095-9d9d-0a195f7b5f69&displaylang=en
I do recall having problems with the old versions of sysprep and xp- but not like the ones you describe.
GL!
-rich
That said, http://support.microsoft.com/?kbid=288348 states the the encryption key's for EFS should be exported, then restored to an imaged PC. I'll bet the same might hold true for syskey, it is able to be exported to removable media, and it is possible to restore to the imaged pc. I've not seen this issue with syskey and sysprep, I can test again to see. I assume your using the latest version of sysprep- actually for XP you should use the sysprep from the XP Service Pack1 Deployment tools http://www.microsoft.com/downloads/details.aspx?FamilyID=7a83123d-507b-4095-9d9d-0a195f7b5f69&displaylang=en
I do recall having problems with the old versions of sysprep and xp- but not like the ones you describe.
GL!
-rich
ASKER
Hi richrumble-
Just to make sure we are on the same page here, I don't believe this problem is related to EFS at all. I understand that EFS does not encrypt the registry. If I copy just my data to another machine, I would then need to restore my encruption key in order to access the data. Not so if I move my system partition image and data to another machine (but yes, I have exported my key for backup purposes).
The error messages above state that mini-setup is unable to change the registry. I understand that syskey does encrypt master keys. I also believe that the master keys are based upon the SIDs. When I configure sysprep to NOT change the SIDs, then I have no problems. Hence, my conclusion that changing the SIDs breaks the ability for syskey to unencrypt the master keys since the encryption is based upon the original SIDs. This is my current thinking.
Good thought - but I am using is SP1 version of syskey.
On a separate note, your are stating that the tools today can "obtain the information syskey aims to protect". That concerns me. I understood that it would take a few decades to crack EFS using today's supercomputers. I understand that the only feasible way to access EFS encrypted files is to get the master key. I understand that syskey encrypts the master key with EFS level encryption. I looked at pwdump3 and found this:
>> Using this tool, a system administrator can check on the strength of the passwords on his system.
>> Please note: pwdump3 does not exploit a new vulerability; it utilizes
>> existing Windows communications capabilities. To use the program
>> successfully, one must supply a username and password that has
>> administrative-level privileges on the remote system.
This does not seem to support what you are implying. I would be VERY interested to find out how one could defeat the syskey and EFS encryption on my machine and get access - I would be grateful if you could provide further details (although this is not related to my problem...)
Another observation - the links you have provided in the past couple of posts do not support your position that syskey adds no additional encryption. I also do not see how the SID reader can help - I already know how to look in the registry to find out my SIDs.
You refer to "exporting" the syskey; I believe you use Syskey to "encrypt" parts of the SAM which then requires a password or startup disk to decrypt parts of the SAM upon startup. I configured syskey to require a password upon startup instead of requiring a startup disk. I am not sure I see that reconfiguring syskey to require a startup disk instead of a startup password gets me any closer to solving my problem - unless I have misunderstood your suggestion.
Richrumble - I really appreciate your efforts - I can tell that you have put time into your posts and creating the links. I am trying not to be difficult here, and although I have learned some new things from your posts, I don't find that I am any closer to resolving my problem. I hope this post helps you better understand my situation - or maybe helps point out where I am misunderstanding what you are trying to tell me.
With Regards-
Sam
Just to make sure we are on the same page here, I don't believe this problem is related to EFS at all. I understand that EFS does not encrypt the registry. If I copy just my data to another machine, I would then need to restore my encruption key in order to access the data. Not so if I move my system partition image and data to another machine (but yes, I have exported my key for backup purposes).
The error messages above state that mini-setup is unable to change the registry. I understand that syskey does encrypt master keys. I also believe that the master keys are based upon the SIDs. When I configure sysprep to NOT change the SIDs, then I have no problems. Hence, my conclusion that changing the SIDs breaks the ability for syskey to unencrypt the master keys since the encryption is based upon the original SIDs. This is my current thinking.
Good thought - but I am using is SP1 version of syskey.
On a separate note, your are stating that the tools today can "obtain the information syskey aims to protect". That concerns me. I understood that it would take a few decades to crack EFS using today's supercomputers. I understand that the only feasible way to access EFS encrypted files is to get the master key. I understand that syskey encrypts the master key with EFS level encryption. I looked at pwdump3 and found this:
>> Using this tool, a system administrator can check on the strength of the passwords on his system.
>> Please note: pwdump3 does not exploit a new vulerability; it utilizes
>> existing Windows communications capabilities. To use the program
>> successfully, one must supply a username and password that has
>> administrative-level privileges on the remote system.
This does not seem to support what you are implying. I would be VERY interested to find out how one could defeat the syskey and EFS encryption on my machine and get access - I would be grateful if you could provide further details (although this is not related to my problem...)
Another observation - the links you have provided in the past couple of posts do not support your position that syskey adds no additional encryption. I also do not see how the SID reader can help - I already know how to look in the registry to find out my SIDs.
You refer to "exporting" the syskey; I believe you use Syskey to "encrypt" parts of the SAM which then requires a password or startup disk to decrypt parts of the SAM upon startup. I configured syskey to require a password upon startup instead of requiring a startup disk. I am not sure I see that reconfiguring syskey to require a startup disk instead of a startup password gets me any closer to solving my problem - unless I have misunderstood your suggestion.
Richrumble - I really appreciate your efforts - I can tell that you have put time into your posts and creating the links. I am trying not to be difficult here, and although I have learned some new things from your posts, I don't find that I am any closer to resolving my problem. I hope this post helps you better understand my situation - or maybe helps point out where I am misunderstanding what you are trying to tell me.
With Regards-
Sam
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
richrumble - I certainly admire the depth of your technical knowledge on this matter.
My comments for further understanding
1) You are saying that by enabling syskey, no further encryption whatsoever is made to any of the SAM - that the startup password I have assigned with syskey is stored in the SAM using 40-bit encryption, that enabling syskey (with startup password prompt) results in the following process:
a) read the 40-bit startup password from the SAM
b) re-encrypts it using 128-bit encryption in memory
c) have XP Pro prompt for a startup password
d) encrypts the entered startup password in memory using 128-bit encryption
e) match the two passwords in memory using (b) and (d)
f) continue the XP Pro startup process upon a match?
Did I understand that right?
>> Syskey does not perminatly encrypt the information it is protecting
I am confused - the link you provided (http://www.microsoft.com/technet/security/bulletin/fq99-056.mspx) says "Syskey is designed to prevent password cracking attacks by encrypting the SAM database using 128-bit cryptography." It goes on to say that the stream-reuse flaw was patched and that "The patch returns the protection to its stronger state by eliminating the key reuse." It confirms what you said (only affected NT4), and confirms that this was not a problem for Windows 2000. I am using XP Pro.
Your other 2 links (http://www.bindview.com/news/display.cfm?Release=/99/1222.txt and http://www.winnetmag.com/Article/ArticleID/14780/14780.html) confirms this bug/vulnerability and references the Microsoft bulletin and patch from almost 5 years ago.
Do you still believe that this 5 year old NT vulnerability exists in XP Pro? Or am I somehow missing your point (I do that sometimes...)
Your link http://www.winnetmag.com/Article/ArticleID/14780/14780.html referenced the following link: http://support.microsoft.com/kb/q143475/ which says:
System Key hotfix: Strong encryption protects private account information by encrypting the password data using a 128-bit cryptographically random key, known as a password encryption key.
Only the private password information is strongly encrypted in the database, not the entire account database. Every system using the strong encryption option will have a unique password encryption key. The password encryption key is itself encrypted with a System Key. Using strong encryption of account passwords adds additional protection for the contents of the SAM portion of the registry and subsequent backup copies of the registry information
>> While syskey does encrypt the sam with 128-bit encryption in MEMORY, what is written to the HD is still the 40-bit key
The pasted text above seems to contradict your statement by stating that the the "information is strongly encrypted in the database". Again, please let me know if I am misunderstanding what you are trying to tell me or if there is a link that will substantiate this.
And Back to the heart of my problem:
>> Would there be a problem with enabling syskey AFTER you've imaged the PC's?
Too late... man weeks of work configuring my machine - and I don't believe that one can un-syskey once it is enabled.
>> Also of note, if the SAM is deletedaltogether off the HD, syskey enabled or not, the local admin will be a blank password. If there is a passphrase and even if the key's are stored on a floppy, using chntpw or the linux floppy can get around those just fine
I'm missing the point here - I don't believe the admin password is the problem (I did set it to blank per your earlier post and did get one less error message). I am still thinking that because the SIDs are changed and that the syskey password is based upon a SID (maybe the admin SID), that once the SID is changed, certain components of the SAM are no longer accessible.
Sorry if I am missing your points here - I am hoping you have the patience to post again!
richrumble - my brain hurts - you make me think!
With Great Restpect
Sam
My comments for further understanding
1) You are saying that by enabling syskey, no further encryption whatsoever is made to any of the SAM - that the startup password I have assigned with syskey is stored in the SAM using 40-bit encryption, that enabling syskey (with startup password prompt) results in the following process:
a) read the 40-bit startup password from the SAM
b) re-encrypts it using 128-bit encryption in memory
c) have XP Pro prompt for a startup password
d) encrypts the entered startup password in memory using 128-bit encryption
e) match the two passwords in memory using (b) and (d)
f) continue the XP Pro startup process upon a match?
Did I understand that right?
>> Syskey does not perminatly encrypt the information it is protecting
I am confused - the link you provided (http://www.microsoft.com/technet/security/bulletin/fq99-056.mspx) says "Syskey is designed to prevent password cracking attacks by encrypting the SAM database using 128-bit cryptography." It goes on to say that the stream-reuse flaw was patched and that "The patch returns the protection to its stronger state by eliminating the key reuse." It confirms what you said (only affected NT4), and confirms that this was not a problem for Windows 2000. I am using XP Pro.
Your other 2 links (http://www.bindview.com/news/display.cfm?Release=/99/1222.txt and http://www.winnetmag.com/Article/ArticleID/14780/14780.html) confirms this bug/vulnerability and references the Microsoft bulletin and patch from almost 5 years ago.
Do you still believe that this 5 year old NT vulnerability exists in XP Pro? Or am I somehow missing your point (I do that sometimes...)
Your link http://www.winnetmag.com/Article/ArticleID/14780/14780.html referenced the following link: http://support.microsoft.com/kb/q143475/ which says:
System Key hotfix: Strong encryption protects private account information by encrypting the password data using a 128-bit cryptographically random key, known as a password encryption key.
Only the private password information is strongly encrypted in the database, not the entire account database. Every system using the strong encryption option will have a unique password encryption key. The password encryption key is itself encrypted with a System Key. Using strong encryption of account passwords adds additional protection for the contents of the SAM portion of the registry and subsequent backup copies of the registry information
>> While syskey does encrypt the sam with 128-bit encryption in MEMORY, what is written to the HD is still the 40-bit key
The pasted text above seems to contradict your statement by stating that the the "information is strongly encrypted in the database". Again, please let me know if I am misunderstanding what you are trying to tell me or if there is a link that will substantiate this.
And Back to the heart of my problem:
>> Would there be a problem with enabling syskey AFTER you've imaged the PC's?
Too late... man weeks of work configuring my machine - and I don't believe that one can un-syskey once it is enabled.
>> Also of note, if the SAM is deletedaltogether off the HD, syskey enabled or not, the local admin will be a blank password. If there is a passphrase and even if the key's are stored on a floppy, using chntpw or the linux floppy can get around those just fine
I'm missing the point here - I don't believe the admin password is the problem (I did set it to blank per your earlier post and did get one less error message). I am still thinking that because the SIDs are changed and that the syskey password is based upon a SID (maybe the admin SID), that once the SID is changed, certain components of the SAM are no longer accessible.
Sorry if I am missing your points here - I am hoping you have the patience to post again!
richrumble - my brain hurts - you make me think!
With Great Restpect
Sam
You make me type, i think that's worse... ;p
I understand the porblem. M$ is saying one thing (with the links I am providing), however it's been greatly documented that the protection they are promising isn't a reality. And it's easy to see for your self. using NTFS-DOS or the linux boot floppy/cd-rom. In order for M$'s Syskey to work as "advertised" the sam hashes would have to be the 128-bit versions of the 40-bit hashs- and then write that to disk. However, even in win2k-xp-and 2003 this is not the case. The syskey encryption works the same way NT-Auth works, by comparing hashes.
(from reading your last post, I'm sure you get these basics- but just in case)
When you type in your password to log-on to a pc, the pc looks at what you typed, then contact's the Domain Controler (or GC) and they negotiate another round of encryption called a challenge hash, then the DC/GC uses that challenge to encrypt the password it has in the DC/GC sam hash for that user name. The DC/GC waits to hear from the workstation. The workstation then encrypts what you typed with the LanMan/NTLM hash, then encrypts that NThash with the challenge, once both have been encrypted, that data is sent to the DC/GC. The DC/GC looks to see if that matches what it computed, if it does, your auth'd and you log-in. If not, your asked to try again.
Syskey does the same, it uses the values in the SAM on the HD, then encrypts that hash with the 128-bit algorythim on top of the 40-bit versions in the SAM, and stores that in memory.
If you turn off a syskey enabled PC suddenly (like pulling the power cable out), and you read the SAM off-line using a boot disk, you'll see that syskey doesn't write the 128-bit value to disk at any time.
The startup password is yet another Auth Mechanism, which was not available in the first itteration of syskey btw. I think once M$ figured out that syskey wasn't much of anything, they added the additional password function, this to me seems a lot like a bios boot password.
Now while you cannot reliably disable syskey after it's been enabled- what I would do is recreate the master image, and not enable syskey on the master image. Then when i imaged a PC, i'd turn on syskey after mini-setup finished.
Also, the vulnerability mentioned above did only apply to NT4, and nothing afterwards- so I do not see this affecting anything nowadays.
I've just tested a ghost image, syskey was enabled, and sid's set to change on the XP machine, and I have not encoutered a problem with this box so far. I'll bet I have a problem if I set the syskey password though... I'll give it a try and see if I can come up with a solution.
-rich
I understand the porblem. M$ is saying one thing (with the links I am providing), however it's been greatly documented that the protection they are promising isn't a reality. And it's easy to see for your self. using NTFS-DOS or the linux boot floppy/cd-rom. In order for M$'s Syskey to work as "advertised" the sam hashes would have to be the 128-bit versions of the 40-bit hashs- and then write that to disk. However, even in win2k-xp-and 2003 this is not the case. The syskey encryption works the same way NT-Auth works, by comparing hashes.
(from reading your last post, I'm sure you get these basics- but just in case)
When you type in your password to log-on to a pc, the pc looks at what you typed, then contact's the Domain Controler (or GC) and they negotiate another round of encryption called a challenge hash, then the DC/GC uses that challenge to encrypt the password it has in the DC/GC sam hash for that user name. The DC/GC waits to hear from the workstation. The workstation then encrypts what you typed with the LanMan/NTLM hash, then encrypts that NThash with the challenge, once both have been encrypted, that data is sent to the DC/GC. The DC/GC looks to see if that matches what it computed, if it does, your auth'd and you log-in. If not, your asked to try again.
Syskey does the same, it uses the values in the SAM on the HD, then encrypts that hash with the 128-bit algorythim on top of the 40-bit versions in the SAM, and stores that in memory.
If you turn off a syskey enabled PC suddenly (like pulling the power cable out), and you read the SAM off-line using a boot disk, you'll see that syskey doesn't write the 128-bit value to disk at any time.
The startup password is yet another Auth Mechanism, which was not available in the first itteration of syskey btw. I think once M$ figured out that syskey wasn't much of anything, they added the additional password function, this to me seems a lot like a bios boot password.
Now while you cannot reliably disable syskey after it's been enabled- what I would do is recreate the master image, and not enable syskey on the master image. Then when i imaged a PC, i'd turn on syskey after mini-setup finished.
Also, the vulnerability mentioned above did only apply to NT4, and nothing afterwards- so I do not see this affecting anything nowadays.
I've just tested a ghost image, syskey was enabled, and sid's set to change on the XP machine, and I have not encoutered a problem with this box so far. I'll bet I have a problem if I set the syskey password though... I'll give it a try and see if I can come up with a solution.
-rich
ASKER
Thank Rich-
I would like to do the test you suggest - I have ntfs-dos on a dos boot disk (I am still "Linux-stupid"). What exactly am I looking for to confirm that the passwords in the sam are NOT encrypted with a 128-bit key and is as vulnerable as you say with syskey enabled?
By the way, I am on a workgroup - no Domain controller.
>> however it's been greatly documented that the protection they are promising isn't a reality
>> this to me seems a lot like a bios boot password.
>> Syskey does the same, it uses the values in the SAM on the HD, then encrypts that hash with the 128-bit algorythim on top of the 40-bit versions in the SAM, and stores that in memory.
Is your position that Syskey does not perform any encryption on the SAM? Non-microsoft posts are contradicting this.
Would you dispute the following link:
http://www.windowsnetworking.com/kbase/WindowsTips/WindowsNT/RegistryTips/Miscellaneous/Whathappenswhensyskeyisinstalledandhowtogetridofit.html
When syskey is active, the hashes are encrypted/obfuscated yet
another time before being stored in the SAM registry.
However, they're stored in the old form in memory after boot
(pwdump2 demonstrates this),
since the old form is needed for NTLM authentication on the network etc.
Regarding my problem, thanks for your above and beyond efforts by testing a ghost image. Which of the syskey configurations did you test(boot disk or obfuscation)?
I am eager to find out your results with the syskey password.
I would like to do the test you suggest - I have ntfs-dos on a dos boot disk (I am still "Linux-stupid"). What exactly am I looking for to confirm that the passwords in the sam are NOT encrypted with a 128-bit key and is as vulnerable as you say with syskey enabled?
By the way, I am on a workgroup - no Domain controller.
>> however it's been greatly documented that the protection they are promising isn't a reality
>> this to me seems a lot like a bios boot password.
>> Syskey does the same, it uses the values in the SAM on the HD, then encrypts that hash with the 128-bit algorythim on top of the 40-bit versions in the SAM, and stores that in memory.
Is your position that Syskey does not perform any encryption on the SAM? Non-microsoft posts are contradicting this.
Would you dispute the following link:
http://www.windowsnetworking.com/kbase/WindowsTips/WindowsNT/RegistryTips/Miscellaneous/Whathappenswhensyskeyisinstalledandhowtogetridofit.html
When syskey is active, the hashes are encrypted/obfuscated yet
another time before being stored in the SAM registry.
However, they're stored in the old form in memory after boot
(pwdump2 demonstrates this),
since the old form is needed for NTLM authentication on the network etc.
Regarding my problem, thanks for your above and beyond efforts by testing a ghost image. Which of the syskey configurations did you test(boot disk or obfuscation)?
I am eager to find out your results with the syskey password.
ASKER
Hi richrumble -
I haven't heard back from you, so I figure I made you type too much...!
Your posts have been of great value to me - as a result, I have disabled LM Hash storage - so LM Hashes for user accounts are no longer available in my registry for cracking
Regarding your statements that syskey is easily defeated:
>> despite syskey's intentions- with the tools available today- syskey offers no additional protection from these tools obtaining the information syskey aim's to protect.
From my search on the web, SAMInside seems to be the most recognized password recovery utility that can crack syskey. I am attaching a link to their response confirming that they CANNOT crack syskey unless the key itself is stored in the registry (syskey obfuscation method that I asked you about in my last post).
http://www.insidepro.com/gb/eng/index.shtml
Subject: Re: SAM/SYSTEM files you request in message 158 to analyze
Hello!
Program SAMInside recovers passwords only if
SYSKEY is located in the Windows registry.
If your SYSKEY is entered on OS boot (or if
you store it on separate diskette), you're to
select menu "Import SAM and SYSKEY files...".
At the same time you aren't to use "GetSyskey" utility to get SYSKEY, but:
- manually create 16-byte file containing key (if you enter it manually); or
- use key stored on separate floppy disk (find more about SYSKEY.EXE use on this
page: http://support.microsoft.com/default.aspx?scid=KB;en-us;q143475)
P.S. Other programs (PWSEX + BKHive&SAMDump2)
also not work with your SAM/SYSTEM-files.
Best regards,
InsidePro Support
E-mail: Support@InsidePro.com
Web: http://www.InsidePro.com
Although we took a valuable detour on whether syskey was easily defeatable or not, My original and outstanding question remains:
How can I use sysprep to prepare my current laptop for imaging so that it will issue new SIDs - (keeping in mind that I have configured syskey to require a startup password)? When I tested the image, an error occured after I provided the syskey startup password (see error log above).
Unless I hear otherwise, I will close this thread next week and award points.
I haven't heard back from you, so I figure I made you type too much...!
Your posts have been of great value to me - as a result, I have disabled LM Hash storage - so LM Hashes for user accounts are no longer available in my registry for cracking
Regarding your statements that syskey is easily defeated:
>> despite syskey's intentions- with the tools available today- syskey offers no additional protection from these tools obtaining the information syskey aim's to protect.
From my search on the web, SAMInside seems to be the most recognized password recovery utility that can crack syskey. I am attaching a link to their response confirming that they CANNOT crack syskey unless the key itself is stored in the registry (syskey obfuscation method that I asked you about in my last post).
http://www.insidepro.com/gb/eng/index.shtml
Subject: Re: SAM/SYSTEM files you request in message 158 to analyze
Hello!
Program SAMInside recovers passwords only if
SYSKEY is located in the Windows registry.
If your SYSKEY is entered on OS boot (or if
you store it on separate diskette), you're to
select menu "Import SAM and SYSKEY files...".
At the same time you aren't to use "GetSyskey" utility to get SYSKEY, but:
- manually create 16-byte file containing key (if you enter it manually); or
- use key stored on separate floppy disk (find more about SYSKEY.EXE use on this
page: http://support.microsoft.com/default.aspx?scid=KB;en-us;q143475)
P.S. Other programs (PWSEX + BKHive&SAMDump2)
also not work with your SAM/SYSTEM-files.
Best regards,
InsidePro Support
E-mail: Support@InsidePro.com
Web: http://www.InsidePro.com
Although we took a valuable detour on whether syskey was easily defeatable or not, My original and outstanding question remains:
How can I use sysprep to prepare my current laptop for imaging so that it will issue new SIDs - (keeping in mind that I have configured syskey to require a startup password)? When I tested the image, an error occured after I provided the syskey startup password (see error log above).
Unless I hear otherwise, I will close this thread next week and award points.
This is my contention: The 40-bit version of this password: "HelloWorld" is
Admin:500:NO PASSWORD******************
admin:1007:NO PASSWORD******************
That is the NTLM hash, the case sensitive version. This is a fresh install of winxp- no syskey enabled. It's also the same key I read from the SAM of a syskey enabled machine, and booted using http://home.eunet.no/~pnordahl/ntpasswd/ The cd-rom version is what I preffer. It will read and show you the hash, even reset a password. With NTFS-DOS you have to copy the sam file off and view it, or you can try to use "type" to show you the contents of it. c:\windows\system32\config
I do disagree with the paper linked above, even though he is the author of the very tool I use to dump/change the hash's. Pwdump3 get's the hash's, even with the password protection, and the floppy storage of the syskey... you'll have to try it to verify I suppose. I'll brb, i'm going to see if I remember how to read the SAM file in the system32\config dir.
You are correct, that I do not have a solution to your sysprep question. I've tried all variations, syskey stored in registry, syskey stored on floppy, syskey stored on floppy with password protection, syskey stored in registry with password protection- I am able to go through the mini-setup no problem, and I can get the passwords using pwdump3 off the machine just fine in each one of those scenirios. Sid's changed everytime btw.
-rich
Admin:500:NO PASSWORD******************
admin:1007:NO PASSWORD******************
That is the NTLM hash, the case sensitive version. This is a fresh install of winxp- no syskey enabled. It's also the same key I read from the SAM of a syskey enabled machine, and booted using http://home.eunet.no/~pnordahl/ntpasswd/ The cd-rom version is what I preffer. It will read and show you the hash, even reset a password. With NTFS-DOS you have to copy the sam file off and view it, or you can try to use "type" to show you the contents of it. c:\windows\system32\config
I do disagree with the paper linked above, even though he is the author of the very tool I use to dump/change the hash's. Pwdump3 get's the hash's, even with the password protection, and the floppy storage of the syskey... you'll have to try it to verify I suppose. I'll brb, i'm going to see if I remember how to read the SAM file in the system32\config dir.
You are correct, that I do not have a solution to your sysprep question. I've tried all variations, syskey stored in registry, syskey stored on floppy, syskey stored on floppy with password protection, syskey stored in registry with password protection- I am able to go through the mini-setup no problem, and I can get the passwords using pwdump3 off the machine just fine in each one of those scenirios. Sid's changed everytime btw.
-rich
ASKER
Rich- thanks for the link - (http://home.eunet.no/~pnordahl/ntpasswd). I tried your preferred CD-Rom version. Really cool - I will have to keep this CD on hand.
This is what I found:
1) Even with syskey (startup passphrase) enabled, I WAS able to blank Administrator and user passwords as you have said; however, I still needed to provide the syskey startup passphrase to startup before I could log into the user account - and sure enough, blanking the password for any account allowed me to then login without a password.
2) I used the utility to remove syskey - and Windows did boot - but then I was unable to log into ANY accounts, even those whose passwords I had blanked either before AND/OR after I had disabled syskey
The author does note (http://home.eunet.no/~pnordahl/ntpasswd/syskey.txt) that
"VeryBAD: SWITHCHING OFF IN WINDOWS 2000 AND XP NOT PERFECT,
WILL CAUSE TROUBLE, but you can access the computer
afterwards."
In my case, I was NOT able to access my computer. I was unable to get past the logon screen - but it appears from the author's comments that others can login under XP (maybe changes in SP2 closed vulnerability?). Most of his work seems to have been for NT with some for Windows 2000: "resetting this mode flag and SecureBoot to 0 is all that's needed to switch off syskey in NT4 (up to SP6 at time of writing). "
A followup e-mail to InsidePro supports my current belief that there is not yet a method to crack syskey (or that he is also unaware of a method to do so):
SA> I was told that syskey was easy to defeat, even with passphrase or
SA> floppy startup. However, if I understand you correctly, you are
SA> saying that if I use syskey with startup password, then nobody will
SA> be able to crack my system with password recovery software?
Yes.
Best regards,
InsidePro Support
E-mail: Support@InsidePro.com
Web: http://www.InsidePro.com
Although even more off topic, I encrypt "My Documents" with EFS. So even if there is a method to blank passwords and defeat syskey, I believe that my EFS encrypted data will remain uncrackable.
Back to my problem: I really appreciate your trying all the variations you mentioned in your last post. I think I will need to try with a new install and see whether there is something about my current 'image' that is causing the problem whenever I sysprep and generate new SIDs. Will post my results.
This is what I found:
1) Even with syskey (startup passphrase) enabled, I WAS able to blank Administrator and user passwords as you have said; however, I still needed to provide the syskey startup passphrase to startup before I could log into the user account - and sure enough, blanking the password for any account allowed me to then login without a password.
2) I used the utility to remove syskey - and Windows did boot - but then I was unable to log into ANY accounts, even those whose passwords I had blanked either before AND/OR after I had disabled syskey
The author does note (http://home.eunet.no/~pnordahl/ntpasswd/syskey.txt) that
"VeryBAD: SWITHCHING OFF IN WINDOWS 2000 AND XP NOT PERFECT,
WILL CAUSE TROUBLE, but you can access the computer
afterwards."
In my case, I was NOT able to access my computer. I was unable to get past the logon screen - but it appears from the author's comments that others can login under XP (maybe changes in SP2 closed vulnerability?). Most of his work seems to have been for NT with some for Windows 2000: "resetting this mode flag and SecureBoot to 0 is all that's needed to switch off syskey in NT4 (up to SP6 at time of writing). "
A followup e-mail to InsidePro supports my current belief that there is not yet a method to crack syskey (or that he is also unaware of a method to do so):
SA> I was told that syskey was easy to defeat, even with passphrase or
SA> floppy startup. However, if I understand you correctly, you are
SA> saying that if I use syskey with startup password, then nobody will
SA> be able to crack my system with password recovery software?
Yes.
Best regards,
InsidePro Support
E-mail: Support@InsidePro.com
Web: http://www.InsidePro.com
Although even more off topic, I encrypt "My Documents" with EFS. So even if there is a method to blank passwords and defeat syskey, I believe that my EFS encrypted data will remain uncrackable.
Back to my problem: I really appreciate your trying all the variations you mentioned in your last post. I think I will need to try with a new install and see whether there is something about my current 'image' that is causing the problem whenever I sysprep and generate new SIDs. Will post my results.
There should be like 3 warnings for that floppy when turning syskey off... it's never worked for me reliably. Sorry you'll have to start over, but that's life with M$ sometimes. Once you have gotten back to the point where your going to run sysprep- Leave syskey off for the time being, make an image that will change the sid's, and test. If that works, keep that image just in case, then turn on syskey on the pc you derive the image from, then re-run sysprep, hopefully you won't have trouble, if you do still, you can roll back to the saved image just before syskey was enabled.
I was reading through my hacking exposed 3rd edition with reguard to syskey, and making sure I'm not crazy. By blanking the passwords, or changing them, in the sam, then writting them to disk- when the PC boot's up, syskey will take those pass's and encrypt them as it's supposed to, but will not write that value to disk, as I've been maintaing. Granted also, that ADMIN Right's and or Physical Access are required to do so.
Cracking syskey has never been in my claim, however bypassing it is. Syskey only run's when windows is running, and never overwrites the sam to disk. The newest version of the linux-boot-reset utility doesn't allow you to view the hash like it used to, I'm going to look for an old version to see if it does. Copying the SAM using ntfs-dos does also reflect the fact that the hash is the same syskey or no for the "HelloWorld" password.
Syskey will no affect M$ EFS- While EFS seems safe from cracking, it too suffers from a fatal flaw, that I exploit on a monthly basis. EFS creates a efsX.tmp file in the directory that the file or folder being encrypted resides. "X" being a number starting at 0 and incrementing. Even if the EFS key's are exported, the data remains in an unencrypted form on the HD. Using over-writters, formatters, disc wipes, are useless if one is using a good low-level reader like the ones you can get from OnTrack software- http://www.ontrack.com/software/
For years I used Tiramisu, with great sucess, and now we have the whole suite of ontrack's tools. They have paid for themselves twice over this year alone. While EFS encrypted files seem pretty safe if the key's are exported, they are not. Even using OnTrack's own Data Eraser, I am able to recover the data, np.
http://seclists.org/lists/bugtraq/2001/Jan/0304.html http://www.ntfs.com/issues-encrypted-files.htm
BTW, despite claims (again) all HD data is recoverable- depends on what level you wnat to take it to, with an electron-tunneling microscope all HD data is recoverable. But even without one, ontrack's tools are great. Altough data that is in a RAID stripe is difficult to recover.
You keep getting me off the subject ;) Anywho, let me know how your rebuild goes...
-rich
I was reading through my hacking exposed 3rd edition with reguard to syskey, and making sure I'm not crazy. By blanking the passwords, or changing them, in the sam, then writting them to disk- when the PC boot's up, syskey will take those pass's and encrypt them as it's supposed to, but will not write that value to disk, as I've been maintaing. Granted also, that ADMIN Right's and or Physical Access are required to do so.
Cracking syskey has never been in my claim, however bypassing it is. Syskey only run's when windows is running, and never overwrites the sam to disk. The newest version of the linux-boot-reset utility doesn't allow you to view the hash like it used to, I'm going to look for an old version to see if it does. Copying the SAM using ntfs-dos does also reflect the fact that the hash is the same syskey or no for the "HelloWorld" password.
Syskey will no affect M$ EFS- While EFS seems safe from cracking, it too suffers from a fatal flaw, that I exploit on a monthly basis. EFS creates a efsX.tmp file in the directory that the file or folder being encrypted resides. "X" being a number starting at 0 and incrementing. Even if the EFS key's are exported, the data remains in an unencrypted form on the HD. Using over-writters, formatters, disc wipes, are useless if one is using a good low-level reader like the ones you can get from OnTrack software- http://www.ontrack.com/software/
For years I used Tiramisu, with great sucess, and now we have the whole suite of ontrack's tools. They have paid for themselves twice over this year alone. While EFS encrypted files seem pretty safe if the key's are exported, they are not. Even using OnTrack's own Data Eraser, I am able to recover the data, np.
http://seclists.org/lists/bugtraq/2001/Jan/0304.html http://www.ntfs.com/issues-encrypted-files.htm
BTW, despite claims (again) all HD data is recoverable- depends on what level you wnat to take it to, with an electron-tunneling microscope all HD data is recoverable. But even without one, ontrack's tools are great. Altough data that is in a RAID stripe is difficult to recover.
You keep getting me off the subject ;) Anywho, let me know how your rebuild goes...
-rich
ASKER
rich-
I have taken the off-topic thread and created a new post with it's own points (500) entitled:
Is there a way to 1) bypass XP Pro Syskey that requires a startup passphrase, and 2) bypass EFS -- in order to access files that were created within EFS-encrypted folders
To continue the thread on bypassing Syskey and EFS, please go here: https://www.experts-exchange.com/questions/21223219/Is-there-a-way-to-1-bypass-XP-Pro-Syskey-that-requires-a-startup-passphrase-and-2-bypass-EFS-in-order-to-access-files-that-were-created-within-EFS-encrypted-folders.html
--------
I would like this question to stay on topic - my original question remains:
How can I use sysprep to prepare my current laptop for imaging so that it will issue new SIDs - (keeping in mind that syskey requires a startup password)? When I tested the image, an error occured after I provided the system password (setup unable to change password for user account Administrator because of the following error: SamChangePasswordUser returned status c000006a. Fatal error: windows is unable to start because the registry could not be updated).
Summary of where I am:
1) I know how to get sysprep to issue new SIDs (this is the default setting). However, issuing new SIDs while syskey is enabled to require a startup passphrase results in Windows shutting down after I get past the syskey passphrase.
2) richrumble has been kind enough to do his own testing and was able to enable syskey with option to require a startup syskey passphrase, was able to successfully do a sysprep with new SIDs and startup the new image. I am going to try this with a new XP Pro install (actually, XP MCE 2004)
2) Per maotx's suggestion, I set the admin password to null - I did receive one less error message, however, it still failed and I am still believing it has to do with syskey. Here is the setuperr.log file:
Warning:
Setup was unable to change the password for user account AdminSam because of the following error:
SamChangePasswordUser returned status c000006a.
***
Warning:
Setup was unable to change the password for user account AdminSam because of the following error:
SamChangePasswordUser returned status c000006a.
***
Warning:
LookupAccountName Administrator (1332)
***
Warning:
Setup failed to get user profile directory. (SystemMyGetUserProfileDir
***
Warning:
Setup failed to update server profile directory.
***
Error:
Setup failed to update user(s) profiles. (UpdateServerProfileDirect
***
Fatal Error:
Windows is unable to start because the registry could not be updated. To address this problem, please contact your computer manufacturer. Windows must now Shut Down.
***
Fatal Error:
Windows is unable to start because the registry could not be updated. To address this problem, please contact your computer manufacturer. Windows must now Shut Down.
***
If anyone has any other thoughts on this problem, please post! I will try to recreate richrumble's test with a clean install to see if maybe my current configuration is responsible for the problem.
Thanks-
I have taken the off-topic thread and created a new post with it's own points (500) entitled:
Is there a way to 1) bypass XP Pro Syskey that requires a startup passphrase, and 2) bypass EFS -- in order to access files that were created within EFS-encrypted folders
To continue the thread on bypassing Syskey and EFS, please go here: https://www.experts-exchange.com/questions/21223219/Is-there-a-way-to-1-bypass-XP-Pro-Syskey-that-requires-a-startup-passphrase-and-2-bypass-EFS-in-order-to-access-files-that-were-created-within-EFS-encrypted-folders.html
--------
I would like this question to stay on topic - my original question remains:
How can I use sysprep to prepare my current laptop for imaging so that it will issue new SIDs - (keeping in mind that syskey requires a startup password)? When I tested the image, an error occured after I provided the system password (setup unable to change password for user account Administrator because of the following error: SamChangePasswordUser returned status c000006a. Fatal error: windows is unable to start because the registry could not be updated).
Summary of where I am:
1) I know how to get sysprep to issue new SIDs (this is the default setting). However, issuing new SIDs while syskey is enabled to require a startup passphrase results in Windows shutting down after I get past the syskey passphrase.
2) richrumble has been kind enough to do his own testing and was able to enable syskey with option to require a startup syskey passphrase, was able to successfully do a sysprep with new SIDs and startup the new image. I am going to try this with a new XP Pro install (actually, XP MCE 2004)
2) Per maotx's suggestion, I set the admin password to null - I did receive one less error message, however, it still failed and I am still believing it has to do with syskey. Here is the setuperr.log file:
Warning:
Setup was unable to change the password for user account AdminSam because of the following error:
SamChangePasswordUser returned status c000006a.
***
Warning:
Setup was unable to change the password for user account AdminSam because of the following error:
SamChangePasswordUser returned status c000006a.
***
Warning:
LookupAccountName Administrator (1332)
***
Warning:
Setup failed to get user profile directory. (SystemMyGetUserProfileDir
***
Warning:
Setup failed to update server profile directory.
***
Error:
Setup failed to update user(s) profiles. (UpdateServerProfileDirect
***
Fatal Error:
Windows is unable to start because the registry could not be updated. To address this problem, please contact your computer manufacturer. Windows must now Shut Down.
***
Fatal Error:
Windows is unable to start because the registry could not be updated. To address this problem, please contact your computer manufacturer. Windows must now Shut Down.
***
If anyone has any other thoughts on this problem, please post! I will try to recreate richrumble's test with a clean install to see if maybe my current configuration is responsible for the problem.
Thanks-
ASKER
richrumble - you said:
There should be like 3 warnings for that floppy when turning syskey off... it's never worked for me reliably. Sorry you'll have to start over, but that's life with M$ sometimes. Once you have gotten back to the point where your going to run sysprep- Leave syskey off for the time being, make an image that will change the sid's, and test. If that works, keep that image just in case, then turn on syskey on the pc you derive the image from, then re-run sysprep, hopefully you won't have trouble, if you do still, you can roll back to the saved image just before syskey was enabled.
I wish I could do this, but I have done a LOT of work since syskey was enabled - going back to that image and recreating the work on my OS is not something I want to do (I would rather keep the same SIDs when I transfer to the new laptop...). Good thing to remember next time I have to build a system from scratch upon which I want syskey enabled...
There should be like 3 warnings for that floppy when turning syskey off... it's never worked for me reliably. Sorry you'll have to start over, but that's life with M$ sometimes. Once you have gotten back to the point where your going to run sysprep- Leave syskey off for the time being, make an image that will change the sid's, and test. If that works, keep that image just in case, then turn on syskey on the pc you derive the image from, then re-run sysprep, hopefully you won't have trouble, if you do still, you can roll back to the saved image just before syskey was enabled.
I wish I could do this, but I have done a LOT of work since syskey was enabled - going back to that image and recreating the work on my OS is not something I want to do (I would rather keep the same SIDs when I transfer to the new laptop...). Good thing to remember next time I have to build a system from scratch upon which I want syskey enabled...
ASKER
rich - are you still out there?
>> You are correct, that I do not have a solution to your sysprep question. I've tried all variations, syskey stored in registry, syskey stored on floppy, syskey stored on floppy with password protection, syskey stored in registry with password protection- I am able to go through the mini-setup no problem, and I can get the passwords using pwdump3 off the machine just fine in each one of those scenirios. Sid's changed everytime btw.
I tried 2 other configurations:
1) Restored the OEM image that came on my laptop, did the initial XP configuration (admin password, user accounts, network...) and then enabled syskey. Rebooted and syskey prompted for the startup password. Everything worked fine. Then did a sysprep (copied sysprep.exe and setupcl.exe to c:\sysprep and then ran sysprep.exe; selected "mini setup"). I restarted the system - syskey prompted me for the startup password. Syskey accepted the password, started the mini setup and then gave me the same error message (windows needs to shut down). Error log was the same as I have posted above
2) I then deleted the system partition and did a new install of MCE2005. Followed the same steps above to enable syskey, and did a sysprep. Same errors.
After trying to do a mini setup on 3 syskey'd, sysprep'd OS images that require a syskey startup password AND receiving the same error, I am not able to recreate richrumble's results.
Rich- did you follow the same steps I have outlined here, or are there other steps you did that I have missed?
One of my original comments:
>> I've used syskey to lock down the SAM - and I believe the password is tied to the SID(?)
My conclusions so far:
1) I was wrong (thanks rich): syskey does not "lock down the SAM"
2) There is some connection between syskey and the SIDs that prevents (at least part of) the registry from being modified when the SIDs are changed.
Here is a link to another user that has experienced this problem:
http://www.mcse.ms/archive65-2004-3-462546.html
Anyone else have any wisdom on this?
>> You are correct, that I do not have a solution to your sysprep question. I've tried all variations, syskey stored in registry, syskey stored on floppy, syskey stored on floppy with password protection, syskey stored in registry with password protection- I am able to go through the mini-setup no problem, and I can get the passwords using pwdump3 off the machine just fine in each one of those scenirios. Sid's changed everytime btw.
I tried 2 other configurations:
1) Restored the OEM image that came on my laptop, did the initial XP configuration (admin password, user accounts, network...) and then enabled syskey. Rebooted and syskey prompted for the startup password. Everything worked fine. Then did a sysprep (copied sysprep.exe and setupcl.exe to c:\sysprep and then ran sysprep.exe; selected "mini setup"). I restarted the system - syskey prompted me for the startup password. Syskey accepted the password, started the mini setup and then gave me the same error message (windows needs to shut down). Error log was the same as I have posted above
2) I then deleted the system partition and did a new install of MCE2005. Followed the same steps above to enable syskey, and did a sysprep. Same errors.
After trying to do a mini setup on 3 syskey'd, sysprep'd OS images that require a syskey startup password AND receiving the same error, I am not able to recreate richrumble's results.
Rich- did you follow the same steps I have outlined here, or are there other steps you did that I have missed?
One of my original comments:
>> I've used syskey to lock down the SAM - and I believe the password is tied to the SID(?)
My conclusions so far:
1) I was wrong (thanks rich): syskey does not "lock down the SAM"
2) There is some connection between syskey and the SIDs that prevents (at least part of) the registry from being modified when the SIDs are changed.
Here is a link to another user that has experienced this problem:
http://www.mcse.ms/archive65-2004-3-462546.html
Anyone else have any wisdom on this?
I must apologize that when i did this, looks like my sids did not change upon further inspection. Let me try again :( Onething that I've always done before sysprep is run on the image is a chkdsk /f on the c: probably won't do anything, but it's the only thing i probably did different. I'll get back to you. This could be an issue for M$ support to look into, there is nothing in their KB as far as I can find.
-rich
-rich
ASKER
Hi rich-
THanks for your response.
>> Onething that I've always done before sysprep is run on the image is a chkdsk /f on the c:
Great suggestion (I agree that it probably won't change my results since I tried with 3 OS installs - and the odds....). I'll have to incorporate that step into my practice. Thanks-
THanks for your response.
>> Onething that I've always done before sysprep is run on the image is a chkdsk /f on the c:
Great suggestion (I agree that it probably won't change my results since I tried with 3 OS installs - and the odds....). I'll have to incorporate that step into my practice. Thanks-
ASKER
Well - had to start from scratch on my new laptop since I have not found an answer. Per richrumble's earlier suggestion, I have learned to image my system partition BEFORE I enable syskey. That way, if I need to migrate my system partition onto another machine, I can restore the image that does NOT have syskey enabled, and then do a sysprep.
If anyone come up with an answer to my original question, please let me know!
If anyone come up with an answer to my original question, please let me know!
Windows NT was the only "Professional" version of windows that required you to enable syskey.
Windows 2K and up already have it enabled by default.
Sysprep wipes out all of your SIDS and creates new ones on restart, similar to a fresh install.
To answer your question, to wipe out SIDS all you have to do is run Sysprep with default settings and reboot.
The reason your getting the error is because the Administrator password on the system must be null if it is to be changed by using the mini-setup wizard in sysprep.
See http://support.microsoft.com/default.aspx?scid=kb;en-us;200607 for more info on that.
Your My Documents will need an account with the original SID of the user to unencrypt it. Unless you can restore your encryption key that is ;-)
Hope that helps.