We have many users that run GNU/Linux workstations. At the moment everyone is using local accounts. We want to convert them to IPA clients and still allow them sudo privileges on their own workstations.
It's easy to grant them access to their workstations by making them all a member of a "workstation" AD group and letting them login with ssh, GNOME, etc. What's less obvious is how to centrally give them sudo access only on their own workstations.
I could create an HBAC rule per person to give them sudo privileges to their own workstation, but then I'll have to make hundreds of rules. The only solution appears to be to keep the access (i.e. ssh, desktop environment) centrally controlled in IPA, but make the custom sudo access locally controlled. Is this the only way to do what I want?
Thanks in advance.
On Mon, Dec 19, 2022 at 03:32:33PM -0500, Ranbir via FreeIPA-users wrote:
We have many users that run GNU/Linux workstations. At the moment everyone is using local accounts. We want to convert them to IPA clients and still allow them sudo privileges on their own workstations.
It's easy to grant them access to their workstations by making them all a member of a "workstation" AD group and letting them login with ssh, GNOME, etc. What's less obvious is how to centrally give them sudo access only on their own workstations.
I could create an HBAC rule per person to give them sudo privileges to their own workstation, but then I'll have to make hundreds of rules. The only solution appears to be to keep the access (i.e. ssh, desktop environment) centrally controlled in IPA, but make the custom sudo access locally controlled. Is this the only way to do what I want?
Hi Ranbir,
I think you can use a single HBAC rule to allow all users to execute sudo on their workstations. But then you would need a distinct sudorule for each user/workstation pair to allow them full permissions on that machine.
I don't see a way around it. But I could be overlooking something.
It would be nice if you could associate workstations (hosts) to users directly, then automatically generate/infer HBAC and sudo rules (subject to domain-wide policy settings). Is it a known RFE?
Thanks, Fraser
On Tue, 2022-12-20 at 13:08 +1000, Fraser Tweedale via FreeIPA-users wrote:
I don't see a way around it. But I could be overlooking something.
That's exactly what I was thinking.
It would be nice if you could associate workstations (hosts) to users directly, then automatically generate/infer HBAC and sudo rules (subject to domain-wide policy settings). Is it a known RFE?
I haven't searched. Should I create one and if so, where?
Either on the host page or for the user where you could select the user or workstation accordingly to auto create a sudo rule to give the user admin privilege. I don't think we'd need to see the workstation sudo rule in the web interface (since it could be a massive list). Just the switch for it whatever to show that it's enabled would be enough.
For now, we'll have to use a combination of an HBAC rule and a local sudo rule or create individual sudo rules per user/workstation.
On ti, 20 joulu 2022, Ranbir via FreeIPA-users wrote:
On Tue, 2022-12-20 at 13:08 +1000, Fraser Tweedale via FreeIPA-users wrote:
I don't see a way around it. But I could be overlooking something.
That's exactly what I was thinking.
It would be nice if you could associate workstations (hosts) to users directly, then automatically generate/infer HBAC and sudo rules (subject to domain-wide policy settings). Is it a known RFE?
I haven't searched. Should I create one and if so, where?
FreeIPA does not provide generation capabilities in itself. These things are specific to individual deployments and their logic is impossible to automate in a generic way without exposing some kind of a general purpose language to express it. So we aren't going to implement this when all you can do is to use ansible-freeipa to define your logic and actions already.
Either on the host page or for the user where you could select the user or workstation accordingly to auto create a sudo rule to give the user admin privilege. I don't think we'd need to see the workstation sudo rule in the web interface (since it could be a massive list). Just the switch for it whatever to show that it's enabled would be enough.
For now, we'll have to use a combination of an HBAC rule and a local sudo rule or create individual sudo rules per user/workstation.
On Tue, 2022-12-20 at 08:22 +0200, Alexander Bokovoy via FreeIPA-users wrote:
FreeIPA does not provide generation capabilities in itself. These things are specific to individual deployments and their logic is impossible to automate in a generic way without exposing some kind of a general purpose language to express it. So we aren't going to implement this when all you can do is to use ansible-freeipa to define your logic and actions already.
I don't understand why it would be so hard. I'll try to explain better how it might work.
1. 700 users get workstations 2. we put all users into a "workstation" user group 3. an HBAC rule "allow_workstation" is created for the "workstation" user group to login using the Services sshd, sudo, su, and su-l, as well as an HBAC Service Group called gnome 4. In the host records for each of the workstations, we select which user is the "admin" for that workstation. 5. IPA creates internally a Sudo rule for the user and workstation pair that gives that user "admin" control (i.e. all commands allowed as root/anyone)
That's it. freeipa would be doing on its own and tracking internally what we would have to do anyway via ansible or the web UI. Nothing fancy or complicated. Why would this be difficult to support within freeipa? I apologize if this is a dumb question. :P
Some background info: we have many hundreds of workstations we want to bring into our new IPA deployment and new ones are being added all of the time. I don't want to use local sudo rules and I also don't want to create sudo rules approaching 1000 in number. Both are dumb solutions, even with ansible.
Please feel free to hammer my take on this! :)
Not sure if this helps but I've found on my fedora machines installing Spotify via lpf requires adding my user to the pkg-build group.
When I do that it seems to persist on that machine without effecting groups on other machines. Maybe worth a shot. Might be best to do it then clear sss cache and reboot see if the groups persist on the specific machine.
20 Dec 2022 18:14:59 Ranbir via FreeIPA-users freeipa-users@lists.fedorahosted.org:
On Tue, 2022-12-20 at 08:22 +0200, Alexander Bokovoy via FreeIPA-users wrote:
FreeIPA does not provide generation capabilities in itself. These things are specific to individual deployments and their logic is impossible to automate in a generic way without exposing some kind of a general purpose language to express it. So we aren't going to implement this when all you can do is to use ansible-freeipa to define your logic and actions already.
I don't understand why it would be so hard. I'll try to explain better how it might work.
- 700 users get workstations
- we put all users into a "workstation" user group
- an HBAC rule "allow_workstation" is created for the "workstation"
user group to login using the Services sshd, sudo, su, and su-l, as well as an HBAC Service Group called gnome 4. In the host records for each of the workstations, we select which user is the "admin" for that workstation. 5. IPA creates internally a Sudo rule for the user and workstation pair that gives that user "admin" control (i.e. all commands allowed as root/anyone)
That's it. freeipa would be doing on its own and tracking internally what we would have to do anyway via ansible or the web UI. Nothing fancy or complicated. Why would this be difficult to support within freeipa? I apologize if this is a dumb question. :P
Some background info: we have many hundreds of workstations we want to bring into our new IPA deployment and new ones are being added all of the time. I don't want to use local sudo rules and I also don't want to create sudo rules approaching 1000 in number. Both are dumb solutions, even with ansible.
Please feel free to hammer my take on this! :)
-- Ranbir _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.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.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On ti, 20 joulu 2022, Ranbir wrote:
On Tue, 2022-12-20 at 08:22 +0200, Alexander Bokovoy via FreeIPA-users wrote:
FreeIPA does not provide generation capabilities in itself. These things are specific to individual deployments and their logic is impossible to automate in a generic way without exposing some kind of a general purpose language to express it. So we aren't going to implement this when all you can do is to use ansible-freeipa to define your logic and actions already.
I don't understand why it would be so hard. I'll try to explain better how it might work.
- 700 users get workstations
- we put all users into a "workstation" user group
- an HBAC rule "allow_workstation" is created for the "workstation"
user group to login using the Services sshd, sudo, su, and su-l, as well as an HBAC Service Group called gnome 4. In the host records for each of the workstations, we select which user is the "admin" for that workstation. 5. IPA creates internally a Sudo rule for the user and workstation pair that gives that user "admin" control (i.e. all commands allowed as root/anyone)
That's it. freeipa would be doing on its own and tracking internally what we would have to do anyway via ansible or the web UI. Nothing fancy or complicated. Why would this be difficult to support within freeipa? I apologize if this is a dumb question. :P
This is not a dumb question, of course. ;) What you describe above is pretty much what I said is a configuration specific to an individual deployment. Can you implement an automation in FreeIPA for your use case? Yes. Should it be implemented by FreeIPA upstream project? I would say 'no'.
FreeIPA management middleware provides a pluggable core that can be extended with plugins. Most of functionality you see in IPA CLI or access over Web UI is provided by the plugins in IPA management middleware. These plugins can be added externally, in absolute majority of cases they do not require modifications of IPA core itself.
The plugins need to be written in Python. You can find some examples at my github account: https://github.com/abbra. A plugin can also amend actions of other plugins. This means you can add some sort of a plugin that is run when an action is being done on a different object.
This gives a lot of flexibility that can be used to implement whatever logic you want to create. However, there is no magic: someone have to write down the steps to be performed and logically connect them to actions that would trigger the operation in question.
A description of your requirements above cannot be connected to a particular action. It looks like you have at least:
- add a user to 'workstation' user group - select a user as an admin of the workstation
as two definitive actions to be performed before the rest of rules be created. A workstation is a host but we have no concept of ownership of hosts for users. There is a machine ownership by other machines ('ipa host-add-managedby' command), but there is no way to tell that a particular user 'owns' this machine in the host entry.
Hence, you cannot simply connect a user to machine and then trigger some action. You would probably need to add some attribute in IPA to hold this relationship 'user -> machine' which means a new plugin would need to be created, new LDAP attribute allocated to store it, new commands added to manage it, etc.
As I said, this all can be done. We did something similar when integrating FleetCommander desktop management tool with FreeIPA and SSSD: https://github.com/abbra/freeipa-desktop-profile, design document is https://github.com/abbra/freeipa-desktop-profile/blob/master/plugin/Feature.... This was to be able to provide an integrated solution which covered a specific use case and spanned GNOME, FleetCommander, SSSD, FreeIPA, and few other projects.
In the case of the FleetCommander's integration we did not need to automatically create additional HBAC and SUDO rules. Those can be created as a part of the plugin flow, of course, using internal IPA API. Most of the API details are now published at https://freeipa.readthedocs.io/en/latest/api/index.html but for writing plugins you need to read FreeIPA's source code as well.
However, I do not think this should be part of IPA itself. FleetCommander plugin, for example, is maintained separately without any problems. There are other plugins written by different people and different organizations and not all of them are known to FreeIPA developers -- we only get to know about stuff that being published somewhere and asked about on these mailing lists or in an issue tracker.
Now, if you have no people at your organization to implement a plugin to provide an integrated solution, you can write down the logic you need to create all additional rules in ansible-freeipa playbooks. This gives a better way to preserve the logic for administrators and run these playbooks whenever you need to add a new user. This would be a part of the life-cycle management flow which typically includes a lot of other operations, often beyond FreeIPA itself.
Some background info: we have many hundreds of workstations we want to bring into our new IPA deployment and new ones are being added all of the time. I don't want to use local sudo rules and I also don't want to create sudo rules approaching 1000 in number. Both are dumb solutions, even with ansible.
You do realize that in order to use SUDO to limit access on the machine itself, you would need to create SUDO rules anyway, do you? It doesn't matter where they exist, locally or centrally in IPA, the rules would need to exist and be maintained. A move of responsibility between who owns the rules and who creates/removes them does not change the fact that SUDO requires rules to exist to apply.
On 21.12.22 08:59, Alexander Bokovoy via FreeIPA-users wrote:
On ti, 20 joulu 2022, Ranbir wrote:
On Tue, 2022-12-20 at 08:22 +0200, Alexander Bokovoy via FreeIPA-users wrote:
FreeIPA does not provide generation capabilities in itself. These things are specific to individual deployments and their logic is impossible to automate in a generic way without exposing some kind of a general purpose language to express it. So we aren't going to implement this when all you can do is to use ansible-freeipa to define your logic and actions already.
I don't understand why it would be so hard. I'll try to explain better how it might work.
- 700 users get workstations
- we put all users into a "workstation" user group
- an HBAC rule "allow_workstation" is created for the "workstation"
user group to login using the Services sshd, sudo, su, and su-l, as well as an HBAC Service Group called gnome 4. In the host records for each of the workstations, we select which user is the "admin" for that workstation. 5. IPA creates internally a Sudo rule for the user and workstation pair that gives that user "admin" control (i.e. all commands allowed as root/anyone)
That's it. freeipa would be doing on its own and tracking internally what we would have to do anyway via ansible or the web UI. Nothing fancy or complicated. Why would this be difficult to support within freeipa? I apologize if this is a dumb question. :P
This is not a dumb question, of course. ;) What you describe above is pretty much what I said is a configuration specific to an individual deployment. Can you implement an automation in FreeIPA for your use case? Yes. Should it be implemented by FreeIPA upstream project? I would say 'no'.
FreeIPA management middleware provides a pluggable core that can be extended with plugins. Most of functionality you see in IPA CLI or access over Web UI is provided by the plugins in IPA management middleware. These plugins can be added externally, in absolute majority of cases they do not require modifications of IPA core itself.
The plugins need to be written in Python. You can find some examples at my github account: https://github.com/abbra. A plugin can also amend actions of other plugins. This means you can add some sort of a plugin that is run when an action is being done on a different object.
This gives a lot of flexibility that can be used to implement whatever logic you want to create. However, there is no magic: someone have to write down the steps to be performed and logically connect them to actions that would trigger the operation in question. A description of your requirements above cannot be connected to a particular action. It looks like you have at least:
- add a user to 'workstation' user group - select a user as an admin of the workstation
as two definitive actions to be performed before the rest of rules be created. A workstation is a host but we have no concept of ownership of hosts for users. There is a machine ownership by other machines ('ipa host-add-managedby' command), but there is no way to tell that a particular user 'owns' this machine in the host entry.
Hence, you cannot simply connect a user to machine and then trigger some action. You would probably need to add some attribute in IPA to hold this relationship 'user -> machine' which means a new plugin would need to be created, new LDAP attribute allocated to store it, new commands added to manage it, etc.
As I said, this all can be done. We did something similar when integrating FleetCommander desktop management tool with FreeIPA and SSSD: https://github.com/abbra/freeipa-desktop-profile, design document is https://github.com/abbra/freeipa-desktop-profile/blob/master/plugin/Feature.... This was to be able to provide an integrated solution which covered a specific use case and spanned GNOME, FleetCommander, SSSD, FreeIPA, and few other projects.
In the case of the FleetCommander's integration we did not need to automatically create additional HBAC and SUDO rules. Those can be created as a part of the plugin flow, of course, using internal IPA API. Most of the API details are now published at https://freeipa.readthedocs.io/en/latest/api/index.html but for writing plugins you need to read FreeIPA's source code as well.
However, I do not think this should be part of IPA itself. FleetCommander plugin, for example, is maintained separately without any problems. There are other plugins written by different people and different organizations and not all of them are known to FreeIPA developers -- we only get to know about stuff that being published somewhere and asked about on these mailing lists or in an issue tracker.
Now, if you have no people at your organization to implement a plugin to provide an integrated solution, you can write down the logic you need to create all additional rules in ansible-freeipa playbooks. This gives a better way to preserve the logic for administrators and run these playbooks whenever you need to add a new user. This would be a part of the life-cycle management flow which typically includes a lot of other operations, often beyond FreeIPA itself.
Some background info: we have many hundreds of workstations we want to bring into our new IPA deployment and new ones are being added all of the time. I don't want to use local sudo rules and I also don't want to create sudo rules approaching 1000 in number. Both are dumb solutions, even with ansible.
You do realize that in order to use SUDO to limit access on the machine itself, you would need to create SUDO rules anyway, do you? It doesn't matter where they exist, locally or centrally in IPA, the rules would need to exist and be maintained. A move of responsibility between who owns the rules and who creates/removes them does not change the fact that SUDO requires rules to exist to apply.
What we do is fetching the external (Active Directory) admin group for a specific host from an external database and write it in a host's class field. This field is used for an automembership rule that allows (HBAC) all group members to access that particular host.
This concept could easily be customized to allow a single user only and give it sudo permissions.
Cheers, Ronald
On ke, 21 joulu 2022, Ronald Wimmer via FreeIPA-users wrote:
On 21.12.22 08:59, Alexander Bokovoy via FreeIPA-users wrote:
On ti, 20 joulu 2022, Ranbir wrote:
On Tue, 2022-12-20 at 08:22 +0200, Alexander Bokovoy via FreeIPA-users wrote:
FreeIPA does not provide generation capabilities in itself. These things are specific to individual deployments and their logic is impossible to automate in a generic way without exposing some kind of a general purpose language to express it. So we aren't going to implement this when all you can do is to use ansible-freeipa to define your logic and actions already.
I don't understand why it would be so hard. I'll try to explain better how it might work.
- 700 users get workstations
- we put all users into a "workstation" user group
- an HBAC rule "allow_workstation" is created for the "workstation"
user group to login using the Services sshd, sudo, su, and su-l, as well as an HBAC Service Group called gnome 4. In the host records for each of the workstations, we select which user is the "admin" for that workstation. 5. IPA creates internally a Sudo rule for the user and workstation pair that gives that user "admin" control (i.e. all commands allowed as root/anyone)
That's it. freeipa would be doing on its own and tracking internally what we would have to do anyway via ansible or the web UI. Nothing fancy or complicated. Why would this be difficult to support within freeipa? I apologize if this is a dumb question. :P
This is not a dumb question, of course. ;) What you describe above is pretty much what I said is a configuration specific to an individual deployment. Can you implement an automation in FreeIPA for your use case? Yes. Should it be implemented by FreeIPA upstream project? I would say 'no'.
FreeIPA management middleware provides a pluggable core that can be extended with plugins. Most of functionality you see in IPA CLI or access over Web UI is provided by the plugins in IPA management middleware. These plugins can be added externally, in absolute majority of cases they do not require modifications of IPA core itself.
The plugins need to be written in Python. You can find some examples at my github account: https://github.com/abbra. A plugin can also amend actions of other plugins. This means you can add some sort of a plugin that is run when an action is being done on a different object.
This gives a lot of flexibility that can be used to implement whatever logic you want to create. However, there is no magic: someone have to write down the steps to be performed and logically connect them to actions that would trigger the operation in question. A description of your requirements above cannot be connected to a particular action. It looks like you have at least:
- add a user to 'workstation' user group - select a user as an admin of the workstation
as two definitive actions to be performed before the rest of rules be created. A workstation is a host but we have no concept of ownership of hosts for users. There is a machine ownership by other machines ('ipa host-add-managedby' command), but there is no way to tell that a particular user 'owns' this machine in the host entry.
Hence, you cannot simply connect a user to machine and then trigger some action. You would probably need to add some attribute in IPA to hold this relationship 'user -> machine' which means a new plugin would need to be created, new LDAP attribute allocated to store it, new commands added to manage it, etc.
As I said, this all can be done. We did something similar when integrating FleetCommander desktop management tool with FreeIPA and SSSD: https://github.com/abbra/freeipa-desktop-profile, design document is https://github.com/abbra/freeipa-desktop-profile/blob/master/plugin/Feature.... This was to be able to provide an integrated solution which covered a specific use case and spanned GNOME, FleetCommander, SSSD, FreeIPA, and few other projects.
In the case of the FleetCommander's integration we did not need to automatically create additional HBAC and SUDO rules. Those can be created as a part of the plugin flow, of course, using internal IPA API. Most of the API details are now published at https://freeipa.readthedocs.io/en/latest/api/index.html but for writing plugins you need to read FreeIPA's source code as well.
However, I do not think this should be part of IPA itself. FleetCommander plugin, for example, is maintained separately without any problems. There are other plugins written by different people and different organizations and not all of them are known to FreeIPA developers -- we only get to know about stuff that being published somewhere and asked about on these mailing lists or in an issue tracker.
Now, if you have no people at your organization to implement a plugin to provide an integrated solution, you can write down the logic you need to create all additional rules in ansible-freeipa playbooks. This gives a better way to preserve the logic for administrators and run these playbooks whenever you need to add a new user. This would be a part of the life-cycle management flow which typically includes a lot of other operations, often beyond FreeIPA itself.
Some background info: we have many hundreds of workstations we want to bring into our new IPA deployment and new ones are being added all of the time. I don't want to use local sudo rules and I also don't want to create sudo rules approaching 1000 in number. Both are dumb solutions, even with ansible.
You do realize that in order to use SUDO to limit access on the machine itself, you would need to create SUDO rules anyway, do you? It doesn't matter where they exist, locally or centrally in IPA, the rules would need to exist and be maintained. A move of responsibility between who owns the rules and who creates/removes them does not change the fact that SUDO requires rules to exist to apply.
What we do is fetching the external (Active Directory) admin group for a specific host from an external database and write it in a host's class field. This field is used for an automembership rule that allows (HBAC) all group members to access that particular host.
This concept could easily be customized to allow a single user only and give it sudo permissions.
Yep, as one of examples of a custom use of IPA-provided attributes.
Adding Ranbir's usage as a default logic would break the one that your organization developed.
On Wed, 2022-12-21 at 09:09 +0100, Ronald Wimmer via FreeIPA-users wrote:
This concept could easily be customized to allow a single user only and give it sudo permissions.
This sounds like there is at least some usage of python to interact with IPA. I unfortunately do not know python and I don't really want to learn it. We likely have python developers on staff that could do what I need...if they have time for it.
For now, I'll just have to use ansible and train the helpdesk people on how to run playbooks when they deploy Linux workstations. Oooo boy....
Thanks for the input. It was appreciated.
On 22.12.22 23:26, Ranbir via FreeIPA-users wrote:
On Wed, 2022-12-21 at 09:09 +0100, Ronald Wimmer via FreeIPA-users wrote:
This concept could easily be customized to allow a single user only and give it sudo permissions.
This sounds like there is at least some usage of python to interact with IPA. I unfortunately do not know python and I don't really want to learn it. We likely have python developers on staff that could do what I need...if they have time for it.
You would just need a data source with some hostname/admin user-mapping. The rest is pretty easy. If you can find somebody with a little python knowledge feel free to contact me regarding this matter.
Cheers, Ronald
On Wed, 2022-12-21 at 09:59 +0200, Alexander Bokovoy via FreeIPA-users wrote:
[snip]
That was all excellent info. Thank you.
Now, if you have no people at your organization to implement a plugin to provide an integrated solution, you can write down the logic you need to create all additional rules in ansible-freeipa playbooks. This gives a better way to preserve the logic for administrators and run these playbooks whenever you need to add a new user. This would be a part of the life-cycle management flow which typically includes a lot of other operations, often beyond FreeIPA itself.
Yes, I can do what I want via ansible so for the immediate future, that is the route I'll take.
You do realize that in order to use SUDO to limit access on the machine itself, you would need to create SUDO rules anyway, do you? It doesn't matter where they exist, locally or centrally in IPA, the rules would need to exist and be maintained. A move of responsibility between who owns the rules and who creates/removes them does not change the fact that SUDO requires rules to exist to apply.
Yes, of course. My end state is to do as much as possible with the fewest interactions between human and machine required to achieve that end state. But, that depends on skill level and knowledge. lol I'll do the best I can with what I know without getting mired in learning python and reading the freeipa source code.
Thanks again for the detailed reply.
freeipa-users@lists.fedorahosted.org
-
Alexander Bokovoy -
Entrepreneur AJ -
Fraser Tweedale -
Ranbir -
Ronald Wimmer