I work in big company and big brother always watching and enforce its own rules. However to do my job I have special proxy server settings in IE8 which gives me access to what I need. All legal and based on job description. Everything is fine except every few hours my settings go back to standard and I have to reset them manually to this special proxy. I think security team forces some GPO settings which do this. I have admin rights on my computer but, of course, no rights on the domain. Is there way for me to prevent such changes in my personal settings?
That would be very helpful. Even I can do changes manually it most bothers me when I have automated processes. Some batch runs in the middle of the night and it can't work because proxy settings are wrong. Very frustrating.
Any help?
It is indeed likely you have encountered a Group Policy Preference (GPP), an optional part of the GPO system. These GPP are applied either on parameter change (on the side of the central admin) or on every regular GPO refresh - but between these, the end-user is free to change the values.
To check it, simply create the GPO report. In an elevated command prompt, do GPRESULT /H GPReport.html and read the created HTML file. You will likely encounter the GPP parameter. Note the GPO name.
Now, since you do have (organisational) permission to change these parameters, the cleanest option is simply to nicely ask your admin to:
first option: opt you out of the GPO. (give the GPO name and the GPO parameters to the admin)
second option: make the GPP "apply on change" only.
If this is not possible, you may (if it has not been forbidden by another GPO...) disable regular refresh of GPOs. Just open local policies, go to Computer Configuration\Administrative Templates\System\Group Policy and set "Disable background refresh of Group Policy" to enabled. That way, GPO will only refresh on logon. Please note this may be seen as a security risk and be frowned upon by your administrator/security officer/whatever.
Related
Our Problem:
We are using FortiGate in our company with ~2200 Clients. Most of them are using Notebooks. Some people can't connect to the Internet, when they come to the office after days working in home office. Our Fortigate is configured to watch the LogonEvents (EDIT:To be more specific: the attribute "lastlogon") of the Userobject on the Domaincontroller (we have 5) and authenticate the user with the IP of the device. This fails sometimes. Our network-guys are looking at this problem, but in the meantime i have to find solutions on the client-side
One workaround I found is to trigger a User LogonEvent via powershell on the client.
New-PsSession -ComputerName $Env:ComputerName -ErrorAction ignore
But most of the times it creates the User LogonEvent on one specific Domain Controller (mostly the default Logonserver), which is maybe faulty. It's the same when you lock your device and log back in.
Does somebody know another way to create a LogonEvent via Powershell or Batch, where I can select the authenticating Domain Controller? Like, iterating through all our Domain Controllers to create such event on the client.
Edit: Unfortunately, the command has to run with User Permissions.
Edit: Maybe it helps if I tell you my overall goal:
Every client gets a scheduled task via GPO which runs in User-Context
It gets triggerd by event 10000 from source Microsoft-Windows-NetworkProfile (network change)
A powershell script checks if the internet connection is working
If not, the script would try to trigger a LogonEvent on different Domain Controllers to be sure, the Fortigate Agent gets at least one of them.
Mathias has the right idea, but just creating a DirectoryEntry object (which is what [ADSI] is a type accelerator for) doesn't make a network request until you actually use it.
This will tell it to retrieve the name attribute of the root of the domain (any attribute would do - you just need it to get something):
[ADSI]::new("LDAP://domainController.fqdn", "svc_username", "p#ssW0rd").RefreshCache("name")
My project: go - 1.12.5; gin-gonic; vue-cli - 3.8.2.
On windows server 2008 go under the local account, run main.exe - works well. But when log off my account, all local account programs are closed, including my go server.
The first thing I did was try to configure IIS for my GO. Nothing good came of it.
Then I tried to run main.exe from the SYSTEM account psexec -s c:\rafd\main.exe. When log off the process does not close. But the frontend is in my account and SYSTEM does not see the local files (js, html, css) of my project
Tell me how to start the Go server, to after log off my project did not stop life
Two ways to approach it.
Go with ISS (or another web server).
Should you pick this option, you have further choices:
Leave your project's code as is, but
Make sure it's able to be told which socket to listen for connections on—so that you can tell it to listen, say, on localhost:8080.
For instance, teach your program to accept a command-line parameter for that—such as -listen or whatever.
Configure IIS in a way so that it reverse-proxies incoming HTTP requests on a certain virtual host and/or path prefix to a running instance of your server. You'll have to make the IIS configuration—the socket it proxies the requests to—and the way IIS starts your program agree with each other.
Rework the code to use FastCGI protocol instead.
This basically amounts to using net/fastcgi instead of net/http.
The upside is that IIS (even its dirt-old versions) support FastCGI out of the box.
The downsides are that FastCGI is beleived to be slightly slower than plain HTTP in Go, and that you'll lose the ability to run your program in the standalone mode.
Turn your program into a proper Windows™ service or "wrap" it with some helper tool to make it a Windows™ service.
The former is cleaner as it allows your program to actually be aware of control requests the Windows Service Management subsystem would send to you. You could also easily turn your program into a shrink-wrapped product, if/when needed. You could start with golang.org/x/sys/windows/svc.
The latter may be a bit easier, but YMMV.
If you'd like to explore this way, look for tools like srvany, nssm, winsv etc.
Note that of these, only srvany is provided by Microsoft® and, AFAIK, it's missing since Win7, W2k8, so your best built-in bet might be messing with sc.exe.
In either case, should you pick this route, you'll have to deal with the question of setting up proper permissions on your app's assets.
This question is reasonably complex in itself since there are many moving parts involved.
For a start, you have to make sure your assets are tried to be accessed not from "the process' current directory"—which may be essentially random when it runs as a service—but either from the place the process was explicitly told about when run (via command-line option or whatever) or figured out somehow using a reasonably engeneered guess (and this is a complicated topic in itself).
Next, you either have to make sure the account your Windows™ uses to run your service really has the permissions to access the place your assets are stored in.
Another possibility is to add a dedicated account and make the SCM use it for running your service.
Note that in either case proper error handling and their reporting is paramount: when your program is being run non-interactively, you want to know when something goes wrong: socket failed to be opened or listened on, assets not found, access was denied when trying to open an asset file, and so on—in all these cases you have to 1) handle the error, and 2) report it in a way you can deal with it.
For a non-interactive Windows™ program the best way may be to use the Event Log (say, via golang.org/x/sys/windows/svc/eventlog).
Simplest solutions would be using windows schedular.
Start your exe file on system logon with highest privilage in background. So whenever your system will logon it will start your exe and make runnign in background.
You can refer this answer,
How do I set a Windows scheduled task to run in the background?
Say I have a Windows GUI applications with a buttons on it. I am able to simulate a click on that button by using sendMessage winapi calls with BM_CLICK as the parameter to the call.
Now, from a security perspective, I do not want this to happen. i.e. my target process should ignore sendMessage calls from another process. Is there a provision to do this at all ? A way to authenticate the sendMessage calls ?
EDIT: In other words, how can I prevent applications such as Enabler, TurnitOn http://www.raymond.cc/blog/how-to-enable-and-access-disabled-grayed-out-buttons-windows-and-checkboxes/ from accessing functionality that is not meant to be accessed by the user ?
If the application is running in the user's own context, then it can only do what the user can do. The corollary of this, often overlooked, is that anything that the application can do, the user can do.
So there's not really any point in worrying too much about whether a button on such an application is "really" disabled or not. The user can always find another way to do whatever the button was going to do anyway. (This might be by using a registry editor, obtaining another application with the same functionality, or, if nothing else is convenient, they can run the application inside a debugger and force it to re-enable the button.)
The appropriate solution depends on the context:
In many cases, the most appropriate solution is to stop worrying about it. You should be able to trust your users, and if you can't, that's an HR problem, not a technical problem.
If the application is providing an interface to something running in a higher context, such as, for example, the front end for anti-virus software, then the security decisions (is the user allowed to do this?) should be happening at the back end. That is, the security decisions need to be taken by code that isn't in the user's control.
If you're a system administrator trying to lock down a kiosk machine - a machine that is going to be used by untrusted users, typically using a single guest account of some sort - then you use AppLocker or Software Restriction Policy to define which applications the user is allowed to run. Since Enabler and TurnItOn won't be on your list, the user won't be able to run them to bypass your security policy.
In windows 7, is there a way to have every login go to the same user session. So when a person is met with the login screen, they login and can continue working on that same user session. I am asking this because each user has their own login, but on this machine I need a program to be running across all user sessions. Since that doesn't seem feasible, I was just going to have them all login to the same user session.
Is this possible?
The appropriate way to solve this would be to have the program run as a service, and have a client UI that loads on startup 'hook' into the service process. Loading multiple users to the same session space would effectively violate the entire windows security model.
So, you either need to use a shared user for this, or a shared process (either local as a service, or remote as a server)
So, there's one possible way you might be able to get this to work, and that's to set this up as an interactive service. Definitely not a secure way to keep your system, but if you are able to make it work, it should work for your purposes:
Interactive services (in particular, read 'using an interactive service'):
http://msdn.microsoft.com/en-us/library/windows/desktop/ms683502(v=vs.85).aspx
Making srvany.exe (to run non-services as a service) on Windows7/Windows 2008:
http://social.technet.microsoft.com/Forums/en-US/winserverMigration/thread/98a97aee-c62b-4683-94ab-3777899cf7de/
There is any way to run another process with ordinary rights from a process running as administrator? From a process with elevated rights I want to start a process with ordinary rights like it were started from explorer. I tried impersonation but I didn't work.
Use CreateProcessAsUser(). Details are in the linked SDK docs.
No this is not possible (There are several hacky ways to do this (Inject into explorer, task scheduler, SaferAPI+MediumIL etc) but none of them work in all scenarios)
This seems like a nice way to do it, provided you don't care about situations where the Shell is not running (e.g. possibly some Terminal Services application-only setups, perhaps, though I'm not sure):
http://brandonlive.com/2008/04/27/getting-the-shell-to-run-an-application-for-you-part-2-how/
It gets an interface to Explorer.exe, which should be running in the user's normal context, and asks Explorer to execute a command in its behalf. This is done just using simple, documented COM interfaces and without having to mess around with process tokens or code/DLL injection.
The technique I've used with success is to use IShellDispatch2::ShellExecute to ask Explorer to launch the process. Since Explorer typically runs as normal integrity, this is effective. The trick is that it's a bit of work to get the IShellDispatch2 object. I followed the process outlined in this blog.
on linux you can use setuid to change the program user id
for windows
you can look at his:
https://serverfault.com/questions/16886/is-there-an-equivalent-of-su-for-windows
If at all possible, use Larry Osterman's solution (in the comments to Anders' answer) instead, i.e., have a parent process that runs without elevation, and launch both the elevated process and the non-elevated process from there.
If that isn't possible, there is an approach that should work in almost all cases, though it is usually more trouble than it's worth:
Install and start a system service, configured to run as local system. Give it your Remote Desktop session ID, e.g., via a command-line argument or a registry setting, as well as your process ID and the command line you want to run.
From the system service, use GetTokenInformation with TokenLinkedToken to get the linked token from the target process. You have to do this from a system service because you need SE_TCB_NAME to get a usable token. (This limitation does not appear to be documented but is consistent with the behaviour of tokens in Windows.)
Or, if there is no linked token, use WTSQueryUserToken to get a copy of the user's token. I believe this always gives you the limited token (if there is one) but if you want to be safe you can check whether it is an elevated or limited token using GetTokenInformation and TokenElevationType; if it is an elevated token, you can use TokenLinkedToken to get the limited one.
If there is no linked token (TokenElevationTypeDefault) you should use the token as-is. This may happen either because the user is not an administrator, or because UAC is disabled, either globally or because the user logged in using the built-in Administrator account. If the user is not an administrator then the token is already suitable. If UAC is disabled, you should respect the user's intent and use the administrative token.
You can then use CreateProcessAsUser or CreateProcessWithTokenW from the system service to launch the new process.
Finally, the service should delete itself and stop.
There is at least one edge case: if your elevated process is launched from a command window (or other process) which was launched using runas and non-administrative credentials. There is no split token in this case, and the original token may have already been deleted, so unless you captured a copy before elevation took place (Larry's solution, or variants thereof) there is no general way to run the child process in the same user context that the elevated process was originally launched from. The best you can do is the context of the logged on user (via WTSQueryUserToken as described above) which may not be the behaviour the end user would expect. (This may, however, be an acceptable limitation, depending on the scenario.)
When Explorer needs to de-elevate, it uses a scheduled task. This is probably a good solution in most cases, and much easier than my earlier answer.
A simple example in Powershell:
$action = New-ScheduledTaskAction -Execute 'notepad.exe'
Register-ScheduledTask -TaskName 'Launch Notepad' -Action $action -User $env:username
Start-ScheduledTask -TaskName 'Launch Notepad'