cancerface

Thanks Takeshi, glad you like it Well, the DefaultPassword entry from HKLM\Software\Microsoft\Windows NT\WinLogon is missing (the clear-text password), but the Default password is in fact stored in the registry, encrypted, under the HKLM\SECURITY\Policy\Secrets\DefaultPassword key, which you need to manually access using admin privileges. In other words it is more secure than the clear text method, but not perfect, yet I am experimenting with another method suggested by M$ which is a bit more complicated but guarantees better encryption, as suggested in this MSDN page ... CF

@DarkShadows I think I got it working Check out this thread. I think this is what you are looking for. Give it a try and let me know. The program on the above link will not delete the administrator, but it will allow you to create a new user and if the user is added to the administrators group, with autologon activated, then his/her password will be stored in the registry encrypted so that it will not be exposed as clear text ... If this is indeed what you're after I can shape the code up a bit to achieve what we discussed before. CF

Following the discussion with DarkShadows in this thread I tried to implement the idea of securing the new administrator’s password using the LsaStorePrivateData method. It is a simple process if we want to create an account with admin privileges, since this new account will be able to access the stored encrypted password in an autologon scenario. Unfortunately this is not the case for a new, regular user, since the LsaStorePrivateData will only allow the creator of a secret and any members of the administrators group to read the secret. This means that in order to create a simple user and enable autologon without exposing his/her password as a clear text entry in the system registry then we would have to somehow create a login session for this user, impersonate him/her then encrypt and store the password. The LsaStorePrivateData method is not however perfect, as the information stored (DefaultPassword in our case) can be found in HKLM\SECURITY\Policy\Secrets\DefaultPassword. Since there are ways to dump the content of the above key and decrypt the data, I am currently looking for another way of encrypting the password, using the CryptProtectData function of Win2k/XP. In version v0.8 of this tool I have added support for the LsaStorePrivateData functionality. If you create a user with administrator’s privileges and enable autologon, the user’s password will not be stored in the registry as a clear text, but will be encrypted so that it will be more difficult for a non admin user to gain access to this information. In fact this is the process that TweakUI (XP) is using in order to store the DefaultPassword, used for autologon sessions, in the registry. v0.8 Changelog - Added support for LsaStorePrivateData functionality (password encryption for autologon) - Fixed a bug with user enumeration at T12 Updated 1st post and uploaded the new version CF

For the dialup part check this thread (A google search also brought this up ) You'll have to manually enter username/password or write an autoit script ... For the VPN part check this and this threads. CF

It would also be a good idea to remove your product key when you post in a public forum ... CF

After discovering a bug in v0.6 that would not add the created user to any group, I had to release a new version ... In the process I also managed to get this little tool to work in Windows 2000! So here is the new version ... (check first post) v.0.7 Changelog - Fixed nasty bug from 0.6 that wouldn't add the user to a group - Added support for Windows 2000 - Added support for non english windows version (I hope ...) Enjoy! CF

I was reading this page and I thought that it might be a nice thing to try: at T12 try (if possible) to impersonate the administrator and then encrypt his password. It doesn't look trivial to be honest but it sounds like a good idea ... If there is anyone here with a good background in C, they might want to give a hand ... CF

Hmmm, lets see: No clue. Never tried it before so I am not sure what to expect. I doubt that it will affect things however. How about doing what was suggested by Jotnar at the first page of this thread: @echo off echo Renaming/Creating Accounts net user guest {s2J234OPH} renuser guest notguest net localgroup guests notguest /delete renuser Administrator admin net user /add Administrator /active:no /passwordchg:no /passwordreq:yes netuser Administrator /pwnexp:y net user Administrator {s2J234OPH} net localgroup users Administrator /delete Well this is the tricky part and I can't say I have a direct answer, yet.According to this MSDN page it is possible to encrypt one's pasword for autologon using the LsaStorePrivateData function of advapi32. M$ warns you not to use the older LSA private data functions and to move to the safer crypt32 ones. The downside to that is that you lose compatibility with WinNT 3+ (!) which is not a problem in your case as you are dealing with XP. However the problem with crypt32 functions is, according to this MSDN page: So here we are, @T12 running scripts logged as the system account trying to encrypt the password of the newly created admin account. Who knows, maybe it can be done. M$ says typically leaving some hope ... I think so. I'll try to reformat this example and make it work. I'll keep you posted CF

@RogueSpear Fair enough. However the discussion was about getting an encrypted password all the way through so that it won't be exposed as clear text at all To be honest I don't mind having it there in the first place. In fact I am using clear text passwords on my machine but then again I do not have any clients that rely on that, as DarkShadows does … @DarkShadows 1. Run unattended using an encrypted password in winnt.sif 2. Run a script to create the new admin (say NewADmin) @T12 (+ delete/rename the default Administrator) WITH autologon (ie clear text in the registry) 3. First GUI that you get, run a script that will do anything you want + will CHANGE the NewAdmin password to something new (this may be, as you suggested, part of an environmental variable, part hardcoded to the exe) 3a. Write a registry key somewhere that you can read later on and says (somehow) that step 3 succeeded 3b. Clear the autologon feature 4. Reboot Now, your clients can login and do whatever. If they change the pass of the NewAdmin (which you know from step 3 but they don't) then they are severing their support relationship with you. If the NewAdmin's password is left as the one you set in step 2 AND the flag that you set in step 3a is not there then again you clients are severing their support relationship with you since they did not allow the setup to finish (ie they somehow interfered) ... Not perfect, but a though nonetheless... CF

@RogueSpear Are you referring to this? If not, could you provide the code that will create the password for the administrator at cmdlines then enable autologon without leaving the password as a clear text entry in the registry? I think the page that I quoted earlier achieves that however, without testing this, it appears to me that the only person who would be able to encrypt his/her password allowing autologon would be the user himself/herself ... (taken from here)Kind-of-what-happens in DarkShadows's case: using TweakUI (logged as the admin user) he is enabling an encrypted password which does not appear in the registry. He achieves that however on a session that he has already authenticated as himself, and not as the system account from T12 ... ... CF [Edit] I would not delete the administrator account. In fact I would do what you describe RogueSpear, create a new administrator account, hide it (as DarkShadows suggested), rename the old admin acount, add a looooooong password with many many special characters in, remove from the admin group + disable it (same for Guest account) ...

I see ... Well M$ has an article describing the risk but there seems to be a way to encrypt the password after all according to this MSDN page. If this is indeed the case then even if you had an encrypted password at winnt.sif, you can run at cmdlines a tool to delete/rename the admin account, set autologon for the new account and encrypt the password. I'll play around with this and let you know CF

I am a bit confused then. I was under the impression that you wanted to rename the admin account before the 1st GUI logon, enable autologon and (here is my assumption) login with that account (auto), do whatever (create users etc), disable autologon, then leave the station in a state where users can login without seeing the administrator account on the welcome screen. So why do you need an encrypted admin password? If you login as NewAdmin (or whatever the account is going to be) then you can change the registry key that enables autologon for this particular account and then logoff, leaving the station in a mode where users can login and use it without having any traces of the admin password in the registry ... Yes.CF

It all depends on the OS. In 2K I was not able to direclty delete the Administrator account using netapi32 calls. In XP I was able to do that. I have not done this (I am using the old 2k style + CTRL-ALT-DEL to logon) but a quick google search showed this which you can try to prevent the user from appearing on the Welcome screen. This one is also easy to do. I am attaching a compiled script that I wrote which is quite dangerous and as such will not run without a switch. It is working on my english WinXP box but I doubt that it will work on a non-english system right now. What it does: 1. Check that it is running in XP/2k3 2. Check that the user invoking it is not the Administrator that will be deleted 3. Delete the administrator account 4. create a new administraor account called NewAdmin 5. set the password of the new administrator account to 'DarkShadows' (without the '') 6. patch the registry to for autologon 7. patch the registry according to this article (untested!) Note that this will NOT work on Windows 95/98/ME/NT/2k, it will NOT work on Domain accounts (just the local Administrator will be re-created) Again be warned THIS WILL DELETE THE ADMINISTRATOR ACCOUNT AND WILL CREATE A NEW ONE! So don't blame me afterwards! Run it on a virtual PC first to see how it works ... If you're happy with it I can send you the code. Let me first work also on the environmental variable idea ... NewAdminAccount.7z [Edit] You do realize ofcourse that once you enable autologon the registry will contain the password of this user as a string ...

@DarkShadows Do you absolutely have to have the encrypted password set in winnt.sif? If not, here's an idea: Use a non encrypted password at winnt.sif, then at cmdlines run a small exe that will: 1. delete (or rename) the 'Administrator' account 2. create a new 'Administrator' account and set the password to whatever you want 3. patch the registry to autologon the new account and wrap all the above in an encrypted exe so that the new password cannot be easily read. The drawback in this is that the password will be hardcoded to the exe and although it will be encrypted you will have to create the exe from scratch if you want to change it ... If this solution is OK with you I can provide more details on the exe creation ... CF

Yet another update, check the first post Major changes this time as I managed to figure out how to use direct API calls to netapi32 and kernell32 in order to create the user and change the computer name This means that there is no longer the need for any external tools or for native windows tools (such as net.exe and wmi.exe) ... I successfully tested this in a working XP box as well as during a deployment at T13. However the API code breaks in Windows 2k so I had removed the support for that OS until I can figure out another way to add the user to a group in 2k. v.0.6 Changelog - Added a check for OS type (will only run in XP/2K3) - Added a check for admin privileges - Added options to parse the computername/username sections - The computername is set using a direct kernel32 API call - The user is created using a direct netapi32 API call - Changed the interface and added a computer Icon CF

Interesting ... And if you try to run wmic with the /User:Administrator /Password:... options it complains thet user credentials cannot be used for local connections ... RunAs doesn't work either ... CF

I am trying to do the same... A good start might be the adsutil.vbs script inside the AdminScript folder of IIS ... CF [Edit] It works ... On a working machine I configured IIS, created a virtual folder (uploads) and gave some permissions. Then from a cmd prompt I got the properies of that path: cscript.exe adsutil.vbs Enum W3SVC/1/ROOT/uploads and this list all the available parameters for this path: On a virtual machine that has IIS installed but not configured I was able to recreate the above parameters by using: cscript.exe adsutil.vbs SET W3SVC/1/ROOT/uploads/<ParameterName> "<ParameterValue>" It is a long list but it works ... I would love to see a better/faster way to do that though (Another way would be to use metaedit.exe although I am not sure if it supports cmdline options) CF

Nice one Bilou_Gateux B) Beware however that this will not work if run at T13 ... Although WMI responds to calls, anything that I tried to set using it, resulted in an error ... The other thing you can do is call the SetComputerNameEx function from kernel32.dll and change ComputerNamePhysicalNetBIOS and ComputerNamePhysicalDnsHostname. A nice VB example for achieving this can be found here. Or you could use this function in XP. All the above will work on a standalone workstation. You would have to call some AD function to change the computer name if it belongs to a domain. A nice tool to do this is netdom.exe. For a standalone PC (2k/XP/2k3) I have been using compname.exe up until now. It has some nice features: All of the above you can get with WMI. If however you want to rename the computer say at T13 it might be a good idea to use thsi tool ) CF

Shouldn't it be: net user Staff Password /ADD net localgroup "Administrators" /ADD Staff net accounts /maxpwage:unlimited wmic.exe UserAccount Where Name="Staff" Set PasswordExpires= FALSE, PasswordChangeable= False net user Student Password /ADD net accounts /maxpwage:unlimited wmic.exe UserAccount Where Name="Student" Set PasswordExpires= FALSE, PasswordChangeable= False It makes sense to first create the account (Student) and then make the password not expire I run the above code in XP and it worked fine I got both accounts and the password is set to not expire + it cannot be changed However, I have not tested this from RunOnceEx. I can say that it will not work from cmdlines as WMI is not fully functional at that stage. I have tested CUSRMGR.EXE from both cmdlines and RunOnceEx and I can confirm that it works (see my previous post) CF

Are the driver files present after txtmode in %SystemRoot%\System32\drivers ? I had a similar problem in the past when I used the 'F6' method to supply the raid drivers from a floppy and for some reason although txtmode went fine, I would get a bsod and the system would not boot. The driver files however never made it to %SystemRoot%\System32\drivers so I booted using a BartPE CD then manually copied the .sys files and was able to boot from the array eventually. How about integrating the SI raid driver to your install? There are many threads describing the procedure ... Try this one for example, or the unattended guide Hope this helps ... CF

I am running devcon scripts at GuiRunOnce in order to get drivers installed (that were not installed using the BTS packs, or that need further deployment like control panels etc). CF [Edit] I can confirm that devcon.exe can run at T12 without limited functionality, at least on a virtual PC and I do not see a reason why it would not be functional on a real PC ...

Updated first post, bringing this guy to v.0.4 ... Got rid of the external applications used to set the password age and to change the computer name, and implemented WMI calls instead, added an option in the INI file to invoke the 'Confirm' dialog and finally added tooltips, for every control ... CF [Edit] Updated again to 0.4.1 (reverted to external tools since WMI was breaking the code at T13) Updated yet again to 0.5 combining both WMI and external tool calls depending on the system state (at T13 the external tools are used, otherwise WMI is used)

If anyone is interested, it is easy to change the computer name using wmic.exe: wmic.exe ComputerSystem Where Name="%ComputerName%" Rename Name="NewComputerName" It requires a reboot but seems to work ... If you don't want to use the environmental variable %ComputerName%, just replace it with the currently active name of the local machine. CF

I have been playing around with wmic.exe and it appears that you can get the result that you want, without the need for any other (external) tools. In order to disable a user's password (in your case the user was 'Student') from expiring and from being changed you would have to do the following from a command prompt or within some script: wmic.exe UserAccount Where Name="Student" Set PasswordExpires= FALSE, PasswordChangeable= False CF

There's a handy tool called devcon.exe which would help in the scenario that you described. However you will have to play with your settings in order to get it to look for specific things in your system. For example, the following gives me the model of my Silicon Image controller: FOR /F "tokens=4 delims=_,&" %i IN ('devcon.exe hwids PCI\VEN_1095 ^| FINDSTR /c:"SUBSYS"') DO SET controller=%iin my system the above line will set %controller% to 3114 ... Similar results you can get with WMI using wmic.exe. I would start with devcon.exe in order to identify what hardware I have installed and then I would script the installation of drivers using simple querries like the one above. I am sure there's quite a few posts around where people have used VB to achieve the same Hope this helps ... CF PS Try this: devcon.exe hwids * >>MyDevices.txtin order to get a file with all the devices that exist in your system.