Re: syncronizing users to 389ds from Azure AD
by Jonathan Aquilina
Hi Will,
I actually just confirmed that you can create a console .net core app, as well as an asp.net core web app that you can use the .net core with or fully fledged .net framework. My question is now this 389ds is a web app or a console app?
Also how would one integrate this into 389ds as well as cockpit. Does 389 have an irc channel on a network somewhere?
Regards,
Jonathan
From: Jonathan Aquilina <jaquilina(a)eagleeyet.net>
Sent: 10 July 2020 06:23
To: General discussion list for the 389 Directory server project. <389-users(a)lists.fedoraproject.org>
Subject: [389-users] Re: syncronizing users to 389ds from Azure AD
Thanks for the words of encouragement Will 😊
What I need to confirm and if I am not mistaken Visual Studio 2019 actually allows you to create a .net core project to be fair so that might be perfect for compatability sake, but it means we would then need some wrapper of some sort to integrate into the existing codebase.
Regards,
Jonathan
-----Original Message-----
From: William Brown <wbrown(a)suse.de<mailto:wbrown@suse.de>>
Sent: 10 July 2020 06:19
To: 389-users(a)lists.fedoraproject.org<mailto:389-users@lists.fedoraproject.org>
Subject: [389-users] Re: syncronizing users to 389ds from Azure AD
> On 10 Jul 2020, at 13:25, Jonathan Aquilina <jaquilina(a)eagleeyet.net<mailto:jaquilina@eagleeyet.net>> 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 <wbrown(a)suse.de<mailto:wbrown@suse.de>>
> Sent: Friday, 10 July 2020 05:19
> To: 389-users(a)lists.fedoraproject.org<mailto:389-users@lists.fedoraproject.org>
> Subject: [389-users] Re: syncronizing users to 389ds from Azure AD
>
>
>
>> On 10 Jul 2020, at 13:11, Jonathan Aquilina <jaquilina(a)eagleeyet.net<mailto:jaquilina@eagleeyet.net>> 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 <wbrown(a)suse.de<mailto:wbrown@suse.de>>
>> Sent: Friday, 10 July 2020 05:01
>> To: 389-users(a)lists.fedoraproject.org<mailto:389-users@lists.fedoraproject.org>
>> Subject: [389-users] Re: syncronizing users to 389ds from Azure AD
>>
>>
>>
>>> On 10 Jul 2020, at 11:57, Jonathan Aquilina <jaquilina(a)eagleeyet.net<mailto:jaquilina@eagleeyet.net>> 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 <wbrown(a)suse.de<mailto:wbrown@suse.de>>
>>> Sent: Friday, 10 July 2020 01:26
>>> To: 389-users(a)lists.fedoraproject.org<mailto:389-users@lists.fedoraproject.org>
>>> Subject: [389-users] Re: syncronizing users to 389ds from Azure AD
>>>
>>>
>>>
>>>> On 10 Jul 2020, at 02:19, Jonathan Aquilina <jaquilina(a)eagleeyet.net<mailto:jaquilina@eagleeyet.net>> 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: sales(a)eagleeyet.net<mailto:sales@eagleeyet.net>
>>>> Website: https://eagleeyet.net
>>>>
>>>> _______________________________________________
>>>> 389-users mailing list -- 389-users(a)lists.fedoraproject.org<mailto:389-users@lists.fedoraproject.org> To
>>>> unsubscribe send an email to
>>>> 389-users-leave(a)lists.fedoraproject.org<mailto:389-users-leave@lists.fedoraproject.org>
>>>> 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/389-users@lists.fedor
>>>> a
>>>> p
>>>> r
>>>> oject.org
>>>
>>> —
>>> Sincerely,
>>>
>>> William Brown
>>>
>>> Senior Software Engineer, 389 Directory Server SUSE Labs
>>> _______________________________________________
>>> 389-users mailing list -- 389-users(a)lists.fedoraproject.org<mailto:389-users@lists.fedoraproject.org> To
>>> unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org<mailto:389-users-leave@lists.fedoraproject.org>
>>> 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/389-users@lists.fedora
>>> p r oject.org _______________________________________________
>>> 389-users mailing list -- 389-users(a)lists.fedoraproject.org<mailto:389-users@lists.fedoraproject.org> To
>>> unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org<mailto:389-users-leave@lists.fedoraproject.org>
>>> 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/389-users@lists.fedora
>>> p
>>> r
>>> oject.org
>>
>> —
>> Sincerely,
>>
>> William Brown
>>
>> Senior Software Engineer, 389 Directory Server SUSE Labs
>> _______________________________________________
>> 389-users mailing list -- 389-users(a)lists.fedoraproject.org<mailto:389-users@lists.fedoraproject.org> To
>> unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org<mailto:389-users-leave@lists.fedoraproject.org>
>> 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/389-users@lists.fedorap
>> r oject.org _______________________________________________
>> 389-users mailing list -- 389-users(a)lists.fedoraproject.org<mailto:389-users@lists.fedoraproject.org> To
>> unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org<mailto:389-users-leave@lists.fedoraproject.org>
>> 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/389-users@lists.fedorap
>> r
>> oject.org
>
> —
> Sincerely,
>
> William Brown
>
> Senior Software Engineer, 389 Directory Server SUSE Labs
> _______________________________________________
> 389-users mailing list -- 389-users(a)lists.fedoraproject.org<mailto:389-users@lists.fedoraproject.org> To
> unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org<mailto:389-users-leave@lists.fedoraproject.org>
> 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/389-users@lists.fedorapr
> oject.org _______________________________________________
> 389-users mailing list -- 389-users(a)lists.fedoraproject.org<mailto:389-users@lists.fedoraproject.org> To
> unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org<mailto:389-users-leave@lists.fedoraproject.org>
> 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/389-users@lists.fedorapr
> oject.org
—
Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server SUSE Labs _______________________________________________
389-users mailing list -- 389-users(a)lists.fedoraproject.org<mailto:389-users@lists.fedoraproject.org> To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org<mailto:389-users-leave@lists.fedoraproject.org>
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/389-users@lists.fedoraproje...
3 years, 9 months
Re: syncronizing users to 389ds from Azure AD
by William Brown
> On 10 Jul 2020, at 13:25, Jonathan Aquilina <jaquilina(a)eagleeyet.net> 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 <wbrown(a)suse.de>
> Sent: Friday, 10 July 2020 05:19
> To: 389-users(a)lists.fedoraproject.org
> Subject: [389-users] Re: syncronizing users to 389ds from Azure AD
>
>
>
>> On 10 Jul 2020, at 13:11, Jonathan Aquilina <jaquilina(a)eagleeyet.net> 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 <wbrown(a)suse.de>
>> Sent: Friday, 10 July 2020 05:01
>> To: 389-users(a)lists.fedoraproject.org
>> Subject: [389-users] Re: syncronizing users to 389ds from Azure AD
>>
>>
>>
>>> On 10 Jul 2020, at 11:57, Jonathan Aquilina <jaquilina(a)eagleeyet.net> 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 <wbrown(a)suse.de>
>>> Sent: Friday, 10 July 2020 01:26
>>> To: 389-users(a)lists.fedoraproject.org
>>> Subject: [389-users] Re: syncronizing users to 389ds from Azure AD
>>>
>>>
>>>
>>>> On 10 Jul 2020, at 02:19, Jonathan Aquilina <jaquilina(a)eagleeyet.net> 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: sales(a)eagleeyet.net
>>>> Website: https://eagleeyet.net
>>>>
>>>> _______________________________________________
>>>> 389-users mailing list -- 389-users(a)lists.fedoraproject.org To
>>>> unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
>>>> 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/389-users@lists.fedora
>>>> p
>>>> r
>>>> oject.org
>>>
>>> —
>>> Sincerely,
>>>
>>> William Brown
>>>
>>> Senior Software Engineer, 389 Directory Server SUSE Labs
>>> _______________________________________________
>>> 389-users mailing list -- 389-users(a)lists.fedoraproject.org To
>>> unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
>>> 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/389-users@lists.fedorap
>>> r oject.org _______________________________________________
>>> 389-users mailing list -- 389-users(a)lists.fedoraproject.org To
>>> unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
>>> 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/389-users@lists.fedorap
>>> r
>>> oject.org
>>
>> —
>> Sincerely,
>>
>> William Brown
>>
>> Senior Software Engineer, 389 Directory Server SUSE Labs
>> _______________________________________________
>> 389-users mailing list -- 389-users(a)lists.fedoraproject.org To
>> unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
>> 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/389-users@lists.fedorapr
>> oject.org _______________________________________________
>> 389-users mailing list -- 389-users(a)lists.fedoraproject.org To
>> unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
>> 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/389-users@lists.fedorapr
>> oject.org
>
> —
> Sincerely,
>
> William Brown
>
> Senior Software Engineer, 389 Directory Server SUSE Labs _______________________________________________
> 389-users mailing list -- 389-users(a)lists.fedoraproject.org To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
> 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/389-users@lists.fedoraproje...
> _______________________________________________
> 389-users mailing list -- 389-users(a)lists.fedoraproject.org
> To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
> 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/389-users@lists.fedoraproje...
—
Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server
SUSE Labs
3 years, 9 months
Re: syncronizing users to 389ds from Azure AD
by William Brown
> On 10 Jul 2020, at 13:11, Jonathan Aquilina <jaquilina(a)eagleeyet.net> 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 <wbrown(a)suse.de>
> Sent: Friday, 10 July 2020 05:01
> To: 389-users(a)lists.fedoraproject.org
> Subject: [389-users] Re: syncronizing users to 389ds from Azure AD
>
>
>
>> On 10 Jul 2020, at 11:57, Jonathan Aquilina <jaquilina(a)eagleeyet.net> 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-con...
>
> OR
>
> https://docs.microsoft.com/en-us/graph/api/resources/synchronization-over...
>
> 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 <wbrown(a)suse.de>
>> Sent: Friday, 10 July 2020 01:26
>> To: 389-users(a)lists.fedoraproject.org
>> Subject: [389-users] Re: syncronizing users to 389ds from Azure AD
>>
>>
>>
>>> On 10 Jul 2020, at 02:19, Jonathan Aquilina <jaquilina(a)eagleeyet.net> 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: sales(a)eagleeyet.net
>>> Website: https://eagleeyet.net
>>>
>>> _______________________________________________
>>> 389-users mailing list -- 389-users(a)lists.fedoraproject.org To
>>> unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
>>> 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/389-users@lists.fedorap
>>> r
>>> oject.org
>>
>> —
>> Sincerely,
>>
>> William Brown
>>
>> Senior Software Engineer, 389 Directory Server SUSE Labs
>> _______________________________________________
>> 389-users mailing list -- 389-users(a)lists.fedoraproject.org To
>> unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
>> 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/389-users@lists.fedorapr
>> oject.org _______________________________________________
>> 389-users mailing list -- 389-users(a)lists.fedoraproject.org To
>> unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
>> 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/389-users@lists.fedorapr
>> oject.org
>
> —
> Sincerely,
>
> William Brown
>
> Senior Software Engineer, 389 Directory Server SUSE Labs _______________________________________________
> 389-users mailing list -- 389-users(a)lists.fedoraproject.org To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
> 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/389-users@lists.fedoraproje...
> _______________________________________________
> 389-users mailing list -- 389-users(a)lists.fedoraproject.org
> To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
> 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/389-users@lists.fedoraproje...
—
Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server
SUSE Labs
3 years, 9 months
Re: syncronizing users to 389ds from Azure AD
by William Brown
> On 10 Jul 2020, at 11:57, Jonathan Aquilina <jaquilina(a)eagleeyet.net> 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-con...
OR
https://docs.microsoft.com/en-us/graph/api/resources/synchronization-over...
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 <wbrown(a)suse.de>
> Sent: Friday, 10 July 2020 01:26
> To: 389-users(a)lists.fedoraproject.org
> Subject: [389-users] Re: syncronizing users to 389ds from Azure AD
>
>
>
>> On 10 Jul 2020, at 02:19, Jonathan Aquilina <jaquilina(a)eagleeyet.net> 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: sales(a)eagleeyet.net
>> Website: https://eagleeyet.net
>>
>> _______________________________________________
>> 389-users mailing list -- 389-users(a)lists.fedoraproject.org To
>> unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
>> 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/389-users@lists.fedorapr
>> oject.org
>
> —
> Sincerely,
>
> William Brown
>
> Senior Software Engineer, 389 Directory Server SUSE Labs _______________________________________________
> 389-users mailing list -- 389-users(a)lists.fedoraproject.org To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
> 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/389-users@lists.fedoraproje...
> _______________________________________________
> 389-users mailing list -- 389-users(a)lists.fedoraproject.org
> To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
> 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/389-users@lists.fedoraproje...
—
Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server
SUSE Labs
3 years, 9 months
Re: syncronizing users to 389ds from Azure AD
by William Brown
> On 10 Jul 2020, at 02:19, Jonathan Aquilina <jaquilina(a)eagleeyet.net> 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: sales(a)eagleeyet.net
> Website: https://eagleeyet.net
>
> _______________________________________________
> 389-users mailing list -- 389-users(a)lists.fedoraproject.org
> To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
> 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/389-users@lists.fedoraproje...
—
Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server
SUSE Labs
3 years, 9 months
syncronizing users to 389ds from Azure AD
by Jonathan Aquilina
Hi Guys,
I am just wondering is it possible to sync users from Azure AD to a 389ds server?
Regards,
Jonathan Aquilina
EagleEyeT
Phone: +356 2033 0099
Moblie + 356 7995 7942
Email: sales(a)eagleeyet.net<mailto:sales@eagleeyet.net>
Website: https://eagleeyet.net
3 years, 9 months
Announcing 389 Directory Server 1.4.4.4
by Mark Reynolds
389 Directory Server 1.4.4.4
The 389 Directory Server team is proud to announce 389-ds-base version
1.4.4.4
Fedora packages are available on Rawhide (Fedora 33).
https://koji.fedoraproject.org/koji/taskinfo?taskID=46829414
<https://koji.fedoraproject.org/koji/taskinfo?taskID=46829414>
The new packages and versions are:
* 389-ds-base-1.4.4.4-1
Source tarballs are available for download at Download
389-ds-base Source
<https://releases.pagure.org/389-ds-base/389-ds-base-1.4.4.4.tar.bz2>
Highlights in 1.4.4.4
* Bug fixes
Installation and Upgrade
See Download <http://www.port389.org/docs/389ds/download.html> for
information about setting up your yum repositories.
To install the server use *dnf install 389-ds-base*
To install the Cockpit UI plugin use *dnf install cockpit-389-ds*
After rpm install completes, run *dscreate interactive*
For upgrades, simply install the package. There are no further
steps required.
There are no upgrade steps besides installing the new rpms
See Install_Guide
<http://www.port389.org/docs/389ds/howto/howto-install-389.html> for
more information about the initial installation and setup
See Source <http://www.port389.org/docs/389ds/development/source.html>
for information about source tarballs and SCM (git) access.
Feedback
We are very interested in your feedback!
Please provide feedback and comments to the 389-users mailing list:
https://lists.fedoraproject.org/admin/lists/389-users.lists.fedoraproject...
If you find a bug, or would like to see a new feature, file it in our
Pagure project: https://pagure.io/389-ds-base
* Bump version to 1.4.4.4
* Issue 51175 - resolve plugin name leaking
* Issue 51187 - UI - stop importing Cockpit’s PF css
* Issue 51192 - Add option to reject internal unindexed searches
* Issue 50840 - Fix test docstrings metadata-1
* Issue 50840 - Fix test docstrings metadata
* Issue 50980 - fix foo_filter_rewrite
* Issue 51165 - add more logconv stats for the new access log keywords
* Issue 50928 - Unable to create a suffix with countryName either via
dscreate or the admin console
* Issue 51188 - db2ldif crashes when LDIF file can’t be accessed
* Issue 50545 - Port remaining legacy tools to new python CLI
* Issue 51165 - add new access log keywords for wtime and optime
* Issue 49761 - Fix CI test suite issues ( Port remaning acceptance
test suit part 1)
* Issue 51070 - Port Import TET module to python3 part2
* Issue 51142 - Port manage Entry TET suit to python 3 part 1
* Issue 50860 - Port Password Policy test cases from TET to python3 final
* Issue 50696 - Fix Allowed and Denied Ciphers lists - WebUI
* Issue 51169 - UI - attr uniqueness - selecting empty subtree
crashes cockpit
* Issue 49256 - log warning when thread number is very different from
autotuned value
* Issue 51157 - Reindex task may create abandoned index file
* Issue 50873 - Fix issues with healthcheck tool
* Issue 50860 - Port Password Policy test cases from TET to python3 part2
* Issue 51166 - Log an error when a search is fully unindexed
* Issue 50544 - OpenLDAP syncrepl compatability
* Issue 51161 - fix SLE15.2 install issps
* Issue 49999 - rpm.mk build-cockpit should clean cockpit_dist first
* Issue 51144 - dsctl fails with instance names that contain slapd-
* Issue 51155 - Fix OID for sambaConfig objectclass
* Issue 51159 - dsidm ou delete fails
* Issue 50984 - Memory leaks in disk monitoring
* Issue 51131 - improve mutex alloc in conntable
* Issue 49761 - Fix CI tests
* Issue 49859 - A distinguished value can be missing in an entry
* Issue 50791 - Healthcheck should look for notes=A/F in access log
* Issue 51072 - Set the default minimum worker threads
* Issue 51140 - missing ifdef
* Issue 50912 - pwdReset can be modified by a user
* Issue 50781 - Make building cockpit plugin optional
* Issue 51100 - Correct numSubordinates value for cn=monitor
* Issue 51136 - dsctl and dsidm do not errors correctly when using JSON
* Issue 137 - fix compiler warning
* Issue 50781 - Make building cockpit plugin optional
* Issue 51132 - Winsync setting winSyncWindowsFilter not working
as expected
* Issue 51034 - labeledURIObject
* Issue 50545 - Port remaining legacy tools to new python CLI
* Issue 50889 - Extract pem files into a private namespace
* Issue 137 - Implement EntryUUID plugin
* Issue 51072 - improve autotune defaults
* Issue 51115 - enable samba3.ldif by default
* Issue 51118 - UI - improve modal validation when creating an instance
* Issue 50746 - Add option to healthcheck to list all the lint reports
--
389 Directory Server Development Team
3 years, 9 months
dbchangelog Question
by Ghiurea, Isabella
Morning Gurus
I am running multimaster replication with 389-ds-base-1.3.7.5-24.el7_5.x86_64, I will like to know if I can update dbchange log path while DS is online accepting transactions without
any implication for replication?
Thank you
Isabella
3 years, 9 months
