Re: [Freeipa-users] sudo environmental variables
I think i got the options confused. I tried using Options: always_set_home but this did not do anything either. On Thu, Jul 16, 2015 at 3:32 PM, Megan . nagem...@gmail.com wrote: Good Afternoon, I am struggling with sudo and environmental variables. I feel like i'm missing something silly and just need another set of eyes. I have a situation where i need a user(userA) to run a script using sudo as another user (userB). I want to use some environmental variables from userB (script owner) for the purpose of the script. Specifically $PATH and HTTP_PROXY. I have the PATH and HTTP_PROXY set in /home/userB/.bashrc but when userA uses sudo -u userB script it doesn't pickup those environmental variables. I tried using the sudo options and set env_keep+=HTTP_PROXY and that still didn't work. The only thing i found worked so far was adding. i've also tried the sudo -i option and that fails. Thanks in advance. [megantest@tools-dit ~]$ sudo -ll Matching Defaults entries for megantest on this host: requiretty, !visiblepw, always_set_home, env_reset, env_keep=COLORS DISPLAY HOSTNAME HISTSIZE INPUTRC KDEDIR LS_COLORS, env_keep+=MAIL PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE, env_keep+=LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES, env_keep+=LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE, env_keep+=LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY, secure_path=/sbin\:/bin\:/usr/sbin\:/usr/bin, passprompt=Enter RSA PIN+token: User megantest may run the following commands on this host: SSSD Role: script_testing RunAsUsers: testuser Options: env_keep+=HTTP_PROXY Commands: /home/testuser/script.sh -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
[Freeipa-users] sudo environmental variables
Good Afternoon, I am struggling with sudo and environmental variables. I feel like i'm missing something silly and just need another set of eyes. I have a situation where i need a user(userA) to run a script using sudo as another user (userB). I want to use some environmental variables from userB (script owner) for the purpose of the script. Specifically $PATH and HTTP_PROXY. I have the PATH and HTTP_PROXY set in /home/userB/.bashrc but when userA uses sudo -u userB script it doesn't pickup those environmental variables. I tried using the sudo options and set env_keep+=HTTP_PROXY and that still didn't work. The only thing i found worked so far was adding. i've also tried the sudo -i option and that fails. Thanks in advance. [megantest@tools-dit ~]$ sudo -ll Matching Defaults entries for megantest on this host: requiretty, !visiblepw, always_set_home, env_reset, env_keep=COLORS DISPLAY HOSTNAME HISTSIZE INPUTRC KDEDIR LS_COLORS, env_keep+=MAIL PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE, env_keep+=LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES, env_keep+=LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE, env_keep+=LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY, secure_path=/sbin\:/bin\:/usr/sbin\:/usr/bin, passprompt=Enter RSA PIN+token: User megantest may run the following commands on this host: SSSD Role: script_testing RunAsUsers: testuser Options: env_keep+=HTTP_PROXY Commands: /home/testuser/script.sh -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] getting rid of nsds5ReplConflict
Thank you for the reply. I think I just got frustrated. I uninstalled ipa on the dir2 replica then set it back up again as a replica. Everything seems to be replicating just fine without errors now. I know that this isn't the preferred or documented solution but i needed the server back online asap. When i run ipa-replica-manage list-ruv i see dir2 listed twice. Is this a concern? [root@dir1 ipa]# ipa-replica-manage list-ruv dir1.example.com:389: 4 dir3.example.com:389: 5 dir2.example.com:389: 6 dir2.example.com:389: 8 On Tue, May 19, 2015 at 12:37 PM, Rich Megginson rmegg...@redhat.com wrote: On 05/19/2015 10:10 AM, Megan . wrote: I'm struggling with a replication conflict. I had three masters, dir1, dir2, dir3. There were some weird issues with dir2 where I was getting error 49 (Invalid credentials) without any real information. Where did you see this? command line output? Of what command? In a log file? Which log file? Can you post the exact error message along with the context? When i did ipa-replica-manage list-ruv i saw dir2 twice. Can you post the output? I couldn't get it straight What does get it straight mean? Does it mean you ran some commands? If so, what commands did you run and what was the result? so i decided to try to re-create the replica. I disconnected the replica, ran the del for the replica. When i check for replication conflicts i still see it in there and I can't seem to get it to go away. Deleting and recreating the replica will not remove the replication conflict if the conflict has been replicated to other servers. This document doesn't say anything about resolving replica conflict entries by deleting and re-adding replicas: https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html It only shows up on one of the remaining masters. I was trying to follow the documentation The link above? and use ldapmodify to change the dn to cn=olddir2.somewhere.example.something.com7475d90c but everything i seem to be trying doesn't work. What exactly did you do? I'm assuming this entry needs to be cleared up before i can successfully setup dir2 again as a replica. No, not necessarily. Any help would be greatly appreciated. Thanks! [root@dir1 ~]# ldapsearch -x -D cn=directory manager -W -b dc=somewhere,dc=example,dc=something,dc=com nsds5ReplConflict=* \* nsds5ReplConflict Enter LDAP Password: # extended LDIF # # LDAPv3 # base dc=somewhere,dc=example,dc=something,dc=com with scope subtree # filter: nsds5ReplConflict=* # requesting: * nsds5ReplConflict # # dir2.somewhere.example.something.com + 7475d90c-f34911e4-99a0ab24-58022cdf, masters , ipa, etc, somewhere.example.something.com dn: cn=dir2.somewhere.example.something.com+nsuniqueid=7475d90c-f34911e4-99a0ab24-5802 2cdf,cn=masters,cn=ipa,cn=etc,dc=somewhere,dc=example,dc=something,dc=com nsds5ReplConflict: namingConflict cn=dir2.somewhere.example.something.com,cn=masters,c n=ipa,cn=etc,dc=somewhere,dc=example,dc=something,dc=com objectClass: top objectClass: nsContainer cn: dir2.somewhere.example.something.com # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
[Freeipa-users] getting rid of nsds5ReplConflict
I'm struggling with a replication conflict. I had three masters, dir1, dir2, dir3. There were some weird issues with dir2 where I was getting error 49 (Invalid credentials) without any real information. When i did ipa-replica-manage list-ruv i saw dir2 twice. I couldn't get it straight so i decided to try to re-create the replica. I disconnected the replica, ran the del for the replica. When i check for replication conflicts i still see it in there and I can't seem to get it to go away. It only shows up on one of the remaining masters. I was trying to follow the documentation and use ldapmodify to change the dn to cn=olddir2.somewhere.example.something.com7475d90c but everything i seem to be trying doesn't work. I'm assuming this entry needs to be cleared up before i can successfully setup dir2 again as a replica. Any help would be greatly appreciated. Thanks! [root@dir1 ~]# ldapsearch -x -D cn=directory manager -W -b dc=somewhere,dc=example,dc=something,dc=com nsds5ReplConflict=* \* nsds5ReplConflict Enter LDAP Password: # extended LDIF # # LDAPv3 # base dc=somewhere,dc=example,dc=something,dc=com with scope subtree # filter: nsds5ReplConflict=* # requesting: * nsds5ReplConflict # # dir2.somewhere.example.something.com + 7475d90c-f34911e4-99a0ab24-58022cdf, masters , ipa, etc, somewhere.example.something.com dn: cn=dir2.somewhere.example.something.com+nsuniqueid=7475d90c-f34911e4-99a0ab24-5802 2cdf,cn=masters,cn=ipa,cn=etc,dc=somewhere,dc=example,dc=something,dc=com nsds5ReplConflict: namingConflict cn=dir2.somewhere.example.something.com,cn=masters,c n=ipa,cn=etc,dc=somewhere,dc=example,dc=something,dc=com objectClass: top objectClass: nsContainer cn: dir2.somewhere.example.something.com # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
[Freeipa-users] Host groups not working with SUDO Rules
I'm having an issue where user's can't use sudo commands on ipa client hosts. I previously thought my issues with sudo were related to the type of commands, but I've narrowed it down to an issue with using host groups in the sudo rule access list instead of listing the hosts directly. When I use the host group with the host in it, my user cannot run the sudo commands on the host. I have multiple debugs on in my sssd.conf and I have a ton of log files but i'm not sure what will be useful in helping me troubleshoot. IPA client 3.0.0 Centos 6.6 To reproduce: Add in sudo command Create command group Create host group Add host into host group create sudo rule use user groups, host groups, and sudo command groups to create rule Go onto client server clear out /var/lib/sss/db restart sssd test sudo for a user in the user group Test will fail. If i do the same steps and just list the hosts for the sudo rule access, and not the host groups, the sudo commands works fine for the user. When i'm using host groups in the sssd_EXAMPLE.COM.log i see what looks like a successful check for the host in the host group. My hostgroup is uatcluster: (Thu May 7 18:57:02 2015) [sssd[be[EXAMPLE.COM]]] [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse domain SID from [(null)] (Thu May 7 18:57:02 2015) [sssd[be[EXAMPLE.COM]]] [sdap_attrs_get_sid_str] (0x0080): No [objectSIDString] attribute while id-mapping. [0][Success] (Thu May 7 18:57:02 2015) [sssd[be[EXAMPLE.COM]]] [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse domain SID from [(null)] (Thu May 7 18:57:02 2015) [sssd[be[EXAMPLE.COM]]] [acctinfo_callback] (0x0100): Request processed. Returned 0,0,Success (Thu May 7 18:57:02 2015) [sssd[be[EXAMPLE.COM]]] [be_get_account_info] (0x0100): Got request for [4100][1][name=uatcluster] (Thu May 7 18:57:02 2015) [sssd[be[EXAMPLE.COM]]] [acctinfo_callback] (0x0100): Request processed. Returned 0,0,Success (Thu May 7 18:57:09 2015) [sssd[be[EXAMPLE.COM]]] [cleanup_groups] (0x0200): Found 3 expired group entries! i tried to recreate all of my host groups, and uninstall and reinstall the ipa client on one of my hosts. Nothing seems to fix the issue. I'm not really sure where to go from here. It took me 4 days to figure get this far. I'm only mostly sure this is the issue. Thanks in advance for any help. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Host groups not working with SUDO Rules
On the server I am running CentOS release 6.6 (Final) with: sssd-ipa-1.11.6-30.el6_6.4.x86_64 ipa-server-3.0.0-42.el6.centos.x86_64 sudo-1.8.6p3-15.el6.x86_64 On the clients I'm running CentOS release 6.6 (Final): sssd-ipa-1.11.6-30.el6_6.4.x86_64 ipa-client-3.0.0-42.el6.centos.x86_64 sudo-1.8.6p3-15.el6.x86_64 On Thu, May 7, 2015 at 3:15 PM, Dmitri Pal d...@redhat.com wrote: On 05/07/2015 03:07 PM, Megan . wrote: I'm having an issue where user's can't use sudo commands on ipa client hosts. I previously thought my issues with sudo were related to the type of commands, but I've narrowed it down to an issue with using host groups in the sudo rule access list instead of listing the hosts directly. When I use the host group with the host in it, my user cannot run the sudo commands on the host. I have multiple debugs on in my sssd.conf and I have a ton of log files but i'm not sure what will be useful in helping me troubleshoot. IPA client 3.0.0 Centos 6.6 To reproduce: Add in sudo command Create command group Create host group Add host into host group create sudo rule use user groups, host groups, and sudo command groups to create rule Go onto client server clear out /var/lib/sss/db restart sssd test sudo for a user in the user group Test will fail. If i do the same steps and just list the hosts for the sudo rule access, and not the host groups, the sudo commands works fine for the user. When i'm using host groups in the sssd_EXAMPLE.COM.log i see what looks like a successful check for the host in the host group. My hostgroup is uatcluster: (Thu May 7 18:57:02 2015) [sssd[be[EXAMPLE.COM]]] [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse domain SID from [(null)] (Thu May 7 18:57:02 2015) [sssd[be[EXAMPLE.COM]]] [sdap_attrs_get_sid_str] (0x0080): No [objectSIDString] attribute while id-mapping. [0][Success] (Thu May 7 18:57:02 2015) [sssd[be[EXAMPLE.COM]]] [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse domain SID from [(null)] (Thu May 7 18:57:02 2015) [sssd[be[EXAMPLE.COM]]] [acctinfo_callback] (0x0100): Request processed. Returned 0,0,Success (Thu May 7 18:57:02 2015) [sssd[be[EXAMPLE.COM]]] [be_get_account_info] (0x0100): Got request for [4100][1][name=uatcluster] (Thu May 7 18:57:02 2015) [sssd[be[EXAMPLE.COM]]] [acctinfo_callback] (0x0100): Request processed. Returned 0,0,Success (Thu May 7 18:57:09 2015) [sssd[be[EXAMPLE.COM]]] [cleanup_groups] (0x0200): Found 3 expired group entries! i tried to recreate all of my host groups, and uninstall and reinstall the ipa client on one of my hosts. Nothing seems to fix the issue. I'm not really sure where to go from here. It took me 4 days to figure get this far. I'm only mostly sure this is the issue. Thanks in advance for any help. What version are you using? This sounds familiar. I vaguely remember a bug being fixed in this area some time ago. -- Thank you, Dmitri Pal Director of Engineering for IdM portfolio Red Hat, Inc. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] regex with sudo commands
Ok, Thank you. On Tue, May 5, 2015 at 5:35 AM, Pavel Březina pbrez...@redhat.com wrote: On 05/05/2015 10:53 AM, Martin Kosek wrote: On 05/05/2015 03:37 AM, Megan . wrote: Good Evening! I'm running 3.0.0-42 on Centos 6.6. I setup a number of sudo commands today with regular expressions and now users seem to be having issues running any sudo command. Are there any known issues with having regex in sudo commands within the IPA server? Here is an example of a sudo rule I have setup. When my user runs sudo -ll he only sees the below command, and he should have a large number of commands available (like /sbin/service httpd restart) SSSD Role: deploy for UAT RunAsUsers: appusr Commands: /usr/bin/python /usr/share/appusr/onworld-tools/scripts/configure.py -l [a-zA-Z0-9\-_/]* -e EPSG[0-9][0-9][0-9][0-9] -t [a-z]* /usr/share/appusr/apache-ant-1.9.4/bin/ant -f /usr/share/appusr/onworld-tools/scripts/config_deploy.xml deploy-[a-zA-Z0-9\-] -Denv=uat I also purged /var/lib/sss/db and restated sssd thinking it might be related to caching but it didn't help. Thanks in advance! CCing Pavel Brezina for reference as the sudo guru, but I think he will miss more information for your bug. For example, it would help to show the SUDO commands for IPA that should be applied for the respective users: $ ipa sudorule-show ... Martin I believe Tomas already provided the correct answer. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
[Freeipa-users] regex with sudo commands
Good Evening! I'm running 3.0.0-42 on Centos 6.6. I setup a number of sudo commands today with regular expressions and now users seem to be having issues running any sudo command. Are there any known issues with having regex in sudo commands within the IPA server? Here is an example of a sudo rule I have setup. When my user runs sudo -ll he only sees the below command, and he should have a large number of commands available (like /sbin/service httpd restart) SSSD Role: deploy for UAT RunAsUsers: appusr Commands: /usr/bin/python /usr/share/appusr/onworld-tools/scripts/configure.py -l [a-zA-Z0-9\-_/]* -e EPSG[0-9][0-9][0-9][0-9] -t [a-z]* /usr/share/appusr/apache-ant-1.9.4/bin/ant -f /usr/share/appusr/onworld-tools/scripts/config_deploy.xml deploy-[a-zA-Z0-9\-] -Denv=uat I also purged /var/lib/sss/db and restated sssd thinking it might be related to caching but it didn't help. Thanks in advance! -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Decrypt integrity check failed on client
Thank you, that worked. On Fri, Jan 23, 2015 at 6:40 PM, Dmitri Pal d...@redhat.com wrote: On 01/23/2015 03:58 PM, Megan . wrote: Good Day! I installed a new IPA server (same name as the old one) on a new server. I added a single user for testing. I have a client that was previously a client on the old IPA server, i ran ipa-client-install --uninstall, removed the /etc/ipa/ca.crt, removed items left in /tmp, and rebooted. I then updated /etc/hosts to point to the new IPA server, and ran ipa-client-install --no-ntp. The install went fine. Now when i try to login to the client using my new test user, it doesn't work. I get the below errors. I am able to login to the new directory server with my new user, was prompted to change my password, and was able to log back in just fine. Any help is appreciated. Thanks. Client: [root@test3-vm ~]# uname -a Linux test3-vm.mydomain.com 2.6.32-504.1.3.el6.x86_64 #1 SMP Tue Nov 11 17:57:25 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux [root@test3-vm ~]# cat /etc/redhat-release CentOS release 6.6 (Final) [root@test3-vm ~]# rpm -qa | grep ipa-client ipa-client-3.0.0-42.el6.centos.x86_64 Server: [root@dir1 ~]# uname -a Linux dir1.mydomain.com 2.6.32-504.3.3.el6.x86_64 #1 SMP Wed Dec 17 01:55:02 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux [root@dir1 ~]# cat /etc/redhat-release CentOS release 6.6 (Final) [root@dir1 ~]# rpm -qa | grep ipa-server ipa-server-selinux-3.0.0-42.el6.centos.x86_64 ipa-server-3.0.0-42.el6.centos.x86_64 From client: [root@test3-vm sssd]# klist -kt /etc/krb5.keytab Keytab name: FILE:/etc/krb5.keytab KVNO Timestamp Principal - 1 01/23/15 14:27:05 host/test3-vm.mydomain@mydomain.com 1 01/23/15 14:27:05 host/test3-vm.mydomain@mydomain.com 1 01/23/15 14:27:05 host/test3-vm.mydomain@mydomain.com 1 01/23/15 14:27:06 host/test3-vm.mydomain@mydomain.com [root@test3-vm sssd] This works fine: [root@test3-vm sssd]# kinit tester1 Password for test...@mydomain.com: [root@test3-vm sssd]# [root@test3-vm sssd]# tail -200 krb5_child.log (Fri Jan 23 14:43:01 2015) [[sssd[krb5_child[2812 [unpack_buffer] (0x0100): cmd [241] uid [1004] gid [1004] validate [true] enterprise principal [false] offline [false] UPN [test...@mydomain.com] (Fri Jan 23 14:43:01 2015) [[sssd[krb5_child[2812 [unpack_buffer] (0x0100): ccname: [FILE:/tmp/krb5cc_1004_XX] keytab: [/etc/krb5.keytab] (Fri Jan 23 14:43:01 2015) [[sssd[krb5_child[2812 [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_RENEWABLE_LIFETIME] from environment. (Fri Jan 23 14:43:01 2015) [[sssd[krb5_child[2812 [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from environment. (Fri Jan 23 14:43:01 2015) [[sssd[krb5_child[2812 [set_canonicalize_option] (0x0100): SSSD_KRB5_CANONICALIZE is set to [true] (Fri Jan 23 14:43:01 2015) [[sssd[krb5_child[2812 [k5c_setup_fast] (0x0100): SSSD_KRB5_FAST_PRINCIPAL is set to [host/test3-vm.mydomain@mydomain.com] (Fri Jan 23 14:43:01 2015) [[sssd[krb5_child[2812 [check_fast_ccache] (0x0200): FAST TGT is still valid. (Fri Jan 23 14:43:01 2015) [[sssd[krb5_child[2812 [get_and_save_tgt] (0x0020): 981: [-1765328353][Decrypt integrity check failed] (Fri Jan 23 14:43:01 2015) [[sssd[krb5_child[2812 [map_krb5_error] (0x0020): 1043: [-1765328353][Decrypt integrity check failed] (Fri Jan 23 14:43:01 2015) [[sssd[krb5_child[2812 [k5c_send_data] (0x0200): Received error code 1432158218 (Fri Jan 23 15:39:54 2015) [[sssd[krb5_child[2900 [unpack_buffer] (0x0100): cmd [241] uid [1004] gid [1004] validate [true] enterprise principal [false] offline [false] UPN [test...@mydomain.com] (Fri Jan 23 15:39:54 2015) [[sssd[krb5_child[2900 [unpack_buffer] (0x0100): ccname: [FILE:/tmp/krb5cc_1004_XX] keytab: [/etc/krb5.keytab] (Fri Jan 23 15:39:54 2015) [[sssd[krb5_child[2900 [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_RENEWABLE_LIFETIME] from environment. (Fri Jan 23 15:39:54 2015) [[sssd[krb5_child[2900 [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from environment. (Fri Jan 23 15:39:54 2015) [[sssd[krb5_child[2900 [set_canonicalize_option] (0x0100): SSSD_KRB5_CANONICALIZE is set to [true] (Fri Jan 23 15:39:54 2015) [[sssd[krb5_child[2900 [k5c_setup_fast] (0x0100): SSSD_KRB5_FAST_PRINCIPAL is set to [host/test3-vm.mydomain@mydomain.com] (Fri Jan 23 15:39:54 2015) [[sssd[krb5_child[2900 [check_fast_ccache] (0x0200): FAST TGT is still valid. (Fri Jan 23 15:39:54 2015) [[sssd[krb5_child[2900 [get_and_save_tgt] (0x0020): 981: [-1765328353][Decrypt integrity check failed] (Fri Jan 23 15:39:54 2015) [[sssd[krb5_child[2900 [map_krb5_error] (0x0020): 1043: [-1765328353][Decrypt integrity check failed] (Fri Jan 23 15:39:54 2015) [[sssd[krb5_child[2900
[Freeipa-users] Decrypt integrity check failed on client
Good Day! I installed a new IPA server (same name as the old one) on a new server. I added a single user for testing. I have a client that was previously a client on the old IPA server, i ran ipa-client-install --uninstall, removed the /etc/ipa/ca.crt, removed items left in /tmp, and rebooted. I then updated /etc/hosts to point to the new IPA server, and ran ipa-client-install --no-ntp. The install went fine. Now when i try to login to the client using my new test user, it doesn't work. I get the below errors. I am able to login to the new directory server with my new user, was prompted to change my password, and was able to log back in just fine. Any help is appreciated. Thanks. Client: [root@test3-vm ~]# uname -a Linux test3-vm.mydomain.com 2.6.32-504.1.3.el6.x86_64 #1 SMP Tue Nov 11 17:57:25 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux [root@test3-vm ~]# cat /etc/redhat-release CentOS release 6.6 (Final) [root@test3-vm ~]# rpm -qa | grep ipa-client ipa-client-3.0.0-42.el6.centos.x86_64 Server: [root@dir1 ~]# uname -a Linux dir1.mydomain.com 2.6.32-504.3.3.el6.x86_64 #1 SMP Wed Dec 17 01:55:02 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux [root@dir1 ~]# cat /etc/redhat-release CentOS release 6.6 (Final) [root@dir1 ~]# rpm -qa | grep ipa-server ipa-server-selinux-3.0.0-42.el6.centos.x86_64 ipa-server-3.0.0-42.el6.centos.x86_64 From client: [root@test3-vm sssd]# klist -kt /etc/krb5.keytab Keytab name: FILE:/etc/krb5.keytab KVNO Timestamp Principal - 1 01/23/15 14:27:05 host/test3-vm.mydomain@mydomain.com 1 01/23/15 14:27:05 host/test3-vm.mydomain@mydomain.com 1 01/23/15 14:27:05 host/test3-vm.mydomain@mydomain.com 1 01/23/15 14:27:06 host/test3-vm.mydomain@mydomain.com [root@test3-vm sssd] This works fine: [root@test3-vm sssd]# kinit tester1 Password for test...@mydomain.com: [root@test3-vm sssd]# [root@test3-vm sssd]# tail -200 krb5_child.log (Fri Jan 23 14:43:01 2015) [[sssd[krb5_child[2812 [unpack_buffer] (0x0100): cmd [241] uid [1004] gid [1004] validate [true] enterprise principal [false] offline [false] UPN [test...@mydomain.com] (Fri Jan 23 14:43:01 2015) [[sssd[krb5_child[2812 [unpack_buffer] (0x0100): ccname: [FILE:/tmp/krb5cc_1004_XX] keytab: [/etc/krb5.keytab] (Fri Jan 23 14:43:01 2015) [[sssd[krb5_child[2812 [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_RENEWABLE_LIFETIME] from environment. (Fri Jan 23 14:43:01 2015) [[sssd[krb5_child[2812 [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from environment. (Fri Jan 23 14:43:01 2015) [[sssd[krb5_child[2812 [set_canonicalize_option] (0x0100): SSSD_KRB5_CANONICALIZE is set to [true] (Fri Jan 23 14:43:01 2015) [[sssd[krb5_child[2812 [k5c_setup_fast] (0x0100): SSSD_KRB5_FAST_PRINCIPAL is set to [host/test3-vm.mydomain@mydomain.com] (Fri Jan 23 14:43:01 2015) [[sssd[krb5_child[2812 [check_fast_ccache] (0x0200): FAST TGT is still valid. (Fri Jan 23 14:43:01 2015) [[sssd[krb5_child[2812 [get_and_save_tgt] (0x0020): 981: [-1765328353][Decrypt integrity check failed] (Fri Jan 23 14:43:01 2015) [[sssd[krb5_child[2812 [map_krb5_error] (0x0020): 1043: [-1765328353][Decrypt integrity check failed] (Fri Jan 23 14:43:01 2015) [[sssd[krb5_child[2812 [k5c_send_data] (0x0200): Received error code 1432158218 (Fri Jan 23 15:39:54 2015) [[sssd[krb5_child[2900 [unpack_buffer] (0x0100): cmd [241] uid [1004] gid [1004] validate [true] enterprise principal [false] offline [false] UPN [test...@mydomain.com] (Fri Jan 23 15:39:54 2015) [[sssd[krb5_child[2900 [unpack_buffer] (0x0100): ccname: [FILE:/tmp/krb5cc_1004_XX] keytab: [/etc/krb5.keytab] (Fri Jan 23 15:39:54 2015) [[sssd[krb5_child[2900 [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_RENEWABLE_LIFETIME] from environment. (Fri Jan 23 15:39:54 2015) [[sssd[krb5_child[2900 [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from environment. (Fri Jan 23 15:39:54 2015) [[sssd[krb5_child[2900 [set_canonicalize_option] (0x0100): SSSD_KRB5_CANONICALIZE is set to [true] (Fri Jan 23 15:39:54 2015) [[sssd[krb5_child[2900 [k5c_setup_fast] (0x0100): SSSD_KRB5_FAST_PRINCIPAL is set to [host/test3-vm.mydomain@mydomain.com] (Fri Jan 23 15:39:54 2015) [[sssd[krb5_child[2900 [check_fast_ccache] (0x0200): FAST TGT is still valid. (Fri Jan 23 15:39:54 2015) [[sssd[krb5_child[2900 [get_and_save_tgt] (0x0020): 981: [-1765328353][Decrypt integrity check failed] (Fri Jan 23 15:39:54 2015) [[sssd[krb5_child[2900 [map_krb5_error] (0x0020): 1043: [-1765328353][Decrypt integrity check failed] (Fri Jan 23 15:39:54 2015) [[sssd[krb5_child[2900 [k5c_send_data] (0x0200): Received error code 1432158218 [root@test3-vm sssd]# cat /etc/sssd/sssd.conf # Do not edit Managed by Spacewalk [domain/MYDOMAIN.COM] cache_credentials = True krb5_store_password_if_offline = True ipa_domain =
[Freeipa-users] Issues with new install - Configuration of CA failed
I am having a very difficult time getting the ipa server installed on
our test server.
CentOS release 6.6 (Final)
Linux test1-vm.example.com 2.6.32-504.3.3.el6.x86_64 #1 SMP Wed Dec 17
01:55:02 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
ipa-server-3.0.0-42.el6.centos.x86_64
I tried to reinstall pki-selinux, reboot, relabel and that didn't help
yum reinstall pki-selinux
I reviewed a number of threads and didn't seem to see my issue of
Request:java.net.ConnectException: Connection refused at step 2/20
https://www.redhat.com/archives/freeipa-users/2014-April/msg00278.html
Any suggestions would be greatly appreciated.
I used: ipa-server-install --no-ntp
Continue to configure the system with these values? [no]: yes
The following operations may take some minutes to complete.
Please wait until the prompt is returned.
Configuring directory server for the CA (pkids): Estimated time 30 seconds
[1/3]: creating directory server user
[2/3]: creating directory server instance
[3/3]: restarting directory server
Done configuring directory server for the CA (pkids).
Configuring certificate server (pki-cad): Estimated time 3 minutes 30 seconds
[1/20]: creating certificate server user
[2/20]: configuring certificate server instance
ipa : CRITICAL failed to configure ca instance Command
'/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname
test1-vm.example.com -cs_port 9445 -client_certdb_dir /tmp/tmp-WQ28_w
-client_certdb_pwd -preop_pin MvLsuha0GPxvJSnYoL5u
-domain_name IPA -admin_user admin -admin_email root@localhost
-admin_ -agent_name ipa-ca-agent -agent_key_size 2048
-agent_key_type rsa -agent_cert_subject CN=ipa-ca-agent,O=EXAMPLE.COM
-ldap_host test1-vm.example.com -ldap_port 7389 -bind_dn cn=Directory
Manager -bind_ -base_dn o=ipaca -db_name ipaca
-key_size 2048 -key_type rsa -key_algorithm SHA256withRSA -save_p12
true -backup_pwd -subsystem_name pki-cad -token_name internal
-ca_subsystem_cert_subject_name CN=CA Subsystem,O=EXAMPLE.COM
-ca_subsystem_cert_subject_name CN=CA Subsystem,O=EXAMPLE.COM
-ca_ocsp_cert_subject_name CN=OCSP Subsystem,O=EXAMPLE.COM
-ca_server_cert_subject_name CN=test1-vm.example.com,O=EXAMPLE.COM
-ca_audit_signing_cert_subject_name CN=CA Audit,O=EXAMPLE.COM
-ca_sign_cert_subject_name CN=Certificate Authority,O=EXAMPLE.COM
-external false -clone false' returned non-zero exit status 255
Configuration of CA failed
install log:
[root@test1-vm log]# cat ipaserver-install.log
2015-01-13T19:47:59Z DEBUG Loading StateFile from
'/var/lib/ipa/sysrestore/sysrestore.state'
2015-01-13T19:47:59Z DEBUG Loading Index file from
'/var/lib/ipa/sysrestore/sysrestore.index'
2015-01-13T19:47:59Z DEBUG httpd is not configured
2015-01-13T19:47:59Z DEBUG kadmin is not configured
2015-01-13T19:47:59Z DEBUG dirsrv is not configured
2015-01-13T19:47:59Z DEBUG pki-cad is not configured
2015-01-13T19:47:59Z DEBUG pki-tomcatd is not configured
2015-01-13T19:47:59Z DEBUG pkids is not configured
2015-01-13T19:47:59Z DEBUG install is not configured
2015-01-13T19:47:59Z DEBUG krb5kdc is not configured
2015-01-13T19:47:59Z DEBUG ntpd is not configured
2015-01-13T19:47:59Z DEBUG named is not configured
2015-01-13T19:47:59Z DEBUG ipa_memcached is not configured
2015-01-13T19:47:59Z DEBUG filestore is tracking no files
2015-01-13T19:47:59Z DEBUG Loading Index file from
'/var/lib/ipa-client/sysrestore/sysrestore.index'
2015-01-13T19:47:59Z DEBUG /usr/sbin/ipa-server-install was invoked
with options: {'zone_refresh': 0, 'reverse_zone': None, 'realm_name':
None, 'create_sshfp': True, 'conf_sshd': True, 'conf_ntp': False,
'subject': None, 'no_forwarders': False, 'persistent_search': True,
'ui_redirect': True, 'domain_name': None, 'idmax': 0, 'hbac_allow':
False, 'no_reverse': False, 'dirsrv_pkcs12': None, 'unattended':
False, 'selfsign': False, 'trust_sshfp': False, 'external_ca_file':
None, 'no_host_dns': False, 'http_pkcs12': None, 'zone_notif': False,
'forwarders': None, 'idstart': 184480, 'external_ca': False,
'ip_address': None, 'conf_ssh': True, 'serial_autoincrement': True,
'zonemgr': None, 'setup_dns': False, 'host_name': None, 'debug':
False, 'external_cert_file': None, 'uninstall': False}
2015-01-13T19:47:59Z DEBUG missing options might be asked for
interactively later
2015-01-13T19:47:59Z DEBUG Loading Index file from
'/var/lib/ipa/sysrestore/sysrestore.index'
2015-01-13T19:47:59Z DEBUG Loading StateFile from
'/var/lib/ipa/sysrestore/sysrestore.state'
2015-01-13T19:47:59Z DEBUG args=/usr/sbin/httpd -t -D DUMP_VHOSTS
2015-01-13T19:47:59Z DEBUG stdout=VirtualHost configuration:
wildcard NameVirtualHosts and _default_ servers:
_default_:8443 test1-vm.example.com (/etc/httpd/conf.d/nss.conf:84)
2015-01-13T19:47:59Z DEBUG stderr=Syntax OK
2015-01-13T19:48:02Z DEBUG Check if test1-vm.example.com is a primary
hostname for localhost
2015-01-13T19:48:02Z DEBUG Primary hostname for localhost: test1-vm.example.com
Re: [Freeipa-users] can't register new clients
Ok, Thank you for the information. During the restore i ran into https://fedorahosted.org/freeipa/ticket/4726 and sudo -u apache kdestroy fixed it. I think there was also something else minor that i was able to fix by running a command differently. I had two clients that I HAD to get online due to a deadline, so i manually configured the clients using (http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/linux-manual.html) and they work fine now. I have a third client that I'm working with where i have some more time. This one is on the same VLAN as the directory server, so that eliminates and network related issues as a possibility. I ran openssl s_client -host dir1.example.com -port 443 -CAfile ca.crt against the ca.crt that was left from the failed install and it looks fine. I might try to regenerate the certificate and see if that helps although it looks like a real pain for verso 3 according to http://www.freeipa.org/page/Howto/CA_Certificate_Renewal#Procedure_in_IPA_.3C_4.0 [root@walker ipa]# openssl s_client -host dir1.example.com -port 443 -CAfile ca.crt CONNECTED(0003) depth=1 O = example.com, CN = Certificate Authority verify error:num=19:self signed certificate in certificate chain verify return:0 --- Certificate chain 0 s:/O=example.com/CN=dir1.example.com i:/O=example.com/CN=Certificate Authority 1 s:/O=example.com/CN=Certificate Authority i:/O=example.com/CN=Certificate Authority --- Server certificate -BEGIN CERTIFICATE- Masdfasdf more stuff here -END CERTIFICATE- subject=/O=example.com/CN=dir1.example.com issuer=/O=example.com/CN=Certificate Authority --- No client certificate CA names sent --- SSL handshake has read 2095 bytes and written 591 bytes --- New, TLSv1/SSLv3, Cipher is AES128-SHA Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1.1 Cipher: AES128-SHA Session-ID: 22BBDF13AA4DDFFF7562A624D0A6B1B35BCE727FD59AFF1572B4928851DFB91B Session-ID-ctx: Master-Key: 9EF37866161FD89469DD5631744051123456788F5C035CB8F5E8A85F9B2FAAE96698F48559D1338C42B4F20FC Key-Arg : None Krb5 Principal: None PSK identity: None PSK identity hint: None Start Time: 1418237923 Timeout : 300 (sec) Verify return code: 19 (self signed certificate in certificate chain) --- !DOCTYPE HTML PUBLIC -//IETF//DTD HTML 2.0//EN htmlhead title301 Moved Permanently/title /headbody h1Moved Permanently/h1 pThe document has moved a href=https://dir1.example.com/ipa/ui;here/a./p hr addressApache/2.2.15 (CentOS) Server at dir1.example.com Port 443/address /body/html closed On Wed, Dec 10, 2014 at 3:19 AM, Martin Kosek mko...@redhat.com wrote: On 12/09/2014 03:57 PM, Megan . wrote: This is happening with all new clients. I had to rebuild the LDAP server onto new hardware and the network team put us on a new VLAN. so my physical server and IP changed. I was previously able to register clients, but after all of the changes, i can no longer register them. At this point i'm not sure if there is a network issue or something wrong with the IPA server. The existing clients are communicating fine, no errors or complains. I have two new clients to add and both have the same symptoms. I used these procedures to backup then restore onto the new host http://www.freeipa.org/page/V3/Backup_and_Restore To change the IP i just updated /etc/hosts and pushed it out to the clients This may be related. Did the backup and restore really go correctly? AFAIK, this feature did not go through more heavy testing in the community yet, so there may be rough edges. There were several bug fixes to backup and restore scripts in FreeIPA 4.1.x releases already. But if the hostname is the same, A/ and PTR DNS records are still valid and your other clients work fine, it should be OK. So you are saying that installation still fails with the NSS error -8054? I am thinking that the next step should be to run ipa-client-install with --force flag to make sure that it does not clean the certificate downloaded from LDAP and check that the cert downloaded to /ect/ipa/ca.crt is indeed OK (you already tested the one downloaded by wget, but theoretically, the one in LDAP could be different). On Tue, Dec 9, 2014 at 9:05 AM, Rob Crittenden rcrit...@redhat.com wrote: Megan . wrote: Everything looks ok. Our Networks team only opened 443 from the client to the server. is 80 required to be open too for registration? 80 is a lot harder for me to request on our network. I think I might have found the issue. Maybe it can't verify the CA because its pointing to port 80, and 80 isn't open. Is it possible to change the certificate so this information is available via 443 or does that not make sense since its trying to get information about the secure connection in the first place. I don't think port 80 is the problem and in any case
Re: [Freeipa-users] can't register new clients
Everything looks ok. Our Networks team only opened 443 from the client to the server. is 80 required to be open too for registration? 80 is a lot harder for me to request on our network. I think I might have found the issue. Maybe it can't verify the CA because its pointing to port 80, and 80 isn't open. Is it possible to change the certificate so this information is available via 443 or does that not make sense since its trying to get information about the secure connection in the first place. from the server: [root@dir1 ipa]# openssl verify -verbose -CAFile ca.crt . . Authority Information Access: OCSP - URI:http://dir1.example.com:80/ca/ocsp . [root@data2-uat ipa]# wget https://dir1.example.com/ipa/config/ca.crt -O /tmp/ipa.crt --2014-12-09 13:21:32-- https://dir1.example.com/ipa/config/ca.crt Resolving dir1.example.com... 172.28.27.170 Connecting to dir1.example.com|172.28.27.170|:443... connected. ERROR: cannot verify dir1.example.com’s certificate, issued by “/O=EXAMPLE.COM/CN=Certificate Authority”: Self-signed certificate encountered. To connect to dir1.example.com insecurely, use ‘--no-check-certificate’. [root@data2-uat ipa]# wget https://dir1.example.com/ipa/config/ca.crt -O /tmp/ipa.crt --no-check-certificate --2014-12-09 13:22:11-- https://dir1.example.com/ipa/config/ca.crt Resolving dir1.example.com... 172.28.27.170 Connecting to dir1.example.com|172.28.27.170|:443... connected. WARNING: cannot verify dir1.example.com’s certificate, issued by “/O=EXAMPLE.COM/CN=Certificate Authority”: Self-signed certificate encountered. HTTP request sent, awaiting response... 200 OK Length: 1357 (1.3K) [application/x-x509-ca-cert] Saving to: “/tmp/ipa.crt” 100%[] 1,357 --.-K/s in 0.005s 2014-12-09 13:22:11 (246 KB/s) - “/tmp/ipa.crt” saved [1357/1357] [root@data2-uat ipa]# cd /tmp [root@data2-uat tmp]# openssl s_client -host dir1.example.com -port 443 -CAfile /tmp/ipa.crt CONNECTED(0003) depth=1 O = EXAMPLE.COM, CN = Certificate Authority verify return:1 depth=0 O = EXAMPLE.COM, CN = dir1.example.com verify return:1 --- Certificate chain 0 s:/O=EXAMPLE.COM/CN=dir1.example.com i:/O=EXAMPLE.COM/CN=Certificate Authority 1 s:/O=EXAMPLE.COM/CN=Certificate Authority i:/O=EXAMPLE.COM/CN=Certificate Authority --- Server certificate -BEGIN CERTIFICATE- ... -END CERTIFICATE- subject=/O=EXAMPLE.COM/CN=dir1.example.com issuer=/O=EXAMPLE.COM/CN=Certificate Authority --- No client certificate CA names sent --- SSL handshake has read 2095 bytes and written 591 bytes --- New, TLSv1/SSLv3, Cipher is AES128-SHA Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1.1 Cipher: AES128-SHA Session-ID: F6A664BC942DF235EF546007379A79A00245G34FA7C0E6F191B911E9CFEC17D0 Session-ID-ctx: Master-Key: 8C9A5FB1DFDDA72FF09780A85A43FA3C1AA14D4FB199F510A0DC3DF0C53DCDD0F26211CA886342E84030EA891959 Key-Arg : None Krb5 Principal: None PSK identity: None PSK identity hint: None Start Time: 1418131359 Timeout : 300 (sec) Verify return code: 0 (ok) --- closed On Tue, Dec 9, 2014 at 4:18 AM, Martin Kosek mko...@redhat.com wrote: On 12/08/2014 08:00 PM, Megan . wrote: I looked through the logs on the server and i see the below error in the apache error log when i try to register a client: [Mon Dec 08 12:20:38 2014] [error] SSL Library Error: -12195 Peer does not recognize and trust the CA that issued your certificate I ran ipa-getcert list and everything seems ok (nothing expired) but i'm not sure where to troubleshoot from here. The next step would be to check the actual HTTP certificate (on the client machine) and see what's wrong. I did a simple test you can follow: # wget http://ipa.mkosek-f21.test/ipa/config/ca.crt -O /tmp/ipa.crt # openssl s_client -host ipa.mkosek-f21.test -port 443 -CAfile /tmp/ipa.crt CONNECTED(0003) depth=1 O = MKOSEK-F21.TEST, CN = Certificate Authority verify return:1 depth=0 O = MKOSEK-F21.TEST, CN = ipa.mkosek-f21.test verify return:1 --- Certificate chain 0 s:/O=MKOSEK-F21.TEST/CN=ipa.mkosek-f21.test i:/O=MKOSEK-F21.TEST/CN=Certificate Authority 1 s:/O=MKOSEK-F21.TEST/CN=Certificate Authority i:/O=MKOSEK-F21.TEST/CN=Certificate Authority --- Server certificate ... SSL-Session: Protocol : TLSv1.2 Cipher: AES128-SHA Session-ID: 5A4B326D2E8FB80408D628D1975C49C4F78D3E65F31E475F9E7B9BBBE11F576E Session-ID-ctx: Master-Key: D5C31E9E36503ADC9F162439B41A7A608260D7DF5EB357FB3D79C9CFAE700912526893E7DD9AA56F5B6CD320FBA98C49 Key-Arg : None Krb5 Principal: None PSK identity: None PSK identity hint: None Start Time: 1418073191 Timeout : 300 (sec) Verify return code: 0 (ok) --- On Fri, Dec 5, 2014 at 7:51 PM, Megan . nagem...@gmail.com wrote: It failed again
Re: [Freeipa-users] can't register new clients
I looked through the logs on the server and i see the below error in the apache error log when i try to register a client: [Mon Dec 08 12:20:38 2014] [error] SSL Library Error: -12195 Peer does not recognize and trust the CA that issued your certificate I ran ipa-getcert list and everything seems ok (nothing expired) but i'm not sure where to troubleshoot from here. On Fri, Dec 5, 2014 at 7:51 PM, Megan . nagem...@gmail.com wrote: It failed again. [root@cache2-uat ~]# certutil -L -d sql:/etc/pki/nssdb Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI [root@cache2-uat ~]# Not sure if its related, but on the directory server in the apache error.log I see the below every time a client tries to register: [Sat Dec 06 00:48:35 2014] [error] SSL Library Error: -12271 SSL client cannot verify your certificate On the directory server i ran ipa-getcert list and the certs seem ok. On Fri, Dec 5, 2014 at 5:10 PM, Rob Crittenden rcrit...@redhat.com wrote: Megan . wrote: Sorry for being unclear. It still fails. Same error. Hmm, strange. Try being explicit about sql: # certutil -L -d sql:/etc/pki/nssdb And if there is a CA cert there, delete it. rob On Dec 5, 2014 4:39 PM, Rob Crittenden rcrit...@redhat.com mailto:rcrit...@redhat.com wrote: Megan . wrote: Thanks. I did have an issue last week where i tried to do the client install and it failed because of a firewall issue. Networks has it opened now. I deleted ca.crt before trying again. There doesn't seem to be a certificate in /etc/pki/nssdb for it. [root@data2-uat ipa]# certutil -L -d /etc/pki/nssdb Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI [root@data2-uat ipa]# certutil -D -n 'IPA CA' -d /etc/pki/nssdb certutil: could not find certificate named IPA CA: SEC_ERROR_BAD_DATABASE: security library: bad database. [root@data2-uat ipa]# ls [root@data2-uat ipa]# pwd /etc/ipa [root@data2-uat ipa]# ls -al total 16 drwxr-xr-x. 2 root root 4096 Dec 5 21:16 . drwxr-xr-x. 82 root root 12288 Dec 5 21:16 .. [root@data2-uat ipa]# So trying to install the client again fails or succeeds now? rob On Fri, Dec 5, 2014 at 4:03 PM, Rob Crittenden rcrit...@redhat.com mailto:rcrit...@redhat.com wrote: Rob Crittenden wrote: Megan . wrote: Good Day! I am getting an error when i register new clients. libcurl failed to execute the HTTP POST transaction. SSL connect error I can't find anything useful not the internet about the error. Can someone help me troubleshoot? CentOS 6.6 x64 ipa-client-3.0.0-42.el6.centos.x86_64 ipa-server-3.0.0-42.el6.centos.x86_64 curl-7.19.7-40.el6_6.1.x86_64 Do you have NSS_DEFAULT_DB_TYPE set to sql? I don't know that we've done any testing on the client with this set. Never mind, that's not it. The problem is: * NSS error -8054 Which is SEC_ERROR_REUSED_ISSUER_AND_SERIAL So I'd do this: # rm /etc/ipa/ca.crt You may also want to ensure that the IPA CA certificate isn't in /etc/pki/nssdb: # certutil -L -d /etc/pki/nssdb And then perhaps # certutil -D -n 'IPA CA' -d /etc/pki/nssdb rob -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
[Freeipa-users] can't register new clients
Good Day!
I am getting an error when i register new clients.
libcurl failed to execute the HTTP POST transaction. SSL connect error
I can't find anything useful not the internet about the error. Can
someone help me troubleshoot?
CentOS 6.6 x64
ipa-client-3.0.0-42.el6.centos.x86_64
ipa-server-3.0.0-42.el6.centos.x86_64
curl-7.19.7-40.el6_6.1.x86_64
I checked the 443 connection to the ipa server and it is open to the client.
[root@data2-uat ipa]# ipa-client-install --domain=somewhere.com
--server=dir1.somewhere.com --no-ntp --realm=somewhere.com -d
/usr/sbin/ipa-client-install was invoked with options: {'domain':
'somewhere.com', 'force': False, 'krb5_offline_passwords': True,
'primary': False, 'mkhomedir': False, 'create_sshfp': True,
'conf_sshd': True, 'conf_ntp': False, 'on_master': False,
'ntp_server': None, 'server': ['dir1.somewhere.com'], 'no_nisdomain':
False, 'principal': None, 'hostname': None, 'no_ac': False,
'unattended': None, 'sssd': True, 'trust_sshfp': False, 'realm_name':
'somewhere.com', 'dns_updates': False, 'conf_sudo': True, 'conf_ssh':
True, 'force_join': False, 'ca_cert_file': None, 'nisdomain': None,
'prompt_password': False, 'permit': False, 'debug': True,
'preserve_sssd': False, 'uninstall': False}
missing options might be asked for interactively later
Loading Index file from '/var/lib/ipa-client/sysrestore/sysrestore.index'
Loading StateFile from '/var/lib/ipa-client/sysrestore/sysrestore.state'
[IPA Discovery]
Starting IPA discovery with domain=somewhere.com,
servers=['dir1.somewhere.com'], hostname=data2-uat.somewhere.com
Server and domain forced
[Kerberos realm search]
Search DNS for TXT record of _kerberos.somewhere.com.
No DNS record found
[LDAP server check]
Verifying that dir1.somewhere.com (realm None) is an IPA server
Init LDAP connection with: ldap://dir1.somewhere.com:389
Search LDAP server for IPA base DN
Check if naming context 'dc=proj,dc=somewhere,dc=com' is for IPA
Naming context 'dc=proj,dc=somewhere,dc=com' is a valid IPA context
Search for (objectClass=krbRealmContainer) in dc=proj,dc=somewhere,dc=com (sub)
Found: cn=somewhere.com,cn=kerberos,dc=proj,dc=somewhere,dc=com
Discovery result: Success; server=dir1.somewhere.com,
domain=somewhere.com, kdc=None, basedn=dc=proj,dc=somewhere,dc=com
Validated servers: dir1.somewhere.com
will use discovered domain: somewhere.com
Using servers from command line, disabling DNS discovery
will use provided server: dir1.somewhere.com
Autodiscovery of servers for failover cannot work with this configuration.
If you proceed with the installation, services will be configured to
always access the discovered server for all operations and will not
fail over to other servers in case of failure.
Proceed with fixed values and no DNS discovery? [no]: yes
will use discovered realm: somewhere.com
will use discovered basedn: dc=proj,dc=somewhere,dc=com
Hostname: data2-uat.somewhere.com
Hostname source: Machine's FQDN
Realm: somewhere.com
Realm source: Discovered from LDAP DNS records in dir1.somewhere.com
DNS Domain: somewhere.com
DNS Domain source: Forced
IPA Server: dir1.somewhere.com
IPA Server source: Provided as option
BaseDN: dc=proj,dc=somewhere,dc=com
BaseDN source: From IPA server ldap://dir1.somewhere.com:389
Continue to configure the system with these values? [no]: yes
args=/usr/sbin/ipa-rmkeytab -k /etc/krb5.keytab -r somewhere.com
stdout=
stderr=Failed to open keytab '/etc/krb5.keytab': No such file or directory
User authorized to enroll computers: mkispert
will use principal provided as option: mkispert
Synchronizing time with KDC...
Search DNS for SRV record of _ntp._udp.somewhere.com.
No DNS record found
args=/usr/sbin/ntpdate -U ntp -s -b -v dir1.somewhere.com
stdout=
stderr=
args=/usr/sbin/ntpdate -U ntp -s -b -v dir1.somewhere.com
stdout=
stderr=
args=/usr/sbin/ntpdate -U ntp -s -b -v dir1.somewhere.com
stdout=
stderr=
Unable to sync time with IPA NTP server, assuming the time is in sync.
Please check that 123 UDP port is opened.
Writing Kerberos configuration to /tmp/tmphDx3Aq:
#File modified by ipa-client-install
includedir /var/lib/sss/pubconf/krb5.include.d/
[libdefaults]
default_realm = somewhere.com
dns_lookup_realm = false
dns_lookup_kdc = false
rdns = false
ticket_lifetime = 24h
forwardable = yes
[realms]
somewhere.com = {
kdc = dir1.somewhere.com:88
master_kdc = dir1.somewhere.com:88
admin_server = dir1.somewhere.com:749
default_domain = somewhere.com
pkinit_anchors = FILE:/etc/ipa/ca.crt
}
[domain_realm]
.somewhere.com = somewhere.com
somewhere.com = somewhere.com
Password for mkisp...@somewhere.com:
args=kinit mkisp...@somewhere.com
stdout=Password for mkisp...@somewhere.com:
Warning: Your password will expire in 2 days on Mon Dec 8 11:48:37 2014
stderr=
trying to retrieve CA cert via LDAP from ldap://dir1.somewhere.com
Successfully retrieved CA cert
Subject: CN=Certificate Authority,O=somewhere.com
Issuer: CN=Certificate
Re: [Freeipa-users] can't register new clients
It failed again. [root@cache2-uat ~]# certutil -L -d sql:/etc/pki/nssdb Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI [root@cache2-uat ~]# Not sure if its related, but on the directory server in the apache error.log I see the below every time a client tries to register: [Sat Dec 06 00:48:35 2014] [error] SSL Library Error: -12271 SSL client cannot verify your certificate On the directory server i ran ipa-getcert list and the certs seem ok. On Fri, Dec 5, 2014 at 5:10 PM, Rob Crittenden rcrit...@redhat.com wrote: Megan . wrote: Sorry for being unclear. It still fails. Same error. Hmm, strange. Try being explicit about sql: # certutil -L -d sql:/etc/pki/nssdb And if there is a CA cert there, delete it. rob On Dec 5, 2014 4:39 PM, Rob Crittenden rcrit...@redhat.com mailto:rcrit...@redhat.com wrote: Megan . wrote: Thanks. I did have an issue last week where i tried to do the client install and it failed because of a firewall issue. Networks has it opened now. I deleted ca.crt before trying again. There doesn't seem to be a certificate in /etc/pki/nssdb for it. [root@data2-uat ipa]# certutil -L -d /etc/pki/nssdb Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI [root@data2-uat ipa]# certutil -D -n 'IPA CA' -d /etc/pki/nssdb certutil: could not find certificate named IPA CA: SEC_ERROR_BAD_DATABASE: security library: bad database. [root@data2-uat ipa]# ls [root@data2-uat ipa]# pwd /etc/ipa [root@data2-uat ipa]# ls -al total 16 drwxr-xr-x. 2 root root 4096 Dec 5 21:16 . drwxr-xr-x. 82 root root 12288 Dec 5 21:16 .. [root@data2-uat ipa]# So trying to install the client again fails or succeeds now? rob On Fri, Dec 5, 2014 at 4:03 PM, Rob Crittenden rcrit...@redhat.com mailto:rcrit...@redhat.com wrote: Rob Crittenden wrote: Megan . wrote: Good Day! I am getting an error when i register new clients. libcurl failed to execute the HTTP POST transaction. SSL connect error I can't find anything useful not the internet about the error. Can someone help me troubleshoot? CentOS 6.6 x64 ipa-client-3.0.0-42.el6.centos.x86_64 ipa-server-3.0.0-42.el6.centos.x86_64 curl-7.19.7-40.el6_6.1.x86_64 Do you have NSS_DEFAULT_DB_TYPE set to sql? I don't know that we've done any testing on the client with this set. Never mind, that's not it. The problem is: * NSS error -8054 Which is SEC_ERROR_REUSED_ISSUER_AND_SERIAL So I'd do this: # rm /etc/ipa/ca.crt You may also want to ensure that the IPA CA certificate isn't in /etc/pki/nssdb: # certutil -L -d /etc/pki/nssdb And then perhaps # certutil -D -n 'IPA CA' -d /etc/pki/nssdb rob -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
[Freeipa-users] Setting up clients to use replica server
Good Evening!
We are using 3.0.0-42 on Centos 6.6. I am not using NTP or DNS (we
are not allowed to run these services in our environment.)
I configured the replica using the directions at
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/installing-replica.html
I'm trying to configure my clients to failover to the replica. I
believe I have my sssd.conf correct but i can't figure out the proper
syntax for the krb5.conf. Is there documentation somewhere that I can
use? I tried placing to kdc = in the file with dir1 and dir2, but it
didn't work. Any help is greatly appreciated.
My sssd.conf
[domain/MYDOMAIN.COM]
cache_credentials = True
krb5_store_password_if_offline = True
ipa_domain = MYDOMAIN.COM
id_provider = ipa
auth_provider = ipa
access_provider = ipa
ldap_tls_cacert = /etc/ipa/ca.crt
ipa_hostname = db2-uat.mydomain.com
chpass_provider = ipa
ipa_server = _srv_, dir1.mydomain.com, dir2.mydomain.com
dns_discovery_domain = MYDOMAIN.COM
sudo_provider = ldap
ldap_uri = ldap://dir1.mydomain.com, ldap://dir2.mydomain.com
ldap_sudo_search_base = ou=sudoers,dc=mydomain,dc=com
ldap_sasl_mech = GSSAPI
ldap_sasl_authid = host/db2-uat.mydomain.com
ldap_sasl_realm = MYDOMAIN.COM
krb5_server = dir1.mydomain.com, dir2.mydomain.com
[sssd]
services = nss, pam, ssh, sudo
config_file_version = 2
domains = MYDOMAIN.COM
[nss]
[pam]
[sudo]
debug_level = 5
[autofs]
[ssh]
[pac]
my krb5.conf
includedir /var/lib/sss/pubconf/krb5.include.d/
[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log
[libdefaults]
default_realm = MYDOMAIN.COM
dns_lookup_realm = false
dns_lookup_kdc = true
rdns = false
ticket_lifetime = 24h
forwardable = yes
[realms]
MYDOMAIN.COM = {
kdc = dir1.mydomain.com:88
master_kdc = dir1.mydomain.com:88
admin_server = dir1.mydomain.com:749
default_domain = mydomain.com
pkinit_anchors = FILE:/etc/ipa/ca.crt
}
[domain_realm]
.mydomain.com = MYDOMAIN.COM
mydomain.com = MYDOMAIN.COM
[dbmodules]
MYDOMAIN.COM = {
db_library = ipadb.so
}
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go To http://freeipa.org for more info on the project
[Freeipa-users] sudo with freeIPA
Good Morning, I'm very new to freeIPA. I'm running centOS 6.5 with freeIPA v3 I have the freeIPA server up but i'm working on getting SUDO configured. Currently i'm having problems getting sudo commands to work on the client. I'm a bit unclear if i have everything configured correctly. The only thing that I can figure out might be an issue, is when i try the sudo command i see a filter search with objectclass=sudoRule but when i check the ldap server it has objectclass=sudoRole, so there are no results. Any ideas? Thank you in advance for any advice. [tuser2@map1 ~]$ sudo /sbin/iptables -L Enter RSA PIN+token: tuser2 is not allowed to run sudo on map1. This incident will be reported. CLIENT: yum installed libsss_sudo I added nisdomainname dir1.server.example.com to /etc/rc.d/rc.local **still not sure what this is for ** Created a sudo user on ldap server ldappasswd -x -S -W -h dir1.server.example.com -ZZ -D cn=Directory Manager uid=sudo,cn=sysaccounts,cn=etc,dc=server,dc=example,dc=com ** [root@map1 sssd]# cat /etc/nsswitch.conf # passwd: files sss shadow: files sss group: files sss sudoers:files sss sudoers_debug: 1 #sudoers:files hosts: files dns bootparams: files ethers: files netmasks: files networks: files protocols: files rpc:files services: files sss netgroup: files sss publickey: files automount: files ldap aliases:files [root@map1 sssd]# [root@map1 sssd]# cat sssd.conf [domain/server.example.com] debug_level = 5 cache_credentials = True krb5_store_password_if_offline = True ipa_domain = server.example.com id_provider = ipa auth_provider = ipa access_provider = ipa ipa_hostname = map1.server.example.com chpass_provider = ipa ipa_server = _srv_, dir1.server.example.com ldap_netgroup_search_base = cn=ng,cn=compat,dc=server,dc=example,dc=com ldap_tls_cacert = /etc/ipa/ca.crt sudo_provider = ldap ldap_uri = ldap://dir1.server.example.com ldap_sudo_search_base = ou=sudoers,dc=server,dc=example,dc=com ldap_sasl_mech = GSSAPI ldap_sasl_authid = host/dir1.server.example.com ldap_sasl_realm = server.example.com krb5_server = dir1.server.example.com [sssd] services = nss, pam, ssh, sudo config_file_version = 2 domains = server.example.com [nss] [pam] [sudo] debug_level=5 [autofs] [ssh] [pac] from the sssd_sudo.log (Mon Aug 25 10:36:31 2014) [sssd[sudo]] [sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with [((objectClass=sudoRule)(|(sudoUser=ALL)(name=defaults)(sudoUser=tuser2)(sudoUser=#107965)(sudoUser=%tuser2)(sudoUser=+*))((dataExpireTimestamp=1408962991)))] (Mon Aug 25 10:36:31 2014) [sssd[sudo]] [sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with [((objectClass=sudoRule)(|(sudoUser=ALL)(sudoUser=tuser2)(sudoUser=#107965)(sudoUser=%tuser2)(sudoUser=+*)))] (Mon Aug 25 10:36:33 2014) [sssd[sudo]] [client_recv] (0x0200): Client disconnected! [root@dir1 ~]# !ldaps ldapsearch -h dir1.server.example.com -x -D cn=Directory Manager -W -b dc=server,dc=example,dc=com 'objectclass=sudoRole' Enter LDAP Password: # extended LDIF # # LDAPv3 # base dc=server,dc=example,dc=com with scope subtree # filter: objectclass=sudoRole # requesting: ALL # # test, sudoers, server.example.com dn: cn=test,ou=sudoers,dc=server,dc=example,dc=com objectClass: sudoRole sudoUser: megan2 sudoUser: tuser2 sudoHost: map1.server.example.com sudoCommand: /sbin/iptables -L sudoCommand: /home/tuser1/test.sh sudoCommand: test2.sh cn: test # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 [root@dir1 ~]# ldapsearch -h dir1.server.example.com -x -D cn=Directory Manager -W -b dc=server,dc=example,dc=com 'objectclass=sudoRule' Enter LDAP Password: # extended LDIF # # LDAPv3 # base dc=server,dc=example,dc=com with scope subtree # filter: objectclass=sudoRule # requesting: ALL # # search result search: 2 result: 0 Success # numResponses: 1 -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] sudo with freeIPA
): user: tuser2 (Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]] [pam_print_data] (0x0100): service: sudo (Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]] [pam_print_data] (0x0100): tty: /dev/pts/1 (Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]] [pam_print_data] (0x0100): ruser: tuser2 (Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]] [pam_print_data] (0x0100): rhost: (Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]] [pam_print_data] (0x0100): authtok type: 0 (Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]] [pam_print_data] (0x0100): authtok size: 0 (Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]] [pam_print_data] (0x0100): newauthtok type: 0 (Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]] [pam_print_data] (0x0100): newauthtok size: 0 (Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]] [pam_print_data] (0x0100): priv: 0 (Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]] [pam_print_data] (0x0100): cli_pid: 17822 (Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]] [hbac_get_category] (0x0200): Category is set to 'all'. (Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]] [hbac_get_category] (0x0200): Category is set to 'all'. (Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]] [hbac_get_category] (0x0200): Category is set to 'all'. (Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]] [ipa_hbac_evaluate_rules] (0x0080): Access granted by HBAC rule [allow_all] (Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]] [be_pam_handler_callback] (0x0100): Backend returned: (0, 0, NULL) [Success] (Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]] [be_pam_handler_callback] (0x0100): Backend returned: (0, 0, Success) [Success] (Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]] [be_pam_handler_callback] (0x0100): Sending result [0][server.example.com] (Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]] [be_pam_handler_callback] (0x0100): Sent result [0][server.example.com] (Mon Aug 25 11:54:46 2014) [sssd[be[server.example.com]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'LDAP' (Mon Aug 25 11:54:46 2014) [sssd[be[server.example.com]]] [get_port_status] (0x0100): Reseting the status of port 389 for server 'dir1.server.example.com' (Mon Aug 25 11:54:46 2014) [sssd[be[server.example.com]]] [be_resolve_server_process] (0x0200): Found address for server dir1.server.example.com: [10.10.26.148] TTL 7200 (Mon Aug 25 11:54:46 2014) [sssd[be[server.example.com]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'KERBEROS' (Mon Aug 25 11:54:46 2014) [sssd[be[server.example.com]]] [be_resolve_server_process] (0x0200): Found address for server dir1.server.example.com: [10.10.26.148] TTL 7200 (Mon Aug 25 11:54:46 2014) [sssd[be[server.example.com]]] [child_sig_handler] (0x0100): child [17823] finished successfully. (Mon Aug 25 11:54:46 2014) [sssd[be[server.example.com]]] [sdap_kinit_done] (0x0100): Could not get TGT: 14 [Bad address] (Mon Aug 25 11:54:46 2014) [sssd[be[server.example.com]]] [fo_set_port_status] (0x0100): Marking port 389 of server 'dir1.server.example.com' as 'not working' (Mon Aug 25 11:54:46 2014) [sssd[be[server.example.com]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'LDAP' (Mon Aug 25 11:54:46 2014) [sssd[be[server.example.com]]] [fo_resolve_service_send] (0x0020): No available servers for service 'LDAP' (Mon Aug 25 11:54:46 2014) [sssd[be[server.example.com]]] [sdap_id_op_connect_done] (0x0020): Failed to connect, going offline (5 [Input/output error]) (Mon Aug 25 11:54:46 2014) [sssd[be[server.example.com]]] [be_run_offline_cb] (0x0080): Going offline. Running callbacks. (Mon Aug 25 11:54:46 2014) [sssd[be[server.example.com]]] [sdap_sudo_periodical_first_refresh_done] (0x0040): Periodical full refresh of sudo rules failed [dp_error: 1] ([11]: Resource temporarily unavailable) (Mon Aug 25 11:54:46 2014) [sssd[be[server.example.com]]] [remove_krb5_info_files] (0x0200): Could not remove [/var/lib/sss/pubconf/kpasswdinfo.server.example.com], [2][No such file or directory] (Mon Aug 25 11:54:46 2014) [sssd[be[server.example.com]]] [remove_krb5_info_files] (0x0200): Could not remove [/var/lib/sss/pubconf/kdcinfo.server.example.com], [2][No such file or directory] (Mon Aug 25 11:54:46 2014) [sssd[be[server.example.com]]] [remove_krb5_info_files] (0x0200): Could not remove [/var/lib/sss/pubconf/kpasswdinfo.server.example.com], [2][No such file or directory] On Mon, Aug 25, 2014 at 7:08 AM, Alexander Bokovoy aboko...@redhat.com wrote: On Mon, 25 Aug 2014, Martin Kosek wrote: On 08/25/2014 12:51 PM, Megan . wrote: Good Morning, I'm very new to freeIPA. Welcome on board! I'm running centOS 6.5 with freeIPA v3 I have the freeIPA server up but i'm working on getting SUDO configured. Currently i'm having problems getting sudo commands to work on the client. I'm a bit unclear if i have everything
Re: [Freeipa-users] sudo with freeIPA
[be[server.domain.com]]] [be_pam_handler_callback] (0x0100): Backend returned: (0, 0, Success) [Success] (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] [be_pam_handler_callback] (0x0100): Sending result [0][server.domain.com] (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] [be_pam_handler_callback] (0x0100): Sent result [0][server.domain.com] On Mon, Aug 25, 2014 at 8:11 AM, Jakub Hrozek jhro...@redhat.com wrote: On Mon, Aug 25, 2014 at 06:51:27AM -0400, Megan . wrote: Good Morning, I'm very new to freeIPA. I'm running centOS 6.5 with freeIPA v3 I have the freeIPA server up but i'm working on getting SUDO configured. Currently i'm having problems getting sudo commands to work on the client. I'm a bit unclear if i have everything configured correctly. The only thing that I can figure out might be an issue, is when i try the sudo command i see a filter search with objectclass=sudoRule but when i check the ldap server it has These two searches are unrelated. The sudoRule objectlass is what we use internally in sssd cache. On the LDAP side, sudoRole is used. In general, only the [domain] process works with LDAP data, all others (nss, pam, sudo, ...) work with cached data that might look totally different. objectclass=sudoRole, so there are no results. Any ideas? Thank you in advance for any advice. Can you put debug_level into the domain section as well and increase the debug_level of both to 7? [tuser2@map1 ~]$ sudo /sbin/iptables -L Enter RSA PIN+token: tuser2 is not allowed to run sudo on map1. This incident will be reported. CLIENT: yum installed libsss_sudo I added nisdomainname dir1.server.example.com to /etc/rc.d/rc.local **still not sure what this is for ** Created a sudo user on ldap server ldappasswd -x -S -W -h dir1.server.example.com -ZZ -D cn=Directory Manager uid=sudo,cn=sysaccounts,cn=etc,dc=server,dc=example,dc=com ** The config file looks good to me. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
