Background
I have a Windows 7 VM with two user accounts (condor_usr1 and condor_usr2) that is used for source code compiling. The condor_usr[1|2] accounts are members of the administrators group. I have an HTCondor master VM that periodically receives jobs and assigns each job to run on one of the condor_usr[1|2] accounts. The condor service on the Win7 VM runs as the local system account, but jobs being executed actually run as the condor_usr[1|2] account.
I have a new requirement to sign the compiled executable. I've imported the certificate with private key into the Current User\Personal key store in the Windows Certificate store.
Problem
If I'm logged into the Win7 VM (e.g. via remote desktop) as one of the condor_usr accounts, then compiles running as that account will successfully sign the executable, but compiles running as the other account will fail to sign the executable. For example, if I'm logged in as condor_usr2, then compiles running under condor_usr2 will sign successfully and compiles running under condor_usr1 will fail to sign. If I log out, both accounts fail to sign.
The specific error I receive is:
C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\Microsoft\VisualStudio\v15.0\OfficeTools\Microsoft.VisualStudio.Tools.Office.targets(264,9): error MSB3482: An error occurred while signing: The system cannot find the file specified.
Turned on some audit logging and found the following log that occurred at the same time as a signing failure.
Goal
Sign the compiled executable successfully regardless of which account the compile is running as and without requiring a user to be logged in.
What I've Figured Out So Far
The code/project being compiled is a Visual Studio 2017 solution.
The signing method is ClickOnce manifest signing (an option in the VS2017 project).
When a compile job is started, the job logs in as condor_usr[1|2] using logon type 2 (interactive logon).
https://ss64.com/nt/syntax-logon-types.html
Things I've Tried
Unless otherwise noted, these actions had no effect and were reverted.
Adding the condor_usr accounts to the Cryptographic Operators group.
Importing the certificate w/ private key to the Local Computer\Personal key store.
Granting the Network Service account full control to the certificate/private key.
https://community.dynamics.com/nav/b/technicaltipsandtricksfordynamicsnav/posts/how-to-grant-access-to-the-certificate-s-private-key-to-the-service-account-for-microsoft-dynamics-nav-server
Using PsExec -h make.bat to obtain the account's elevated token.
https://learn.microsoft.com/en-us/sysinternals/downloads/psexec
I considered that User Account Control (UAC) may be preventing the system account and/or condor_usr account from accessing the certificate store (or private keys in the cert store), but UAC is already disabled on the Win7 VM.
I placed the original .pfx certificate file in the VS2017 solution and targeted it instead of the certificate in the key store. This had no effect, which leads me to believe that the issue is some sort of signing permission rather than (or perhaps in addition to) purely permissions around the actual certificate store.
I tried starting a job while logged in via remote desktop, and then logging out of the remote desktop session (actual logout, not disconnect) before the job got to the signing portion. Signing failed.
Make sure all the accounts involved in the process has the "Logon as service" rights by ensuring they are present in the local policy "Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment\Log on as a service". Note that this change becomes effective the next time the owner of the account(s) logs on.
Try running the HTCondor service directly as "condor_usr1" instead of the "Local System" account.
Related
I was installing the filebeat application and I noticed that I needed to run powershell as administrator in order to install them. When I checked the service using wmic service get name,startname,status it showed Local System. I'm wondering what this account is as this is neither the user account or the administrator account. Will this always be the case when I install services as administrator? What is the difference if I install it as a normal user and as administrator?
In any case, I've set this service to start automatically when windows start. Would this service start only when the user I used to install it logs in or will it start regardless of which user logs in?
OK, let's unpack that one by one, in no particular order:
Only a user with administrator rights can install a service.
Services that are configured to start automatically are started as soon as Windows is up and running; Windows does not wait until somebody logs in. It makes no difference to the service who the logged-on user is, or whether anybody is logged in at all, unless the service application itself has been explicitly programmed to check.
The program that installs the service decides what account the service uses to run. Windows doesn't care what user account was used to install the service, it doesn't even keep track.
If the program that installs the service wants it to use an ordinary user account, it must know the password for that account. There are various special accounts that a service can run in, these accounts do not require a password. One of these special accounts is Local System.
Local System is the highest-privilege service account in Windows; it has all the same rights as an administrator, and can do things an administrator can't. Local System is also the account that the user-mode part of Windows itself runs in, roughly equivalent to the UNIX root account except that it doesn't have a password.
Additional notes, for completeness:
One alternative to Local System is for the service to run as Local Service or as Network Service, which are non-administrative service accounts. The only difference between the two is that if the computer is joined to an Active Directory domain, the Network Service account has network access to other machines in the domain and the Local Service account does not.
It is also possible to configure a service to run in a special service account that is unique to that particular service. This is mostly useful if you want the service to have access to a particular file or folder, but do not want to give it administrator rights.
Nitpickers corner:
It is I believe technically possible to reconfigure Windows to allow non-administrators to install services, but this is not supported and would be a Very Bad Idea. If you did, though, it would still make no difference who installed the service. Windows doesn't record this information.
I'm trying to authenticate to Opends server using winldap , I installed my self signed certificate to system trusted root certificates,personal store etc(where ever applicable). ldp.exe which is a tool by microsoft works fine for ssl and tls connection .I have 2 user accounts in my PC(admin and Administrator) everything works fine for both user accounts , except my windows service.
My windows service(a library management program) couldn't verify the server certificate. but my sample code works(which is a small part of code similar to my windows service) ,
I have seen similar scenarios on this website and their suggestion (https://msdn.microsoft.com/en-us/library/aa702621.aspx).
My service displays Group name as N/A in services tab and user name as SYSTEM in processes tab of task manager and I'm not sure what to do , please some one help me to solve this issue.
Thanks in advance.
Actually Windows has 3 types of certificate stores Local User , System , Services .
Usually windows services run as a special account called System(we can make it run on a particular user account as well)
Self signed certificate is added to the local user account alone (for both admin and Administrator as mentioned). so the windows Service couldn't verify the certificate.
Solution is to add the certificate to the System store .
The program works fine
I'm curious to know the order of Windows startup during a user login. Does anyone know?
Basically, my application was being invoked by login script that a GPO calls. While 3rd party EXE was being invoked, it was failing to start.
Then, through trial and error, I found that HKCU...\RunOnce keys execute after the login script. Same result, the EXE was being called, but failing to start.
What worked: updated the login script create a shortcut in the user's Startup folder. Now the EXE starts up as expected.
I know that AutoRuns can tell me all the locations where startup items can be placed, does anyone know the execution order as a whole? I was able to find that Run and RunOnce keys get called asynchronously. I can keep testing each startup item that AutoRuns states, but this could take days.
I'm mostly interested in Windows 2003 Server login startup flow, but I would suspect its very similar to other Windows flavors in use today.
Source: Understanding the Startup Process - Windows 7 Tutorial
The normal startup sequence for Windows 7 is:
Power-on self test (POST) phase
Initial startup phase
Windows Boot Manager phase
Windows Boot Loader phase
Kernel loading phase
Logon phase
Kernel Loading Phase The Windows Boot Loader is responsible for loading the Windows kernel (Ntoskrnl.exe) and the HAL into memory.
Together, the kernel and the HAL initialize a group of software
features that are called the Windows executive. The Windows executive
processes the configuration information stored in the registry in
HKLM\SYSTEM\CurrentControlSet and starts services and drivers. The
following sections provide more detail about the kernel loading phase.
Logon Phase
The Windows subsystem starts Winlogon.exe, a system service that
enables you to log on and log off. Winlogon.exe then does the
following:
Starts the Services subsystem (Services.exe), also known as the SCM. The SCM initializes services that the registry entry Start
designates as Autoload in the registry subkey
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Servicename.
Starts the Local Security Authority (LSA) process (Lsass.exe).
Parses the Ctrl+Alt+Delete key combination at the Begin Logon prompt (if the computer is part of an
AD DS domain).
The logon user interface (LogonUI) feature and the credential provider
(which can be the standard credential provider or a third-party
credential provider) collect the user name and password (or other
credentials) and pass this information securely to the LSA for
authentication. If the user supplied valid credentials, access is
granted by using either the default Kerberos V 5 authentication
protocol or Windows NT LAN Manager (NTLM).
Winlogon initializes security and authentication features while PnP
initializes auto-load services and drivers. After the user logs on,
the control set referenced by the registry entry LastKnownGood
(located in HKLM\SYSTEM\Select) is updated with the contents in the
CurrentControlSet subkey. By default, Winlogon then starts
Userinit.exe and the Windows Explorer shell. Userinit may then start
other processes, including:
Group Policy settings take effect Group Policy settings that apply to the user and computer take effect.
Startup programs run When not overridden by Group Policy settings, Windows starts logon scripts, startup programs, and services
referenced in the following registry subkeys and file system folders:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Runonce
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Explorer\Run
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Windows\Run
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunOnce
SystemDrive\Documents and Settings\All Users\Start Menu\Programs\Startup
SystemDrive\Documents and Settings\username\Start Menu\Programs\Startup
Several applications might be configured to start by default after you
install Windows, including Windows Defender. Computer manufacturers or
IT departments might configure other startup applications.
Windows startup is not complete until a user successfully logs on to
the computer. If startup fails during the logon phase, you have a
problem with a service or application configured to start
automatically.
If you want further information check the source link.
How can I configure Visual Studio remote debugging when:
My developer machine is a member of an AD domain, and my username is "DevelopersName".
The "remote" machine is on the same Ethernet segment, but is not part of the domain.
The "remote" machine must run software under "RemoteUserName".
Most documentation I can find suggests that you need have both machines in the same domain and with identical usernames. That's not possible here.
I could possibly add my username to "remote", but the software still needs to run under "RemoteUserName.
If it helps, I could add 2nd network card to my developer machine and directly connect the "remote" machine.
Using VS2008, but will be moving soon to VS2010.
Thank you.
Sorry, but I've just spent the last 10 hours trying to debug your exact problem. My findings are not good.
You need to get your accounts synced, especially if you are using your remote app to connect to other systems in your SOA environment, ie: Sharepoint, AD.
You can to some extent get remote debugging to work, if you create an account on your local machine with the same name as that of your remote machine (lets do it like this rather rather than working with the domain account).
You then need to make sure the remote service is running under this account, and its a member of the administrators group. And by this I mean hold down control, and right click run as - with the remote debugger, and select the user (not required if remote server is logged in as the required user).
Run the wizard it will open the required ports, use Authentication, because non authentication won't debug managed code. Breakpoints are never met, and there is nothing you can do about this.
On your local dev machine, log off your domain account, and log onto the local account with matching name as the account on server thats running the remote service.
Now you stand a change of remote debugging. If you can't do any of the above, sorry there is no workaround, its entirely dependent on the user account and having the right permissions.
If you don't want to create a local account, try starting our debugger via command prompt using the following command:
runas /user:[user#machinename] /netonly [debugger.exe]
E.g.:
runas /user:john#mypc123 /netonly devenv.exe
I assume it's managed debugging you're talking about (for native debugging there's a remote debugging solution with no authentication). In this case, I would suggest that you use a local user to launch the debugger on your machine. If this local user's name and password match "RemoteUserName"'s name and password, it should work.
(Note that this does not preclude you from using the AD account to log in to your workstation, you just need to set up another account and use runas to launch Visual Studio.)
Since yesterday I haven't been able to generate strong name keys using sn.exe or through Visual Studio which also uses sn.exe.
When attempting to generate a key file the following cimmand is executed
sn - k "key file.snk"
sn.exe then responds with
Failed to generate a strong name key pair -- Access is denied.
After repeating this process while running Process Monitor I now know that the locations to which sn.exe is denied access all reside within the following directory
\ProgramData\Microsoft\Crypto\RSA\MachineKeys
Querying the permissions of this folder reveals that the Everyone and Administrators groups have no rights and the NETWORK SERVICE account has Full Control.
Yesterday, I installed SourceGear Fortress which does use the NETWORK SERVICE account, however that is the only sicnificant change to the system prior to the issue occuring.
Is it normal for Everyone and Administrators to have no rights to the RSA key store?
After restoring Read and Write permissions to my user account for the MachineKeys directory I was again able to generate keys