Learn more about these different git repos.
Other Git URLs
We want to give support to Active Directory for using Fleet Commander to deploy desktop profiles to Linux Clients under an AD domain.
On the Fleet Commander admin part we will be responsible of saving the profiles information to Active directory, but for the clients that consume that configuration we need SSSD to handle that stored information.
Due to the differences between FreeIPA and AD, in AD the information will be stored in a different way, so we need SSSD to be able to retrieve that information, and reusing the codebase we already have for fleet commander, generate needed information for fleet commander client.
After some discussion in #sssd channel at freenode and investigation in our part, we have agreed the best way to implement this is by using AD GPOs to store the information.
We have been testing the way AD handles GPO storage and it is basically compound of:
Our initial proposal is to do the following:
The GPOs are bound to different organizative units (users, groups, etc), so SSSD should be able to determine what GPOs would apply for the user logging in and retrieve the needed information.
On the other hand, the json file would give information that is needed for the fleet commander processing part. The first one is the profile priority, and the second one is the profile settings data. Right now, that information is saved into deskprofile objects in FreeIPA by using @abbra 's freeipa-desktop-profile plugin, but in AD we need to store it into the json file to avoid modifying schemas in AD.
The only implementation detail that is not really solved right now, is the global policy setting (The order the profiles will apply like users-groups-hosts-hostgroups) because we don't know if AD has any global storage to set a custom value like that, so while we figure out how to do that, we will assume the order is the default: Users-Groups-Hosts-Hostgroups.
At the moment, I'm filing the ticket into the Future Releases milestone. While having the ticket tracks the request, we currently don't have plans ourselves to implement this request -- of course, if this is something RHEL would like, then let's talk on the RHEL level about allocating people to implement this work.
Metadata Update from @jhrozek: - Issue set to the milestone: SSSD Future releases (no date set yet)
I agree @jhrozek , and I know this is something that right now is unplanned for development at SSSD side. As you said, the resources for developing this will be figured out and discussed later with involving RHEL and desktop team management into assign people to this.
The main goal of this issue is to discuss about the implementation of this feature in SSSD.
Right now I'm the only one assigned to this and I created this issue to know your oppinion about the ideas exposed here and if they would work in an SSSD feature implementation or just there is an easier/more efficent way to do that.
Metadata Update from @thalman: - Issue tagged with: Patch is welcome
Thank you for taking time to submit this request for SSSD. Unfortunately this issue was not given priority and the team lacks the capacity to work on it at this time.
Given that we are unable to fulfill this request I am closing the issue as wontfix.
If the issue still persist on recent SSSD you can request re-consideration of this decision by reopening this issue. Please provide additional technical details about its importance to you.
Thank you for understanding.
Metadata Update from @pbrezina: - Issue close_status updated to: wontfix - Issue status updated to: Closed (was: Open)
SSSD is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in SSSD's github repository.
This issue has been cloned to Github and is available here: - https://github.com/SSSD/sssd/issues/4558
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Login to comment on this ticket.