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.
Related
I looked at the config files everything is fine, made environment variables PATH's, started and restarted the service put in the right password, searched for someone with similar problems(not found).
Every time i go to the default location via browser I get the login screen but when i put in 'root' and the password I get an error message 'Login Failed'.
When I set athenticate=false in the conf file i can access the web manager.
Anybody know how to solve this or at least what might be wrong?
During the installation, the ArangoDB Installer will ask you the password for the administrator user.
Use root as user name with your password to gain access to the database.
Open a CMD-Window in your ArangoDB installation directory.
To re-gain access to the database, stop the ArangoDB database service using
sc stop ArangoDB
after the database was stopped, invoke
.\usr\bin\arango-secure-installation
which will ask you for a new password.
After that, start the service again using:
sc start ArangoDB
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 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.
How can I stop and then restart an IIS 7 application pool from an MSBuild script running inside TeamCity. I want to deploy our nightly builds to an IIS server for out testers to view.
I have tried using appcmd like so:
appcmd stop apppool /apppool.name:MYAPP-POOL
... but I have run into elevation issues in Windows 2008 that so far have stopped me from being able to run that command from my TeamCity build process because Windows 2008 requires elevation in order to run appcmd.
If I do not stop the application pool before I copy my files to the web server my MSBuild script is unable to copy the files to the server.
Has anybody else seen and solved this issue when deploying web sites to IIS from TeamCity?
This article describes using an htm file named App_offline.htm to take a site offline. Once the IIS detectes this file in the root of a web application directory,
ASP.NET 2.0 will shut-down the application, unload the application
domain from the server, and stop processing any new incoming requests
for that application.
In App_offline-htm, you can put a user-friendly message indicating that the site is currently under maintainance.
Jason Lee shows the MSDeploy calls you need to use (plus much more about integrating these steps in your build scripts!).
MSDeploy
-verb:sync
-source:contentPath="[absolute_path]App_offline-Template.htm"
-dest:contentPath="name_of_site/App_offline.htm",computerName="copmuter_name",
username=user_with_administrative priviliges,password=passwort
After deployment you can remove the App_offline.htm file using the following call:
MSDeploy
-verb:delete
-dest:contentPath="name_of_site/App_offline.htm",computerName="computer_name",
username=user_with_administrative_priviliges,password=passwort
The msbuild community tasks includes an AppPoolController that appears to do what you want (though as noted it is dated and at present only supports IIS6.) An example:
<AppPoolController ApplicationPoolName="MyAppPool" Action="Restart" />
Note that you can also provide a username and password if necessary.
Edit: Just noticed that the MSBuild Extension Pack has an Iis7AppPool task that is probably more appropriate.
this is the fairly hackey workaround I ended up using:
1) Set up a limited-access account for your service to run as. Since I'm running a CruiseControl.NET service, I'll call my user 'ccnet'. He does NOT have admin rights.
2) Make a new local user account, and assign to the Administrators group (I'll call him 'iis_helper' for this example). Give him some password, and set it to never expire.
3) Change iis_helper's access permissions to NOT allow local login or remote desktop login, and anything else you might want to do to lock down this account.
4) Log in (either locally or through remote desktop) as your non-admin user, 'ccnet' in this example.
5) Open a command terminal, and use the 'runas' command to execute whatever it is that needs to be run escalated. Use the /savecred option. Specify your new administrative user.
runas /savecred /user:MYMACHINE\iis_helper "C:\Windows\System32\inetsrv\appcmd.exe"
The first time it will prompt you for 'iis_helper's password. After that, it will be stored thanks to the /savecred option (this is why we're running it once from a real command prompt, so we can enter the password once).
6) Assuming that command executed OK, you can now log out. I then logged back in as a local admin and turned off the 'ccnet' user for local interactive login, and remote desktop. The account is only used to run a service, but no real logins. This isnt a mandatory step.
7) Set up your service to run as your user account ('ccnet').
8) Configure whatever service is running (CruiseControl.NET in my case) to execute the 'runas' command instead of 'appcmd.exe' directly, the same as before:
replace:
"C:\Windows\System32\inetsrv\appcmd.exe" start site "My Super Site"
with:
runas /savecred /user:MYMACHINE\iis_helper "\"C:\Windows\System32\inetsrv\appcmd.exe\" start site \"My Super Site\""
The thing to note there is that the command should be in one set of quotes, with all the inner quotes escaped (slash-quote).
9) Test, call it a day, hit the local pub.
Edit: I apparently did #9 in the wrong order and had a few too many before testing...
This method also doesn't completely work. It does attempt to run as the administrative account, however it still runs as a non-escalated process under the administrative user, so still no admin permissions. I didn't initially catch the failure because the 'runas' command spawns a separate cmd window then closes right away, so I wasn't seeing the failure output.
Its starting to seem like the only real possibility might be writing a windows service that will run as admin, and its only purpose is to run appcmd.exe, then somehow call that service to start/stop IIS.
Isn't it great how UAC is there to secure things, but in actuality just unsecures more servers, because anything you want to do you have to do as admin, so its easier to just always run everything as admin and forget it?
You can try changing the Build Agent Service settings to log-on as a normal user account instead of SYSTEM (the default), this can be done from the services control panel (Start | Run | services.msc).
If it doesn't help, you can also try configuring the appcmd to always run elevated, refer to this document for details.
In case such option is not available for appcmd or it still doesn't work, you can disable UAC completely for this user.
Here you go. You can use this from CC.NET with NAnt or just with NAnt:
http://nantcontrib.sourceforge.net/release/latest/help/tasks/iisapppool.html
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).