Re: [Freeipa-users] Python Client
On 02/13/2013 12:47 AM, It Meme wrote: Thank you for your reply. Could there be anyway that accounts can be provisioned to IPA, via LDAP, from existing IAM system? The newly provisioned accounts can be temporarily stored in IPA's 389 Directory Server, and subsequently an automated task can IPA-ize the accounts (i.e. via the Python libraries). The accounts that have not been IPA-ized will be provisioned in a disabled state (i.e. users will be not using them). After accounts have been IPA-ize, account attributes, such as 'givenName', 'password', 'membershipOf', can be managed by LDAP from the central IAM system. IMO a solution might be to do something like this: https://fedorahosted.org/freeipa/ticket/1593 You create a plugin for DS to intercept the changes and send them over DBUS or socket So the whole thing would work like this: You create a different tree for accounts managed by the external system for example under cn=ext, ... You create a plugin that would intercept add, delete and modify commands and would also send these over the DBUS/Socket to a python service that would translate the changes into ipa user-add, ipa user-mod and ipa-user-del commands. The value of this approach is that would take advantage of the standard interfaces of both systems and have full control over the code you develop. Would that work for you? Thank you. On Tue, Feb 12, 2013 at 4:18 PM, Dmitri Pal d...@redhat.com mailto:d...@redhat.com wrote: On 02/12/2013 12:42 PM, It Meme wrote: Yes - Dmitri is correct. Our purchased IAM product has LDAP connectors. It is possible to customize to develop other connector protocols but it requires tweaking the core product code - this adds risk and, if not careful, could break our support with vendor or increase operational risk to a critical production system. The most practical option is to continue to use the LDAP connectors to provision accounts to directory server. If we use IPA, that would mean provisioning accounts, from our IAM product to IPA, via LDAP (Step 1) - and subsequently running a script that will call the python libraries to IPA-ize the provisioned accounts (Step 2). It will assist our help desk staff if 'Step 1' provisioned accounts were created in main accounts tree in IPA - then subsequent script will IPA-ize the accounts for 'Step 2' and accounts will be updated in same tree. Any gotchas foreseen with above? Yes. You need to be very careful. You are bypassing all the checks that framework creates around user and group management. It is also unclear how the system would react to the half baked user. It is all doable but you shift the risk from the tweaking core product code to creating a custom IPA code. IMO the level of risk is nearly the same. We have larger user base with ~40K new accounts per year and 600K ongoing - automating the tasks in stable systems, and having help desk insight to account statuses are critical items for management. Thank you for your help, insights, input - they are very helpful and greatly appreciated. On 2013-02-10, at 7:32, Dmitri Pal d...@redhat.com mailto:d...@redhat.com wrote: On 02/09/2013 11:53 AM, John Dennis wrote: On 02/08/2013 05:29 PM, It Meme wrote: Hi: Scenario: 1) User is created via LDAP call to IPA (i.e.the 389 Directory Server) The above user will not have IPA-specific attributes. Can we use the Python Library, or CLI, to modify the account to IPA-ize it? You're really better off using the IPA API directly rather than trying to bypass it. Why? Because we implement additional logic inside the commands. If you could achieve everything IPA does by just modifying an LDAP server there wouldn't be a need for IPA. A good example of this is group membership, some of that logic is handled directly by a plugin to the 389 DS, but a large part of it is implemented in the IPA commands that manage users and groups. You really don't want to bypass it. You have a number of options on how to call the IPA commands: 1) the ipa command line client 2) sending the command formatted in JSON to the server 3) sending the command formatted in XML-RPC to the server 4) calling the command from your own python code 5) using the web GUI It's really not hard to call the IPA command line client from a program, typically this is done via a system command of which there are a number of variants. The following thread has a discussion of how to invoke one of our commands from Python code, this particular email response from Martin
Re: [Freeipa-users] Python Client
It Meme wrote: Thank you for your reply. Could there be anyway that accounts can be provisioned to IPA, via LDAP, from existing IAM system? The newly provisioned accounts can be temporarily stored in IPA's 389 Directory Server, and subsequently an automated task can IPA-ize the accounts (i.e. via the Python libraries). The accounts that have not been IPA-ized will be provisioned in a disabled state (i.e. users will be not using them). After accounts have been IPA-ize, account attributes, such as 'givenName', 'password', 'membershipOf', can be managed by LDAP from the central IAM system. I think as has been suggested your best bet is to write the users to a location outside of the IPA DIT and run a periodic query or write a service that uses LDAP persistent search to retrieve the user then pass it to the IPA framework via user-add. I think persistent search and a user principal in a keytab would be a pretty decent way to go. rob Thank you. On Tue, Feb 12, 2013 at 4:18 PM, Dmitri Pal d...@redhat.com mailto:d...@redhat.com wrote: On 02/12/2013 12:42 PM, It Meme wrote: Yes - Dmitri is correct. Our purchased IAM product has LDAP connectors. It is possible to customize to develop other connector protocols but it requires tweaking the core product code - this adds risk and, if not careful, could break our support with vendor or increase operational risk to a critical production system. The most practical option is to continue to use the LDAP connectors to provision accounts to directory server. If we use IPA, that would mean provisioning accounts, from our IAM product to IPA, via LDAP (Step 1) - and subsequently running a script that will call the python libraries to IPA-ize the provisioned accounts (Step 2). It will assist our help desk staff if 'Step 1' provisioned accounts were created in main accounts tree in IPA - then subsequent script will IPA-ize the accounts for 'Step 2' and accounts will be updated in same tree. Any gotchas foreseen with above? Yes. You need to be very careful. You are bypassing all the checks that framework creates around user and group management. It is also unclear how the system would react to the half baked user. It is all doable but you shift the risk from the tweaking core product code to creating a custom IPA code. IMO the level of risk is nearly the same. We have larger user base with ~40K new accounts per year and 600K ongoing - automating the tasks in stable systems, and having help desk insight to account statuses are critical items for management. Thank you for your help, insights, input - they are very helpful and greatly appreciated. On 2013-02-10, at 7:32, Dmitri Pal d...@redhat.com mailto:d...@redhat.com wrote: On 02/09/2013 11:53 AM, John Dennis wrote: On 02/08/2013 05:29 PM, It Meme wrote: Hi: Scenario: 1) User is created via LDAP call to IPA (i.e.the 389 Directory Server) The above user will not have IPA-specific attributes. Can we use the Python Library, or CLI, to modify the account to IPA-ize it? You're really better off using the IPA API directly rather than trying to bypass it. Why? Because we implement additional logic inside the commands. If you could achieve everything IPA does by just modifying an LDAP server there wouldn't be a need for IPA. A good example of this is group membership, some of that logic is handled directly by a plugin to the 389 DS, but a large part of it is implemented in the IPA commands that manage users and groups. You really don't want to bypass it. You have a number of options on how to call the IPA commands: 1) the ipa command line client 2) sending the command formatted in JSON to the server 3) sending the command formatted in XML-RPC to the server 4) calling the command from your own python code 5) using the web GUI It's really not hard to call the IPA command line client from a program, typically this is done via a system command of which there are a number of variants. The following thread has a discussion of how to invoke one of our commands from Python code, this particular email response from Martin shows how it can be done in in about half a dozen lines of code. https://www.redhat.com/archives/freeipa-users/2012-June/msg00334.html What I'm not understanding why you're avoiding using the commands we provide. If you're not familiar with how to call another program/process we can help you or just google it. Or is the problem your existing management system does not provide you with any hooks to
Re: [Freeipa-users] Python Client
Yes - Dmitri is correct. Our purchased IAM product has LDAP connectors. It is possible to customize to develop other connector protocols but it requires tweaking the core product code - this adds risk and, if not careful, could break our support with vendor or increase operational risk to a critical production system. The most practical option is to continue to use the LDAP connectors to provision accounts to directory server. If we use IPA, that would mean provisioning accounts, from our IAM product to IPA, via LDAP (Step 1) - and subsequently running a script that will call the python libraries to IPA-ize the provisioned accounts (Step 2). It will assist our help desk staff if 'Step 1' provisioned accounts were created in main accounts tree in IPA - then subsequent script will IPA-ize the accounts for 'Step 2' and accounts will be updated in same tree. Any gotchas foreseen with above? We have larger user base with ~40K new accounts per year and 600K ongoing - automating the tasks in stable systems, and having help desk insight to account statuses are critical items for management. Thank you for your help, insights, input - they are very helpful and greatly appreciated. On 2013-02-10, at 7:32, Dmitri Pal d...@redhat.com wrote: On 02/09/2013 11:53 AM, John Dennis wrote: On 02/08/2013 05:29 PM, It Meme wrote: Hi: Scenario: 1) User is created via LDAP call to IPA (i.e.the 389 Directory Server) The above user will not have IPA-specific attributes. Can we use the Python Library, or CLI, to modify the account to IPA-ize it? You're really better off using the IPA API directly rather than trying to bypass it. Why? Because we implement additional logic inside the commands. If you could achieve everything IPA does by just modifying an LDAP server there wouldn't be a need for IPA. A good example of this is group membership, some of that logic is handled directly by a plugin to the 389 DS, but a large part of it is implemented in the IPA commands that manage users and groups. You really don't want to bypass it. You have a number of options on how to call the IPA commands: 1) the ipa command line client 2) sending the command formatted in JSON to the server 3) sending the command formatted in XML-RPC to the server 4) calling the command from your own python code 5) using the web GUI It's really not hard to call the IPA command line client from a program, typically this is done via a system command of which there are a number of variants. The following thread has a discussion of how to invoke one of our commands from Python code, this particular email response from Martin shows how it can be done in in about half a dozen lines of code. https://www.redhat.com/archives/freeipa-users/2012-June/msg00334.html What I'm not understanding why you're avoiding using the commands we provide. If you're not familiar with how to call another program/process we can help you or just google it. Or is the problem your existing management system does not provide you with any hooks to execute code when an action occurs. But from everything you've said so far you imply it does provide such hooks. Perhaps if you could be more specific we could be more helpful. It seems that the management system in question can insert an entry into LDAP but can't do the generic hook. I bet this is the issue here. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Python Client
On 02/12/2013 12:42 PM, It Meme wrote: Yes - Dmitri is correct. Our purchased IAM product has LDAP connectors. It is possible to customize to develop other connector protocols but it requires tweaking the core product code - this adds risk and, if not careful, could break our support with vendor or increase operational risk to a critical production system. The most practical option is to continue to use the LDAP connectors to provision accounts to directory server. If we use IPA, that would mean provisioning accounts, from our IAM product to IPA, via LDAP (Step 1) - and subsequently running a script that will call the python libraries to IPA-ize the provisioned accounts (Step 2). It will assist our help desk staff if 'Step 1' provisioned accounts were created in main accounts tree in IPA - then subsequent script will IPA-ize the accounts for 'Step 2' and accounts will be updated in same tree. Any gotchas foreseen with above? Yes. You need to be very careful. You are bypassing all the checks that framework creates around user and group management. It is also unclear how the system would react to the half baked user. It is all doable but you shift the risk from the tweaking core product code to creating a custom IPA code. IMO the level of risk is nearly the same. We have larger user base with ~40K new accounts per year and 600K ongoing - automating the tasks in stable systems, and having help desk insight to account statuses are critical items for management. Thank you for your help, insights, input - they are very helpful and greatly appreciated. On 2013-02-10, at 7:32, Dmitri Pal d...@redhat.com wrote: On 02/09/2013 11:53 AM, John Dennis wrote: On 02/08/2013 05:29 PM, It Meme wrote: Hi: Scenario: 1) User is created via LDAP call to IPA (i.e.the 389 Directory Server) The above user will not have IPA-specific attributes. Can we use the Python Library, or CLI, to modify the account to IPA-ize it? You're really better off using the IPA API directly rather than trying to bypass it. Why? Because we implement additional logic inside the commands. If you could achieve everything IPA does by just modifying an LDAP server there wouldn't be a need for IPA. A good example of this is group membership, some of that logic is handled directly by a plugin to the 389 DS, but a large part of it is implemented in the IPA commands that manage users and groups. You really don't want to bypass it. You have a number of options on how to call the IPA commands: 1) the ipa command line client 2) sending the command formatted in JSON to the server 3) sending the command formatted in XML-RPC to the server 4) calling the command from your own python code 5) using the web GUI It's really not hard to call the IPA command line client from a program, typically this is done via a system command of which there are a number of variants. The following thread has a discussion of how to invoke one of our commands from Python code, this particular email response from Martin shows how it can be done in in about half a dozen lines of code. https://www.redhat.com/archives/freeipa-users/2012-June/msg00334.html What I'm not understanding why you're avoiding using the commands we provide. If you're not familiar with how to call another program/process we can help you or just google it. Or is the problem your existing management system does not provide you with any hooks to execute code when an action occurs. But from everything you've said so far you imply it does provide such hooks. Perhaps if you could be more specific we could be more helpful. It seems that the management system in question can insert an entry into LDAP but can't do the generic hook. I bet this is the issue here. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Python Client
Thank you for your reply. Could there be anyway that accounts can be provisioned to IPA, via LDAP, from existing IAM system? The newly provisioned accounts can be temporarily stored in IPA's 389 Directory Server, and subsequently an automated task can IPA-ize the accounts (i.e. via the Python libraries). The accounts that have not been IPA-ized will be provisioned in a disabled state (i.e. users will be not using them). After accounts have been IPA-ize, account attributes, such as 'givenName', 'password', 'membershipOf', can be managed by LDAP from the central IAM system. Thank you. On Tue, Feb 12, 2013 at 4:18 PM, Dmitri Pal d...@redhat.com wrote: On 02/12/2013 12:42 PM, It Meme wrote: Yes - Dmitri is correct. Our purchased IAM product has LDAP connectors. It is possible to customize to develop other connector protocols but it requires tweaking the core product code - this adds risk and, if not careful, could break our support with vendor or increase operational risk to a critical production system. The most practical option is to continue to use the LDAP connectors to provision accounts to directory server. If we use IPA, that would mean provisioning accounts, from our IAM product to IPA, via LDAP (Step 1) - and subsequently running a script that will call the python libraries to IPA-ize the provisioned accounts (Step 2). It will assist our help desk staff if 'Step 1' provisioned accounts were created in main accounts tree in IPA - then subsequent script will IPA-ize the accounts for 'Step 2' and accounts will be updated in same tree. Any gotchas foreseen with above? Yes. You need to be very careful. You are bypassing all the checks that framework creates around user and group management. It is also unclear how the system would react to the half baked user. It is all doable but you shift the risk from the tweaking core product code to creating a custom IPA code. IMO the level of risk is nearly the same. We have larger user base with ~40K new accounts per year and 600K ongoing - automating the tasks in stable systems, and having help desk insight to account statuses are critical items for management. Thank you for your help, insights, input - they are very helpful and greatly appreciated. On 2013-02-10, at 7:32, Dmitri Pal d...@redhat.com wrote: On 02/09/2013 11:53 AM, John Dennis wrote: On 02/08/2013 05:29 PM, It Meme wrote: Hi: Scenario: 1) User is created via LDAP call to IPA (i.e.the 389 Directory Server) The above user will not have IPA-specific attributes. Can we use the Python Library, or CLI, to modify the account to IPA-ize it? You're really better off using the IPA API directly rather than trying to bypass it. Why? Because we implement additional logic inside the commands. If you could achieve everything IPA does by just modifying an LDAP server there wouldn't be a need for IPA. A good example of this is group membership, some of that logic is handled directly by a plugin to the 389 DS, but a large part of it is implemented in the IPA commands that manage users and groups. You really don't want to bypass it. You have a number of options on how to call the IPA commands: 1) the ipa command line client 2) sending the command formatted in JSON to the server 3) sending the command formatted in XML-RPC to the server 4) calling the command from your own python code 5) using the web GUI It's really not hard to call the IPA command line client from a program, typically this is done via a system command of which there are a number of variants. The following thread has a discussion of how to invoke one of our commands from Python code, this particular email response from Martin shows how it can be done in in about half a dozen lines of code. https://www.redhat.com/archives/freeipa-users/2012-June/msg00334.html What I'm not understanding why you're avoiding using the commands we provide. If you're not familiar with how to call another program/process we can help you or just google it. Or is the problem your existing management system does not provide you with any hooks to execute code when an action occurs. But from everything you've said so far you imply it does provide such hooks. Perhaps if you could be more specific we could be more helpful. It seems that the management system in question can insert an entry into LDAP but can't do the generic hook. I bet this is the issue here. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc.
Re: [Freeipa-users] Python Client
On 02/09/2013 11:53 AM, John Dennis wrote: On 02/08/2013 05:29 PM, It Meme wrote: Hi: Scenario: 1) User is created via LDAP call to IPA (i.e.the 389 Directory Server) The above user will not have IPA-specific attributes. Can we use the Python Library, or CLI, to modify the account to IPA-ize it? You're really better off using the IPA API directly rather than trying to bypass it. Why? Because we implement additional logic inside the commands. If you could achieve everything IPA does by just modifying an LDAP server there wouldn't be a need for IPA. A good example of this is group membership, some of that logic is handled directly by a plugin to the 389 DS, but a large part of it is implemented in the IPA commands that manage users and groups. You really don't want to bypass it. You have a number of options on how to call the IPA commands: 1) the ipa command line client 2) sending the command formatted in JSON to the server 3) sending the command formatted in XML-RPC to the server 4) calling the command from your own python code 5) using the web GUI It's really not hard to call the IPA command line client from a program, typically this is done via a system command of which there are a number of variants. The following thread has a discussion of how to invoke one of our commands from Python code, this particular email response from Martin shows how it can be done in in about half a dozen lines of code. https://www.redhat.com/archives/freeipa-users/2012-June/msg00334.html What I'm not understanding why you're avoiding using the commands we provide. If you're not familiar with how to call another program/process we can help you or just google it. Or is the problem your existing management system does not provide you with any hooks to execute code when an action occurs. But from everything you've said so far you imply it does provide such hooks. Perhaps if you could be more specific we could be more helpful. It seems that the management system in question can insert an entry into LDAP but can't do the generic hook. I bet this is the issue here. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Python Client
On 02/08/2013 05:29 PM, It Meme wrote: Hi: Scenario: 1) User is created via LDAP call to IPA (i.e.the 389 Directory Server) The above user will not have IPA-specific attributes. Can we use the Python Library, or CLI, to modify the account to IPA-ize it? You're really better off using the IPA API directly rather than trying to bypass it. Why? Because we implement additional logic inside the commands. If you could achieve everything IPA does by just modifying an LDAP server there wouldn't be a need for IPA. A good example of this is group membership, some of that logic is handled directly by a plugin to the 389 DS, but a large part of it is implemented in the IPA commands that manage users and groups. You really don't want to bypass it. You have a number of options on how to call the IPA commands: 1) the ipa command line client 2) sending the command formatted in JSON to the server 3) sending the command formatted in XML-RPC to the server 4) calling the command from your own python code 5) using the web GUI It's really not hard to call the IPA command line client from a program, typically this is done via a system command of which there are a number of variants. The following thread has a discussion of how to invoke one of our commands from Python code, this particular email response from Martin shows how it can be done in in about half a dozen lines of code. https://www.redhat.com/archives/freeipa-users/2012-June/msg00334.html What I'm not understanding why you're avoiding using the commands we provide. If you're not familiar with how to call another program/process we can help you or just google it. Or is the problem your existing management system does not provide you with any hooks to execute code when an action occurs. But from everything you've said so far you imply it does provide such hooks. Perhaps if you could be more specific we could be more helpful. -- John Dennis jden...@redhat.com Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Python Client
On 02/08/2013 05:29 PM, It Meme wrote: Hi: Scenario: 1) User is created via LDAP call to IPA (i.e.the 389 Directory Server) The above user will not have IPA-specific attributes. Can we use the Python Library, or CLI, to modify the account to IPA-ize it? Is this an integration with the external provisioning system? Do you need to do it in real time or in batches? A simple solution that comes to mind is: to create users in a different sub tree in ipa temporarily run a cron job to inspect this area and translate the data in this temp entry into the arguments of the CLI add user command and then clean this temp area. ldap search parse ipa user-add delete processed temp entries The job can run at the cadence you think is reasonable - 30 min may be? Thanks. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Python Client
On 02/08/2013 06:33 PM, It Meme wrote: Hi Dmitri: Yes, we are evaluating ways of provisioning users and their group memberships for Joiner, Mover, Leaver (JML) events. We were thinking of your suggestion as an option and your reply was very helpful. Our expected real-time scenarios is probably 5 mins latency. Is it viable to explore provisioning accounts/group to the destination tree via LDAP calls and a subsequent cron job runs, identifies the newly provisioned accounts, and applies modifications to create the IPA-specific attributes? Or is the temp folder the only option? You can do either, I think it is more error prone for you to try to convert the user that is already inserted. You would to make sure that all the attributes are in place. You would have to decompose the logic of the IPA user add and effectively re-implement it. Another approach would be to build a simple bridge that would take LDAP request and translate it into IPA JSON request. Such tool would be quite useful for us too. I am not sure how simple such thing would be in reality though. Thank you for all your great help. On Fri, Feb 8, 2013 at 2:39 PM, Dmitri Pal d...@redhat.com mailto:d...@redhat.com wrote: On 02/08/2013 05:29 PM, It Meme wrote: Hi: Scenario: 1) User is created via LDAP call to IPA (i.e.the 389 Directory Server) The above user will not have IPA-specific attributes. Can we use the Python Library, or CLI, to modify the account to IPA-ize it? Is this an integration with the external provisioning system? Do you need to do it in real time or in batches? A simple solution that comes to mind is: to create users in a different sub tree in ipa temporarily run a cron job to inspect this area and translate the data in this temp entry into the arguments of the CLI add user command and then clean this temp area. ldap search parse ipa user-add delete processed temp entries The job can run at the cadence you think is reasonable - 30 min may be? Thanks. ___ Freeipa-users mailing list Freeipa-users@redhat.com mailto:Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ http://www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com mailto:Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
