Re: [Freeipa-users] RHEL 6.3 identity manual - IPA
Hi, ipa-client-install should take care of setting up sudo on the client to use IPA, afaik. Essential line in nsswitch.conf: sudoers:files ldap Please read herehttps://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/6-Beta/html-single/Identity_Management_Guide/index.html#sudo As for the second question. dc=example,dc=com is, well, an example. example.com is used throughout the documentation for documentation purposes where a domain name is needed. Please replace is with you're domain, e.g. dc=yourcompanyname,dc=com Met vriendelijke groeten, * Fred* On Mon, Feb 4, 2013 at 7:29 AM, Rajnesh Kumar Siwal rajnesh.si...@gmail.com wrote: I am planning to use the sudo feature on IPA 2.2. By default the IPA client that I configured does not seems to use fetch the sudo user details. It looks that we need to modify nsswitch.conf and ldap.conf to support it. Can sssd take care of fetching the sudo user details ? Secondly, I am not able to find the password for uid=sudo,cn=sysaccounts,cn=etc,dc=example,dc=com . How do I find it ? Will it be safe to change password of this sudo user or it may impact the IPA Server ? Please suggest. -- Regards, Rajnesh Kumar Siwal ___ 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] sudo rule working even after the user has been removed from the sudo rule
Here is the outuput of ldapsearch :- dn: cn=Admins,ou=sudoers,dc=example,dc=com objectClass: sudoRole sudoUser: %ctsadmin sudoHost: ALL sudoCommand: ALL sudoRunAsUser: ALL cn: Admins The rule still says that the group ctsadmin is allowed (Which should not happen after I remove the ctsadmin group from sudo access) On the IPA Web Interface there is not sudo role attached to the User rsiwal (Neither Direct nor Indirect). May be there is some bug. On Mon, Feb 4, 2013 at 1:22 PM, Rajnesh Kumar Siwal rajnesh.si...@gmail.com wrote: Hi all, I have just created a setup for sudo on the IPA Server 2.2. I modified nsswitch.conf to use ldap. ldap.conf has been modified to fetch sudo users from the IPA Server. Now, th euser in group admin can do sudo. 1. rsiwal being a user of group sudo can run all commands as sudo (FINE) 2. If I disable the rule Admins (that I admin group access to sudo), the sudo still works for the user rsiwal (Which should not work logically). 3. Removed the group Admins (including rsiwal) from the Sudo rule. The rule is still allowing user rsiwal to run sudo su -. (It should Fail) Is there some kind of caching being at the Server / client end ? -- Regards, Rajnesh Kumar Siwal -- Regards, Rajnesh Kumar Siwal ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] RHEL 6.3 identity manual - IPA
IPA client on CentOS 5.6 was not able to take care of it.) On Mon, Feb 4, 2013 at 1:54 PM, Fred van Zwieten fvzwie...@vxcompany.com wrote: Hi, ipa-client-install should take care of setting up sudo on the client to use IPA, afaik. Essential line in nsswitch.conf: sudoers:files ldap Please read here As for the second question. dc=example,dc=com is, well, an example. example.com is used throughout the documentation for documentation purposes where a domain name is needed. Please replace is with you're domain, e.g. dc=yourcompanyname,dc=com Met vriendelijke groeten, Fred On Mon, Feb 4, 2013 at 7:29 AM, Rajnesh Kumar Siwal rajnesh.si...@gmail.com wrote: I am planning to use the sudo feature on IPA 2.2. By default the IPA client that I configured does not seems to use fetch the sudo user details. It looks that we need to modify nsswitch.conf and ldap.conf to support it. Can sssd take care of fetching the sudo user details ? Secondly, I am not able to find the password for uid=sudo,cn=sysaccounts,cn=etc,dc=example,dc=com . How do I find it ? Will it be safe to change password of this sudo user or it may impact the IPA Server ? Please suggest. -- Regards, Rajnesh Kumar Siwal ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- Regards, Rajnesh Kumar Siwal ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] SOLVED: Re: sudo rule working even after the user has been removed from the sudo rule
Looking into the sssd logs, I came to know there there was one more rule allowing access:- (Mon Feb 4 14:13:01 2013) [sssd[be[chargepoint.dmz]]] [hbac_get_category] (5): Category is set to 'all'. (Mon Feb 4 14:13:01 2013) [sssd[be[chargepoint.dmz]]] [ipa_hbac_evaluate_rules] (3): Access granted by HBAC rule [allow_all] (Mon Feb 4 14:13:01 2013) [sssd[be[chargepoint.dmz]]] [be_pam_handler_callback] (4): Backend returned: (0, 0, NULL) [Success] I disabled that allow_all rule, now it is fine. On Mon, Feb 4, 2013 at 2:02 PM, Rajnesh Kumar Siwal rajnesh.si...@gmail.com wrote: Here is the outuput of ldapsearch :- dn: cn=Admins,ou=sudoers,dc=example,dc=com objectClass: sudoRole sudoUser: %ctsadmin sudoHost: ALL sudoCommand: ALL sudoRunAsUser: ALL cn: Admins The rule still says that the group ctsadmin is allowed (Which should not happen after I remove the ctsadmin group from sudo access) On the IPA Web Interface there is not sudo role attached to the User rsiwal (Neither Direct nor Indirect). May be there is some bug. On Mon, Feb 4, 2013 at 1:22 PM, Rajnesh Kumar Siwal rajnesh.si...@gmail.com wrote: Hi all, I have just created a setup for sudo on the IPA Server 2.2. I modified nsswitch.conf to use ldap. ldap.conf has been modified to fetch sudo users from the IPA Server. Now, th euser in group admin can do sudo. 1. rsiwal being a user of group sudo can run all commands as sudo (FINE) 2. If I disable the rule Admins (that I admin group access to sudo), the sudo still works for the user rsiwal (Which should not work logically). 3. Removed the group Admins (including rsiwal) from the Sudo rule. The rule is still allowing user rsiwal to run sudo su -. (It should Fail) Is there some kind of caching being at the Server / client end ? -- Regards, Rajnesh Kumar Siwal -- Regards, Rajnesh Kumar Siwal -- Regards, Rajnesh Kumar Siwal ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] sudo rule working even after the user has been removed from the sudo rule
I deleted the following entry from the IPA WebUI All Except Shell (Sudo Role) but ldapsearch still fetches it (Effectively sudo works after the deletion of the rule) :- dn: cn=All Except Shell,ou=sudoers,dc=example,dc=com objectClass: sudoRole sudoUser: %ctsadmin sudoHost: ALL sudoCommand: ALL sudoRunAsUser: ALL sudoOption: !authenticate cn: All Except Shell Is it present in cache somewhere ? On Mon, Feb 4, 2013 at 2:18 PM, Rajnesh Kumar Siwal rajnesh.si...@gmail.com wrote: Looking into the sssd logs, I came to know there there was one more rule allowing access:- (Mon Feb 4 14:13:01 2013) [sssd[be[chargepoint.dmz]]] [hbac_get_category] (5): Category is set to 'all'. (Mon Feb 4 14:13:01 2013) [sssd[be[chargepoint.dmz]]] [ipa_hbac_evaluate_rules] (3): Access granted by HBAC rule [allow_all] (Mon Feb 4 14:13:01 2013) [sssd[be[chargepoint.dmz]]] [be_pam_handler_callback] (4): Backend returned: (0, 0, NULL) [Success] I disabled that allow_all rule, now it is fine. On Mon, Feb 4, 2013 at 2:02 PM, Rajnesh Kumar Siwal rajnesh.si...@gmail.com wrote: Here is the outuput of ldapsearch :- dn: cn=Admins,ou=sudoers,dc=example,dc=com objectClass: sudoRole sudoUser: %ctsadmin sudoHost: ALL sudoCommand: ALL sudoRunAsUser: ALL cn: Admins The rule still says that the group ctsadmin is allowed (Which should not happen after I remove the ctsadmin group from sudo access) On the IPA Web Interface there is not sudo role attached to the User rsiwal (Neither Direct nor Indirect). May be there is some bug. On Mon, Feb 4, 2013 at 1:22 PM, Rajnesh Kumar Siwal rajnesh.si...@gmail.com wrote: Hi all, I have just created a setup for sudo on the IPA Server 2.2. I modified nsswitch.conf to use ldap. ldap.conf has been modified to fetch sudo users from the IPA Server. Now, th euser in group admin can do sudo. 1. rsiwal being a user of group sudo can run all commands as sudo (FINE) 2. If I disable the rule Admins (that I admin group access to sudo), the sudo still works for the user rsiwal (Which should not work logically). 3. Removed the group Admins (including rsiwal) from the Sudo rule. The rule is still allowing user rsiwal to run sudo su -. (It should Fail) Is there some kind of caching being at the Server / client end ? -- Regards, Rajnesh Kumar Siwal -- Regards, Rajnesh Kumar Siwal -- Regards, Rajnesh Kumar Siwal -- Regards, Rajnesh Kumar Siwal ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] CRITICAL Failed to load upload-cacert.ldif
Hi, Running the installer of the latest stable on a fresh Fedora 18, I get the following error during install: [30/36]: Upload CA cert to the directory ipa : CRITICAL Failed to load upload-cacert.ldif: Command '/usr/bin/ldapmodify -v -f /tmp/tmpLFZEuz -H ldap://..:389 -x -D cn=Directory Manager -y /tmp/tmpYzjl4P' returned non-zero exit status 247 [31/36]: initializing group membership -- Kind regards, Jorick Astrego Netbulae B.V. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] sudo rule working even after the user has been removed from the sudo rule
Restarting IPA removed the rule that was deleted manually through GUI . It looks like a bug the IPA Webui was not able to delete the sudo rule cn: All Except Shell On Mon, Feb 4, 2013 at 3:54 PM, Rajnesh Kumar Siwal rajnesh.si...@gmail.com wrote: I deleted the following entry from the IPA WebUI All Except Shell (Sudo Role) but ldapsearch still fetches it (Effectively sudo works after the deletion of the rule) :- dn: cn=All Except Shell,ou=sudoers,dc=example,dc=com objectClass: sudoRole sudoUser: %ctsadmin sudoHost: ALL sudoCommand: ALL sudoRunAsUser: ALL sudoOption: !authenticate cn: All Except Shell Is it present in cache somewhere ? On Mon, Feb 4, 2013 at 2:18 PM, Rajnesh Kumar Siwal rajnesh.si...@gmail.com wrote: Looking into the sssd logs, I came to know there there was one more rule allowing access:- (Mon Feb 4 14:13:01 2013) [sssd[be[chargepoint.dmz]]] [hbac_get_category] (5): Category is set to 'all'. (Mon Feb 4 14:13:01 2013) [sssd[be[chargepoint.dmz]]] [ipa_hbac_evaluate_rules] (3): Access granted by HBAC rule [allow_all] (Mon Feb 4 14:13:01 2013) [sssd[be[chargepoint.dmz]]] [be_pam_handler_callback] (4): Backend returned: (0, 0, NULL) [Success] I disabled that allow_all rule, now it is fine. On Mon, Feb 4, 2013 at 2:02 PM, Rajnesh Kumar Siwal rajnesh.si...@gmail.com wrote: Here is the outuput of ldapsearch :- dn: cn=Admins,ou=sudoers,dc=example,dc=com objectClass: sudoRole sudoUser: %ctsadmin sudoHost: ALL sudoCommand: ALL sudoRunAsUser: ALL cn: Admins The rule still says that the group ctsadmin is allowed (Which should not happen after I remove the ctsadmin group from sudo access) On the IPA Web Interface there is not sudo role attached to the User rsiwal (Neither Direct nor Indirect). May be there is some bug. On Mon, Feb 4, 2013 at 1:22 PM, Rajnesh Kumar Siwal rajnesh.si...@gmail.com wrote: Hi all, I have just created a setup for sudo on the IPA Server 2.2. I modified nsswitch.conf to use ldap. ldap.conf has been modified to fetch sudo users from the IPA Server. Now, th euser in group admin can do sudo. 1. rsiwal being a user of group sudo can run all commands as sudo (FINE) 2. If I disable the rule Admins (that I admin group access to sudo), the sudo still works for the user rsiwal (Which should not work logically). 3. Removed the group Admins (including rsiwal) from the Sudo rule. The rule is still allowing user rsiwal to run sudo su -. (It should Fail) Is there some kind of caching being at the Server / client end ? -- Regards, Rajnesh Kumar Siwal -- Regards, Rajnesh Kumar Siwal -- Regards, Rajnesh Kumar Siwal -- Regards, Rajnesh Kumar Siwal -- Regards, Rajnesh Kumar Siwal ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] CRITICAL Failed to load upload-cacert.ldif
On 02/04/2013 11:31 AM, Jorick Astrego wrote: Hi, Running the installer of the latest stable on a fresh Fedora 18, I get the following error during install: [30/36]: Upload CA cert to the directory ipa : CRITICAL Failed to load upload-cacert.ldif: Command '/usr/bin/ldapmodify -v -f /tmp/tmpLFZEuz -H ldap://..:389 -x -D cn=Directory Manager -y /tmp/tmpYzjl4P' returned non-zero exit status 247 [31/36]: initializing group membership Hello Jorick, this is a benign error message as per https://fedorahosted.org/freeipa/ticket/3375 You can safely ignore it. The error message will be fixed in next release... Martin ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] RHEL 6.3 identity manual - IPA
On Mon, Feb 4, 2013 at 9:33 AM, Rajnesh Kumar Siwal rajnesh.si...@gmail.com wrote: IPA client on CentOS 5.6 was not able to take care of it.) that's why you should be using a config management tool like cfengine, puppet, chef, ansible, ., (choose your poison). Organizations usually have multiple admins and people make mistakes. Config tools ensure configs are consistent (they can also wreak havoc if not used properly haha), but that's where test/dev systems are for ;-) -- groet, natxo ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] RHEL 6.3 identity manual - IPA
Fred van Zwieten wrote: Hi, ipa-client-install should take care of setting up sudo on the client to use IPA, afaik. Not yet, https://fedorahosted.org/freeipa/ticket/3358 Essential line in nsswitch.conf: sudoers:files ldap Please read here https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/6-Beta/html-single/Identity_Management_Guide/index.html#sudo Note that the configuration file name is wrong for RHEL 6. You need to use /etc/sudo-ldap.conf. rob As for the second question. dc=example,dc=com is, well, an example. example.com http://example.com is used throughout the documentation for documentation purposes where a domain name is needed. Please replace is with you're domain, e.g. dc=yourcompanyname,dc=com Met vriendelijke groeten, * Fred* On Mon, Feb 4, 2013 at 7:29 AM, Rajnesh Kumar Siwal rajnesh.si...@gmail.com mailto:rajnesh.si...@gmail.com wrote: I am planning to use the sudo feature on IPA 2.2. By default the IPA client that I configured does not seems to use fetch the sudo user details. It looks that we need to modify nsswitch.conf and ldap.conf to support it. Can sssd take care of fetching the sudo user details ? Secondly, I am not able to find the password for uid=sudo,cn=sysaccounts,cn=etc,dc=example,dc=com . How do I find it ? Will it be safe to change password of this sudo user or it may impact the IPA Server ? Please suggest. -- Regards, Rajnesh Kumar Siwal ___ Freeipa-users mailing list Freeipa-users@redhat.com mailto: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 ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] SOLVED: Re: sudo rule working even after the user has been removed from the sudo rule
Rajnesh Kumar Siwal wrote: Looking into the sssd logs, I came to know there there was one more rule allowing access:- (Mon Feb 4 14:13:01 2013) [sssd[be[chargepoint.dmz]]] [hbac_get_category] (5): Category is set to 'all'. (Mon Feb 4 14:13:01 2013) [sssd[be[chargepoint.dmz]]] [ipa_hbac_evaluate_rules] (3): Access granted by HBAC rule [allow_all] (Mon Feb 4 14:13:01 2013) [sssd[be[chargepoint.dmz]]] [be_pam_handler_callback] (4): Backend returned: (0, 0, NULL) [Success] I disabled that allow_all rule, now it is fine. I don't know why that would make any difference. HBAC != sudo. rob On Mon, Feb 4, 2013 at 2:02 PM, Rajnesh Kumar Siwal rajnesh.si...@gmail.com wrote: Here is the outuput of ldapsearch :- dn: cn=Admins,ou=sudoers,dc=example,dc=com objectClass: sudoRole sudoUser: %ctsadmin sudoHost: ALL sudoCommand: ALL sudoRunAsUser: ALL cn: Admins The rule still says that the group ctsadmin is allowed (Which should not happen after I remove the ctsadmin group from sudo access) On the IPA Web Interface there is not sudo role attached to the User rsiwal (Neither Direct nor Indirect). May be there is some bug. On Mon, Feb 4, 2013 at 1:22 PM, Rajnesh Kumar Siwal rajnesh.si...@gmail.com wrote: Hi all, I have just created a setup for sudo on the IPA Server 2.2. I modified nsswitch.conf to use ldap. ldap.conf has been modified to fetch sudo users from the IPA Server. Now, th euser in group admin can do sudo. 1. rsiwal being a user of group sudo can run all commands as sudo (FINE) 2. If I disable the rule Admins (that I admin group access to sudo), the sudo still works for the user rsiwal (Which should not work logically). 3. Removed the group Admins (including rsiwal) from the Sudo rule. The rule is still allowing user rsiwal to run sudo su -. (It should Fail) Is there some kind of caching being at the Server / client end ? -- Regards, Rajnesh Kumar Siwal -- Regards, Rajnesh Kumar Siwal ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] sudo rule working even after the user has been removed from the sudo rule
Rajnesh Kumar Siwal wrote: I deleted the following entry from the IPA WebUI All Except Shell (Sudo Role) but ldapsearch still fetches it (Effectively sudo works after the deletion of the rule) :- dn: cn=All Except Shell,ou=sudoers,dc=example,dc=com objectClass: sudoRole sudoUser: %ctsadmin sudoHost: ALL sudoCommand: ALL sudoRunAsUser: ALL sudoOption: !authenticate cn: All Except Shell Is it present in cache somewhere ? I think we need more information on your configuration, distribution, exact package version(s) and what you've done. rob On Mon, Feb 4, 2013 at 2:18 PM, Rajnesh Kumar Siwal rajnesh.si...@gmail.com wrote: Looking into the sssd logs, I came to know there there was one more rule allowing access:- (Mon Feb 4 14:13:01 2013) [sssd[be[chargepoint.dmz]]] [hbac_get_category] (5): Category is set to 'all'. (Mon Feb 4 14:13:01 2013) [sssd[be[chargepoint.dmz]]] [ipa_hbac_evaluate_rules] (3): Access granted by HBAC rule [allow_all] (Mon Feb 4 14:13:01 2013) [sssd[be[chargepoint.dmz]]] [be_pam_handler_callback] (4): Backend returned: (0, 0, NULL) [Success] I disabled that allow_all rule, now it is fine. On Mon, Feb 4, 2013 at 2:02 PM, Rajnesh Kumar Siwal rajnesh.si...@gmail.com wrote: Here is the outuput of ldapsearch :- dn: cn=Admins,ou=sudoers,dc=example,dc=com objectClass: sudoRole sudoUser: %ctsadmin sudoHost: ALL sudoCommand: ALL sudoRunAsUser: ALL cn: Admins The rule still says that the group ctsadmin is allowed (Which should not happen after I remove the ctsadmin group from sudo access) On the IPA Web Interface there is not sudo role attached to the User rsiwal (Neither Direct nor Indirect). May be there is some bug. On Mon, Feb 4, 2013 at 1:22 PM, Rajnesh Kumar Siwal rajnesh.si...@gmail.com wrote: Hi all, I have just created a setup for sudo on the IPA Server 2.2. I modified nsswitch.conf to use ldap. ldap.conf has been modified to fetch sudo users from the IPA Server. Now, th euser in group admin can do sudo. 1. rsiwal being a user of group sudo can run all commands as sudo (FINE) 2. If I disable the rule Admins (that I admin group access to sudo), the sudo still works for the user rsiwal (Which should not work logically). 3. Removed the group Admins (including rsiwal) from the Sudo rule. The rule is still allowing user rsiwal to run sudo su -. (It should Fail) Is there some kind of caching being at the Server / client end ? -- Regards, Rajnesh Kumar Siwal -- Regards, Rajnesh Kumar Siwal -- Regards, Rajnesh Kumar Siwal ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] sudo rule working even after the user has been removed from the sudo rule
The details are as follows :- [root@ipa1 ~]# cat /etc/redhat-release CentOS release 6.3 (Final) [root@ipa1 ~]# rpm -qa|grep -i ipa ipa-server-2.2.0-17.el6_3.1.x86_64 libipa_hbac-python-1.8.0-32.el6.x86_64 ipa-pki-ca-theme-9.0.3-7.el6.noarch ipa-python-2.2.0-17.el6_3.1.x86_64 device-mapper-multipath-libs-0.4.9-56.el6_3.1.x86_64 libipa_hbac-1.8.0-32.el6.x86_64 python-iniparse-0.3.1-2.1.el6.noarch ipa-client-2.2.0-17.el6_3.1.x86_64 ipa-server-selinux-2.2.0-17.el6_3.1.x86_64 ipa-pki-common-theme-9.0.3-7.el6.noarch ipa-admintools-2.2.0-17.el6_3.1.x86_64 device-mapper-multipath-0.4.9-56.el6_3.1.x86_64 [root@ipa1 ~]# uname -a Linux ipa1.chargepoint.dmz 2.6.32-279.19.1.el6.x86_64 #1 SMP Wed Dec 19 07:05:20 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux As of now this is a standalone server being run (No replication till now) We have been interacting with the Web Interface only. One thing, the Server is in Migration Mode . The users have yet to login into the Migration Page and get their credentials created. [root@ipa1 ~]# ipa config-show Maximum username length: 32 Home directory base: /home Default shell: /bin/bash Default users group: ipausers Default e-mail domain: chargepoint.com Search time limit: 2 Search size limit: 100 User search fields: uid,givenname,sn,telephonenumber,ou,title Group search fields: cn,description Enable migration mode: TRUE Certificate Subject base: O=MYCOMPANY.DMZ Password Expiration Notification (days): 15 Password plugin features: AllowNThash SELinux user map order: guest_u:s0$xguest_u:s0$user_u:s0-s0:c0.c1023$staff_u:s0-s0:c0.c1023$unconfined_u:s0-s0:c0.c1023 Default SELinux user: guest_u:s0 We have migrated the Users/Groups from the OpenLDAP Server (after disabling compat-mode) using schema RFC 2307. I am not yet aable to migrate sudo roles so will be creating them manually. On Mon, Feb 4, 2013 at 7:59 PM, Rob Crittenden rcrit...@redhat.com wrote: Rajnesh Kumar Siwal wrote: I deleted the following entry from the IPA WebUI All Except Shell (Sudo Role) but ldapsearch still fetches it (Effectively sudo works after the deletion of the rule) :- dn: cn=All Except Shell,ou=sudoers,dc=example,dc=com objectClass: sudoRole sudoUser: %ctsadmin sudoHost: ALL sudoCommand: ALL sudoRunAsUser: ALL sudoOption: !authenticate cn: All Except Shell Is it present in cache somewhere ? I think we need more information on your configuration, distribution, exact package version(s) and what you've done. rob On Mon, Feb 4, 2013 at 2:18 PM, Rajnesh Kumar Siwal rajnesh.si...@gmail.com wrote: Looking into the sssd logs, I came to know there there was one more rule allowing access:- (Mon Feb 4 14:13:01 2013) [sssd[be[chargepoint.dmz]]] [hbac_get_category] (5): Category is set to 'all'. (Mon Feb 4 14:13:01 2013) [sssd[be[chargepoint.dmz]]] [ipa_hbac_evaluate_rules] (3): Access granted by HBAC rule [allow_all] (Mon Feb 4 14:13:01 2013) [sssd[be[chargepoint.dmz]]] [be_pam_handler_callback] (4): Backend returned: (0, 0, NULL) [Success] I disabled that allow_all rule, now it is fine. On Mon, Feb 4, 2013 at 2:02 PM, Rajnesh Kumar Siwal rajnesh.si...@gmail.com wrote: Here is the outuput of ldapsearch :- dn: cn=Admins,ou=sudoers,dc=example,dc=com objectClass: sudoRole sudoUser: %ctsadmin sudoHost: ALL sudoCommand: ALL sudoRunAsUser: ALL cn: Admins The rule still says that the group ctsadmin is allowed (Which should not happen after I remove the ctsadmin group from sudo access) On the IPA Web Interface there is not sudo role attached to the User rsiwal (Neither Direct nor Indirect). May be there is some bug. On Mon, Feb 4, 2013 at 1:22 PM, Rajnesh Kumar Siwal rajnesh.si...@gmail.com wrote: Hi all, I have just created a setup for sudo on the IPA Server 2.2. I modified nsswitch.conf to use ldap. ldap.conf has been modified to fetch sudo users from the IPA Server. Now, th euser in group admin can do sudo. 1. rsiwal being a user of group sudo can run all commands as sudo (FINE) 2. If I disable the rule Admins (that I admin group access to sudo), the sudo still works for the user rsiwal (Which should not work logically). 3. Removed the group Admins (including rsiwal) from the Sudo rule. The rule is still allowing user rsiwal to run sudo su -. (It should Fail) Is there some kind of caching being at the Server / client end ? -- Regards, Rajnesh Kumar Siwal -- Regards, Rajnesh Kumar Siwal -- Regards, Rajnesh Kumar Siwal -- Regards, Rajnesh Kumar Siwal ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] SOLVED: Re: sudo rule working even after the user has been removed from the sudo rule
Not sure but this is what resolved it. On Mon, Feb 4, 2013 at 7:51 PM, Rob Crittenden rcrit...@redhat.com wrote: Rajnesh Kumar Siwal wrote: Looking into the sssd logs, I came to know there there was one more rule allowing access:- (Mon Feb 4 14:13:01 2013) [sssd[be[chargepoint.dmz]]] [hbac_get_category] (5): Category is set to 'all'. (Mon Feb 4 14:13:01 2013) [sssd[be[chargepoint.dmz]]] [ipa_hbac_evaluate_rules] (3): Access granted by HBAC rule [allow_all] (Mon Feb 4 14:13:01 2013) [sssd[be[chargepoint.dmz]]] [be_pam_handler_callback] (4): Backend returned: (0, 0, NULL) [Success] I disabled that allow_all rule, now it is fine. I don't know why that would make any difference. HBAC != sudo. rob On Mon, Feb 4, 2013 at 2:02 PM, Rajnesh Kumar Siwal rajnesh.si...@gmail.com wrote: Here is the outuput of ldapsearch :- dn: cn=Admins,ou=sudoers,dc=example,dc=com objectClass: sudoRole sudoUser: %ctsadmin sudoHost: ALL sudoCommand: ALL sudoRunAsUser: ALL cn: Admins The rule still says that the group ctsadmin is allowed (Which should not happen after I remove the ctsadmin group from sudo access) On the IPA Web Interface there is not sudo role attached to the User rsiwal (Neither Direct nor Indirect). May be there is some bug. On Mon, Feb 4, 2013 at 1:22 PM, Rajnesh Kumar Siwal rajnesh.si...@gmail.com wrote: Hi all, I have just created a setup for sudo on the IPA Server 2.2. I modified nsswitch.conf to use ldap. ldap.conf has been modified to fetch sudo users from the IPA Server. Now, th euser in group admin can do sudo. 1. rsiwal being a user of group sudo can run all commands as sudo (FINE) 2. If I disable the rule Admins (that I admin group access to sudo), the sudo still works for the user rsiwal (Which should not work logically). 3. Removed the group Admins (including rsiwal) from the Sudo rule. The rule is still allowing user rsiwal to run sudo su -. (It should Fail) Is there some kind of caching being at the Server / client end ? -- Regards, Rajnesh Kumar Siwal -- Regards, Rajnesh Kumar Siwal -- Regards, Rajnesh Kumar Siwal ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] RHEL 6.3 identity manual - IPA
Hi Rob, This is the way I configured it:- 1. Added the details in /etc/ldap.conf :- binddn uid=sudo,cn=sysaccounts,cn=etc,dc=chargepoint,dc=dmz bindpw ssl start_tls tls_cacertfile /etc/ipa/ca.crt tls_checkpeer yes bind_timelimit 5 timelimit 15 uri ldap://ipa1.chargepoint.dmz sudoers_base ou=SUDOers,dc=chargepoint,dc=dmz sudoers_debug 1 2. Modified /etc/nsswitch.conf to fetch sudo details from ldap:- sudoers:files ldap 3. So what I can understand from the above steps is that I am interacting directly with the LDAP (389-ds) Server directly (because I am not using sss (instead ldap is being used)). On Mon, Feb 4, 2013 at 7:50 PM, Rob Crittenden rcrit...@redhat.com wrote: Fred van Zwieten wrote: Hi, ipa-client-install should take care of setting up sudo on the client to use IPA, afaik. Not yet, https://fedorahosted.org/freeipa/ticket/3358 Essential line in nsswitch.conf: sudoers:files ldap Please read here https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/6-Beta/html-single/Identity_Management_Guide/index.html#sudo Note that the configuration file name is wrong for RHEL 6. You need to use /etc/sudo-ldap.conf. rob As for the second question. dc=example,dc=com is, well, an example. example.com http://example.com is used throughout the documentation for documentation purposes where a domain name is needed. Please replace is with you're domain, e.g. dc=yourcompanyname,dc=com Met vriendelijke groeten, * Fred* On Mon, Feb 4, 2013 at 7:29 AM, Rajnesh Kumar Siwal rajnesh.si...@gmail.com mailto:rajnesh.si...@gmail.com wrote: I am planning to use the sudo feature on IPA 2.2. By default the IPA client that I configured does not seems to use fetch the sudo user details. It looks that we need to modify nsswitch.conf and ldap.conf to support it. Can sssd take care of fetching the sudo user details ? Secondly, I am not able to find the password for uid=sudo,cn=sysaccounts,cn=etc,dc=example,dc=com . How do I find it ? Will it be safe to change password of this sudo user or it may impact the IPA Server ? Please suggest. -- Regards, Rajnesh Kumar Siwal ___ Freeipa-users mailing list Freeipa-users@redhat.com mailto: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 -- Regards, Rajnesh Kumar Siwal ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] RHEL 6.3 identity manual - IPA
Rajnesh Kumar Siwal wrote: Hi Rob, This is the way I configured it:- 1. Added the details in /etc/ldap.conf :- binddn uid=sudo,cn=sysaccounts,cn=etc,dc=chargepoint,dc=dmz bindpw ssl start_tls tls_cacertfile /etc/ipa/ca.crt tls_checkpeer yes bind_timelimit 5 timelimit 15 uri ldap://ipa1.chargepoint.dmz sudoers_base ou=SUDOers,dc=chargepoint,dc=dmz sudoers_debug 1 2. Modified /etc/nsswitch.conf to fetch sudo details from ldap:- sudoers:files ldap 3. So what I can understand from the above steps is that I am interacting directly with the LDAP (389-ds) Server directly (because I am not using sss (instead ldap is being used)). What distribution and release number is the client? Can you include what you see when you execute a sudo? rob On Mon, Feb 4, 2013 at 7:50 PM, Rob Crittenden rcrit...@redhat.com wrote: Fred van Zwieten wrote: Hi, ipa-client-install should take care of setting up sudo on the client to use IPA, afaik. Not yet, https://fedorahosted.org/freeipa/ticket/3358 Essential line in nsswitch.conf: sudoers:files ldap Please read here https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/6-Beta/html-single/Identity_Management_Guide/index.html#sudo Note that the configuration file name is wrong for RHEL 6. You need to use /etc/sudo-ldap.conf. rob As for the second question. dc=example,dc=com is, well, an example. example.com http://example.com is used throughout the documentation for documentation purposes where a domain name is needed. Please replace is with you're domain, e.g. dc=yourcompanyname,dc=com Met vriendelijke groeten, * Fred* On Mon, Feb 4, 2013 at 7:29 AM, Rajnesh Kumar Siwal rajnesh.si...@gmail.com mailto:rajnesh.si...@gmail.com wrote: I am planning to use the sudo feature on IPA 2.2. By default the IPA client that I configured does not seems to use fetch the sudo user details. It looks that we need to modify nsswitch.conf and ldap.conf to support it. Can sssd take care of fetching the sudo user details ? Secondly, I am not able to find the password for uid=sudo,cn=sysaccounts,cn=etc,dc=example,dc=com . How do I find it ? Will it be safe to change password of this sudo user or it may impact the IPA Server ? Please suggest. -- Regards, Rajnesh Kumar Siwal ___ Freeipa-users mailing list Freeipa-users@redhat.com mailto: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 ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Backup and Restoration of IPA Server
Thanks Christian. I am still looking for some workaround till then. On Mon, Feb 4, 2013 at 10:16 PM, Christian Hernandez christi...@4over.com wrote: Looks like a backup/restore procedure is in the roadmap http://www.freeipa.org/page/Roadmap Thank you, Christian Hernandez 1225 Los Angeles Street Glendale, CA 91204 Phone: 877-782-2737 ext. 4566 Fax: 818-265-3152 christi...@4over.com mailto:christi...@4over.com www.4over.com http://www.4over.com On Mon, Feb 4, 2013 at 2:54 AM, Rajnesh Kumar Siwal rajnesh.si...@gmail.com wrote: Does it means that we don't have any backup / restoration process as of now for IPA 2.2 ? I am really concerned about such a critical application. It would be greate if you could please specify the set of manual commands in case they can be used for Backup / Restoration purpose. -- Regards, Rajnesh Kumar Siwal ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- Regards, Rajnesh Kumar Siwal ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] sudo rule working even after the user has been removed from the sudo rule
Rajnesh Kumar Siwal wrote: The details are as follows :- [root@ipa1 ~]# cat /etc/redhat-release CentOS release 6.3 (Final) [root@ipa1 ~]# rpm -qa|grep -i ipa ipa-server-2.2.0-17.el6_3.1.x86_64 libipa_hbac-python-1.8.0-32.el6.x86_64 ipa-pki-ca-theme-9.0.3-7.el6.noarch ipa-python-2.2.0-17.el6_3.1.x86_64 device-mapper-multipath-libs-0.4.9-56.el6_3.1.x86_64 libipa_hbac-1.8.0-32.el6.x86_64 python-iniparse-0.3.1-2.1.el6.noarch ipa-client-2.2.0-17.el6_3.1.x86_64 ipa-server-selinux-2.2.0-17.el6_3.1.x86_64 ipa-pki-common-theme-9.0.3-7.el6.noarch ipa-admintools-2.2.0-17.el6_3.1.x86_64 device-mapper-multipath-0.4.9-56.el6_3.1.x86_64 [root@ipa1 ~]# uname -a Linux ipa1.chargepoint.dmz 2.6.32-279.19.1.el6.x86_64 #1 SMP Wed Dec 19 07:05:20 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux As of now this is a standalone server being run (No replication till now) We have been interacting with the Web Interface only. The ou=sudoers entry in LDAP is a virtual entry managed by the compat plugin. It should detect deletes and remove them from its view. If you restart the dirsrv service does the entry go away? One thing, the Server is in Migration Mode . The users have yet to login into the Migration Page and get their credentials created. Migration mode has no impact on sudo. I am not yet aable to migrate sudo roles so will be creating them manually. There currently no way to import existing sudo rules. rob On Mon, Feb 4, 2013 at 7:59 PM, Rob Crittenden rcrit...@redhat.com wrote: Rajnesh Kumar Siwal wrote: I deleted the following entry from the IPA WebUI All Except Shell (Sudo Role) but ldapsearch still fetches it (Effectively sudo works after the deletion of the rule) :- dn: cn=All Except Shell,ou=sudoers,dc=example,dc=com objectClass: sudoRole sudoUser: %ctsadmin sudoHost: ALL sudoCommand: ALL sudoRunAsUser: ALL sudoOption: !authenticate cn: All Except Shell Is it present in cache somewhere ? I think we need more information on your configuration, distribution, exact package version(s) and what you've done. rob On Mon, Feb 4, 2013 at 2:18 PM, Rajnesh Kumar Siwal rajnesh.si...@gmail.com wrote: Looking into the sssd logs, I came to know there there was one more rule allowing access:- (Mon Feb 4 14:13:01 2013) [sssd[be[chargepoint.dmz]]] [hbac_get_category] (5): Category is set to 'all'. (Mon Feb 4 14:13:01 2013) [sssd[be[chargepoint.dmz]]] [ipa_hbac_evaluate_rules] (3): Access granted by HBAC rule [allow_all] (Mon Feb 4 14:13:01 2013) [sssd[be[chargepoint.dmz]]] [be_pam_handler_callback] (4): Backend returned: (0, 0, NULL) [Success] I disabled that allow_all rule, now it is fine. On Mon, Feb 4, 2013 at 2:02 PM, Rajnesh Kumar Siwal rajnesh.si...@gmail.com wrote: Here is the outuput of ldapsearch :- dn: cn=Admins,ou=sudoers,dc=example,dc=com objectClass: sudoRole sudoUser: %ctsadmin sudoHost: ALL sudoCommand: ALL sudoRunAsUser: ALL cn: Admins The rule still says that the group ctsadmin is allowed (Which should not happen after I remove the ctsadmin group from sudo access) On the IPA Web Interface there is not sudo role attached to the User rsiwal (Neither Direct nor Indirect). May be there is some bug. On Mon, Feb 4, 2013 at 1:22 PM, Rajnesh Kumar Siwal rajnesh.si...@gmail.com wrote: Hi all, I have just created a setup for sudo on the IPA Server 2.2. I modified nsswitch.conf to use ldap. ldap.conf has been modified to fetch sudo users from the IPA Server. Now, th euser in group admin can do sudo. 1. rsiwal being a user of group sudo can run all commands as sudo (FINE) 2. If I disable the rule Admins (that I admin group access to sudo), the sudo still works for the user rsiwal (Which should not work logically). 3. Removed the group Admins (including rsiwal) from the Sudo rule. The rule is still allowing user rsiwal to run sudo su -. (It should Fail) Is there some kind of caching being at the Server / client end ? -- Regards, Rajnesh Kumar Siwal -- Regards, Rajnesh Kumar Siwal -- Regards, Rajnesh Kumar Siwal ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Replication flood caused by ipa_lockout plugin
Loris Santamaria wrote: Hi on a production IPA realm with 3 servers and about 2000 users we were experimenting a very high load on the servers. Further investigation showed that the high load was caused by a lot of writes done by the IPA dirsrv instance. Activating the audit logging showed a lot of MOD operation to the directory, like these: time: 20130204140217 dn: uid=,cn=users,cn=accounts,dc=XXX,dc=XXX,dc=XX changetype: modify replace: modifiersName modifiersName: cn=IPA Lockout,cn=plugins,cn=config - replace: modifyTimestamp modifyTimestamp: 20130204183216Z - replace: entryusn entryusn: 3472506 - time: 20130204140217 dn: uid=,cn=users,cn=accounts,dc=XXX,dc=XXX,dc=XX changetype: modify replace: modifiersName modifiersName: cn=IPA Lockout,cn=plugins,cn=config - replace: modifyTimestamp modifyTimestamp: 20130204183217Z - replace: entryusn entryusn: 3472507 There is an HTTP proxy server which connects to IPA to perform user authorization and it seems that it does a BIND on behalf of the user for every page the user visits... and for every successful BIND the IPA Lockout plugin does the MODs indicated above. It is to note that currently we are not locking accounts on failed authentication to the directory, so the above MODs seem completely unnecessary. For the time being we disabled the ipa lockout plugin, but we would like to know if the behavior highlighted above is expected or if we should file a bug. Fixed in 389-ds-base 1.2.11. See bug https://bugzilla.redhat.com/show_bug.cgi?id=782975 The commit is: https://lists.fedoraproject.org/pipermail/389-commits/2012-May/005209.html rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Backup and Restoration of IPA Server
I use the following to dump my LDAP databases: #!/bin/sh /usr/lib64/dirsrv/slapd-PKI-IPA/db2ldif.pl -D cn=directory manager -j /var/lib/dirsrv/scripts-YOUR-KERB-REALM/dmanager.credentials -n ipaca -a /var/lib/dirsrv/slapd-PKI-IPA/bak/ipaca.`/bin/date +%Y%m%d%H%M%S`.ldif /var/lib/dirsrv/scripts-YOUR-KERB-REALM/db2ldif.pl -D cn=directory manager -j /var/lib/dirsrv/scripts-YOUR-KERB-REALM/dmanager.credentials -n userroot -a /var/lib/dirsrv/slapd-YOUR-KERB-REALM/bak/userroot.`/bin/date +%Y%m%d%H%M%S`.ldif I have that in a script that's run by cron, followed up by a script to delete old backups. Netbackup takes care of backing up the systems. dmanager.credentials just has the Directory Manager password in it in plain test. Not optimal, but it works. --Jason On Mon, Feb 4, 2013 at 10:51 AM, Rajnesh Kumar Siwal rajnesh.si...@gmail.com wrote: Thanks Christian. I am still looking for some workaround till then. On Mon, Feb 4, 2013 at 10:16 PM, Christian Hernandez christi...@4over.com wrote: Looks like a backup/restore procedure is in the roadmap http://www.freeipa.org/page/Roadmap Thank you, Christian Hernandez 1225 Los Angeles Street Glendale, CA 91204 Phone: 877-782-2737 ext. 4566 Fax: 818-265-3152 christi...@4over.com mailto:christi...@4over.com www.4over.com http://www.4over.com On Mon, Feb 4, 2013 at 2:54 AM, Rajnesh Kumar Siwal rajnesh.si...@gmail.com wrote: Does it means that we don't have any backup / restoration process as of now for IPA 2.2 ? I am really concerned about such a critical application. It would be greate if you could please specify the set of manual commands in case they can be used for Backup / Restoration purpose. -- Regards, Rajnesh Kumar Siwal ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- Regards, Rajnesh Kumar Siwal ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- The government is going to read our mail anyway, might as well make it tough for them. GPG Public key ID: B6A1A7C6 ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] IPA Create User
Thank you John for your helpful reply. Near real time will be sufficient - within the 5 min range. Will it be practical when managing a user's groups - these can happen when a user moves within the organization or is terminated. On Fri, Feb 1, 2013 at 8:59 PM, John Dennis jden...@redhat.com wrote: On 02/01/2013 10:26 PM, It Meme wrote: Hi Dimitri: Thank you for your helpful posts. Do you know of any organization that provisions accounts and groups in real-time, from an external IdM system, to IPA, via CLI? We have an IdM system which will be reading data from HR, and making 'joiner, mover, leaver, decisions' - accounts are provisioned, deleted, groups changed etc based on the HR data. Is it feasible to consider the IdM system calling the CLI, via scripts, to create/delete accounts, manage groups, in near real-time? Calling a script does not take much time (especially compared to the elapsed time it takes for the command to complete), it would only be an issue if you were trying to do a number of transactions per second, but it doesn't sound like your HR dept is going to need that kind of throughput. It's also possible to call our API from Python, others have done this. Whether your IdM forks out to a shell script or to a Python script would be negligible compared to the total elapsed time to complete the operation. I suppose the answer to your question begs another, what's your definition of real time? If your IdM triggers a transaction and it completes within a few seconds is that real time? John -- 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] IPA Create User
On 02/04/2013 07:07 PM, It Meme wrote: Thank you John for your helpful reply. Near real time will be sufficient - within the 5 min range. Will it be practical when managing a user's groups - these can happen when a user moves within the organization or is terminated. I'm not sure we've done timing measurements on various operations, but in general most IPA commands are fast executing in sub-second elapsed time on the server. Latency on the client side can be introduced by such things as authentication (mitigated by the use of client sessions), network latencies between the client and the server, DNS resolution, etc. Those types of network induced latencies can be very hard to predict because it depends on a number of external factors having nothing to do with IPA per se. Elapsed time on the server is also influenced by LDAP tuning (e.g. indexes), memory, available CPU, etc. Things like adding a user, or adding a user to a group are not compute intensive and should execute quickly. For your intended use I don't see any issues with the elapsed time for command execution. -- 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] IPA Create User
Thank you John - much appreciated. Sent from my iPhone On 2013-02-04, at 16:35, John Dennis jden...@redhat.com wrote: On 02/04/2013 07:07 PM, It Meme wrote: Thank you John for your helpful reply. Near real time will be sufficient - within the 5 min range. Will it be practical when managing a user's groups - these can happen when a user moves within the organization or is terminated. I'm not sure we've done timing measurements on various operations, but in general most IPA commands are fast executing in sub-second elapsed time on the server. Latency on the client side can be introduced by such things as authentication (mitigated by the use of client sessions), network latencies between the client and the server, DNS resolution, etc. Those types of network induced latencies can be very hard to predict because it depends on a number of external factors having nothing to do with IPA per se. Elapsed time on the server is also influenced by LDAP tuning (e.g. indexes), memory, available CPU, etc. Things like adding a user, or adding a user to a group are not compute intensive and should execute quickly. For your intended use I don't see any issues with the elapsed time for command execution. -- 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
[Freeipa-users] Java JSON Example - IPA API
Hi. Would be any online examples for calling the IPA JSON APIs from a java application? Thanks. Sent from my iPhone ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
