<html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> <div class="moz-cite-prefix">On 10/28/2014 12:11 PM, Craig White wrote: </div> <blockquote cite="mid:f66e86ed703449aeb17e37fbcbe7e4a2@BLUPR08MB488.namprd08.prod.outlook.com" type="cite"> <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> <meta name="Generator" content="Microsoft Word 14 (filtered medium)"> <style></style> <div class="WordSection1"> From: <a class="moz-txt-link-abbreviated" href="mailto:freeipa-users-bounces@redhat.com">freeipa-users-bounces@redhat.com</a> [<a class="moz-txt-link-freetext" href="mailto:freeipa-users-bounces@redhat.com">mailto:freeipa-users-bounces@redhat.com</a>] On Behalf Of Dmitri Pal Sent: Monday, October 27, 2014 5:32 PM To: <a class="moz-txt-link-abbreviated" href="mailto:freeipa-users@redhat.com">freeipa-users@redhat.com</a> Subject: Re: [Freeipa-users] getent passwd / group<o:p></o:p> <o:p> </o:p> <div> On 10/27/2014 07:38 PM, Craig White wrote:<o:p></o:p> </div> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> RHEL 6.5 – new install<o:p></o:p> ipa-server-3.0.0-42.el6.x86_64<o:p></o:p> 389-ds-base-1.2.11.15-47.el6.x86_64<o:p></o:p> <o:p></o:p> On the master, I get nothing<o:p></o:p> <o:p></o:p> [root@ipa001 log]# getent passwd admin<o:p></o:p> [root@ipa001 log]#<o:p></o:p> <o:p></o:p> But it works on the replica as expected<o:p></o:p> <o:p></o:p> [root@ipa002nadev01 ~]# getent passwd admin<o:p></o:p> admin:*:1140000000:1110000000:Administrator:/home/admin:/bin/bash<o:p></o:p> <o:p></o:p> I am used to using PADL / NSSWITCH with OpenLDAP and I am rather surprised that on both, ‘getent passwd’ and ‘getent group’ return only entries from local files but then again, I’ve never used sssd before.<o:p></o:p> <o:p></o:p> Partial from /etc/sssd/sssd.conf<o:p></o:p> [domain/stt.local]<o:p></o:p> cache_credentials = True<o:p></o:p> krb5_store_password_if_offline = True<o:p></o:p> ipa_domain = stt.local<o:p></o:p> id_provider = ipa<o:p></o:p> auth_provider = ipa<o:p></o:p> access_provider = ipa<o:p></o:p> ipa_hostname = ipa001nadev01.stt.local<o:p></o:p> chpass_provider = ipa<o:p></o:p> ipa_server = ipa001nadev01.stt.local<o:p></o:p> ldap_tls_cacert = /etc/ipa/ca.crt<o:p></o:p> <o:p></o:p> [sssd]<o:p></o:p> services = nss, sudo, pam, ssh<o:p></o:p> config_file_version = 2<o:p></o:p> domains = stt.local<o:p></o:p> debug_level = 6<o:p></o:p> <o:p></o:p> Shouldn’t I be seeing both local files and IPA defined users with ‘getent passwd’ and IPA defined users with ‘getent group’ commands?<o:p></o:p> <o:p></o:p> What could cause ‘getent passwd admin’ not to work on the master server now when I know I tested it when I first set it up and it worked? I have done little more than import users and groups from OpenLDAP and configure HBAC, sudo stuff in the IPA web UI.<o:p></o:p> <o:p></o:p> </blockquote> Please check on master: 1. Installation logs. Client on the server is installed last and may be there is something that went wrong at this stage but the rest of the server is OK. 2. DNS. Can you resolve the host properly? 3. Firewall. Can you kinit admin or or do an ldap search? ----<o:p></o:p> It’s weird because it is mostly functioning perfectly.<o:p></o:p> <o:p> </o:p> /var/log/ipaclient-install.log doesn’t show any errors. Gives every indication that things went as planned. The /var/log/ipaserver-install.log is a rather large file and a cursory inspection doesn’t reveal anything that is interesting. The only thing that was not normal about the install was the first install was un-installed because I used DNS forwarders and the boss said no forwarders. So I installed a second time but nothing seemed unusual about either server or client install. <o:p></o:p> <o:p> </o:p> DNS – resolves / working perfectly for the authoritative and non-authoritative zones – forward and reverse. I thought the ‘ipa-client-install –enable-dns-updates’ worked extremely well after modifying it to ensure that both forward and reverse zone entries were created.<o:p></o:p> <o:p> </o:p> kinit <a moz-do-not-send="true" href="mailto:admin@STT.LOCAL">admin@STT.LOCAL</a> works – rejects wrong password entries and accepts correct password entries.<o:p></o:p> Ldapsearch works fine<o:p></o:p> Firewall… (we are talking about localhost but)<o:p></o:p> ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED<o:p></o:p> ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0<o:p></o:p> ACCEPT all -- 0.0.0.0/0 0.0.0.0/0<o:p></o:p> ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 ctstate NEW tcp dpt:22<o:p></o:p> ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:80<o:p></o:p> ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:53<o:p></o:p> ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 state NEW udp dpt:53<o:p></o:p> ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:88<o:p></o:p> ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 state NEW udp dpt:88<o:p></o:p> ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 state NEW udp dpt:123<o:p></o:p> ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:389<o:p></o:p> ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:443<o:p></o:p> ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:464<o:p></o:p> ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 state NEW udp dpt:464<o:p></o:p> ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:636<o:p></o:p> ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:7389<o:p></o:p> ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 state NEW udp dpt:7389<o:p></o:p> ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:9443<o:p></o:p> ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:9444<o:p></o:p> ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:9445<o:p></o:p> REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited<o:p></o:p> </div> </blockquote> Then we need SSSD logs with the debug_level in the right sections as Jakub mentioned in his mail. <pre class="moz-signature" cols="72">-- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc.</pre> </body> </html>