I need to monitor other accounts on a Windows Server, and have figured out that to do so, I have to be able to run a monitoring process on them. The main program runs from a full-access (possibly NT_AUTHORITY) account, but all ways of starting processes seem to require the user password! help please!
You could create this as a service instead and when installed supply password for the service properties (which user you want to run it as). Then the need to re-enter password should disappear.
Related
Good day.
I am developing a program that will be used in a corporate environment by the end users. The application will automatically fix certain errors as soon as the user selects the application name, chooses the symptom or error message and clicking on the fix button.
The idea behind is to decrease the amount of calls we receive at the IT Service Desk (The company's personal Call Centre for IT Issues) and at the same time assist the end user by resolving the issue within a minute (versus waiting on the phone for up to 15 minutes or more).
I've am not yet allowed to upload an image of the application, but imagine a small'ish windows form with 2 columns; Aplication name and Synptom. The user will choose the application's name, click on the error message and click on the FIX button. This basically automates whatever we has IT Techs would manually.
The problem I'm facing is that some of the code is supposed to be executed with adminsitartor rights, eg. Stop and Start a given service, adding regsitry entries for Local Machine, etc.
Given the fact that none of the users will be allowed to have elevated rights and the fact that they need to use this application as a sort of "self-help" alternative without the need to call the IT Service Desk, is there a way to give a set of code "administrator permissions"? The application should NOT request the user to enter ANY passwords.
Regards,
Willem
No way, AFAIK: the model in common operating systems is process-centric, so that the process is given permissions that are then inherited by its code. You can elevate such privileges at some point, but that will be for the whole future life of the process (or as long as the authentication token for it ceases to be valid).
In windows the right way to do that is to employ a back-end service: at boot, you start the service called IT_Auto_Fixer_Back_End with high permissions (try to avoid Administrator, NetworkService or LocalService could be enough for you). When the app IT_Auto_Fixer_Front_End is started with USER privileges, it operates until it needs something with high privileges. At that point it sends a request to the service, that will do it.
If you choose this way, some important advices:
The IT_Auto_Fixer_Back_End must not become a backdoor! If you use TCP as form of communication with IT_Auto_Fixer_Front_End, make it listen localhost only and use SSL (yes!) to encrypt local traffic
It must not be possible to invoke arbitrary commands using IT_Auto_Fixer_Back_End. You need to enumerate the possible requests that could be made (i.e. a command like stop_mysql_service rather than accepting directly the string net stop mysql - the application logic will translate your string into the real OS command)
Every input from the user could be used to perform command injection. To prevent this, use the Windows API that requires an array for the command - this way if the user adds options to a command (i.e. the name of the service in net stop) they won't be interpreted as another command (common scenario: when accepting the name of the service as a parameter, a malicious user that tries to execute something like net start mysql ; net user /add hacker t00E4sy). Authentication and encryption will not help you against this, you must escape any user input that goes inside the command.
Sanitize your ENVIRONMENT by using the API that executes commands setting the PATH (and other relevant variables), so that the user will not be able to taint the PATH, executing C:\temp\net.exe instead of C:\Windows\System32\Net.exe
IT_Auto_Fixer_Back_End service should be authenticated: it should check every time if the request comes form the user by checking if the Kerberos token is valid (Windows => you get a very nice Kerberos environment for free!). This will prevent someone else to break into the machine, use SSL to connect to the localhost port and elevate privileges through your service
The above (authentication) still stands when something else (i.e. shared memory, windows sockets, a file, etc...) is used as communication channel between IT_Auto_Fixer_Back_End and IT_Auto_Fixer_Front_End
Life gets harder when you want to properly implement something dealing with multiple level of permissions...
I have written my own windows service which interacts with a SQL database and updates it. The service was running fine and seems to be functioning correctly, however of late it seems to go down at random times and cannot restart due to the error designated in the question. I have tried various searches to fix this, but unfortunately I have come up with nothing. The aim is to eventually having this service running on my companies server, but I can't adjust any server settings, I am but a user on the server, so I have restrictions to some settings.
Any quick fixes, would be helpful!
Open the Services Manager. ( Win + R, then type services.msc )
Then right click on the SQL Server process and click Properties
Then go to Log On, and select This account:
Then click Browse, and add your username in the box. (Notice it should contain the domain, in my case is AD\myusername), then Check Names and accept.
Finally type your password in the other two fields, and that's it, you should have permission to start your process now.
Cheers!!
One issue for us was the format of the account user name, we initially used
domain\username
and got the 1069-logon error, then ultimately I tried validating the user name in the properties | logon tab of the Service (in Control Panel / Service Manager), using the "Browse" and "Search" for the user name and it turned it suggested and validated ok with the reverse format
username#domain
This also worked and resolved the 1069 error, and let us script the startup using sc.exe.
Error 1069 is vague and can have different causes. I am sharing my experience here.
I encountered this error when trying to get a service to run under my account (I am trying to get my services to see the same LocalDB as interactive processes running on my account for development purposes). I use an MSA (Microsoft Account) with Windows’s PIN login normally, so I rarely enter my Windows password. To resolve the issue, I locked my screen, selected Password input instead of PIN input, and then entered my password. I assume this somehow reminded Windows what my password was and made my local account more legit.
Before doing this, you need to configure the user account in question to have the Logon as Service privilege. To do this, open the Group Policy Editor. Expand Computer / Windows Configuration / Security Configuration / Local Policies / User Permissions Assignment and then open Login as Service. From there, you can add your user in question.
also check for "Deny Logon service" policy.
user should not be added over there
We had this issue as well because the account was set so that the password expired. After we updated the account to not expire and set the password this error stopped.
The account could also be locked out. To unlock it, you only need to change that user's password (new and old password can be the same).
What also worked for me was re-entering the password in the services->LogOn window. Even when you think the account and password is correct, re-entering it will re-grant the account permission to log on as a service.
I'm tryning to start a .bat file as the last step in OnAfterInstall in the context of an other user. I'm doing this by using the Process.Start overload with user name, domain and password as input. It works fine if I do not check the 'Everyone' in the installation. If i have the 'Everyone' selected I get access denied, with the same user (administrator). If I run the installment using the .start method with just the proccess name it work fine.
To test this I made a Windows froms application that start the proccess the same way after I install using 'Everyone', and it works fine.
Does anyone know why I can't access the file in OnAfterInstall with 'Everyone' selected, using an other user context?
Most likely when you check everyone you are telling the install program it doesn't need elevate permissions so it doesn't ask for them. Even when you run as an admin in windows vista or 7 your process token is that of a user until the UAC elevates you. There are a set of polices you need to be able to call createprocessasuser which is what is happening underneath. Give all polices related to the above api to everyone and then see if it works.
(rephrased...)
How do you manage 'application' database accounts that have to follow the same policy as regular login-capable user accounts.
We have many processes in our system that run, unattended all the time, or part of scheduled jobs that need to access the database (Informix). These have been, up until now, nologin/noexpire accounts. We're now required to treat them as normal user accounts and their password to expire normally.
How do you manage/synchronize applications authenticating against the database when the credentials will at some point change?
We could generate a password based on the month, but since work is getting pushed through the system 24/7, that would likely lockout the account for too many failed attempts.
Two questions:
Are the applications (processes) running on the same machine as IDS?
Are they run by a process with the application account ID, or are they run by some administrative user (such as 'root') and the connection to the database specifies user name and password?
The answers are important because if the process is running on the local machine (the same machine as IDS) and the program is running as the 'application user', then the connection does not require a password at all. So, the expiry/change of the passwords would not affect the database system at all.
If the applications are run on the same machine but are started by 'root', then an option is to modify the code that runs the applications so that where it now does:
run_application
in future it does:
su app_user -c run_application
User 'root', of course, is empowered to run things as other users without bothering with trivial details like passwords. You might have to modify the application to avoid connecting with user name and password, again.
If the applications are not run on the same machines as IDS, the options are trickier. There are ways to achieve this effect; you probably do not want to exercise them.
(Contact me offline if you need details. I will need some more details from you, too. See my profile.)
Using Windows 2003, I'm look for a way to create a "logoff script" that will continue with the current logoff then immediately login another user. So, "UserA" logs off. Script fires to login "UserB".
This is part of an application upgrade for a computer where we have written the 'shell'; similar to a kiosk application. For the upgrade we need to logon as 'Adminstrator' then, when the upgrade has completed, logoff 'Administrator' and logon as 'sample_user'. We would like to accomplish this WITHOUT rebooting.
Note, I do not want a script that will initiate the logoff (i.e. "shutdown"). I'm looking for a script that will run upon the user logging off (set via Group Policies). As above, the script should log a different user on.
Thanks.
Don't think it's possible in the stated way (script at logoff).
You'd have to set the machine to logon automatically as a specified account and then log off (having it log on automatically for you) and then you'd have to disable that feature again afterwards, by placing a temporary logon script... generally sounds messy.
The actual setting can be made using tools like Microsofts Shared Computer Toolkit or similar (not so sure how the "normal" registry auto-login behaves at manual logout but I've had an XP kiosk that would automatically log on instantly, even if you logged out manually - you had to override it using some key like shift+logoff to be able to manually specify the login again, so somehow it can be made).
The "easiest" way might be to replace msgina.dll with someone of your own making...
But why are you doing this? Just use runas and start whatever you need to do as that other user without logging off the console user - it's a multi-user system afterall? The desktop is just fluff ^^
(This will anyhow require that the user credentials are available to your script, which kind of makes it redundant as you compromise the security of that account - defying the purpose of having that second account in the first place, for whatever purpose it exists?)
I would try setting the registry to autologon with the user you want, and then simply logging off the admin user. That should log your kiosk-user right back on.
Not sure how to login another user once the current user logs off (not sure if windows would let you...)
But you can use shutdown to logoff:
shutdown /?
Here's some ideas that probaly fall into the "cheap hack" category:
How about logging in at UserB in the first place, and then using runas /user:userA <cmd> to run the first part of the install process?
If that's unacceptable, I know there's a way to make Windows workstations (those that aren't part of a Domain) automatically log in into a certain user account after a restart. Perhaps if you looked into which Registry changes happen, and duplicated them, a reboot would automatically log in that user. (Of course, as a final stage, after userB logs in, you would have to revert those changes :-)
It also occurs to me to wonder if perhaps there's a way for a service to force an open "login screen" to log in as a certain user. Maybe using some method like the way the Remote Desktop does it remotely... If that's possible, then you could create a service that you install before logoff of userA, that would trigger the login of userB.
You can script it with VNC (there are many free versions, take your pick). Set up a VNC server process on the machine to listen on localhost. When the user logs off, your logoff script will connect to the machine using VNC and send the keystrokes necessary to log on the next user. VNC uses the RFB (remote framebuffer) protocol; there are libraries for most popular languages, so you should be able to get something working quickly. Or there are related tools that might help.
If you were to run something like this as a normal script in a given language, it would most likely not work as when you log out of your account, all processes should be killed along with your running script.
You might be able to create some sort of 'service' that would run on a service account (i.e. always active) that would automatically do this user switching for you.
My bets are on Windows Powershell, although I'm not entirely sure what functionality it has as far as actually creating a service.
A quick search brings up the following (The second link is to a forum but it mentions running Powershell as a service and sending that service a parameter which would be the path to your user switching script)
How to Create a Windows Service using Powershel
Powershell Script as a Windows Service
I don't have a Windows 2003 server or a system with a "Group Policies" setup to test my hunch but you could take a look at SU ("switch user") for Windows. Originally part of the Resource Toolkit this has been extended to a new SUperior SU. Do post the results/script if this works.
You could approach this from the perspective of building a remote control utility (like VNC, etc). The big thing here is that if you want access to the Logon screen (i.e. the CTRL + ALT + DEL / username/password) part, the only kicker is that a Windows Service is the only component that can access this, so you'd have to create one.
The only problem I see with this technique as a whole is that even if you spent a great deal of effort getting it to work (and it would be a pretty big effort), the chances of this working successfully with the whole thing originating from a logoff script (i.e. when stuff is shutting down) are low even due to the number of things that can go wrong when logging back on as Administrator.
Just remember that for anything you need to run as an Administrator, there are easier ways in Windows to make that happen (such as Run As, changing the user permissions on the items that need to update, etc).