That seems like hard work compared to using the powershell cmdlets. If you had an ongoing integration that needed to do it, sure. Hit the REST api for a one-off? Hmm.
(googles ‘bulk create users in azure active directory’) https://blogs.msdn.microsoft.com/charles_sterling/2015/06/29/creating-users-in-an-azure-ad-in-bulk/ From: Greg Low (罗格雷格博士) Sent: Wednesday, 21 June 2017 4:44 PM To: ozDotNet Subject: Re: Azure Active Directory Hi Greg You make a call to get a token, then call the graph api to create users. https://msdn.microsoft.com/library/azure/ad/graph/api/users-operations#CreateUser Regards, Greg Dr Greg Low 1300SQLSQL (1300 775 775) office | +61 419201410 mobile│ +61 3 8676 4913 fax SQL Down Under | Web: www.sqldownunder.com From: ozdotnet-boun...@ozdotnet.com <ozdotnet-boun...@ozdotnet.com> on behalf of Greg Keogh <gfke...@gmail.com> Sent: Wednesday, June 21, 2017 5:12:25 PM To: ozDotNet Subject: Re: Azure Active Directory Chaps, I spent almost four hours this afternoon attempting to write some managed code that authenticated a user/password against Azure AD from a native app. I know you're not supposed to handle credentials like that, but it was an experiment for migration of the old database. I read hundreds of confusing and conflicting articles on the subject and they generally say it's possible, but I failed despite heroic and obtuse efforts. I presume it just doesn't work the way I think and I'm using the frameworks incorrectly. To be honest, I'm not even sure I had the AD environment setup correctly, so I might have been doubly wasting my time. Now I'm wondering how I would migrate hundreds of users from the legacy database into Azure AD. Anyone done that? GK On 21 June 2017 at 12:19, Greg Low (罗格雷格博士) <g...@greglow.com> wrote: AAD is a wonderful tool really. Keep in mind that it has a couple of flavours, B2C (business to consumer) being the latest. I’ve got clients who moved to it and simply love it. One is a car manufacturer who used to have to manage domains for dealers, etc. They used to spend their life with password and access issues. Now they just use 2 factor auth and cloud-based password reset, etc. and that’s all pretty much disappeared. It’s also worth thinking about the fact that AAD is what anyone using Office 365 will already be using anyway. And it can then be the directory for a big range of other things – Microsoft stuff like Power BI, Flow, Office 365, etc. but also others like DropBox, ZenDesk, etc, etc, etc. Regards, Greg Dr Greg Low 1300SQLSQL (1300 775 775) office | +61 419201410 mobile│ +61 3 8676 4913 fax SQL Down Under | Web: www.sqldownunder.com |http://greglow.me From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of Greg Keogh Sent: Wednesday, 21 June 2017 10:45 AM To: ozDotNet <ozdotnet@ozdotnet.com> Subject: Re: Azure Active Directory Yooiks! I'm not quite sure what I want (which is a worry). WAAD vs AADDS You say WAAD is more light-weight, which probably suits us, I think. Overall, as a coder, I want to put all authentication and permission/roles information for all of our apps and users in a single place where it can be maintained by admin staff, and it's easy to query from .NET code. Am I wrong to regard WAAD as some sort of "magic" database to where I can stuff all our vintage data? Perhaps I'm thinking like a reductionist and expecting a quick fix. If all you need to do is put WAAD authentication in front of a web app, then this is a piece of piss. Just deploy your app into App Server or App Service Environment and then turn on Azure AD auth. The App Service intercepts requests and does the SAML login for you transparently. The logged on user gets presented back to the app in a cookie. This is a good clue. I'll look into the details of doing this. GK
