I have 2 CAS servers on my primary site.I want to use Allow/Block/Quarantine feature of 2010 through which I can allow block Active Sync access for particular devices.Do I need to put the Allow Block list on both the CAS servers or putting it on one will take care for both the CAS servers.
I am using
set-CASMailbox -Identity <MailboxIdParameter> -ActiveSyncAllowedDeviceIDs <MultiValuedProperty>
to allow or block a particular device.
This permission is set on mailbox so does not matters from which cas server we access the mailbox.Once set it will allow or block from all the servers in cas array.
Related
I want to do snmpv3 authentication with an active directory user instead of a local user?
The servers are Red Hat Enterprise 8.7 integrated with the AD and have access to different active directory groups. I would like the authentication to be done by a user present in the active directory.
SNMP is a protocol defined without any restriction on where the user accounts are. However, the tools (such as NET-SNMP) you use (either manager side or agent side) are often not AD aware.
For example, NET-SNMP specifically requires users to be configured in snmpd.conf, and each users needs to have authentication/privacy modes and passphrases chosen. That's not compatible with an AD user who usually has a single password.
Therefore, I'd like to say you shouldn't attempt to mix the two.
References
NET-SNMP
How are the following settings, located under Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> Security Options, related:
Interactive logon: Number of previous logons to cache (in case domain controller is not available)
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\CachedLogonsCount
determines whether a user can log on to a Windows domain by using cached account information
Network access: Do not allow storage of passwords and credentials for network authentication
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\DisableDomainCreds
determines whether Credential Manager saves passwords and credentials for later use when it gains domain authentication
Is CachedLogonsCount just a more fine-grained policy, with DisableDomainCreds the same as setting CachedLogonsCount to 0?
CachedLogonsCount controls how many previous local logons are cached locally, so the user can sign-in to the machine in case the domain controller is unavailable. Very important difference: Windows does not cache the actual credentials, only a hash used to verify the password. This means even compromising the stored information does not give access to any domain credentials. Reference.
DisableDomainCreds controls if the actual credentials are cashed so a user can access domain resources without re-authenticating during their session. If you enable this policy, a user will be force to re-type their password every time they access a network resource, e.g. a network share. This functionality stores the actual credentials. Reference.
Two answer your question: No, these are two different mechanisms with different goals.
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.
When configuring the global security for Websphere Application Server, no matter you choose Federated Repositories, LDAP registry or custom registry, there is a property named 'Server user identity' to be setup. According to the official explanation, this is used for authentication during server to server communication. Does it mean when server communicating with each other within one cell, authentication is required and this value would be used there? And does this value only impact internal process, like within same cell? Or it can also be between cells? If it's not leveraged like this way, then how does 'Server user identity' work?
Kinda don't understand this. Please help me figure it out. Thanks in advance
Until WAS 6, a single user identity was required, namely 'primary administrative user', for both administrative access and internal process communication . This user, by definition, had to exist on the configured user registry.
From version 6.1 onwards, WAS requires an administrative user, distinguished from the server user identity, so that administrative actions can be audited separately.
For all practical purposes, if you are using version 6.1+, and you are not in a mixed-release cell (cell containing profiles of older versions of WAS in addition to current versions), you may just go ahead with automatically generated internal user id. An internally-generated server ID also adds a further level of protection to the server environment because the server password is not exposed.
For mixed-release cells you may check infocenter here for details on how to configure server user id in this case.
Server user id is used for server to server communication in a cell. I could not find any documentation that implies this parameter is also related with cross cell communication.
I am trying to figure out how we would configure / setup the authentication, Queues, and Queue managers for connecting an MQ Client that is on a server / domain completely separate from the MQ Server it will be forwarding messages to.
I would assume that in a normally organizational environment you could just use Active Directory (if hosted on windows servers) for the authentication / AD lookup. However, in this scenario because they are different orgs you couldn't do that?
Can you simply apply SSL certs to both client / server and use that as your authentication? If so is that just applied to the Channel used in the connections?
Not sure how to proceed forward with this.
Any suggestions would be greatly appreciated.
Thanks,
S
Take a look at the Hardening WebSphere MQ presentation for v7.0 and earlier. The thing to remember is that WMQ does not authenticate anything. It authorizes based on OS identities and groups but there is no password checking being done.
For situations where QMgrs and clients live on Windows networks, the connection uses the SID and so it appears that some useful authentication was performed. BUT if a connection from a non-Windows platform is attempted, the Windows QMgr uses the string representation of the ID. So for example, if someone has a Linux VM on their desktop they can easily create a user ID called MUSR_MQADMIN and the Windows QMgr will accept the connection. There is a setting that causes the Windows QMgr to only accept connections with SIDS that it can resolve but even there its just a matter of knowing what the SID values are to spoof them on a connection.
The lesson here is that any QMgr, even one on Windows, must be configured to authenticate remote connections. With WMQ v7.1 and later, the QMgr has functionality to map X.509 certificate DNs to user IDs, or to perform IP filtering. Prior to v7.1 these functions required an exit such as BlockIP2. Capitalware sells MQAUSX which has the functions of BlockIP2, plus will perform ID and password authentication and is supported.
The first recommendation is to use a v7.1 QMgr so that you get the CHLAUTH rules for mapping and filtering. Even if you don't use certificates v7.1 limits administrative connections so it is harder for an attacker to gain full admin rights. Then if you need password validation, use SSL channels (to encrypt the password and prevent simply replay attacks) in combination with an exit that you can write yourself or purchase.
Just be aware that allowing a connection from outside your domain doesn't present any new challenges. The pre-v7.1 Windows QMgr that does not have MCAUSER set in the channel definition or by an exit allows remote administrative access, even from connections originating in the local Windows domain. There was always a need to harden that QMgr, even though honest users will have received authorization errors if the administrator did not set up auths for them.
Summary:
For clients originating outside your administrative domain, I'd recommend mutually authenticated TLS/SSL channels. The same page I linked to above also contains the WMQ Security Lab guide and scripts which show how to script the creation and exchange of WMQ certs and configure WMQ Explorer with them.
Whatever else you do, the MCAUSER on any legitimate channel must be set either in the configuration or by an exit. If the client is allowed to specify the ID, there is nothing to prevent it from specifying an administrative ID. For channels that are NOT being used such as SYSTEM.DEF.* and SYSTEM.AUTO.*, set the MCAUSER to a value that cannot be a local ID such as no!body or on v7.1 and later *NOACCESS.