I have a big problem that I need some help, please.
I have a Windows domain with AD and it has 10 DC in different networks. I have one specific user that after he changed it's password he is getting locked out (password expiration due date).
Looking at the logs I found 2 machines he was "disconnected" in the RDP and I logged him out from there. Logs were saying explicitly the machine name so it was easy and the domain controller for that region let's call DC4. I just logged him out and not more logs saying about those 2 machines.
But he is still getting locked out in the DC5 and the logs say just the computer name of the domain controller and of course he is not logged in there.
We have many integrations with others applications, using LDAP protocol to authenticate users, etc... we basically use the AD users/groups for everything.
I tried using wireshark to see some logs but wasn't lucky, maybe I just used a bad filter search, but for some integrations I have LDAPS...
We reverted his password back to the one before all of this started and he is fine of course, but we need to figure this out.
So, is there another way to check the real source of blocking an account?
In the Windows Logs I was looking for event ID 4740 and 4771. For the DC4 it has only the 4740 what just says the DC4 itself. I asked him to check for any script or something he has using his account but he said nothing he remembers.
Any recommendation you guys have?
A user account was locked out.
Subject:
Security ID: SYSTEM
Account Name: DC4$
Account Domain: DOMAIN
Logon ID: 0x3E7
Account That Was Locked Out:
Security ID: DOMAIN\user_here
Account Name: user_here
Additional Information:
Caller Computer Name: DC4
Thanks!
Someone from MS forum was able to help me (I posted there as well, just in case). The answer/help that solved for me was looking at the 4625 event ID!
So please, use at least these 3 - 4740, 4771 and 4625.
Related
I have tried multiple times to get this to work, but I haven't figured it out yet, so I'm asking in here, hoping that someone will be able to help me out.
I am using Atlassian's Bitbucket, Jira and Bamboo and they're all synced with an AD. At the moment I am using my AD user to retrieve all the other users. It works, but it's not optimal, as the password expires every three months, and I have to change the LDAP user login info on all three applications. We have ordered a Service User, where the password doesn't expire, but the problem is that the Service User is in another group.
The picture below shows how the AD is set up. My Service User is in a group called Special Users. I would like to use this user as the login user in the settings. This way I would never have to think about changing password, when my AD password expires.
I would then like to retrieve all the users from the "Normal Users" group.
Let me know if more information is needed.
Thanks.
You could also add multiple user directories pointing to different parts of your Active Directory.
Jira has an internal Crowd out of the box.
You may let Jira connect to User directory and let all other application use Jira for authintication.
This would save time by only updating your LDAP password every 3 months on 1 application and reflected on all 3 applications
I am new to Salesforce, but am an experienced developer. I am provided a link to a Salesforce report, which mostly has the right filters (query). I would like to use an REST API to pull that information as CSV or JSON so that I can do further processing on it.
Here are my questions:
Do I need special permissions to make API calls? What are they?
Do I need to create an "app" with client-key & secret? Does my admin need to grant me permission for this too?
There are a lot of REST APIs from Salesforce, which one do I need to get the info from the report? Analytics?
How do I authenticate in code?
You'd have to work with the System Administrator on the security pieces. Anybody who knows how the company works, can all users see everything, is there Single Sign-On in place, how likely is the report to change...
You will need an user account to pull the data. You need to decide if it'll be some "system account" (you know username and password and have them stored in your app) or can it run for any user in this org. It might not matter much but reports are "fun". If there will be data visibility issues 6 months from now, you'll be asked to make sure the report shows only French data to French users etc... you can make it in report filters or have multiple reports - or you can just use current users access and then it's the sysadmin that has to set the sharing rules right. (would you ever think about packaging what you did and reusing in another SF instance? Making a mobile app out of it? Things like that, they may sound stupid now but will help you decide on best path)
The user (whether it'll be system account or human) needs Profile permissions like "API Enabled" + whatever else you'd need normally ("Run Reports" etc). If you're leaning towards doing it with system user - you might want to look at Password Policies and maybe set password to Never Expires. Now this is bit dangerous so there would be other things you might want to read up about: "API only user" (can't login to website), maybe even locking down the account so it can login only from certain IP ranges or at certain times when the job's supposed to be scheduled...
Connected App and OAUth2 stuff - it's a good idea to create one, yes. Technically you don't have to, you could use SOAP API to call login, get session id... But it's bit weak, OAuth2 would give you more control over security. If you have sandboxes - there's little-known trick. You can make connected app in production (or even totally unrelated Developer Edition) and use client id & secret from it to login to sandboxes. If you create app in sandbox and you refresh it - keys stop working.
(back to security piece - in connected app you can let any user allow/deny access or sysadmin would allow only say these 3 users to connect, "pre-authorize". Could be handy)
Login - there are few REST API ways to login. Depends on your decision. if you have 1 dedicated user you'll probably go with "web server flow". I've added example https://stackoverflow.com/a/56034159/313628 if you don't have a ready SF connection library in your programming language.
If you'll let users login with their own credentials there will be typical OAuth "dance" of going to the target page (Google login, LinkedIn, Twitter...) and back to your app on success. This even works if client has Single Sign-On enabled. Or you could let people type in their username and pass into your app but that's not a great solution.
Pull the actual report already
Once you have session id. Official way would be to use Reporting API, for example https://developer.salesforce.com/docs/atlas.en-us.api_analytics.meta/api_analytics/sforce_analytics_rest_api_get_reportdata.htm
A quick & dirty and officially not supported thing is to mimic what happens when user clicks the report export in UI. Craft a GET request with right cookie and you're golden. See https://stackoverflow.com/a/57745683/313628. No idea if this will work if you went with dedicated account and "API access only" permission.
I have a Asp.net MVC application that uses Azure AD and OpenID Connect OWIN middlewares to handle authentication. Everything works fine except for one thing : if a user is already logged-in on another Microsoft Application lets say a Office 365 account or maybe a live mail account, when trying to login it recives a page saying that it is not allowed to log into my app, which is correct, but some how I need to catch that situation in my code to allow the user to sign in with a different account. Is there a way of doing that? This is by design? I mean : the user have to log in only with a live/azure account at the time ? I couldn't find any documentation about this.
As of today there is typically one user at a time, but we will soon support for you a way to select a specific user instead of automatically signing you in with the most recent one.
One way you can work around this today is by injecting the parameter "prompt=login" in your sign in requests. You can do that in the RedirectToIdentityProvider notifications, similarly to what is showin in http://www.cloudidentity.com/blog/2014/11/17/skipping-the-home-realm-discovery-page-in-azure-ad/ for domain_hint. This will cause the sign in experience to always start with a fresh prompt even if the user is already signed in. The draw back is that you'll never get SSO this way. Hopefully our account switiching feature will become available soon, keep an eye on http://blogs.technet.com/b/ad/ for announcements
I am currently working on a AD installation where there are about 45,000 accounts and about 60+ global catalogue servers, some accounts are active some are disabled. Some active accounts are service account which don't appear to login as the lastlogondate is several months old.
If I disable some of the service accounts which do not login the application stops working so I know the application is authenticating to AD somehow.
My question is how can I determine which account have been used to authenticate but have not actually 'logged in'? Is there an attribute I can query or can I set it somehow that AD writes to the event log?
Simply speaking, lastLogonTimestamp is the right attribute to find inactive accounts.
See following link for descriptions on different related attributes:
http://social.technet.microsoft.com/wiki/contents/articles/22461.understanding-the-ad-account-attributes-lastlogon-lastlogontimestamp-and-lastlogondate.aspx
Just copied from above link, using PowerShell, you can get inactive users (inactive for AROUND 90 days, note lastLogonTimestamp is only an approx value) by calling:
Search-ADAccount -AccountInactive -DateTime ((get-date).adddays(-90)) -UsersOnly
For the last logon time from Hyena, I suspect it is inaccurate.
(I never use Hyena before, so just a guess.)
From the following link:
http://www.systemtools.com/HyenaHelp/index.htm#userlogoninfo.htm
Seems by default it only get the last logon info from one DC only. If they get this info from lastLogon attribute instead of lastLogonTimestamp (very likely, otherwise the "Check All Domain Controllers" option is meaningless), it will only get the logon time on this specific DC only. So if those service account are always using DC1 in recent authentications but you connect to DC2 to get the logon time, you will only get a very old time (or none if it never use DC2 to authenticate).
I don't know what function or technique you are using in Hyena to get the 'last logon' information, but as indicated by others, the AD attribute 'lastlogontimestamp' will get you a fairly accurate date/time (~within 10-day accuracy) of the last use of an account. This attribute can be added to any query in Hyena for all of your users. You can also export out the service information on all computers and servers, to see what accounts are being used.
If you need additional assistance, contact SystemTools Support - support#systemtools.com
We are always ready to support our customers.
(I am with SystemTools (Hyena) support)
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.