cancerface
Content Type
Profiles
Forums
Events
Posts posted by cancerface
-
-
@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
0 -
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
0 -
-
It would also be a good idea to remove your product key when you post in a public forum
...CF
0 -
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
0 -
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
0 -
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.Q: Should winnt.sif include the AutoLogon setting for the purpose of your program?
How about doing what was suggested by Jotnar at the first page of this thread:Q: Is there a command to disable an account via the command prompt in Windows XP?@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.4. Set Autologon to NewAdmin account @T12.Q: This I do not know how to do. Can you help with this one?
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:
... Typically, only a user with the same logon credential as the encrypter can decrypt the data. In addition, the encryption and decryption usually must be done on the same computer...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 ...
5. First Boot into Windows Full GUI ...-Windows logs on as NewAdmin – Windows should do this automatically, assuming the previous step works as planned.
-Execute RunOnceEx and GUIRunOnce – Windows should do this automatically, assuming the systems engineer (that would be me) builds the XPCD correctly.
-Execute any other cleanup scripts – Windows should do this automatically, assuming the systems engineer (that would be me) builds the XPCD correctly.
-Change NewAdmin's password to something new and more secure.
Q: This I do not know how to do. Can you help with this one?
I think so. I'll try to reformat this example and make it work. I'll keep you posted
CF
0 -
@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
0 -
@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)The CryptProtectData function performs encryption on the data in a DATA_BLOB structure. Typically, only a user with the same logon credential as the encrypter can decrypt the data. In addition, the encryption and decryption usually must be done on the same computerKind-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) ...
0 -
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
0 -
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.6. Have you tested this to ensure that the NewAdmin in fact does logon automatically?CF
0 -
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.
It would awesome If the program in question could pull part of the password from an environmental variable at execution timeThis 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 ...
[Edit]
You do realize ofcourse that once you enable autologon the registry will contain the password of this user as a string ...
0 -
@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
0 -
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
0 -
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
0 -
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:
KeyType : (STRING) "IIsWebVirtualDir"AppRoot : (STRING) "/LM/W3SVC/1/Root/uploads"
AppFriendlyName : (STRING) "uploads"
AppIsolated : (INTEGER) 2
EnableDefaultDoc : (BOOLEAN) True
DirBrowseShowDate : (BOOLEAN) True
DirBrowseShowTime : (BOOLEAN) True
DirBrowseShowSize : (BOOLEAN) True
DirBrowseShowExtension : (BOOLEAN) True
DirBrowseShowLongDate : (BOOLEAN) True
AccessRead : (BOOLEAN) True
AccessWrite : (BOOLEAN) True
AccessExecute : (BOOLEAN) False
AccessScript : (BOOLEAN) True
AccessSource : (BOOLEAN) False
AccessNoRemoteRead : (BOOLEAN) False
AccessNoRemoteWrite : (BOOLEAN) False
AccessNoRemoteExecute : (BOOLEAN) False
AccessNoRemoteScript : (BOOLEAN) False
EnableDirBrowsing : (BOOLEAN) True
Path : (STRING) "F:\My Documents\Web Uploads"
AccessFlags : (INTEGER) 515
DirBrowseFlags : (INTEGER) 3221225534
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
0 -
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:
Displays SMBIOS information and changes/displays the computer name.COMPNAME [/c name | /d [template]| /s]
/c[hange] Changes the computer name to the one specified.
/d[isplay] Displays the computer name.
/s[mbios] Displays the serial number information from SMBIOS.
name New computer name. Only valid with the /c option.
This may contain macros; see below.
template When used in conjuction with /d, displays the evaluated name.
Templates will normally contain macros; see below.
The following macros are valid in the name or template.
?s = System serial number. ?c = Chassis serial number.
?b = Mainboard serial number.
?a = The first populated number from system, chassis and mainboard numbers.
?u = System UUID ?U = Fake UUID (24 zeros plus MAC).
?G = If System UUID is FFFF... or 0000... or null it uses ?U, otherwise ?u.
?i, ?j, ?k, ?l = 1st, 2nd, 3rd, 4th octets of IP (decimal).
?I, ?J, ?K, ?L = 1st, 2nd, 3rd, 4th octets of IP (hex).
?d = Hostname found by reverse DNS lookup of IP address.
?m = First MAC address. ?e = Existing NetBIOS computer name.
?D = day ?M = month ?Y = year
?1, ?2, ?3, ..., ?0 = 1, 2, 3, ..., 10 random alphanumeric characters.
Examples:
COMPNAME /d Displays the NetBIOS computer name.
COMPNAME /d ?s Displays the system serial number.
COMPNAME /s Displays system summary information.
COMPNAME /c jupiter Changes computer name to "jupiter".
COMPNAME /c acme-?s Changes computer name to "acme-ABCDEF" where
ABCDEF is the system serial number.
Notes:
* You can simply replace a /c switch with a /d switch to check the name.
* If the name (after macro expansion) is longer than 15 characters,
then the NetBIOS name will be truncated, but the DNS name (on Windows
2000 and above) will be the full length. This may break some applications.
* The following characters (and spaces) are invalid and removed automatically:
\ * + = | : ; " ? < > ,
* The _ character gets translated to - to avoid DNS name problems.
* This program does not rename the computer's domain account.
----------------------------------------------------------------------------
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
0 -
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= FalseIt 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
0 -
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
0 -
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 ...
0 -
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)
0 -
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
0 -
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
0 -
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.txt
in order to get a file with all the devices that exist in your system.
0
)
)
[beta] User Creation Tool
in Unattended Windows 2000/XP/2003
Posted
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