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...
Related
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.
Password complexity setting is disabled in default domain GPO. I need to enable it on one server, but I don't have the access to edit this GPO on the domain level. When I open local security settings on the server, option to enable (or disable) is grayed out. Is there a way to override default domain GPO for password complexity locally in the registry? And to keep it that way, to stop GPO from being propagated down from domain level to this particular server?
There are two moments in your case. First you can't use a local group policy for domain accounts because AD accounts store on only DCs. Only Domain Controller Polices. And ones apply only to user accounts. Not computer accounts. Second you can use a local group policy for edit settings for only local user accounts. Run the gpedit.msc command on local server for it.
But since Windows 2008 Domain you can separate password policy for different user groups. You can read about it here for example
https://technet.microsoft.com/en-us/library/cc770842(v=ws.10).aspx
Good luck.
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.
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 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.