|
Home > Archive > IIS Server > November 2004 > IIS6 - Metabase Export - IMSAdminBase2::Export
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
IIS6 - Metabase Export - IMSAdminBase2::Export
|
|
| Higgs Boson 2004-11-02, 7:48 am |
| We are attempting to work with IISCNFG.VBS. While the documentation states
that
the export file is encrypted using the /d switch with this utility we have
found that the
output file is never encrypted. the following commands produce IDENTICAL
output files:
[watch 4 wrap]
iiscnfg.vbs /export /d XXXXXXXX /sp /lm/w3svc/1 /f c:\temp\PASSWORD.xml
/inherited /children
iiscnfg.vbs /export /sp /lm/w3svc/1 /f c:\temp\NOPASSWORD.xml /inherited
/children
Directory of C:\temp
11/02/2004 09:32 AM 35,792 NOPASSWORD.xml
11/02/2004 09:31 AM 35,792 PASSWORD.xml
so whats up with that?
thanks.
dlr
| |
| David Wang [Msft] 2004-11-03, 2:48 am |
| Are you SURE the output files are identical? You do realize that two files
with the same size are NOT identical? I do not repro your claims, unless
you managed to specify a password whose encryption results is the same as
the existing mechanism.
--
//David
IIS
This posting is provided "AS IS" with no warranties, and confers no rights.
//
"Higgs Boson" <higgs.boson@play.net> wrote in message
news:OvxO6nOwEHA.1264@TK2MSFTNGP12.phx.gbl...
We are attempting to work with IISCNFG.VBS. While the documentation states
that
the export file is encrypted using the /d switch with this utility we have
found that the
output file is never encrypted. the following commands produce IDENTICAL
output files:
[watch 4 wrap]
iiscnfg.vbs /export /d XXXXXXXX /sp /lm/w3svc/1 /f c:\temp\PASSWORD.xml
/inherited /children
iiscnfg.vbs /export /sp /lm/w3svc/1 /f c:\temp\NOPASSWORD.xml /inherited
/children
Directory of C:\temp
11/02/2004 09:32 AM 35,792 NOPASSWORD.xml
11/02/2004 09:31 AM 35,792 PASSWORD.xml
so whats up with that?
thanks.
dlr
| |
| Dennis Redfield 2004-11-04, 7:48 am |
| Ok David,
On CLOSER INSPECTION we see:
The following fields are encrypted in BOTH files:
sessionkey
AdminACL (All Of These)
AnonymousUserPass
LogOdbcPassword
SmTpDsPassword
WAMUserPass
The encrypted VALUE is different between the files (but have an equal byte
count).
QUESTION:
What is the point of this arrangement?
Wouldn't it be more useful to have two options:
1) create the XML export file in PLAIN TEXT (all fields); OR
2) create the XML export file in encrypted format (all fields, you
supply a password).
The advantage of a plaintext version is that this could be archived to
document (web) system state for disaster recovery (and general
documentation).
"David Wang [Msft]" <someone@online.microsoft.com> wrote in message
news:eAQOoBYwEHA.4004@tk2msftngp13.phx.gbl...
> Are you SURE the output files are identical? You do realize that two
files
> with the same size are NOT identical? I do not repro your claims, unless
> you managed to specify a password whose encryption results is the same as
> the existing mechanism.
>
> --
> //David
> IIS
> This posting is provided "AS IS" with no warranties, and confers no
rights.
> //
> "Higgs Boson" <higgs.boson@play.net> wrote in message
> news:OvxO6nOwEHA.1264@TK2MSFTNGP12.phx.gbl...
> We are attempting to work with IISCNFG.VBS. While the documentation
states
> that
> the export file is encrypted using the /d switch with this utility we have
> found that the
> output file is never encrypted. the following commands produce IDENTICAL
> output files:
> [watch 4 wrap]
>
> iiscnfg.vbs /export /d XXXXXXXX /sp /lm/w3svc/1 /f c:\temp\PASSWORD.xml
> /inherited /children
>
> iiscnfg.vbs /export /sp /lm/w3svc/1 /f c:\temp\NOPASSWORD.xml /inherited
> /children
>
>
> Directory of C:\temp
> 11/02/2004 09:32 AM 35,792 NOPASSWORD.xml
> 11/02/2004 09:31 AM 35,792 PASSWORD.xml
>
> so whats up with that?
>
> thanks.
>
> dlr
>
>
>
| |
| David Wang [Msft] 2004-11-05, 2:47 am |
| Actually I would like to ask what is the point of your two options.
1. If the XML export is in plain text, then why do we bother with any
security/encryption to begin with. Given this logic, why would Windows
bother encrypting the SAM and why would Unix hash the .password file.
Sensitive data should stay encrypted, even for archival -- it should be
machine-invariant so that restoration is easy.
2. Why would we need to encrypted the entire XML file if only certain fields
contain sensitive information. That is a waste of effort.
3. Plain-text archival is an insufficient requirement. A machine-invariant
metabase which is also secured is the best possible alternative, and that is
possible with IIS6.
Simply put, only the properties that are sensitive are encrypted, and they
stay encrypted during export/import transport for your security. You have
the option of import/export metabase nodes (useful only for that machine)
and backup/restore, which can use a private password which makes the XML
file machine-invariant.
Basically, those properties are encrypted against the machine's private
key -- this is why you cannot copy the values verbatim between two different
machines (because their machine private keys are different -- so you cannot
decrypt on the other machine).
You can create metabase backups which are encrypted with a password that you
choose -- whereby IIS will encrypt those properties with this password
instead of the private key -- so you can restore these metabase XML files on
another machine by simply entering in the password and having IIS re-encrypt
the values using the new machine's private machine key.
--
//David
IIS
This posting is provided "AS IS" with no warranties, and confers no rights.
//
"Dennis Redfield" <higgs.boson@play.net> wrote in message
news:ONJeOXnwEHA.2568@TK2MSFTNGP11.phx.gbl...
Ok David,
On CLOSER INSPECTION we see:
The following fields are encrypted in BOTH files:
sessionkey
AdminACL (All Of These)
AnonymousUserPass
LogOdbcPassword
SmTpDsPassword
WAMUserPass
The encrypted VALUE is different between the files (but have an equal byte
count).
QUESTION:
What is the point of this arrangement?
Wouldn't it be more useful to have two options:
1) create the XML export file in PLAIN TEXT (all fields); OR
2) create the XML export file in encrypted format (all fields, you
supply a password).
The advantage of a plaintext version is that this could be archived to
document (web) system state for disaster recovery (and general
documentation).
"David Wang [Msft]" <someone@online.microsoft.com> wrote in message
news:eAQOoBYwEHA.4004@tk2msftngp13.phx.gbl...
> Are you SURE the output files are identical? You do realize that two
files
> with the same size are NOT identical? I do not repro your claims, unless
> you managed to specify a password whose encryption results is the same as
> the existing mechanism.
>
> --
> //David
> IIS
> This posting is provided "AS IS" with no warranties, and confers no
rights.
> //
> "Higgs Boson" <higgs.boson@play.net> wrote in message
> news:OvxO6nOwEHA.1264@TK2MSFTNGP12.phx.gbl...
> We are attempting to work with IISCNFG.VBS. While the documentation
states
> that
> the export file is encrypted using the /d switch with this utility we have
> found that the
> output file is never encrypted. the following commands produce IDENTICAL
> output files:
> [watch 4 wrap]
>
> iiscnfg.vbs /export /d XXXXXXXX /sp /lm/w3svc/1 /f c:\temp\PASSWORD.xml
> /inherited /children
>
> iiscnfg.vbs /export /sp /lm/w3svc/1 /f c:\temp\NOPASSWORD.xml /inherited
> /children
>
>
> Directory of C:\temp
> 11/02/2004 09:32 AM 35,792 NOPASSWORD.xml
> 11/02/2004 09:31 AM 35,792 PASSWORD.xml
>
> so whats up with that?
>
> thanks.
>
> dlr
>
>
>
| |
| Dennis Redfield 2004-11-05, 7:48 am |
| gee, lighten up david. but thanks for the clarification:
>You have the option of import/export metabase nodes (useful only for that
machine)
> and backup/restore, which can use a private password which makes the XML
> file machine-invariant.
THIS POINT WAS NOT CLEAR TO ME FROM BOL.
It would be "nice" however to be able to decrypt without restoring the XML
file to
a IIS system.
thanks again.
dlr
"David Wang [Msft]" <someone@online.microsoft.com> wrote in message
news:Ocfj9CxwEHA.2600@TK2MSFTNGP09.phx.gbl...
> Actually I would like to ask what is the point of your two options.
> 1. If the XML export is in plain text, then why do we bother with any
> security/encryption to begin with. Given this logic, why would Windows
> bother encrypting the SAM and why would Unix hash the .password file.
> Sensitive data should stay encrypted, even for archival -- it should be
> machine-invariant so that restoration is easy.
> 2. Why would we need to encrypted the entire XML file if only certain
fields
> contain sensitive information. That is a waste of effort.
> 3. Plain-text archival is an insufficient requirement. A
machine-invariant
> metabase which is also secured is the best possible alternative, and that
is
> possible with IIS6.
>
> Simply put, only the properties that are sensitive are encrypted, and they
> stay encrypted during export/import transport for your security. You have
> the option of import/export metabase nodes (useful only for that machine)
> and backup/restore, which can use a private password which makes the XML
> file machine-invariant.
>
> Basically, those properties are encrypted against the machine's private
> key -- this is why you cannot copy the values verbatim between two
different
> machines (because their machine private keys are different -- so you
cannot
> decrypt on the other machine).
>
> You can create metabase backups which are encrypted with a password that
you
> choose -- whereby IIS will encrypt those properties with this password
> instead of the private key -- so you can restore these metabase XML files
on
> another machine by simply entering in the password and having IIS
re-encrypt
> the values using the new machine's private machine key.
>
> --
> //David
> IIS
> This posting is provided "AS IS" with no warranties, and confers no
rights.
> //
> "Dennis Redfield" <higgs.boson@play.net> wrote in message
> news:ONJeOXnwEHA.2568@TK2MSFTNGP11.phx.gbl...
> Ok David,
> On CLOSER INSPECTION we see:
> The following fields are encrypted in BOTH files:
> sessionkey
> AdminACL (All Of These)
> AnonymousUserPass
> LogOdbcPassword
> SmTpDsPassword
> WAMUserPass
>
> The encrypted VALUE is different between the files (but have an equal byte
> count).
>
> QUESTION:
> What is the point of this arrangement?
>
> Wouldn't it be more useful to have two options:
> 1) create the XML export file in PLAIN TEXT (all fields); OR
> 2) create the XML export file in encrypted format (all fields, you
> supply a password).
>
> The advantage of a plaintext version is that this could be archived to
> document (web) system state for disaster recovery (and general
> documentation).
>
> "David Wang [Msft]" <someone@online.microsoft.com> wrote in message
> news:eAQOoBYwEHA.4004@tk2msftngp13.phx.gbl...
> files
unless[vbcol=seagreen]
as[vbcol=seagreen]
> rights.
> states
have[vbcol=seagreen]
IDENTICAL[vbcol=seagreen]
>
>
>
|
|
|
|
|