> On 10 Jul 2020, at 13:25, Jonathan Aquilina <[email protected]> wrote: > > Hi Will, > > I was actually thinking .net to be fair but not sure given .net core is only > available on linux what functionality we would have if written in .net and > what would be lost or missing.
Even if the POC is in .net, that can still go a long way to a rewrite in rust or similar for mainlining. But yes, the risk is that as a linux-centric project, we may not have access to .net core, and no one one the team has (?) much experience in .net :( But don't let that stop you, it's better to start somewhere Ithink in a task like this. > > Regards, > Jonathan > > > -----Original Message----- > From: William Brown <[email protected]> > Sent: Friday, 10 July 2020 05:19 > To: [email protected] > Subject: [389-users] Re: syncronizing users to 389ds from Azure AD > > > >> On 10 Jul 2020, at 13:11, Jonathan Aquilina <[email protected]> wrote: >> >> Hi Will, >> >> Thanks for the below. My next question for 389ds what language would this >> need to be developed in? > > Again, it depends. If the tool was external, today it's probably best to use > python and lib389. If it was a plugin in the server that would be C. However, > we are also starting to develop Rust support, and I personally am biased to > prefer Rust (especially it's tools for json like serde are excellent). > > If you were to do this in Rust as an external tool, the jump to making it a > part of the server core would also be easier too if we decided to rearchitect > and integrate it too. So my vote preference order is: > > 1 - Rust > 2 - Python (if external sync tool) > 3 - C (if external or internal) > > Of course, part of it's also what you're happy to work in too. > > Hope that helps, > >> >> Regards, >> Jonathan >> >> -----Original Message----- >> From: William Brown <[email protected]> >> Sent: Friday, 10 July 2020 05:01 >> To: [email protected] >> Subject: [389-users] Re: syncronizing users to 389ds from Azure AD >> >> >> >>> On 10 Jul 2020, at 11:57, Jonathan Aquilina <[email protected]> wrote: >>> >>> Hi William, >>> >>> This is something I would love to work with the community on and help to >>> develop myself just not sure where I would start. >> >> There are a few ways you could approach it. One way would be an external >> daemon that runs and feeds data into a seperate 389 topology. >> >> Another way would be a new "replication plugin" in the server so that 389 >> can consume data from azure AD. >> >> But both of them will need to read data from azure AD and know: >> >> * What have we seen before? >> * What's changed? >> * How to transform the azure ad entry to something 389 can understand. >> >> So I think the first place to start is knowing what API's azure AD has for >> external applications to synchronise data from azure AD. (Getting back into >> azure is another problem of it's own that can be for later). >> >> Maybe these two urls are a starting point. >> >> https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to- >> connect-sync-endpoint-api-v2 >> >> OR >> >> https://docs.microsoft.com/en-us/graph/api/resources/synchronization-o >> verview?view=graph-rest-beta >> >> So I think that's where to start. Then you could probably write a toy-demo >> application that can read from the sync api. Then you can build it out from >> there to push data to 389. >> >> Does that help? >> >> >> >> >> >>> >>> >>> -----Original Message----- >>> From: William Brown <[email protected]> >>> Sent: Friday, 10 July 2020 01:26 >>> To: [email protected] >>> Subject: [389-users] Re: syncronizing users to 389ds from Azure AD >>> >>> >>> >>>> On 10 Jul 2020, at 02:19, Jonathan Aquilina <[email protected]> >>>> wrote: >>>> >>>> Hi Guys, >>>> >>>> I am just wondering is it possible to sync users from Azure AD to a 389ds >>>> server? >>> >>> I don't know of anyone that has done it today, but that doesn't mean >>> it's not possible. It also depends what Azure AD offers for consuming >>> their data. So I think some work would be needed, but as a project, >>> we'd love to support you and advise in anyway we can if you want to >>> do this (but sadly like anything we don't have time to implement it >>> on your behalf today :( ) >>> >>>> >>>> Regards, >>>> Jonathan Aquilina >>>> EagleEyeT >>>> >>>> Phone: +356 2033 0099 >>>> Moblie + 356 7995 7942 >>>> Email: [email protected] >>>> Website: https://eagleeyet.net >>>> >>>> _______________________________________________ >>>> 389-users mailing list -- [email protected] To >>>> unsubscribe send an email to [email protected] >>>> Fedora Code of Conduct: >>>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ >>>> List Guidelines: >>>> https://fedoraproject.org/wiki/Mailing_list_guidelines >>>> List Archives: >>>> https://lists.fedoraproject.org/archives/list/[email protected] >>>> p >>>> r >>>> oject.org >>> >>> — >>> Sincerely, >>> >>> William Brown >>> >>> Senior Software Engineer, 389 Directory Server SUSE Labs >>> _______________________________________________ >>> 389-users mailing list -- [email protected] To >>> unsubscribe send an email to [email protected] >>> Fedora Code of Conduct: >>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ >>> List Guidelines: >>> https://fedoraproject.org/wiki/Mailing_list_guidelines >>> List Archives: >>> https://lists.fedoraproject.org/archives/list/[email protected] >>> r oject.org _______________________________________________ >>> 389-users mailing list -- [email protected] To >>> unsubscribe send an email to [email protected] >>> Fedora Code of Conduct: >>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ >>> List Guidelines: >>> https://fedoraproject.org/wiki/Mailing_list_guidelines >>> List Archives: >>> https://lists.fedoraproject.org/archives/list/[email protected] >>> r >>> oject.org >> >> — >> Sincerely, >> >> William Brown >> >> Senior Software Engineer, 389 Directory Server SUSE Labs >> _______________________________________________ >> 389-users mailing list -- [email protected] To >> unsubscribe send an email to [email protected] >> Fedora Code of Conduct: >> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ >> List Guidelines: >> https://fedoraproject.org/wiki/Mailing_list_guidelines >> List Archives: >> https://lists.fedoraproject.org/archives/list/[email protected] >> oject.org _______________________________________________ >> 389-users mailing list -- [email protected] To >> unsubscribe send an email to [email protected] >> Fedora Code of Conduct: >> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ >> List Guidelines: >> https://fedoraproject.org/wiki/Mailing_list_guidelines >> List Archives: >> https://lists.fedoraproject.org/archives/list/[email protected] >> oject.org > > — > Sincerely, > > William Brown > > Senior Software Engineer, 389 Directory Server SUSE Labs > _______________________________________________ > 389-users mailing list -- [email protected] To unsubscribe > send an email to [email protected] > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/[email protected] > _______________________________________________ > 389-users mailing list -- [email protected] > To unsubscribe send an email to [email protected] > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/[email protected] — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs _______________________________________________ 389-users mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/[email protected]
