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
Related
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?
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.
Customer has moved into Azure AD and needs clarification on two behaviors he is seeing in order to broadly roll out to organization and get off prem.
1- Right now , they have “keep me signed” in configured in Azure AD, however they have shared devices - iPad – in retail stores where they don’t want that behavior and want people to log in every time for websites. Is there a way to set a subgroup of users that keep me signed in will not apply to? Right now they only see a policy setting to configure it on or off for entire organization.
2- Customer turned on self-service password reset portal, how they only see option to configure what options they have to authenticate to be across whole org. Can they set up different options for different groups of users on what is needed to reset password and confirm identity - retail does q&a - business does authentication, etc.
Answer to Q1:
KMSI is controlled via the company branding, and is not on a per-user, but on a "per-language" (because you can have different branding for different locales). In that sense KMSI cannot be controlled on a per-user basis.
Answer to Q2:
SSPR has 3 states - None, Selected, All. When you choose Selected you can chose a single security group for which SSPR will be enabled. All other users will not have SSPR enabled.
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 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.