5 ms·
Addict: An Active Directory REST API
- chunkyslink 9y agoI'm sorry but can someone explain to me how this might benefit my company? We have 20 employees and use Microsoft Office 365.
- pjc50 9y agoDo you want to write a webapp to manipulate AD? Otherwise this probably isn't of any use to you.
- nthcolumn 9y agoScenario #1: You have a small, team, busy people and have some process or workflow that would be greatly streamlined by a simple one-page app let's call it 'todo' which needs to integrate with email and provide single sign-on for ease of use. Your awesome dev Steph who dreams REST hand-pours with love your artisanal todo-365 app this weekend and everyone is using it next week and saving heaps of time because y'know there are only twenty of you... yet. FTW! Scenarios #2: Ugh okay, Alex is the devops, sysadmin, security officer, fire-warden and makes great bullet-coffee but even with twenty there are lot of domain groups to manage with your startup and lots of projects depending on them so Alex just needs a python script for his Ansible playbook and because powershell makes Alex want to throw up.
- toyg 9y agoDoesn't look to me like this can work with web-based AD, so it's probably useless unless you have an actual domain controller on-premises. For the record, web-based 365 ADs (and most modern on-prem) already support webservices, just soap (and somewhat painful) rather than rest. I use it to authenticate from an app outside our network, the implementation wasn't that hard (python) but i really only do auth, no manipulation. It would be cool if MS added REST as an option to make this sort of common case easier, but they are too busy selling you complex integrated services to do that in Azure ("use Visual Studio, next next next, your app is now deployed on Azure and completely integrated with all these management tools. Cool, uh? Now give me lots of money every month or turn it off.")
- nthcolumn 9y agoYes. 365 is cloud AD. My bad. Not familiar with it. Are there no endpoints?
- arethuza 9y agoAzure Active Directory has a pretty comprehensive REST & JSON API - the Azure Active Directory Graph API: https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-graph-api https://docs.microsoft.com/en-us/azure/active-directory/deve...
- dpim 9y agoIt's recommended to access AAD through the Microsoft Graph API (as opposed to the AAD Graph API) unless it is one of the few scenarios not yet supported on Microsoft Graph. There is a lot of investment in adding new functionality to Microsoft Graph (such as the ability to extend AAD entities with custom, persisted properties on the /beta/ endpoint) and tooling. You can try/prototype out a bunch of your AAD requests in the Graph Explorer without writing code/needing to authenticate for most calls: https://developer.microsoft.com/en-us/graph/graph-explorer https://developer.microsoft.com/en-us/graph/graph-explorer
- arethuza 9y agoAh yes - well spotted. I actually did mean the main Microsoft API rather than the specific AAD one....
- sjark 9y agoAzure AD (Office 365) already has a REST API (https://developer.microsoft.com/en-us/graph/ https://developer.microsoft.com/en-us/graph/) so this is really for on-prem Active Directories. On-prem Active Directory also has AD Web Services (https://technet.microsoft.com/en-us/library/dd391908(v=ws.10).aspx https://technet.microsoft.com/en-us/library/dd391908(v=ws.10...) that I guess you could use instead of this, but a simple rest api like this will be easier to integrate with.
- KaiserPro 9y agoIf your AD doesn't have a saml endpoint, and you down want to talk directly to AD, this is _a_ way. However it doesn't allow kerberos, or 2fa, so its not _all_ that useful in an enterprise setting.
- dboreham 9y agoIn case anyone is wondering this is a Node application that implements HTTP->LDAP gateway with JSON response/entry encoding and REST-like request encoding. It would work with other LDAP servers (modulo the use of the paged results control which not all servers support). The hard work is done in this package : https://github.com/dthree/ad https://github.com/dthree/ad and this one: https://github.com/mcavage/node-ldapjs https://github.com/mcavage/node-ldapjs
- deleted 9y ago[deleted]
- juststeve 9y agowhat problem does this solve?
- justinjlynn 9y agoTo be honest, if you have to ask it's probably not one you're having. Things like this tend to be quite application specific. Generally, if you're doing much with AD directly, you'd be doing it via LDAP. However, if you need to talk to it (for some reason) through a web application -- this just might be helpful.
- larvaetron 9y agoThe problem of not having an Active Directory REST API.
- tyingq 9y agoThere are other ways to do it, but if you wanted, for example, to build a tool for employee on-boarding/off-boarding as web app, this might be helpful. Or maybe adding password change to an existing web app that authenticates via AD. There are existing REST apis for AD, so I don't know what this brings that's new.
- 5706906c06c 9y agoI have a bunch of engineers that can presumably automate the provisioning and de-provisioning of the LDAP user accounts without having to mess around with the AD. I hire a consultant (think MSP) to set up and maintain the LDAP hosts and have my engineers write the necessary scripts to perform the aforementioned. This is beneficial for security automation, especially, in the cases where a company is too small to afford a dedicated IT SMEs but large enough to be able to afford something like SSAE-18 SOC 2 Type 2 (or equivalent). In those cases, the security automation in itself presents a repeatable process, which can be verified given the scripts would be executed using a job (Jenkins). This project fits that mold perfectly because that I have dealt with the exact scenario nth times with many start-ups operating in the B2B world with security stipulations such as ISO 27xxx or SOC 2 Type 2.
- brentjanderson 9y agoFor those asking what problem this solves - it solves my problem. We have scripts for automating onboarding/terminations, services that authenticate with AD that don’t support SSO yet, etc. This fills a niche we definitely have.
- dc2 9y agoWell that's good. I built it to fill my niche and hoping others would find use for it as well.
- jaredmcdonald 9y agoi'm sure this is a very useful product, and i understand that "addict" contains the letters "AD", but naming something "addict" while half the US drowns in opioids seems a little weird
- tyingq 9y agoI suspect the down votes are because the word has already been co-opted for years to describe things that aren't issues. Similar for "viral", "infectious", "jonesing", "getting my cookie fix" and so on.
- sergiotapia 9y agoNo need for self-righteous indignity here dude. Keep that on Tumblr.
- thepaulstella 9y agoGross. Be a better human.
- 7ewis 9y agoWanted to make a chatbot a while ago to allow the support guys to unlock AD accounts from our chat system. This sounds like it could be useful! Could someone explain to me where addict would be installed? Not too familiar with the Windows side of things. Does it need to be installed on a DC or, just any machine that can reach AD?
- yellowapple 9y agoMy impression is that it can be installed on any machine (even your own workstation) so long as it can reach your DC.
- danellis 9y agoIf you're listing a bunch of URL patterns and you're not describing your media types, you almost certainly don't have a REST API, so why even call it that? It's an HTTP API. What do you have against calling it that?
- zerkten 9y agoMany people making "REST" APIs don't even know what media types are which means many REST APIs are impure. That doesn't mean that the author won't add these based on feedback, or that they they have something in particular against describing it as an HTTP API. In many cases people searching for a REST API to access AD probably won't care about this particular nuance.
- metmac 9y agoI think its funny how AD is this mystery box to engineers who live outside the IT space. This is potentially super useful for folks to build sweet integrations between AD and modern web applications (i.e: Chat, Ticketing, SAML, SCIM, etc) into a very industry standard Directory Service while abstracting away the Microsoft garb, and not having to worry about the LDAP translations with AD. (AD is LDAP compliant, but there are weird nuances.) As someone who has to live in both worlds, this is super cool start and definitely welcomed. @DC2 well done sir.