I have two service accounts svc-a and svc-b created in the same domain under same OU. Recently I upgraded my Windwos Web server with latest security patch, where these two service accounts are used to run two different IIS websites.
Post patching, svc-a fails to fetch AD group members for any group. While svc-b can still do that.
The error I get with svc-a is,
get-adgroupmember : Either the target name is incorrect or the server
has rejected the client credentials. At line:1 char:1
get-adgroupmember acifeesadmin -server au.amp.local
+ CategoryInfo : SecurityError: (acifeesadmin:ADGroup) [Get-ADGroupMember], AuthenticationException
+ FullyQualifiedErrorId : ActiveDirectoryCmdlet:System.Security.Authentication.AuthenticationException,Microsoft.ActiveDirectory.Management.Commands.GetADGroupMember
One of the suggested fix I found on Google was to enable RC4_HMAC_MD5 encryption method, which when done, svc-a account can fetch AD group members successfully.
Enabling RC4_HMAC_MD5 encryption type is not a feasible solution for us as our Group policy wipes out this change and also it being an older encryption type, is more vulnerable to attacks.
Based on the suggestion from this excellent blog on Kerberos encryption types
https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/decrypting-the-selection-of-supported-kerberos-encryption-types/ba-p/1628797 I have enabled AES 128 and AES 256 encryption types on the service account svc-a
The service account svc-a still cannot fetch AD group members and fails with the same error.
The only way it can fetch AD group members, is when I enable RC4_HMAC encryption type on the Web server(which I don't want to)
In summary,
Two similar service accounts in a domain used in a window web server to run IIS websites
Post security patch installation on the Web server, one of the service account fails to fetch AD group members.
Enabling RC4_HMAC encryption type on the Web server fixes the problem but this is not a feasible solution as our group policy wipes out the change.
Making changes to the service account on AD, to allow AES 128 and AES 256 encryption types does not help
I have tried resetting password for svc-a, that too did not help.
Does anyone know what else should I be trying or has insights on why this doesn't work?
This has been fixed. The service account's password was reset before the RODC was created and hence DC kept issuing service tickets with older encryption method. Resetting the password twice after a gap of 10 hours fixed the issue.
Related
I am trying to create local admin account for my lab machines with unique passwords. I have around 25 machines in the lab. I am looking out if there is any way where we can store the password in Azure keyvault and if password is rotated in azure key vault, the authentication should pick up the updated password and authorize the user. I have to rotate password too often, usually once in couple of days. The end user would receive the password with which he can login.
This is a too complex task to put it into a simple answer. You have to divide your problem into some smaller ones. Here here the building blocks I would see:
Create an authenticated web api that allows CRUD operations against your Azure Key vault (maybe with ASP core or Azure functions, etc.)
Create a windows service that runs on your lab machines and is able to change the local admin accounts password and can communicate with your web api.
Create an authenticated web page, where you can log in and read the username and password.
All of these steps have to be divided on their own and or not trivial. Also some additional features could make sense like
when a username/password was given out some log is written about who got when this username/password.
when a username/password was given out the windows service will be informed (maybe by regular requests from the windows service or some back channel like SignalR or Redis channel) and produces a new password a given time later (e.g. 8 hours later)
Nevertheless, this is a complex project that needs at least several weeks to be implemented correctly, even if you know how all these techniques are working.
I am having an workstation specific Kerberos issue and hope anyone here would have additional recommendation.
Our application has an application server and web server and we have kerberos configured on both application layer and web layer.
And for certain users, when we provide the Kerberos link and they are not able to authorize in. And we found out the issue is workstation specific. And on the same problematic workstation, the user could access application server via Kerberos authentication.
And on the web logic we see the following error:
[SpnegoFilter.doFilter] Although user authentication to xxx was successful, Integrated Authentication could not extract the user's credentials because it appears delegation was either not configured or disallowed
I am looking for any of Windows setting could potential lead to this issue? We check that our domain is trusted on both working and nonworking machines on the browser level and GPO settings are the same.
What you're describing is unconstrained delegation, which is the act of a user handing the remote server their TGT so the server can impersonate the user without restriction.
Windows deems this as incredibly dangerous (it is) and is moving towards disabling it outright when certain security services are enabled on the client. Specifically Credential Guard. It will also block it for users that are members of the Protected Users security group, though the fact that it's affecting specific workstations leans towards Credential Guard.
If it is the above issues the correct solution is to switch to constrained delegation.
If I set up composer-rest-server to use github authentication (as described in https://hyperledger.github.io/composer/latest/integrating/enabling-rest-authentication.html), then a client of the rest server needs to authenticate against github.
If this authentication is successful, then the client acts with the business card that was specified during startup of the rest server (or with the one that was uploaded in multi-user mode).
However, ANY github user may authenticate that way! There is no control which github users may use the rest server (I would expect a configuration file with a white list etc.). Therefore ANY github user may interact with the blockchain the same way using the business card of the rest server?!
This is quite useless in my opinion. Or do I oversee something? What is the purpose of github authentication in composer-rest-server?
Before authentication there is no real access to the Business Network, after authentication there is access to add Cards to a Wallet after which there is access to the business network (controlled by ACL).
The Wallet is unique to the authenticated user, so in your github example if you open a different browser and use a different Github ID you will have an empty Wallet, and no access to the network - except to add a card.
With regard to Github it is just used as an example of a Passport Strategy for Authentication - it is used in the example docs as it is quite easy to set up and anybody can use Github. It might be useful for a public blockchain, but for many examples it might be more appropriate to use a Passport Strategy to connect to a private LDAP or Active Directory.
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.
I am trying to understand better how Kerberos is integrated in Active Directory but I couldn't find a clear answer to this question from the Microsoft documentation.
I understand the process of getting a service ticket to a service from the KDC: client presents his TGT to the KDC along with a request to a specific service, the KDC will send back a service ticket to the client and the client uses this service ticket when accessing the service.
My question is: can I configure the KDC (Active Directory) to refuse to grant a service ticket to specific services for specific users/groups ?
I've tried to search the web for this and play around with configurations in order to achieve this, but I am beginning to suspect that the service ticket only role is to tell the service that "this user is indeed from the legitimate domain" and therefore a service ticket can be given to anyone on the domain. So for example in the case of CIFS (file server) even if I remove all shares from a computer, I can still see that every user can see this computer (i.e via \computer) and by running "klist tickets" I also see that they are granted a ticket to the CIFS service for "computer" even when they can't see any shared folder or drive on it. So specifically in this example, can I somehow make it so that a specific user will never be given a "CIFS" type service ticket for this computer ?
Not with Kerberos. It has been designed for authentication only. You wan't authorization. This is a different problem area.
This is non-trivial to setup but with Windows Server 2012 R2 AD, this is possible to do. Take a look at Authentication Policies & Siloes - http://technet.microsoft.com/en-us/library/dn486813.aspx