When instantiating DirectorySearcher(doman,...) with params you can specify the AuthenticationTypes.
However, when instantiating DirectorySearcher() without params, it is not clear what AuthenticationTypes will be used.
This is now a big deal as the AuthenticationTypes.secure which uses NTLM will be abandoned and disabled on MS AD servers by MS next few months.. which leaves developers scrambling to un-F their SW
My guess is when instantiating DirectorySearcher() without params, the calling code will find the first suitable AuthenticationType, so existing code will not break. But I would like confirmation..
The default is AuthenticationTypes.Secure, which you can see from the source code or by examining the AuthenticationType property:
Console.WriteLine(new DirectoryEntry().AuthenticationType);
However, AuthenticationTypes.Secure does not only try NTLM. The documentation says:
Requests secure authentication. When this flag is set, the WinNT provider uses NTLM to authenticate the client. Active Directory Domain Services uses Kerberos, and possibly NTLM, to authenticate the client. When the user name and password are a null reference (Nothing in Visual Basic), ADSI binds to the object using the security context of the calling thread, which is either the security context of the user account under which the application is running or of the client user account that the calling thread is impersonating.
In the case of Active Directory Domain Services, it will actually prefer Kerberos over NTLM.
Related
I am facing ERROR like below when connecting Microsoft Azure AD after enabling MFA. Before that it gets connected. Today while login, it required me to enable this security feature in my Phone(Microsoft Auithenticator APP). Unless this feature added, i can't able to access MS Outlook in Microsoft 365.
I am using WSO2 Outlook Connector to make connection with Microsoft Graph API
ERROR:
"error":"interaction_required","error_description":"AADSTS50076: Due to a configuration change made by your administrator, or because you moved to a new location, you must use multi-factor authentication to access '00000002-0000-0ff1-ce00-000000000000
Possible solutions:
Use a interactive flow instead.
If you are using a interactive flow and still getting this error, ensure openid is one of the scopes during the interactive sign-in. You might be getting the error after the interactive sign-in and trying to exchange the authorization code for a access token...
https://login.microsoftonline.com/contoso.onmicrosoft.com/oauth2/authorize
?client_id=########-####-####-####-############
&response_type=code
&scope=openid groups.read.all
&nonce=1234
&redirect_uri=https://app.contoso.com
Notice "scope=openid groups.read.all" in the request above.
Add the client application to the exception list of the Conditional Access Policy
Add the user to the exception list of the Conditional Access Policy
If not using conditional access policies and the user is directly enabled for MFA, then as a last resort, disable MFA for the user if solutions above (specifically solution #1 and #2) do not work for you.
I am running a process with loacl admin privilege in Windows and trying to obtain a credential handle for another user using AcquireCredentialsHandle .
It is possible to pass in SEC_WINNT_AUTH_IDENTITY structure with user info ( e.g. user, domain, password) and obtain the handle. I have verified it. Without the SEC_WINNT_AUTH_IDENTITY passing only the pszPrincipal does not work.
I wonder is there any other way one can do it without providing the user password?
I am running the following scenario:
Client obtains a kerberos token using UPN and sends it to server
Server tries to acquire the credential handle (AcquireCredentialsHandle) using UPN of the client.
Any suggestions please?
You normally don't get to request a ticket on behalf of other users. That would be a very dangerous security issue.
There are two ways around this.
Use S4U2Self which is where the application requests a ticket to themselves using the passed in username, which will get them a ticket on behalf of the user to themselves. This lets you see things like user group membership. You need to be running as SYSTEM or have SeImpersonatePrivilege to do this.
Use S4U2Proxy aka protocol transition which is where the application requests a ticket for another service using the passed in username. This lets you impersonate the user based only on the name, and must be explicitly granted to the server and target by AD. This is an incredibly dangerous privilege because you're allowing your application to have the equivalent rights as a KDC.
Unfortunately this is a fairly complicated bit of code so it's not shareable in this post as-is. You can find a sample application here: https://github.com/SteveSyfuhs/DelegatedAuthentication
The gist of the process is:
Client sends username to service.
Service is configured for SeImpersonatePrivilege or SeTcbPrivilege (meaning running as SYSTEM)
Service calls LsaLogonUser and passes just the username, returning an NT token handle.
Service calls SetThreadToken with the token from (3).
Service calls AcquireCredentialsHandle without any credentials (uses default SSO creds).
Service calls InitializeSecurityContext
Service sends token to target server
Deploying the same HTTP based application on several web servers (srv1, srv2, etc). Protecting the application with SPNEGO auth. The servers are Linux and AD doesn't know of their existence, i.e. they are not joined to the domain. I've got the whole SPNEGO working smoothly on a single host. Now moving on to the subsequent hosts.
Most guides I've found will tell you that you need
An account in AD
A SPN
A keytab (generated on the AD server and then
moved to the Linux host)
While I believe that (2) + (3) will always need to be per-server, I'm somewhat uncertain about (1). Can I do with only one account? I would really like to not having all these accounts in AD if I can do with only one.
This blog has a good recipe for how it can be done: The first invocation of ktpass (for srv1) should be as described in the all the guides you find on the internet, however subsequent invocations (for srv2, srv3, etc) should be using the -setpass and -setupn options.
However I've found that when one uses the ktpass.exe tool the account's userPrincipalName attribute changes to become as given by princ argument from the last invocation of ktpass. So the name of the srv, e.g. srv3 is coded into the name and the name of the account will therefore basically change with each invocation of ktpass. When the web server performs the final step in the SPNEGO chain of events, which is to contact AD using the keytab as credentials, it will look for an account in AD with a userPrincipalName equal to the SPN and this step will therefore fail. (source, scroll to last post, list item 3). Contradicting this is that I'm using Tomcat and thereby JAAS and as far as I understand I can hardcode the principal name to use in my jaas.conf file thereby effectively ignoring the principal name from the keytab.
Can multiple app servers + single account in AD ever work and if so how?
In short, yes it will work and I will tell you how. First of all let's clarify some things and some statements not properly described in your question or the comments:
You have three machines which serve the same DNS name, this means that you either have a DNS round-robin: service.example.com will returned a shuffled list if IPs or a load-balancer (hard of sort) will only one IP for the A record depending on the load. For Kerberos, both setups are equal in the outcome.
Now, you cannot say that the AD does not know the existence of a service or a server if you require Kerberos authentication. It will and must know otherwise it cannot create service tickets for your clients which they pass on to the server. Additionally, Tomcat will not contact the KDC to accept the security context because the service ticket is encrypted with the account's long-term key.
Here is the approach: You have already figured out that one SPN can be bound to one machine, multiple bindings are not allowed. This is the case when you have the machine name bound to the machine account (srv1$, etc.). You need a service account. The service account is a regular account without password expiration, e.g., my-service#EXAMPLE.COM. For this account, you will bind your CNAME or A record. Have you Tomcat authenticator to accept all securty contexts with this service account and it will work.
How to create this magical service account on a Unix-like OS?
Use mskutil to
create the service account,
create a keytab for that service account,
bind your SPN to that service account and have the keytab updated.
After that you will have a keytab suitable for your use. Verify with an LDAP query (e.g., with Softerra's LDAP browser or else) that the account exists, the SPN (servicePrincipalName) is bound to that account and you are done.
Important: if any of your clients use MIT Kerberos or Heimdal, you must set rdns = false your your krb5.conf.
Godspeed!
If a user logs in to their computer using a Single Sign-On system such as Active Directory, LDAP, or Kerberos, is it possible for applications they run to know who they are and what system they authenticated with? Can I get enough information out of these systems to verify their identity without requiring any additional user input?
Specifically, I would like to be able to check these things:
Did they log in via a single sign-on system at all, or are they just using a regular user account on this machine?
What system did they use?
Does the system have some URI that would distinguish it from any other directory?
What is the current user's distinguished name in that directory?
Can I get some information which I can pass to another host to prove to that host that the user is who they said they are? For example, a token that can be used to query the SSO system.
I'd assume all of these things should be possible, and in fact encouraged, but I am not positive. I'm sure the method of getting at this information is
SSO (at least with Kerberos which is used by ActiveDirectoy) is based on a token. As soon as the user requests access to a kerberized system the system queries for the token and checks its validity for accessing the system. It's as good as querying for username and password. when the user did not log in with an Kerberos-account there is no tiket so no automated access.
using the token you can get the users login- name and from that you can then use that to query the SSO-backend (typically LDAP) for more information on that user.
LDAP is not an SSO-system as it is simply a storage query protocol but it is often used as backend for SSO-systems.
The problem often is kerberizing an application. for Webapps that means you have to kerberize the webserver so that that one then can handle the authentication process with the SSO-service and then pass that information on to the unferlying webapp.
Hope that answers you questions.
for more information have a look around the web for kerberos
You are really asking about two things:
Authentication: Who are you?
Authorization: What are you allowed to do?
Kerberos really only answers the first question, you need a secondary system like LDAP or Active Directory ( which is both kerberos and ldap in a single server) to answer the second.
If your system is using kerberos correctly, any user login should have an associated kerberos ticket. With this ticket, you can request "service" tickets
to prove your identity to remote servers that support kerberos. The ticket
contains your principal identity in the realm ( user#DOMAIN.NET ) that can be
used to query authorization systems.
However, the details required to get all the moving parts in that sentence working together "on the same page" so to speak can be very complex. The remote service has to support accepting kerberos credentials, it has to be either in the same realm or have a cross realm trust relationship configured.... The list
gets pretty long. Depending on your exact application environment, using all these things can be fairly trivial, or it can be next to impossible.
I have a web app that uses the Active Directory Membership Provider and when
a user changes their password, they can login with either the old password or
the new password for a while.
This KB article (http://support.microsoft.com/kb/906305/en-us) leads me to
believe that this behavior is caused by NTLM authentication.
Is there a way to configure the AD Membership Provider to only do Kerberos
Authentication and not NTLM?
NOTE: My app configures the provider with a minimum set of parameters, so every
configuration setting is set to its default.
It does not appear that you can change the method used. Its odd that both passwords would still work unless the credentials are being cached locally as if it were a disconnected machine (similar to what happens when you disconnect a machine from a domain and log into it). This doesnt sound like something the provider itself is doing, unless the provider is caching credentials. I didnt see anything for expiration of credentials which leads me to believe that it is not doing that.
Is sounds odd that they could log in with both passwords, I would expect one or the other to work, depending on GC replication lag between DCs or something along that lines.