Anyone who know "What's the least privileges of NetLocalGroupAddMembers?"
Appreciate your helps.
MSDN says:
If you call this function on a domain controller that is running
Active Directory, access is allowed or denied based on the access
control list (ACL) for the securable object. The default ACL permits
only Domain Admins and Account Operators to call this function. On a
member server or workstation, only Administrators and Power Users can
call this function.
This is confirmed by Requirements for Network Management Functions on Active Directory Domain Controllers:
For updates, the default ACL permits only Domain Administrators and
Account Operators to write information. One exception is that users
can change their own password and set the usri*_usr_comment field.
Another exception is that Account Operators cannot modify
administration accounts.
and Requirements for Network Management Functions on Servers and Workstations:
By default, only Administrators and Power Users can write information.
Related
Unable to give the permission 'chg' to the SYSTEM.AUTH.DATA.QUEUE. We tried giving using setmqaut with mqm super user access but no luck! Currently it is flooding our AMQERR* error logs. Need your help on this.
The SYSTEM.AUTH.DATA.QUEUE is very restricted. This is because it holds the data that is your authority rules. You cannot give chg permission to a non-privileged user ID and a privileged user ID already has the ability to change.
IBM Knowledge Center says:-
Authorization data is stored on a local queue called SYSTEM.AUTH.DATA.QUEUE. Access to this queue is restricted to users in the mqm group, and additionally on Windows, to users in the Administrators group, and users logged in with the SYSTEM ID. User access to the queue cannot be changed.
If you need to make a change to this queue (you don't say why), then you can only do it using a privileged user id, e.g. a member of the mqm group.
Background: I'm writing a service and want to give it as few privileges as necessary.
Virtual Accounts (sometimes "Virtual Service Accounts") are sparsely documented feature new to Windows 7/2008R2 that are automatically managed accounts for services that need minimal privileges but access the network with a computer identity in a domain environment.
My service doesn't need network access, so I'm using LocalService, but I don't like the fact that if I grant access to a file/etc I granting access to all services running as that account.
Is there a least privileged account I can use?
You don't need to change the account the service runs under; LocalService is fine.
Instead, configure the service to have a non-zero SID type, i.e., specify either SERVICE_SID_TYPE_UNRESTRICTED or SERVICE_SID_TYPE_RESTRICTED. You can do this using the ChangeServiceConfig2() function and the SERVICE_CONFIG_SERVICE_SID_INFO option.
You can then grant access to files and other protected resources using the service SID, whose name is NT SERVICE\myservice, rather than LocalService. This will grant access to only your service. (Well, and any other services sharing the same process, but most third-party services run in their own process.)
For least privilege, use SERVICE_SID_TYPE_RESTRICTED. This means that the service can only access protected objects that explicitly grant access to either Everyone, the service SID, the logon session SID, or WRITE_RESTRICTED. You should also use the SERVICE_CONFIG_REQUIRED_PRIVILEGES_INFO option to reduce the privileges granted to the service; many services do not need any privileges at all. (In that case, you may find that you need to specify SE_CHANGE_NOTIFY_NAME rather than an empty list, though I might be misremembering.)
I need to be able to store a user's Exchange password so I can use it to perform some task later on, using EWS. I know storing passwords in plain text is a horrid crime, so what options do I have?
In my case, my application will have access to an administrative account that will have the ability to use impersonation to work with users' Calendars. I need to store the password of this admin account so I can use it while authenticating with the Exchange server at a later time. I am not planning on using the EWS Managed API.
I have a user that created a calendar app with similar requirements. By default, an account that has these permissions globally is horrible and not recommended. Impersonation roles were granted by department that required access to the app to reduce risk scope. However if you require this globally, here's what I recommended for mitigating the account/password exposure:
Restrict the accounts functionality to Exchange services only. Features like log on locally and other general domain user privileges are not needed for an EWS service account that only needs mailbox access and impersonation roles. In this case, the account cannot log onto a computer nor can it be used for RDP. This limits exposure for malicious use.
The user/pass can be stored in your applications database and the connection string would also be stored outside of your application, there's a lot here: https://security.stackexchange.com/questions/22817/how-to-encrypt-database-connection-credentials-on-a-web-server and encrypting the password within the database; further reading: http://www.darkreading.com/safely-storing-user-passwords-hashing-vs-encrypting/a/d-id/1269374
Restrict DB server and management access. This is a larger issue than it should be if the database server is shared between groups. Audit the database server access, and re-restrict if you have too many cooks in the kitchen. The database server should also not be directly accessed by user networks but that may be a larger issue to tackle.
Restrict access to the application. As in, is it available externally or only available inside your perimeter? Either way, the application should also include authentication just to access, using Kerberos or some other SSL auth, make sure the application cannot be used to DoS the EWS services from over-access.
Create a one-off throttling policy on Exchange for this user and assign accordingly to prevent the application from breaking EWS or limiting regular user functionalities. This is something Blackberry admins learned the hard way if they didn't follow recommendations. When BES server wouldn't properly tear down connections, web services would start dropping valid client requests. As such BES had to instruct users to create a one off throttling policy for various Exchange features. I did the same for the user that created my EWS app. And a few times it saved me.
Really it will boil down to good application design and coordinating requirements with the Exchange team.
Don't's:
Don't store the username/password in Apache/IIS pages or the connection string
Don't grant global permissions for the account if you don't have to
Don't allow unauthenticated access to the application and allow unlimited connection times
Hope this helps.
Is it possible to give someone access to the SiteMinder administration console, but in a read only fashion? We want some people to be able to see the configuration but not be able to modify anything.
SiteMinder Administrator accounts can be configured with fine-grained privileges that determine the administrative capabilities available to that administrator.
SiteMinder Administrator accounts are assigned rights to one or more security categories that define their administrative authority in the Administrative UI, such as managing authentication schemes. By default an Administrator account has access to every SiteMinder object related to an assigned security category.
Workspaces define a subset of SiteMinder objects. Assign a workspace to one or more Administrator accounts to filter the objects that are available to them, further controlling the scope of their administrative authority. An Administrator account whose authority is restricted by an assigned workspace is known as a scoped administrator.
Consult the SiteMinder Policy Server Configuration guide for more details...
I am new to windows services programming. I have confusion about what to set the Account type while writing a windows services.
How to choose or how to determine to which account type we need to set while writing a service?
We generally create special windows (local for local only access or domain account for things that need to authenticate accross the network) accounts to run custom services. This way we can restrict and lock down the permissions to make sure it only has access to what we need. You can also see which specific users are culprits or resource hogging with monitoring on a shared server.
As for the built in accounts...
Local System:
The built-in LocalSystem user account has a high level of access privileges; it is part of the Administrators group.
Network Service:
The built-in Network Service user account has fewer access privileges on the system than the LocalSystem user account, but the Network Service user account is still able to interact throughout the network with the credentials of the computer account.
Local Service:
The built-in Local Service user account has fewer access privileges on the computer than the Network Service user account, and those user privileges are limited to the local computer. Use the Local Service user account if the worker process does not require access outside the server on which it is running.
Source(s):
Microsoft Technet
LocalSystem
The LocalSystem account is a predefined local account used by the service control manager. This account is not recognized by the security subsystem, so you cannot specify its name in a call to the LookupAccountName function.
It has extensive privileges on the local computer, and acts as the computer on the network. Its token includes the NT AUTHORITY\SYSTEM and BUILTIN\Administrators SIDs; these accounts have access to most system objects. The name of the account in all locales is .\LocalSystem. The name, LocalSystem or ComputerName\LocalSystem can also be used. This account does not have a password. If you specify the LocalSystem account in a call to the CreateService or ChangeServiceConfig function, any password information you provide is ignored.
NetworkService
The NetworkService account is a predefined local account used by the service control manager. This account is not recognized by the security subsystem, so you cannot specify its name in a call to the LookupAccountName function. It has minimum privileges on the local computer and acts as the computer on the network.
This account can be specified in a call to the CreateService and ChangeServiceConfig functions. Note that this account does not have a password, so any password information that you provide in this call is ignored. While the security subsystem localizes this account name, the SCM does not support localized names. Therefore, you will receive a localized name for this account from the LookupAccountSid function, but the name of the account must be NT AUTHORITY\NetworkService when you call CreateService or ChangeServiceConfig, regardless of the locale, or unexpected results can occur.
A service that runs in the context of the NetworkService account presents the computer's credentials to remote servers. By default, the remote token contains SIDs for the Everyone and Authenticated Users groups. The user SID is created from the SECURITY_NETWORK_SERVICE_RID value.
The NetworkService account has its own subkey under the HKEY_USERS registry key. Therefore, the HKEY_CURRENT_USER registry key is associated with the NetworkService account.