Vault Server Installation on Windows 2000 Domain Controller
Moderator: SourceGear
Vault Server Installation on Windows 2000 Domain Controller
starting a new thread - from http://support.sourcegear.com/viewtopic.php?p=3099
Jeff Clausius
SourceGear
SourceGear
like i said in the previous thread, "someone flame me if this is incorrect". i was unaware microsoft addressed this problem in the 1.1 framework.Luther wrote:Note that the link you refer to for creating a weak account if for .NET 1.0, and is not necessary for .NET 1.1.
if you can install using the machine's local system account, that will do. here are the post-installation steps that should get you up and going:Luther wrote: I can get Vault to install if I select the second option, but then it can't access its own database. I assume this is because it set up the user permissions for the database to be something other than IWAM_MACHINENAME. Is it using SQL Server roles? Could I simply add IWAM_MACHINENAME to some Vault role after it installs and then I will be all set?
A) only if vault is connecting via windows authentication:
- sp_grantlogin to DOMAIN\IWAM_MACHINENAME
- sp_revokelogin on MACHINE\$MACHINE
- sp_grantdbaccess to DOMAIN\IWAM_MACHINENAME within the sgvault database
- sp_revokedbaccess to MACHINE\$MACHINE within the sgvault database
- assign the db_owner role to DOMAIN\IWAM_MACHINENAME
- full access to vaultservice directory (eg. c:\inetpub\wwwroot\vaultservice)
- read/write access to %ALLUSERSPROFILE%\Application Data\Microsoft\Crypto\RSA\MachineKeys
- full access to vaultshadowfolder directory. note - this should be inherited by default from the vaultservice directory.
- full access to the folder locations specified in vault.config for both WorkingDirectory and LogFilePath.
i agree. it is too risky to run anything under the local system account.Luther wrote:I'm not fond of changing our ASP.NET 1.1 applications to run under SYSTEM, or of creating a (domain) account for them to run under, as both of these options impose additional security risks.
please note, using separate domain account, explicitly dedicated to vault, with identity impersonation would be even more secure, than running all asp.net services under one DOMAIN\IWAM_MACHINENAME account. however, this does make more of an administrative headache.
in this scenario, it is easiest to use sql server authentication. however, if you want to use windows authentication (until the installation supports the concept of DOMAIN\IWAM_MACHINENAME), you will have to go the route of creating a "weak" account specifically assigned for vault.I am looking into another server resource where we could install the Vault demo for testing purposes, but the SQL Server will still be on this machine, at least in the short term.
please post back how things went.
Jeff Clausius
SourceGear
SourceGear
-
- Posts: 56
- Joined: Wed Apr 28, 2004 3:28 pm
- Location: San Francisco, CA
- Contact:
Looks like that worked (so far)
Here are scripts I used for the permissions:
SQL
------
use sgvault
GO
declare @domain sysname
declare @machine sysname
declare @olduser varchar(1000)
declare @newuser varchar(1000)
-- Get DOMAIN name of the server
create table #TempDomain(a sysname, b sysname)
insert into #TempDomain
exec master..xp_loginconfig 'default domain'
select @domain = substring(b, 1, LEN(b) - 1) from #TempDomain
drop table #TempDomain
-- Get MACHINE name of the server
set @machine = rtrim(cast(SERVERPROPERTY('MachineName') as sysname))
--Determine old user (DOMAIN\MACHINE$) and new user (DOMAIN\IWAM_MACHINE)
set @olduser = rtrim(@domain) + '\' + @machine + '$'
set @newuser = @domain + '\IWAM_' + @machine
--select @olduser, @newuser
exec sp_grantlogin @loginame = @newuser
exec sp_revokelogin @loginame = @olduser
exec sp_grantdbaccess @loginame = @newuser
exec sp_revokedbaccess @name_in_db = @olduser
exec sp_addrolemember @rolename = 'db_owner', @membername = @newuser
GO
------
BAT
------
REM @echo OFF
set VAULTWORKINGDIR=%SYSTEMROOT%\Temp
set VAULTLOGFILEPATH=%SYSTEMROOT%\Temp\sgvault
set OLDUSER=%USERDOMAIN%\%COMPUTERNAME%$
set NEWUSER=%USERDOMAIN%\IWAM_%COMPUTERNAME%
cacls C:\inetpub\wwwroot\VaultService /E /R %OLDUSER%
cacls C:\inetpub\wwwroot\VaultService /E /G %NEWUSER%:F
cacls "%ALLUSERSPROFILE%\Application Data\Microsoft\Crypto\RSA\MachineKeys" /E /R %OLDUSER%
cacls "%ALLUSERSPROFILE%\Application Data\Microsoft\Crypto\RSA\MachineKeys" /E /G %NEWUSER%:F
cacls "%VAULTWORKINGDIR%" /E /R %OLDUSER%
cacls "%VAULTWORKINGDIR%" /E /G %NEWUSER%:F
cacls "%VAULTLOGFILEPATH%" /E /R %OLDUSER%
cacls "%VAULTLOGFILEPATH%" /E /G %NEWUSER%:F
------
I insalled it as SYSTEM\SERVER$ and then ran these scripts. I can log into the Admin tool now, so I will go from there... plan to import a couple of databases to see how that goes
SQL
------
use sgvault
GO
declare @domain sysname
declare @machine sysname
declare @olduser varchar(1000)
declare @newuser varchar(1000)
-- Get DOMAIN name of the server
create table #TempDomain(a sysname, b sysname)
insert into #TempDomain
exec master..xp_loginconfig 'default domain'
select @domain = substring(b, 1, LEN(b) - 1) from #TempDomain
drop table #TempDomain
-- Get MACHINE name of the server
set @machine = rtrim(cast(SERVERPROPERTY('MachineName') as sysname))
--Determine old user (DOMAIN\MACHINE$) and new user (DOMAIN\IWAM_MACHINE)
set @olduser = rtrim(@domain) + '\' + @machine + '$'
set @newuser = @domain + '\IWAM_' + @machine
--select @olduser, @newuser
exec sp_grantlogin @loginame = @newuser
exec sp_revokelogin @loginame = @olduser
exec sp_grantdbaccess @loginame = @newuser
exec sp_revokedbaccess @name_in_db = @olduser
exec sp_addrolemember @rolename = 'db_owner', @membername = @newuser
GO
------
BAT
------
REM @echo OFF
set VAULTWORKINGDIR=%SYSTEMROOT%\Temp
set VAULTLOGFILEPATH=%SYSTEMROOT%\Temp\sgvault
set OLDUSER=%USERDOMAIN%\%COMPUTERNAME%$
set NEWUSER=%USERDOMAIN%\IWAM_%COMPUTERNAME%
cacls C:\inetpub\wwwroot\VaultService /E /R %OLDUSER%
cacls C:\inetpub\wwwroot\VaultService /E /G %NEWUSER%:F
cacls "%ALLUSERSPROFILE%\Application Data\Microsoft\Crypto\RSA\MachineKeys" /E /R %OLDUSER%
cacls "%ALLUSERSPROFILE%\Application Data\Microsoft\Crypto\RSA\MachineKeys" /E /G %NEWUSER%:F
cacls "%VAULTWORKINGDIR%" /E /R %OLDUSER%
cacls "%VAULTWORKINGDIR%" /E /G %NEWUSER%:F
cacls "%VAULTLOGFILEPATH%" /E /R %OLDUSER%
cacls "%VAULTLOGFILEPATH%" /E /G %NEWUSER%:F
------
I insalled it as SYSTEM\SERVER$ and then ran these scripts. I can log into the Admin tool now, so I will go from there... plan to import a couple of databases to see how that goes