I recently tried to work with WindowsPrincipal but I am getting really confused. I use this code snippet:
WindowsPrincipal principal = new WindowsPrincipal(WindowsIdentity.GetCurrent());
MessageBox.Show(Thread.CurrentPrincipal.IsInRole("MyDomain\\Users").ToString());
It returns True so it's OK. But I thought that this "IsInRole" check works against Active Directory. But when I unplug the network cable it still returns true. How come? Is there any easy way to check whether logged user is in specific domain against AD?
Active Directory credentials can be cached on the local system, including role membership (to support Group Policy enforcement). You can turn off the credential cache as described in the MSDN KB Cached Domain Logon Information, but I'm not sure that will clear the cache. While I cannot confirm (as I'm not currently on a system with cached credentials), I believe they are stored as hashes under the registry key HKEY_LOCAL_MACHINE\SECURITY\CACHE\ in values labeled "NLx" where x is an integer.
your code is fine, Windows is a bit smarter than what we think and is caching the user group membership even when you disconnect the network cable, in fact if you are in a AD domain you can also unplug the cable and still log-in because everything is cached locally.
If you want to check really how it works try to unplug the cable, check for another group membership while disconnected and it will be false, then add your user to another group on the server and this check will pass only after you connect your machine to the network again and do a log-off / log-in.
Related
For some strange reason, random computers and random users, appear ad users folders without even login at computers. This appens at random dates.
Please any one have idea? I have none script running for that.
Thank you
• Please check thoroughly whether any unauthorized application is running in the background or not, and if it is running, then kindly uninstall it as it may be an attempt to sneak into your domain environment and steal viable and important information. Also, as you are saying that random computers and random users AD shared folders are popping at the login screen without authenticating in the client system, it might be possible that your Domain Controller account has been compromised by a remote hacker and your organization’s data is at severe risk of misuse and leak.
• Also, check whether any inbound and outbound ports are continuously sending and receiving data through activity log in firewall and what type of communication is happening over those ports. Do an analysis of health status of your environment’s inbound and outbound gateway appliances for any breach or compromise of security policies and set of allowed defined rules. Ensure that your DC and any high privilege account credentials are not compromised and change all the passwords regarding them immediately.
• Scan all the systems thoroughly with licensed and updated Anti-virus software and check for any data leakages.
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!
I have configured the Multiplexer to use ActiveDirectory provider, and I have granted access to the groups (both in web.config and EPiServer on root level). But I can't log in either in Relate or in Edit/Admin mode. In the EventLog on the Domain Controller I can see that the user I tried to log in with have successfully logged on to the domain, but relate does not seems able to handle. If i write wrong username/password relate does give an error, but with correct credentials it says nothing. The same code (direct copy & paste, no modifications at all) works just fine on a CMS6R2 site.
After some tedious work I was able to get to the bottom of the problem. Apparently when using MultiPlexer with relate, I had to put privider1="ActiveDirectory(Role|Membership)Provider" and provider2="EPiServerCommon(Role|Membership)Provider", on all the places in web.config.
I've set up LDAP authentication using pam_ldap on a server and it seemed to be working just fine to begin with, but now I have a problem. Whenever a user changes his password in Active directory, it syncs just fine with LDAP and therefor every system that uses LDAP authentication, except this server which still accepts the old password.
I've tried "getent passwd" and it does list every user in LDAP, and I also tried adding a new user in LDAP, which my server immediately recognized when I try "getent passwd" again.
So apparently my server is commmunicating with LDAP, just not when it comes to new passwords, those the server chooses to cache somewhere.
Google hasn't been helpful at all and some people seem to have had similar problems but their questions always go unanswered.
Hope someone can help.
You may have nscd installed. Check /etc/nscd.conf and lower the TTL.
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.