2:32 p.m.
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.
--
Ranbir
9:08 p.m.
New subject: Grant sudo to users only on their own workstations
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
11:37 p.m.
New subject: Grant sudo to users only on their own workstations
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.
--
Ranbir
12:22 a.m.
New subject: Grant sudo to users only on their own workstations
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.
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
12:14 p.m.
New subject: Grant sudo to users only on their own workstations
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! :)
--
Ranbir
1:32 p.m.
New subject: Grant sudo to users only on their own workstations
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(a)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.
>
> 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! :)
>
> --
> Ranbir
> _______________________________________________
> FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-leave(a)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.fedoraho...
> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
1:59 a.m.
New subject: Grant sudo to users only on their own workstations
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.
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
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/Featu...
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.
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
2:09 a.m.
New subject: Grant sudo to users only on their own workstations
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.
>
> 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
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/Featu...
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
2:33 a.m.
New subject: Grant sudo to users only on their own workstations
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.
>>
>>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
>
>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/Featu...
>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.
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
4:26 p.m.
New subject: Grant sudo to users only on their own workstations
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.
--
Ranbir
5:39 a.m.
New subject: Grant sudo to users only on their own workstations
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
9:48 p.m.
New subject: Grant sudo to users only on their own workstations
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.
--
Ranbir
467
days inactive
486
days old
freeipa-users@lists.fedorahosted.org
11 comments
5 participants
participants (5)
-
Alexander Bokovoy -
Entrepreneur AJ -
Fraser Tweedale -
Ranbir -
Ronald Wimmer