I'm creating a windows user by program an give the created user different privilege with LsaAddAccountRights. Among other things the privilege "SeSecurityPrivilege" which is needed to receive ACL information.
This works on a lot of different Windows versions: 7, 8.1x, 10.x, Server 2019: My program runs by the user can access the ACL of the files (with C# FileInfo.GetAccessControl()). But this did not work on Server 2008R2 and 2012R2. (ATM I could not test Server 2016). All Servers are Domain Controller. Checking privileges with "whoami /priv" shows, that the SeSecurityPrivilege is set on Server 2019 (but disabled), but the other server none of the privileges are shown.
Writing a program queering the privileges with LsaEnumerateAccountRights shows user has the privileges. Checking with PrivilegeCheck shows they are all disabled - on all Server (even 2019, where this is working).
Checking the group policy Group Policy at DC shows, that the Policy is assigned to the user.
Where is my problem? Why did this not work on the old Server version, but on the new one?
Even when a particular account holds a given privilege most of the time most processes will run with the privilege disabled. Use AdjustTokenPrivileges to enable the privilege on a per-process basis (ideally you only enable the privilege for the time it is actually needed and re-disable it afterward). Note that you use LookupPrivilegeValue to get the LUID that identifies a privilege to AdjustTokenPrivileges.
Related
I have a requirement to collect windows facts via ansible. By passing the local Administrator account credentials with Ansible, this works with no issues. If I add my own windows account to the local Admin group, this also works.
The problems starts when I need to connect to a windows server with a non-local admin account (an AD account with Administrator privilege). win_ping fail no matter what I try to make it work.
The Ansible documentation seems to suggest you have to be a local admin or a member of the local admin group.
https://docs.ansible.com/ansible/latest/user_guide/windows_setup.html#http-401-credentials-rejected
This section:
Ensure that the user is a member of the local Administrators group or has been explicitly granted access (a connection test with the winrs command can be used to rule this out).
And they give us this workaround:
https://docs.ansible.com/ansible/latest/user_guide/windows_winrm.html#non-administrator-accounts
Non-Administrator Accounts WinRM is configured by default to only
allow connections from accounts in the local Administrators group.
This can be changed by running:
winrm configSDDL default This will display an ACL editor, where new
users or groups may be added. To run commands over WinRM, users and
groups must have at least the Read and Execute permissions enabled.
While non-administrative accounts can be used with WinRM, most typical
server administration tasks require some level of administrative
access, so the utility is usually limited
But even after adding the remote AD account in the ACL editor and giving access to everything, I still get the same error.
"msg": "ssl: the specified credentials were rejected by the server",
Has anyone got this working with an AD account? Any pointers would be very welcome.
Currently, it looks like I need to have a local account with administrator privilege on every Windows server I want to run ansible on. I'm hoping this is not the case.
Thanks
I have shared computer, where admin install Oracle XE. But I cannot e.g. create new user, because I have not rights in OS, afaik.
In Oracle documentation written that DBA should be member of administrator group.
Does exists way that I can manage local instance XE without admin rights?
I need start/stop database, connect/disconnect, kill session etc. It is need for test my Java application.
Thanks.
You don't need an OS user with admin right (once Oracle is installed and running).
Just connect as SYSDBA then you can create new Oracle users and manage the complete database..
(I do that on XP as well - working with regular user, but connecting as SYSTEM or SYS with the SYSDBA role if I need to configure something in Oracle)
Does exists way that I can manage local instance XE without admin rights?
Probably not ... if that's what the Oracle documentation says.
A sensible strategy would be to discuss your problem with the admins. Point out that it makes it difficult for you to do your job if you don't have access rights. If they won't grant you system Admin rights, ask them to suggest alternatives that will allow you to do your job.
It may be simply that they need to grant you additional rights in Oracle.
How about getting admin rights in a Virtual Machine? See virtualbox.org.
From XE manual here :
" On each platform, if the OS authentication user group does not already exist, it is automatically created when you install Oracle Database XE. In addition, upon installation on the Linux platform, the user account oracle is automatically created and placed in the dba group. Upon installation on the Windows platform, the user performing the installation is automatically added to the ORA_DBA group. On both platforms, you can add other host users to the OS authentication user group to enable them to connect to the database with the SYSDBA privilege. "
Since installation on windows needs admin user which I assume you are not, so it renders the automatic addition of that admin user to ORA_DBA group useless for you.
So what your admin can do immediately after XE installation on this shared machine is just add your non-admin OS user (local or domain level, whatever) to the newly created OS local group "ORA_DBA". Once this is done, you can simply open the sqlplus prompt and connect with SYSDBA privilege using your own non-admin user in future:
connect / as sysdba
However, you will still not be able to restart the Oracle service or the TNS listener, even if you are in the ORA_DBA group.
I am attempting to control a service on a remote machine using the following code:
// Error checking omitted for brevity
HANDLE hToken = NULL;
// user = username with no domain specification
// domain = targetmachine when targetting computer outside of domain
LogonUser(user, domain, password,
LOGON32_LOGON_NEW_CREDENTIALS, LOGON32_PROVIDER_WINNT50, &hToken);
ImpersonateLoggedOnUser(hToken);
SC_HANDLE hSc = OpenSCManager(targetmachine,
SERVICES_ACTIVE_DATABASE, SC_MANAGER_ALL_ACCESS);
This works fine when run from a computer within our local domain and targetting a machine on the same domain, both when using the credentials from the currently logged on user as well as when using other credentials.
However, when I attempt to target a machine that is not on any domain, the OpenSCManager call fails with access denied if I specify anything other than SC_MANAGER_CONNECT as the desired access. Targetting a domain computer from a computer that is outside the domain works (using user/domain/password combination for a domain user that is a local administrator on the target machine). Targetting a computer outside the domain from a computer outside the domain does not work.
The user/password is for a member of the administrator group on the target computer, so there should not be a problem with the account rights.
I've checked the scmanager security descriptor using sc -sdshow scmanager and it is identical for the domain computer and the non-domain computer. Both are running Windows 7 64-bit.
I've also tested to use psexec, which has the same symptoms, i.e. works fine between domain computers but not when targetting non-domain computer.
I have also tested to disable RPC over TCP on the target machine and rebooting it, as this is described as a possible cause for access denied errors but this does not appear to help. I've also tested to disable the Windows Firewall on the targetmachine, but no change.
Is there some setting that needs to be enabled in order for remote configuration of services to work?
It appears that this was caused by new security features from Windows Vista and above. By default, Windows will not grant remotely connecting users full administrator rights unless it is being done within a domain. So in order for this to work, User Account Control Remote Restrictions need to be turned off, but of course this will also lower the security of your computer.
Thanks to Hans Passant for recommending to check for similar issues posted on serverfault.com.
According to < Windows via C/C++ >:
With Windwos Vista, if a user logs on
to the system with an account that
grants high privileges such as Admin,
in addition to the security token
corresponding to this privileged
account, a filtered token is also
created but granted only with the
privileges of a Standard User.
I am wondering, if a user logs on to the system with an account that is even less privileged than Standard User, does the system still create some extra filter token for it? I don't think it is necessary and it doesn't make any sense for the system to do that.
Thanks.
The short answer is that unless the user is an administrator, only a single token is present to represent the user.
When a standard user logs on to a computer a new logon session is created and they are presented with a shell application such as Windows Explorer that was created by the system and associated with the user’s newly created logon session by means of a token. This effectively limits what the user can do since Windows Explorer can only run those applications and access those resources that the user’s logon session permits based on the permissions and privileges specified by the token.
When an administrator logs on to a computer things are a little different and this is where Windows Vista (and Windows 7) differs dramatically from previous versions. Although the system creates a new logon session, it creates not one but two different tokens representing the same logon session. The first token grants all the permissions and privileges afforded to the administrator while the second token is a restricted token, sometimes called a filtered token, offering far fewer permissions and privileges. This restricted token offers practically the same capabilities and constraints as would be granted to a standard user. The system then creates the shell application using the restricted token. This means that although the user is logged on as an administrator, applications are by default run with limited permissions and privileges.
When the administrator needs to perform some task that requires additional permissions or privileges not granted to the restricted token, he or she can elect to run an application using the full security context provided by the unrestricted token. What protects the administrator from malicious code is that this elevation to the unrestricted token is only allowed after the administrator has confirmed the desire to use the unrestricted token by means of a secure prompt provided by the system. Malicious code cannot suppress this prompt and thereby gain complete control over the computer without the user’s knowledge.
When the built-in Administrator account logs on to a computer it appears as if it is treated differently to other users that are part of the Administrators group because it doesn’t receive elevation prompts. This is controlled by a group policy setting entitled “User Account Control: Admin Approval Mode for the built-in Administrator account”. Admin approval mode refers to the elevation prompt that requires an administrator to approve the elevation to the unrestricted token. By default this group policy setting is disabled which means that when the built-in Administrator logs on to a computer it only receives a single unrestricted token. If you enable this group policy setting then the built-in Administrator account will receive a new logon session with two tokens just like the other users that are part of the Administrators group.
I have a script written in Visual Basic that starts a process (given to the script as an argument) on a remote system (again, given as an argument) using WMI. This script works fine when using an Administrator account on the remote system, but when using a non-administrator account, I get the following error:
ConnectServer Failed w/ (-2147024891) Access is denied.
I'd like to be able to run processes on remote systems as a non-administrator user with this script, and I'm pretty sure the problem is due to security settings on the remote system, but I've not been able to reset the right ones.
It sounds like you need to configure launch and activation permissions for this user, on the target machine, via DCOMCNFG. By default non-admin users do not have remote launch and activiation permissions.
Alternatively, depending on the operating system you are connecting to, there may be a "Distributed COM Users" group to which you can add your user. This group already has the appropriate permissions. The Distributed COM Users group was first included in Windows Server 2003 Service Pack 1 (DCOM Security Enhancements).
You can read more about WMI and DCOM permissions here. More detailed steps on how to configure WMI and DCOM are included in the serverfault thread Which permissions/rights does a user need to have WMI access on remote machines?.