Does someone can explain me how this is possible, since according to documentation, it should be impossible to be achieved.
I have two active directory domains that are independent:
Domain A, will be called STAFF-DOMAIN.local
Domain B, will be called ACADEMIC-DOMAIN.LOCAL
There is no Trust-Relationship between those domains at Active Directory Level.
At DNS Level, in STAFF-DOMAIN.local there is a manualy created copy of ACADEMIC-DOMAIN.LOCAL domain.
At DNS Level, in ACADEMIC-DOMAIN.local there is a manualy created copy of STAFF-DOMAIN.local
In my understanding, and by some info gathered, this configurations pre-dates me and is used this way to let keep requests of our resources from staff computers at network level locally instead doing all the trip outside->inside.
As their names indicates, STAFF-DOMAIN.local belongs to our company staff users an resources. ACADEMIC-DOMAIN.local belongs to students, teachers, and is used primarily to let them access to resources in the academic realm.
The issue:
I have one user from STAFF-DOMAIN that can RDP in this domain, because it belongs to a group defined that grants him access to that Domain. His credential is jack#staff-domain.local or STAFF-DOMAIN\jack.
In ACADEMIC-DOMAIN, he has the same username, but with the ACADEMIC-DOMAIN.local with a different password renewable every 90 days. Here his credential is jack#academic-domain.local or ACADEMIC-DOMAIN\jack.
Testing the configuration, using my own user in both domains (prime#STAFF-LOCAL.local, prime#ACADEMIC-DOMAIN.local), I can initiate an rdp connection and Log without problems, using my credentials in both domains independently. I can't however log with my user from STAFF-DOMAIN.local to ACADEMIC-DOMAIN.local, the ACADEMIC-DOMAIN.local server shows me the appropiate message. That's cool because I don't have permissions to do that in a different domain, because no Trust Relationships are defined.
When I do the same tests with user jack in both domains independently, he works fine. If I do an RDP on pdc.ACADEMIC-DOMAIN.local using STAFF-DOMAIN\jack it works and according to documentation should not work.
I've been reviewing every piece of configuration in both domains and as stated, there is no Trust Relationship between domains, no delegation, so I can't figure out why this is happening.
What I'm missing? May I be overlooking something here?
Related
We have an application where we store users login name in the format domain\username. We authenticate via windows and then get additional info from our database by matching the domain\username we get from the user to our database.
Now they want to move to the cloud. We authenticate users via apps in Azure AD. However, the user identifier we get back is first.last#domain.com.
I have fiddled around with https://graph.microsoft.com/v1.0/users/email and the select command to try and get the 'old' name. Howev,er I have not yet found out how to get it.
The reason they move to the cloud is that they are merging two ADs. So some users will be DomainA and some DomainB, but in the same tenant. So my first thought was to try and convert the mail to the other format. However, the two different ADs have different naming standards. One has DOMAINA\fila (two first letters from the first name and two first letters from the last name) and the other one has DOMAINB\firlas. Also it feels really ugly to try and solve it that way.
Is it possible to fetch the users loginname formatted as domain\username via Microsoft Graph?
Using the beta edition of Graph, you can obtain the user's domain and username from the onPremisesDomainName and onPremisesSamAccountName properties:
/beta/users?$select=userPrincipalName,onPremisesDomainName,onPremisesSamAccountName
The domain is stored as a FQDN so you'll need to do some translation. For example, domainName.ad.contoso.com might translate to domainName\).
This will give you a workaround so you can match up users with your internal databases. It is however only a temporary solution. Long-term, you really want to migrate to using the userPrincipalName. This is the primary user identifier and guaranteed to be unique within a given tenant.
Azure AD is a little different than the legacy Active Directory. Certain concepts from legacy AD such as Organizational Units (OUs), Group Policy Objects (GPOs), Kerberos Authentication, Lightweight Directory Access Protocol (LDAP), Domain trusts between multiple domains, and several others simply do not exist in the cloud.
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 read that if user logging on locally (with local user account) the domain GPO will not process. Is it true?
A GPO has a part for the computer and a part for the user that matches the scope in the security filtering of the GPO and is linked to the relevant OU. So if the computer is actually connected to the domain, it will apply all matching GPOs no matter what user is logged in, even for local users.
Hence, if the computer is part of the domain and the user is not (e.g. local user), the computer policies still will be applied and the user policies will not.
So if you want to not apply both policies, you need to use a local user AND remove the computer from the domain (e.g. via a local admin) and for example put it to a local workgroup instead.
The meaning of computer policies is just that: centrally administered settings for a specific machine that cannot be influenced by any user.
I know this is like 6 years old but for anyone else that ends up here, in my experience this is only true if loop back processing is enabled (computer > policies > system > group policy > Configure user Group Policy loopback processing mode > Enabled [merge])
per this post on reddit: https://www.reddit.com/r/sysadmin/comments/2f9tpf/question_does_signing_in_as_a_local_admin_bypass/ck7jvzx?utm_source=share&utm_medium=web2x
without loopback my computer GPOs do not apply. With it, my computer gpo applies even when local users log in
I have a Debian Squeeze system which is using libnss-ldap to bind to a 2008 Active Directory domain controller to look up users and groups. Everything works fine, except for some reason anyone who is in the Domain Admins, Enterprise Admins, or Schema Admins group does not get the correct group memberships. They get only the *Admin group, and no others (unless there are local groups that apply, which do show).
Stranger yet, a "getent group" shows all the correct group memberships for the user, but an "id " or "groups" (when running as the user) doesn't. We use a domain group for sudo access, and this user is unable to use sudo because it fails to see the group membership. As soon as the *Admin membership is removed, lookups work correctly.
I suspected maybe this was an AD security feature, but we have FreeBSD systems using nss-ldap on which these users' group memberships resolve correctly. There is nothing in the logs to indicate why these lookups don't return the normal results, and I haven't been able to find anything via Google to help shed light on the situation. Is anyone else using libnss-ldap in Debian to connect to an AD who can try to confirm this behavior?
Edit: I have confirmed using ldapsearch that the AD is returning the correct results. I also stopped nscd to make sure it wasn't interfering. Any user in Domain Admins sees only his primary group, local groups, and Domain Admins.
BTW, I think this is the issue:
http://support.microsoft.com/kb/976063
I have had this problem also.
I found it eventually about 18 months ago. It is a security feature of Microsoft. There is a service that runs once per hour and removes the admins from the LDAP search. If you do a query as anonymous, you will receive the correct answer for 1 hour. After one hour you will receive nothing. If you log in as a domain user, you will receive the correct information. That is why you get different results.
I do not at this point remember the service name but I am searching for it now. I found it originally on Microsoft tech net about 18 months ago, but by now, I don't remember it.
The point was that the only answer to it is
Disable that service and it does many other security items so that is not a good idea.
Change the LDAP searches to run under a domain user's log in (we have done that on some users)
Create a bogus duplicate contact with the same information for each of our admins. This is probably the easiest and quickest, but the most prone to developing wrong information over time.
The rational of this security feature is to hide all domain admins from random anonymous searches so their credentials can't be compromised by an encyclopedia password attack.
Calvin Thomas
My answer was deleted, but the problem was, in fact UAC as described in http://support.microsoft.com/kb/976063. The issue is that Domain Admins, when UAC is enabled on the DC, actually exist in two states. One that is a member of the domain admins group (i.e., the UAC 'shadow' user) and another that is the normal user. It appears that the DC only returns the former when queried with LDAP. By creating a new group, making that group a member of Domain Admins instead of the accounts themselves, and putting the accounts in the new group, the problem was resolved.
I can check user in active directory, if he exist then I give him permission to open app window, but what if an application has many levels of permission? Do I create special groups of permission in active direcotry and check if user belongs to one of them? . Can application log in automaticaly, or there is always need to enter password?
Active Directory can fulfill two related but seperate functions for an application: Authorization and Authentication.
Authentication is validating that the person using your application is a valid user. If you have the user's credentials (i.e. the application prompts the user for their username and password), you can authenticate them against AD by attempting a connection using their username/password.
Authorization is what lets you determine the level of permissions a particular user has in your application. Active Directory groups are a relatively straightforward and flexible way to implement the various permissions levels. Typically, I will create very fine-grained permissions groups that represent each securable action users can perform in the application (i.e. CanDeleteWidgets, CanAddWidgets, CanEditWidgets ). Then create functional or role groups where you place the users for that role (i.e. Managers, Coordinators, Technicians, etc). Finally, you just nest the role groups into the permissions groups so if, for example, the business requirement is that Managers can delete widgets, you would add the Managers group as a member of the CanDeleteWidgets group. While this may seem more complex, it makes it extremely simple to respond to changing business security requirements (i.e. "Technicians need to be able to delete widgets" - Piece of cake. Add the Technicians role group to the CanDeleteWidgets permissions group and you're done).
As far as logging in automatically, yes, there are a number of ways you can automatically log in a user. For winforms apps, you should just be able to grab the currently logged in user and use that. For web apps, if you can use integrated authentication, you end up with the same thing. Your web server will handle the authentication piece and send over the DOMAIN\USERNAME of the user in a server header variable.