If you're going to run something like this, I thoroughly recommend using Git for it.<p>You can have your cron do something like this:<p><pre><code> curl https://internal.corp/employees.txt > employees.txt
git add employees.txt
git commit -m "Automated: $(date -u)" || exit 0
</code></pre>
The || exit 0 should ensure no errors even if there is nothing to commit<p>Now you have a commit history of every change made to that source of information - just run "git log" to view it.<p>I run this kind of thing on scheduled GitHub Actions all the time, see <a href="https://simonwillison.net/2020/Oct/9/git-scraping/" rel="nofollow">https://simonwillison.net/2020/Oct/9/git-scraping/</a>
I made a tool to track ldap like that [0]. LDAP is a treasure chest of info and great for stalking. for some reason i find it fascinating to see people leaving, and if possible, see how long they worked there for. seeing friends get fired via LDAP before they even knew about it was certainly interesting, too.<p>I noted in the readme..<p><pre><code> Know what's going on in your LDAP directory on-demand with Slack webhook integration.
See new hires, leavers, and promotions as they appear in LDAP.
Monitor when and what HR is doing.
Detect unauthorized changes in LDAP.
Monitor for accidentally leaked data.
Detect when users are logging in and out of LDAP.
</code></pre>
There's also LDAPmonitor[1] which is designed for Microsoft and Active Directory which does effectively the same thing.<p>[0]<a href="https://github.com/MegaManSec/LDAP-Monitoring-Watchdog">https://github.com/MegaManSec/LDAP-Monitoring-Watchdog</a><p>[1]<a href="https://github.com/p0dalirius/LDAPmonitor">https://github.com/p0dalirius/LDAPmonitor</a>
Layoffs in the WFH era are weird. Back in the day you had a pretty good idea of who got laid off because you saw them walking out the door with a box of their stuff. You could go up to them and say, "hey let's meet at $local_watering_hole and hang out". You could swap contact info if you didn't already have it.<p>You could get closure.<p>Now, one day a bunch of people just stop replying to email. You have a to wait a while to figure out if they are actually gone or just busy. And if you're waiting on them for some output to work on <i>your</i> project, they may just never deliver and you won't know why for a while.<p>The company directory, if there is one, often still shows them for 60+ days because of the WARN act. And it seems most companies won't make a "layoff list".<p>It's really hard to get closure if they won't even tell you who got let go, and if they don't give the people a chance to say goodbye by cutting off their access before telling them they are laid off.
Love this bit:<p>"Incidentally, if someone gets mad about you running this sort of thing, you probably don't want to work there anyway. On the other hand, if you're able to build such tools without IT or similar getting "threatened" by it, then you might be somewhere that actually enjoys creating interesting and useful stuff. Treasure such places. They don't tend to last."
LDAP's full of secrets. It's a great way to keep tabs on what's going on in a company. And to think that you can get nearly all of it with anonymous access.<p>Team or department mergers before they were announced? Yep, I've caught those. Secret mailing lists for internal projects? Check who's a member and you can ferret out what's going on. Bonus if the list mail address gives some of it away.<p>`ldapsearch' is good if you know your way around LDAP. Apache LDAP Studio is a great UI tool if you just want to explore.<p>Everyone should know enough about LDAP to build a login service that binds against it for internal apps. You can exploit the groups the sys admins maintain to control permissions in your app. It's very powerful and an easy way to get up an running in no time.
It's amazing how many people came to the same idea independently. At my old gig I created "the sackinator" (getting sacked = getting fired). It was a cronjob that dumped the entire AD directory nightly and then a script to diff the output of any two days.<p>Since the data was dumped, you could always go back and do more analysis. First I just cared about which accounts got deactivated. Then I started tracking title changes, last name changes (people getting married), department sizes, company head count over time etc.<p>> Incidentally, if someone gets mad about you running this sort of thing, you probably don't want to work there anyway. On the other hand, if you're able to build such tools without IT or similar getting "threatened" by it, then you might be somewhere that actually enjoys creating interesting and useful stuff. Treasure such places. They don't tend to last.<p>Couldn't agree more.
Hahahahaha... So, I um have a very similar script that I manage for 'KTMJ' - it's not to find deactivated users, but to synchronize certain ldap attributes to another system. This organization is large enough (300k+ users) that typically, between the time that the script queries ldap, prepares the synchronization file, then actually performs the synchronization import which validates if each user still exists, there are already several hundred accounts that have been deactivated during that window and reported in an 'error' log file. (The actual synchronization and 'error' log file are outside of my direct control)<p>Why did I laugh maniacally?<p>Due to 'budget constraints' my contract is being terminated (they have just been through several rounds of layoffs, I was expecting this), my account will be one of the ones deactivated on the next monthly cycle - prior to that, I will have to handover the processing and expected 'deactivated' users 'error' logging behaviour to my replacements...
So negative! Where I work this tool is called “new-hires”. It uses a restricted read-only API key to our third-party people tool. It was given to me <i>by our People Director</i>. Sometimes there are lines beginning with - but the tool is named for the lines beginning with +.<p>new-hires is built on top of the “people” python module / cli in our monorepo. That tool is so much more useful than just a way of diffing the org chart. Who is in what team, where are they, are they working today, is it time to celebrate their anniversary, etc. It also follows what I coin the “ZFS litmus test” for good CLI tools by providing -pH for parseable, headerless output.<p>Treasure such places indeed.
I tried to make one of these systems at my first job, but my manager expressly forbade me after hearing about it.<p>Later that company would go on to lay off 15% of software engineers in a day. The support team created tickets in the public issue tracker to decommission employee accounts, so a lot of people found out that way before anyone reached out for a meeting.
"Treasure such places. They don't tend to last."<p>True true true. Especially if people are building quirky cool stuff in smaller orgs, its simultaneously a great place to work and has a higher extinction probability.
There was an automated tool like this someone built at Twitter. At first it was cool just to see who the most tenured people were. Then the layoffs happened and it became essential due to the absolute 0 communication happening thanks to the Cool New Management. I remember we used the count of people in one of the default Slack channels to keep track of how many people got the axe. Woof.
Is it common in the USA that employees just disappear without getting the chance to say goodbye to their colleagues? At most places I worked, people tended to send a goodbye email to everyone@company and got a chance to say personal goodbyes, even when there was a negative reason for them to leave.
At my last company they had no system for letting us know if someone had been let go. At one point they laid off the VP of sales and it came up almost by accident in an all-company meeting (not a massive company, <100 but >50) and people were surprised he had been let go.<p>I was young, with nothing to lose (or rather just no self-preservation), and so I spoke up that the policy of saying nothing was silly and potentially very dangerous. If that VP, who I saw around regularly, had emailed me for a list of our clients I would have sent it to him, if he had been waiting at a door telling me he had forgot his keycard I would have let him in, etc. You could argue "You should have always asked up the chain before doing that or refused to let him in on your keycard", but then I'd just shake my head at you. When a VP tells you to do something it's not a great career move to throw up roadblocks, even if it's company policy, in my experience.<p>Going forward the company agreed to send out bland, generic "X is no longer with the company" for "legal" reasons (as in they couldn't say "was fired", "left of their own accord", etc). Which was better for sure. I never thought to scrape our company directory, that's a clever way to do that for sure.
Back when I was at DigitalOcean they were laying off/firing people from the company but not announcing any departures. You'd just go to message someone and their Slack account was deactivated. This was over the course of several weeks. I built a Slack bot to post when accounts got deactivated and learned of some new departures well before those impacted actually did.<p><a href="https://github.com/eddiezane/no-ghosties">https://github.com/eddiezane/no-ghosties</a>
I worked at a company that had an internal website that showed all people, departments, teams, and had a filter you could use for new employees or employees that left. It was sort of a double edged sword: you had enough information to start asking questions about what it meant if a team member or coworker was on the list. What was more interesting is that it almost became ritual for some people to logon first thing in the morning and check the list, every morning.
A former company I was at was really weirdly tight-lipped about people leaving.<p>I'm sure totally unrelatedly, we got dinged a bunch on our SOC2 reports improper "off-boarding" and not removing access from terminated folks since no one knew to remove them.<p>Once we added quarterly SOC2 controls to make sure only employees had accounts it was always a shock to see who had to be removed.<p>I know the intent was to improve morale, but it had the opposite effect.
In Germany it's also a very good idea to monitor the "Handelsregister" (register of all companies) and see who currently is really the CEO, who can sign things etc. This shows early ripples in the force (e.g. founders on their way out, willfully or forced).
At one role our GitHub access was mediated by a CI job that would export users and groups from Google Workspaces and apply them to GitHub. The script would helpfully print a list of actions taken, and we had a general policy of CI logs being world-readable - and this job was no exception.<p>It was a useful way to keep tabs on any skulduggery that was going on.<p>Unrelated, but Confluence has very powerful support for email alerts on changes. These include notifications of deletions, and the email includes the diff of the deleted content. One thing I do at any org that uses confluence heavily is set up notification rules on some interesting spaces and check in from time to time.
There's a very common problem with systems that use SSO, where the 3rd parties that accept SSO logins cache the login information, sometimes indefinitely. A user can leave the company but their login placeholder account stays in the 3rd party, and active login sessions are maintained basically indefinitely. So you can leave the company and lose your AD account, but still access the 3rd party. As Rachel says it's kind of a hard problem to solve (but not that hard).
I once worked at a large bureaucratic org that tried to keep it secret when people left (if quit or were fired) because they thought departures were bad for morale. So it was just a big secret. Are they here any more, are they on PTO, are they out sick, who knows! Can't talk about it. It caused way more gossip and bad morale than it would have just to be straightforward letting us know that so and so was gone.
I'm not sure I get this.<p>If it's in my team/department, I'll know about it one way or another. If not ... Why would I care? People come and go, and if we're friends outside of work, we'll have other channels.<p>Besides that, most companies I worked at don't even maintain the LDAP/whatever properly. I've seen contacts from people that left/were fired stay around for years.
> Incidentally, if someone gets mad about you running this sort of thing, you probably don't want to work there anyway. On the other hand, if you're able to build such tools without IT or similar getting "threatened" by it, then you might be somewhere that actually enjoys creating interesting and useful stuff. Treasure such places. They don't tend to last.<p>too true
Epitaths is a Google thing. I had a friend at Qualcomm who wrote a script to sample the employee phonebook every morning before work so he'd know if he were laid off. We used "ph" from UIUC and the company strangely laid people off not by deleting them but instead by putting them into department 700, "The laid-off department".<p>The web UI allowed elaborate queries so the first time there was a big layoff the ph web page almost went down because everyone was querying to find out who was laid off. Management got mad at this but they really shouldn't have; its correct that you shouldn't work someplace that tries to hide attrition no matter what the source!<p>My friend never got put into dept 700 because i recruited him into Google a few years later ...
Speaking from the other side (the side that does the termination), as long as your IT team is actually good a simple ldap diff isn't going to be enough.<p>Why? Because a good termination process is sensitive to there needing to be a communication about a termination that can happen well after the actual process of eliminating their access and telling them it's their last day.<p>So a better termination process is something like:<p>1. Employee goes to a physical space (preferred) where they don't have their work equipment or talk to their manager and/or HR using something that isn't work controlled (phone call, etc.).<p>2. A manual or scripted process executes that forces sign outs of all work things (computer, slack, google, whatever). Credentials get reset and not disabled. Perhaps someone can try to look for password reset metadata or other things that might indicate a departure, but it's a lot harder than looking for disabled uids.<p>3. After the person leaves or has finished their conversation remotely, the team that works with this person gets a broader communication from someone to tell them about the departure. If the company is small enough, maybe there's a broader communication to more people.<p>4. The rest of the termination process gets fired off that does disable accounts, etc.<p>Why don't all IT departments do this? Well for a lot of reasons:<p>1. They don't care, don't have incentives, or haven't been told by HR, etc. to care about handling the termination process in a more sensitive way.<p>2. For any sufficiently complex company, the number of edges cases of systems where you can't force a logout or handle a password reset increase over time. It takes a lot of testing to make sure a process works because vendors have bugs all the time or unintended behavior.<p>3. The risk of poorly communicated terminations increase as the number of people that either perform or can troubleshoot the automated process to terminate increase. As others commented, you don't want some ticketing system that is readable by a wide amount of people to see termination requests, so now how do you communicate a termination without too many people knowing about it?<p>Strangely enough, I think trying to achieve the most sensitive but automated process is good because it forces the company to communicate and acknowledge a departure before the full termination process fires off, but maybe I'm in the minority.
Did this for a supermarket delivery company, they had an API that exposed their exact stock level for products, scraped the data every 30ish seconds, diffed and repeated :D
There were some interesting orders for sure (cigarettes + soap + 1 beer)
Ha, I did this about 10-15 years ago at a prior company. The turnover was so high (especially in the sales staff) that there would be at least a handful of people mysteriously disappearing each week.<p>I automated a small newsletter called "The Weekly Diff" for a few close trusted coworkers and sent it out each Friday with a list of who's new and who was missing from the company directory. And I kept a scraped database including phone numbers in case anyone wanted to reach out to anyone after they'd been removed.<p>Sometimes you make the best out of a failing company culture. Kept a lot of friends that way just by reaching out with some words of support :)
I’ve done this multiple times, and have two instances running right now which have been active for years. One is simple and watches a smaller org:<p>ldapsearch … > new; diff old new > updates; mail … < updates<p>(On phone, pseudo code, definitely wrong)<p>The other is perhaps more interesting. I built a tool for a tool for a population of specialists in a large company. The tool requires ldap data synced in, and I capture the diffs. That sampling approach provides surprising insights into what’s active/hot/declining, even when the total size of the company would making tracking every employee change quite difficult.
I wrote a script that is looking at the git log of a git repository, it tries to sum up how many commits per author/number of lines changed etc, when the author was active. This also gives some indication on the 'turnover rate' or whatever. (I know lines changed and number of commits is a very bad indication, but it is some indication)<p><a href="https://github.com/MoserMichael/gittools/blob/main/git-whoiswho.py">https://github.com/MoserMichael/gittools/blob/main/git-whois...</a>
I'm a WFH worker. My company is fully remote. They are really great at managing departures and make sure everyone's aware and has a chance to say goodbye.<p>However I can't shake this feeling that the mindset that got us from treating servers like pets to treating them like cattle is creeping into workforce planning, and the WFH movement is making it that much easier.<p>Why plan capacity when you can scale resources up and down on-demand on a whim? With the emotional and morale implications of letting people go hugely reduced it becomes easier to think like that.
> Incidentally, if someone gets mad about you running this sort of thing, you probably don't want to work there anyway.<p>Well that depends I guess. A lot of companies/orgs have privacy policies that prohibit accessing services out of "curiosity." I.e. if you're working at a university it's OK to access student information if you're doing it for a specific work-authorized purpose but you can't go casually looking at people's information just to satisfy some personal interest.
This is a very fun thing to do, unfortunately where I work (France), the HR team send out weekly/monthly emails with somes HR updates, and at the end the list of everyone who is hired (this includes conctractors), and everyone who leaves (resigned or fired), so it would not add any information to run LDAP searches and dumps/diffs.<p>It's always kinda stressful to open this email and find out if one colleague you liked has decided to leave, but most times, this colleague informed you before the email arrives.
I did this before. I ran a cron job once a day that counted the number of active entries in a particular file. It was neat to see the number bump up after an acquisition or drop after a layoff. It was neat to see the overall growth of the company I worked for.<p>I eventually decided that someone _might_ decide that, although freely available, in aggregate, this material could be _sensitive_. I stopped doing it. I deleted years of interesting data...
Scanning, dumping, and diffing of active directory also helps seeing when people got promoted. ("Software Engineer" -> "Software Engineer II" -> "Senior Software Engineer" etc). Useful for figuring out stats on "promotion velocity" in one org vs other.<p>Wouldn't work at "a certain company" if such company now made all their levels secret by default of course.
This is funny... I thought I was the only one who did this. I work in an org of over 1000 people and have found doing a programmatic dump of the org chart gives me insights I would never get from reading our status update. Often it is the only way I learn about colleagues who have left (and returned!) because not everyone sends goodbye messages or even has the opportunity to.
I was at a large company during the dot com bust. Someone added a world readable field (I assume by accident or because they didn’t realize we could all read it) to our LDAP called “Departure date”, which let you look up who was going to be laid off in the next few weeks. :/
When I was working on a small sized startup. We used to write “obituaries” for people who resigned in a newspaper format. We would add some insider jokes as a side article and some parody ads about their new company on the page if the person resigned already found a new company.<p>IIRC, it started from my resignation. Then we kept doing it for future leavers
> if you're able to build such tools without IT or similar getting "threatened" by it, then you might be somewhere that actually enjoys creating interesting and useful stuff. Treasure such places. They don't tend to last.<p>Advice I wish I'd been given before graduating, second only to "get everything in writing".
I made sth similar to monitor my github followers list. it's a simple script to use github api to get followers list & diff each day.<p><a href="https://github.com/tuananh/github-followers-watch/">https://github.com/tuananh/github-followers-watch/</a>
Adam Savage's recent video said large companies don't like to lay off big blocks of employees so they just do it in small batches over the year. They fire the last person who made any mistake.<p><a href="https://youtu.be/CzjftlUQs4g?t=403" rel="nofollow">https://youtu.be/CzjftlUQs4g?t=403</a>
I do this for various reasons at my work.<p>To function in day to day tasks you need to be able to read stuff in AD. I have solved interesting problems this way like: How do I get access to X thing when the security groups are not documented? Find someone with access and recurse their MemberOf and diff your own.<p>I also have used it to find people leaving.
There's data and there's also the behavioral / psychological stuff which is the bigger tell in my experience. Things like delivering half assed work despite having a good track record, and not caring about problems that need to be solved in the mid term.
I built this by accident once!<p>We had this internal web application. It had its own separate username/password table. I was asked to make it so you could login with your regular password instead.<p>It wasn't hard to solve the password part. I could make the web app consult the main system to verify your password at login. But... I couldn't eliminate the web app's user table entirely. It was too fundamental.<p>So I built a thing that ran periodically, got a list of users from both places, diffed the lists, and then did the required create/update/delete operations on the web app's user table. Thus the web app's user table mirrored the main login system.<p>I rolled this thing out and babysat it, keeping an eye on its log file. Naturally my code logged operations done on the user table. And I was like, "Hey, this is telling me who is joining and leaving the company!"<p>It even gave me a little additional info. The web app had certain roles and permissions, and these needed to correspond to organizational structure, which I got from the main login system. So if a user's web app roles changed, it was a clue they may have switched teams or got promoted.<p>I felt like I needed to be a bit careful with this info. Not that I wasn't allowed to have it, but I don't think IT expected anyone to have a tool that would make it that easy to notice changes as they happen. Potentially, I could have known someone was fired before their manager told them or something like that.<p>TLDR: Tried to streamline operations, accidentally developed a signals intelligence capability.
I once discovered that a very large org had AD configured in such a way that you could see “last seen at” timestamp for everyone profile in the company.<p>It would have been trivial to track everyone’s hours using this, which would likely have been unpopular.
Fun fact: back when I was a contractor for Apple many years ago (while Steve Jobs was CEO), I learned through their directory service that Steve Wozniack was still an employee and reported to then-CFO Peter Oppenheimer.
We used to use Sametime and I’d periodically search for “Deleted - “, which would show me everyone who was deleted over the past few months, before they fell out of the system.
For those wondering, by default, any user with an AAD account can query /all/ users via the MS graph API.<p>The trick showed in the article can easily be done on AAD as well.
Just be aware that your company will be logging this behavior and it will seem suspicious. They can make a good case for termination with this evidence.
I postulate that if your company uses LDAP, and you are here on HN, you're going to be laid off within the next 12 months. The existence of LDAP at a company implies that the company is likely highly um "mature" and isn't amenable to the kinds of hackers who have actual interest in the programming field.
Note that in Europe or UK downloading bulk employee lists would likely mean you are now handling 'personal data' and so various GDPR rules kick in
I find this super weird and almost borderline invasion of privacy?
I mean, a job is your professional life and you’re there to work, not go directly make friends or stalk people… I mean sure I’ve made a few people whom I’d call friends in previous jobs and current one too and I’d like to believe that we’d have enough confidence in the friendship to tell each other about quitting. But seeing that potential info about anyone feels very weird…
Not a WFH thing. This is a USA thing!!<p>Edit: OP said "Layoffs in the WFH era are weird"
Yes they are, but people here don't suddenly go offline quite as weird is what I was trying to get at.<p>Here in Sweden if you are FTE there is usually a 1-3 month layoff period (upppsägningstid) where you work and get paid still. At the end of the period you leave.<p>People usually email the team and even the entire company with "hey im leaving here is my info"<p>Now people CAN get fired day of, but that has to be VERY grounded.<p>Again, Not a WFH thing. This is a USA thing!! I notice this time and time again where people complain about IT or WFH, but it's just that you're in the USA, land of the exploited.