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.
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?
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 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 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.
I have an application that runs on Windows Mobile 6 Professional PDA devices. The application is installed by browsing a url from the device and downloading a cab.
Users capture information in the application and this is then replicated back to a SQL 2005 server using merge replication and IIS v6.
Although the user needs to log into the application on the device anybody who knows the url could download and install. Also if you know a users password anyone with a device could update that users information.
I would somehow like to authenticate the devices either at the installation or replication stage (or both).
Is it possible to authenticate a device based on serial number or IMEI (mobile phone ID) number?
Is there a way to load a certificate onto the device so only certificated devices are allowed to connect?
I want a system that is not too hard to implement and support. The users must be able to update their own devices and they are not very good at remembering complicate procedures or password.
One possible solution would be to send the unique device id as part of authentication. There's a post on using GetDeviceUniqueID on the Windows Mobile Team Blog.
You could store this unique id when the user first connect to the server and verify it prior to each merge.
This approach helps to ensure that the user logging in is doing so from their own phone. It solves the problem of a remote intruder downloading your program to their own phone and logging into a legitimate users account. Of course, if such an intruder has access to your users phone AND password, all bets are off.
You have conflicting requirements:
The users must be able to update their
own devices and they are not very good
at remembering complicate procedures
or password.
and:
Also if you know a users password
anyone with a device could update that
users information.
If your users can only (barely) be expected to use a password, then you cannot expect to be able to protect in any case against anyone else who has their password.
There's no 'magic' authentication that will tell you a particular user or device is legitimate beyond what you provide.
You can password protect the download, you can load certificates, you can get the PDA information (and even the cellular information), but unless you add another authentication mechanism, at the end of the day all you've got is a password.
The password is your weakest link, and you seem to be indicating that you can't provide more strict access, but you somehow need it?
If you have another authentication channel (phone, email, SMS) then you can provide a more robust, meaningful authentication.
For instance, you could make your program operation dependent on a "public.key" file with a per-user public key that your server requires for use. Once the user logs in to your website, have them give you their phone number (so now you have the phone number and the password) and send an SMS with a link to a temporary download for the key. Make a new key for each user, keep their private key on the server, and encrypt (or at least authenticate) every transaction between the device and server using this key pair.
Now if someone else wants to pretend they are their user, they have to get that file in one of three ways:
They take it directly off the PDA (they also need the password, as the public key should be protected by the user password)
They get the user to request a new SMS link, and somehow get the link without having the phone
They change the phone number and request a new SMS link
In any case, you are validating not only the password, but also an associate phone number. You can make it hard for users to change the phone number (validate against their email as well when they request a phone number change, have them call in, etc).
Of course you can do the same with other channels of communication, but users are getting more and more used to SMS authentication and download, so it isn't too much more hassle.
-Adam
You could generate slightly different cab file for every download. The only difference would be security token your application would use as user/password analogue. That should be a public key for real security.
You could send them SMS with a code each time they access your application.