| Author | Messages | |
nathanielbahta
Posts:5
 | | 07/16/2008 5:17 PM |
|
Hey all,
Anyone know a good way to encrypt the password you are sending to a box for a password change on a local account on that box? We incorporate the local admin password change into the startup script, but I would rather that not be sent across the wire clear, I would like to figure out a mechanism that would provide encrypted transmission of the password totally. Any ideas?
Thanks,
N. Bahta
| | | |
| bsonposh
Posts:171
| | 07/16/2008 5:18 PM |
| Another option (although to be honest I am not sure how practical it would
be for you) is to use SpecOps Command and utilize Powershell for logon
Scripts. You can encrypt text with user key or a hash with salt. Actually
you could encrypt pretty much anyway you feel like it.
On Mon, May 12, 2008 at 1:48 PM, Brian Desmond <brian@briandesmond.com>
wrote:
> Their "encryption" tool outputs the VBS to a temp folder as I recall.
>
> --brian
>
> On Mon, May 12, 2008 at 1:24 PM, Dan Holme <dan.holme@intelliem.com>
> wrote:
>
> > You should never do this with a startup script.
> >
> > The script ITSELF contains the password, and that's bad.
> >
> >
> >
> > If you **must** put it in a startup script, consider using PrimalScript
> > 2007 (from Sapien), and use their "encryption" tool (a type of obfuscation)
> > to package the script as an exe. Still not perfect, but better.
> >
> >
> >
> > Much better to use a tool that can "reach out" and make the change, even
> > something as simple as
> >
> > Psexec \\*machinename* net user administrator *password*
> >
> > (psexec can run against a list of machines as well)
> >
> >
> >
> > At one client where we needed a "quick and dirty" solution, we had a
> > scheduled task running on a server, using credentials that belonged in the
> > Administrators group of clients, every minute it would reach out to a list
> > of systems (from an Excel list) and run that command. When it saw the
> > command was successful, it would make a note in the Excel file so it
> > wouldn't try again. When we saw that all clients had been changed, life was
> > good.
> >
> >
> >
> > Another solution I thought about (but did not yet implement) is
> > something along this line:
> >
> > Create a parent "shared folder" on a server.
> >
> > Share permission: Domain Computers:CHANGE
> >
> > NTFS permission: remove ALL NTFS permissions (you can
> > opt to give Domain Admins full control or something if you want)
> >
> > Create a subfolder with a text file with the password.
> >
> > NTFS permission: The specific computer has MODIFY permission
> >
> > Startup script
> >
> > Connect to the computer's specific folder
> >
> > Read the text file
> >
> > Change the password as instructed in the text file
> >
> > DELETE the text file
> >
> > Remove self from scope of script so script doesn't run
> > again (e.g. remove self from group to which startup script is scoped)
> >
> > I'd suggest a DIFFERENT local administrator password for each computer.
> >
> >
> >
> > You still have a very big weakness here: the password is in plaintext
> > somewhere, but hopefully for a very short time, and with enough (NTFS)
> > security to reduce the risk somewhat.
> >
> >
> >
> > Those are some options. The only really secure way to do it is to touch
> > the machine remotely (e.g. psexec) or use a systems management tool (e.g.
> > SCCM) that is meant to support that kind of thing.
> >
> >
> >
> >
> >
> > *From:* ActiveDir-owner@mail.activedir.org [mailto:
> > ActiveDir-owner@mail.activedir.org] *On Behalf Of *Brian Desmond
> > *Sent:* Monday, May 12, 2008 6:35 AM
> > *To:* ActiveDir@mail.activedir.org
> > *Subject:* Re: [ActiveDir] Encrypted password change VIA startup script
> >
> >
> >
> > Do it remotely rather than with a startup script?
> >
> >
> >
> > --brian
> >
> > On Mon, May 12, 2008 at 12:26 PM, Nate Bahta <
> > nathaniel.bahta@hotmail.com> wrote:
> >
> > Hey all,
> >
> > Anyone know a good way to encrypt the password you are sending to a box
> > for a password change on a local account on that box? We incorporate the
> > local admin password change into the startup script, but I would rather that
> > not be sent across the wire clear, I would like to figure out a mechanism
> > that would provide encrypted transmission of the password totally. Any
> > ideas?
> >
> > Thanks,
> >
> > N. Bahta
> >
> >
> >
> >
> > --
> > Thanks,
> > Brian Desmond
> > brian@briandesmond.com
> >
> > c - 312.731.3132
> >
>
>
>
> --
> Thanks,
> Brian Desmond
> brian@briandesmond.com
>
> c - 312.731.3132
>
| | | |
| kamleshap
Posts:27
| | 07/16/2008 5:18 PM |
| one of the alternative is pspasswd.exe from sysinternals
http://technet.microsoft.com/hi-in/sysinternals/bb897543(en-us).aspx
And real good alternative is passgen.exe from Steve Riley's book.
It allows you to set random strong password with ability to recall them
easily.
Just go thru' its accompanied document for possible examples.
http://www.protectyourwindowsnetwork.com/tools.htm
--
Kamlesh
On Mon, May 12, 2008 at 10:54 PM, Dan Holme <dan.holme@intelliem.com> wrote:
> You should never do this with a startup script.
>
> The script ITSELF contains the password, and that's bad.
>
>
>
> If you **must** put it in a startup script, consider using PrimalScript
> 2007 (from Sapien), and use their "encryption" tool (a type of obfuscation)
> to package the script as an exe. Still not perfect, but better.
>
>
>
> Much better to use a tool that can "reach out" and make the change, even
> something as simple as
>
> Psexec \\*machinename* net user administrator *password*
>
> (psexec can run against a list of machines as well)
>
>
>
> At one client where we needed a "quick and dirty" solution, we had a
> scheduled task running on a server, using credentials that belonged in the
> Administrators group of clients, every minute it would reach out to a list
> of systems (from an Excel list) and run that command. When it saw the
> command was successful, it would make a note in the Excel file so it
> wouldn't try again. When we saw that all clients had been changed, life was
> good.
>
>
>
> Another solution I thought about (but did not yet implement) is something
> along this line:
>
> Create a parent "shared folder" on a server.
>
> Share permission: Domain Computers:CHANGE
>
> NTFS permission: remove ALL NTFS permissions (you can opt
> to give Domain Admins full control or something if you want)
>
> Create a subfolder with a text file with the password.
>
> NTFS permission: The specific computer has MODIFY permission
>
> Startup script
>
> Connect to the computer's specific folder
>
> Read the text file
>
> Change the password as instructed in the text file
>
> DELETE the text file
>
> Remove self from scope of script so script doesn't run
> again (e.g. remove self from group to which startup script is scoped)
>
> I'd suggest a DIFFERENT local administrator password for each computer.
>
>
>
> You still have a very big weakness here: the password is in plaintext
> somewhere, but hopefully for a very short time, and with enough (NTFS)
> security to reduce the risk somewhat.
>
>
>
> Those are some options. The only really secure way to do it is to touch
> the machine remotely (e.g. psexec) or use a systems management tool (e.g.
> SCCM) that is meant to support that kind of thing.
>
>
>
>
>
> *From:* ActiveDir-owner@mail.activedir.org [mailto:
> ActiveDir-owner@mail.activedir.org] *On Behalf Of *Brian Desmond
> *Sent:* Monday, May 12, 2008 6:35 AM
> *To:* ActiveDir@mail.activedir.org
> *Subject:* Re: [ActiveDir] Encrypted password change VIA startup script
>
>
>
> Do it remotely rather than with a startup script?
>
>
>
> --brian
>
> On Mon, May 12, 2008 at 12:26 PM, Nate Bahta <nathaniel.bahta@hotmail.com>
> wrote:
>
> Hey all,
>
> Anyone know a good way to encrypt the password you are sending to a box
> for a password change on a local account on that box? We incorporate the
> local admin password change into the startup script, but I would rather that
> not be sent across the wire clear, I would like to figure out a mechanism
> that would provide encrypted transmission of the password totally. Any
> ideas?
>
> Thanks,
>
> N. Bahta
>
>
>
>
> --
> Thanks,
> Brian Desmond
> brian@briandesmond.com
>
> c - 312.731.3132
>
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Argue for your limitations, and sure enough, they're yours.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| | | |
| colemancraig1
Posts:40
| | 07/16/2008 5:18 PM |
| I use Jesper Johannson's Passgen utiliy and Joe's must have adfind utility in a scheduled task to change all the local admin passwords. That way you won't have to send the password in plaintext....a career ending move. Some may consider this a hack but it works for us.
ADFind:
http://www.joeware.net/freetools/tools/adfind/index.htm
Passgen:
http://msinfluentials.com/files/folders/jesper/entry6532.aspx
Steps:
=====================================================
1. Create a CMD file that will enumerate all servers in the domain. For example purposes, here is the CMD file for the fictional Constoso domain. Note we have two different OU's where the servers reside, hence the two lines. GREP removes the additional header and summary info and the second adfind appends the output to the servers.txt.
adfind -b ou=prodservers,ou=computers,dc=contoso,dc=com -f "objectcategory=computer" cn -nolabel -nodn | grep -iv "Objects returned" | grep -iv "Directory" | grep -iv "Using Server" | grep -iv "^$" > d:\servers.txt
adfind -b ou=devservers,dc=constoso,dc=com -f "objectcategory=computer" cn -nolabel -nodn | grep -iv "Objects returned" | grep -iv "Directory" | grep -iv "Using Server" | grep -iv "^$" >> d:\servers.txt
2. Create a scheduled task that calls the CMD file on a regular basis. I usually like to use SYSTEM when possible so I don't have to create an account for this particular purpose or worry about passwords expiring.
C:\>schtasks.exe /create /s servername /ru system /sc weekly /tn taskname /tr d:\serverlist.cmd /st 17:30:00
INFO: The Schedule Task "ServerList" will be created under user name ("NT AUTHORITY\SYSTEM").
SUCCESS: The scheduled task "ServerList" has successfully been created.
3. Create a CMD file that runs PASSGEN against all the servers you just dumped. I usually pipe this to a log so I have a list of the passwords that I keep secure (encrypted).
for /f %%m in (d:\servers.txt) do passgen -g %%m_1 <passphrase> -c <administrator> -m %%m -h
4. Finally, create a scheduled task that calls PASSGEN.CMD file to run a on regular basis.
C:\>schtasks.exe /create /s <servername> /u domain\adminaccount /p <password> /sc weekly /tn taskname /tr d:\passgen.cmd /st 18:00:00
=====================================================
Hope this helps.
| | | |
| Marty1_0
Posts:73
| | 07/16/2008 5:18 PM |
| Yes with the option to delete temporary files.
- Bart
On Mon, May 12, 2008 at 7:48 PM, Brian Desmond <brian@briandesmond.com>
wrote:
> Their "encryption" tool outputs the VBS to a temp folder as I recall.
>
> --brian
>
> On Mon, May 12, 2008 at 1:24 PM, Dan Holme <dan.holme@intelliem.com>
> wrote:
>
> > You should never do this with a startup script.
> >
> > The script ITSELF contains the password, and that's bad.
> >
> >
> >
> > If you **must** put it in a startup script, consider using PrimalScript
> > 2007 (from Sapien), and use their "encryption" tool (a type of obfuscation)
> > to package the script as an exe. Still not perfect, but better.
> >
> >
> >
> > Much better to use a tool that can "reach out" and make the change, even
> > something as simple as
> >
> > Psexec \\*machinename* net user administrator *password*
> >
> > (psexec can run against a list of machines as well)
> >
> >
> >
> > At one client where we needed a "quick and dirty" solution, we had a
> > scheduled task running on a server, using credentials that belonged in the
> > Administrators group of clients, every minute it would reach out to a list
> > of systems (from an Excel list) and run that command. When it saw the
> > command was successful, it would make a note in the Excel file so it
> > wouldn't try again. When we saw that all clients had been changed, life was
> > good.
> >
> >
> >
> > Another solution I thought about (but did not yet implement) is
> > something along this line:
> >
> > Create a parent "shared folder" on a server.
> >
> > Share permission: Domain Computers:CHANGE
> >
> > NTFS permission: remove ALL NTFS permissions (you can
> > opt to give Domain Admins full control or something if you want)
> >
> > Create a subfolder with a text file with the password.
> >
> > NTFS permission: The specific computer has MODIFY permission
> >
> > Startup script
> >
> > Connect to the computer's specific folder
> >
> > Read the text file
> >
> > Change the password as instructed in the text file
> >
> > DELETE the text file
> >
> > Remove self from scope of script so script doesn't run
> > again (e.g. remove self from group to which startup script is scoped)
> >
> > I'd suggest a DIFFERENT local administrator password for each computer.
> >
> >
> >
> > You still have a very big weakness here: the password is in plaintext
> > somewhere, but hopefully for a very short time, and with enough (NTFS)
> > security to reduce the risk somewhat.
> >
> >
> >
> > Those are some options. The only really secure way to do it is to touch
> > the machine remotely (e.g. psexec) or use a systems management tool (e.g.
> > SCCM) that is meant to support that kind of thing.
> >
> >
> >
> >
> >
> > *From:* ActiveDir-owner@mail.activedir.org [mailto:
> > ActiveDir-owner@mail.activedir.org] *On Behalf Of *Brian Desmond
> > *Sent:* Monday, May 12, 2008 6:35 AM
> > *To:* ActiveDir@mail.activedir.org
> > *Subject:* Re: [ActiveDir] Encrypted password change VIA startup script
> >
> >
> >
> > Do it remotely rather than with a startup script?
> >
> >
> >
> > --brian
> >
> > On Mon, May 12, 2008 at 12:26 PM, Nate Bahta <
> > nathaniel.bahta@hotmail.com> wrote:
> >
> > Hey all,
> >
> > Anyone know a good way to encrypt the password you are sending to a box
> > for a password change on a local account on that box? We incorporate the
> > local admin password change into the startup script, but I would rather that
> > not be sent across the wire clear, I would like to figure out a mechanism
> > that would provide encrypted transmission of the password totally. Any
> > ideas?
> >
> > Thanks,
> >
> > N. Bahta
> >
> >
> >
> >
> > --
> > Thanks,
> > Brian Desmond
> > brian@briandesmond.com
> >
> > c - 312.731.3132
> >
>
>
>
> --
> Thanks,
> Brian Desmond
> brian@briandesmond.com
>
> c - 312.731.3132
>
| | | |
|
|