ok I managed to fix it by running:

yum remove pam_ldap; sed -i '/pam_ldap/d' /etc/pam.d/*

Thanks for pointing me to the dns problem though, that was the real deal.
Is there a way to setup ipa-client without messing up with resolv.conf?
like disabling the discovery or using just a forwarder?

On Fri, Jul 10, 2015 at 2:11 PM, Angelo Pantano <ghilte...@gmail.com> wrote:

> I still had it because I am in the middle of a PoC for a migration, the
> legacy used pam_ldap and if I just remove it not only the error does not go
> away, but in the secure logs you also see this new error:
>
> Jul 10 14:08:17 ip-10-237-186-172 sshd[7361]: PAM unable to
> dlopen(/lib64/security/pam_ldap.so): /lib64/security/pam_ldap.so: cannot
> open shared object file: No such file or directory
> Jul 10 14:08:17 ip-10-237-186-172 sshd[7361]: PAM adding faulty module:
> /lib64/security/pam_ldap.so
>
> I even tried to invoke authconfig to force disable pam_ldap and enable
> only sssd but instead it absurdly stops sssd and starts oddjobd in its
> place
>
> On Fri, Jul 10, 2015 at 2:04 PM, Alexander Bokovoy <aboko...@redhat.com>
> wrote:
>
>> On Fri, 10 Jul 2015, Angelo Pantano wrote:
>>
>>> I removed the stanza, but anyway I found one problem was the DNS. I
>>> needed
>>> to setup the nameserver in resolv.conf with the ip of the ipa server. I
>>> can
>>> kinit now but ssh is still failing, connection gets closed instead of
>>> letting me in:
>>>
>>> secure.log says:
>>>
>>> Jul 10 13:19:01 ip-10-237-186-172 sshd[5581]: pam_unix(sshd:auth):
>>> authentication failure; logname= uid=0 euid=0 tty=ssh ruser=
>>> rhost=10.61.205.107  user=apantano@ad.tweek
>>> Jul 10 13:19:02 ip-10-237-186-172 sshd[5581]: pam_sss(sshd:auth):
>>> authentication success; logname= uid=0 euid=0 tty=ssh ruser=
>>> rhost=10.61.205.107 user=apantano@ad.tweek
>>> Jul 10 13:19:22 ip-10-237-186-172 sshd[5581]: pam_ldap: ldap_starttls_s:
>>> Can't contact LDAP server
>>> Jul 10 13:19:22 ip-10-237-186-172 sshd[5581]: Failed password for
>>> apantano@ad.tweek from 10.61.205.107 port 61833 ssh2
>>> Jul 10 13:19:22 ip-10-237-186-172 sshd[5581]: fatal: Access denied for
>>> user
>>> apantano@ad.tweek by PAM account configuration [preauth]
>>>
>>> That's odd in so many ways, I got both a failure from pam_unix and a
>>> success from pam_sss...
>>>
>> That's how it should be, it is a _stack_ of authentication modules.
>> pam_unix doesn't know anything beyond /etc/passwd and /etc/shadow.
>>
>> I don't understand *why* do you have pam_ldap configured. You only need
>> pam_sss, remove pam_ldap, this is definitely not a default
>> configuration.
>>
>>
>>
>>>
>>> On Fri, Jul 10, 2015 at 12:50 PM, Alexander Bokovoy <aboko...@redhat.com
>>> >
>>> wrote:
>>>
>>>  On Fri, 10 Jul 2015, Angelo Pantano wrote:
>>>>
>>>>  I am using sssd and from ipa clients the authentication is not working
>>>>> (works fine if I ssh on the ipa-server). I thought it could be due to
>>>>> the
>>>>> external groups being empty and not mapping the AD users.
>>>>>
>>>>> Anyway this is the krb5.conf on the ipa client:
>>>>>
>>>>> #File modified by ipa-client-install
>>>>>
>>>>> includedir /var/lib/sss/pubconf/krb5.include.d/
>>>>>
>>>>> [libdefaults]
>>>>>  default_realm = IPA.TWEEK
>>>>>  dns_lookup_realm = true
>>>>>  dns_lookup_kdc = true
>>>>>  rdns = false
>>>>>  ticket_lifetime = 24h
>>>>>  forwardable = yes
>>>>>  udp_preference_limit = 0
>>>>>  default_ccache_name = KEYRING:persistent:%{uid}
>>>>>
>>>>> [realms]
>>>>>  IPA.TWEEK = {
>>>>>    kdc = centos.ipa.tweek:88
>>>>>    master_kdc = centos.ipa.tweek:88
>>>>>    admin_server = centos.ipa.tweek:749
>>>>>    default_domain = ipa.tweek
>>>>>    pkinit_anchors = FILE:/etc/ipa/ca.crt
>>>>>    auth_to_local = RULE:[1:$1@$0](^.*@AD.TWEEK$)s/@AD.TWEEK/@ad.tweek/
>>>>>    auth_to_local = DEFAULT
>>>>>  }
>>>>>  AD.TWEEK = {
>>>>>    kdc = centos.ipa.tweek:88
>>>>>    pkinit_anchors = FILE:/etc/ipa/ca.crt
>>>>>  }
>>>>>
>>>>>  Why did you override AD.TWEEK KDC to point to FreeIPA?
>>>>
>>>> Remove AD.TWEEK stanza completely. You have 'dns_lookup_realm' and
>>>> 'dns_lookup_kdc' to allow automatic discovery via DNS SRV records.
>>>>
>>>>
>>>>
>>>>  [domain_realm]
>>>>>  .ipa.tweek = IPA.TWEEK
>>>>>  ipa.tweek = IPA.TWEEK
>>>>>  .ad.tweek = AD.TWEEK
>>>>>  ad.tweek = AD.TWEEK
>>>>>
>>>>>
>>>>> and this is the error I see in krb5_child.log
>>>>>
>>>>> (Fri Jul 10 12:38:05 2015) [[sssd[krb5_child[13235]]]] [main] (0x0400):
>>>>> Will perform online auth
>>>>> (Fri Jul 10 12:38:05 2015) [[sssd[krb5_child[13235]]]]
>>>>> [get_and_save_tgt]
>>>>> (0x0400): Attempting kinit for realm [AD.TWEEK]
>>>>> (Fri Jul 10 12:38:05 2015) [[sssd[krb5_child[13235]]]]
>>>>> [get_and_save_tgt]
>>>>> (0x0020): 996: [-1765328378][Client 'freeipa@AD.TWEEK' not found in
>>>>> Kerberos database]
>>>>> (Fri Jul 10 12:38:05 2015) [[sssd[krb5_child[13235]]]] [map_krb5_error]
>>>>> (0x0020): 1065: [-1765328378][Client 'freeipa@AD.TWEEK' not found in
>>>>> Kerberos database]
>>>>>
>>>>>
>>>>> also
>>>>>
>>>>> # kinit freeipa@AD.TWEEK
>>>>> kinit: Cannot find KDC for realm "AD.TWEEK" while getting initial
>>>>> credentials
>>>>>
>>>>> any idea what's the problem? It seems kerberos cannot find users in
>>>>> the AD
>>>>> subdomain
>>>>>
>>>>>
>>>>> this is my sssd.conf
>>>>>
>>>>> [domain/ipa.tweek]
>>>>> debug_level = 6
>>>>> cache_credentials = True
>>>>> krb5_store_password_if_offline = True
>>>>> ipa_domain = ipa.tweek
>>>>> id_provider = ipa
>>>>> auth_provider = ipa
>>>>> ldap_tls_cacert = /etc/ipa/ca.crt
>>>>> ipa_hostname = someaddress_here
>>>>> chpass_provider = ipa
>>>>> ipa_server = _srv_, centos.ipa.tweek
>>>>> dns_discovery_domain = ipa.tweek
>>>>> cn=ad_admins_external,cn=groups,cn=accounts,dc=ipa,dc=tweek
>>>>> subdomains_provider = ipa
>>>>> [sssd]
>>>>> services = nss, pam, pac, ssh
>>>>> config_file_version = 2
>>>>> debud_level = 6
>>>>> domains = ipa.tweek
>>>>>
>>>>> On Fri, Jul 10, 2015 at 12:29 PM, Alexander Bokovoy <
>>>>> aboko...@redhat.com>
>>>>> wrote:
>>>>>
>>>>>  On Fri, 10 Jul 2015, Angelo Pantano wrote:
>>>>>
>>>>>>
>>>>>>  I have a freeipa server trusting an active directory domain, if I
>>>>>> ssh to
>>>>>>
>>>>>>> the ipa server everything works, but if I try to ssh on an ipa client
>>>>>>> the
>>>>>>> authentication fails.
>>>>>>>
>>>>>>> I noticed on the server that the wbinfo -n 'AD\Domain Users' is
>>>>>>> failing:
>>>>>>>
>>>>>>> failed to call wbcLookupName: WBC_ERR_DOMAIN_NOT_FOUND
>>>>>>>
>>>>>>> Also in the logs I see:
>>>>>>>
>>>>>>> log.winbindd-dc-connect:  get_sorted_dc_list: attempting lookup for
>>>>>>> name
>>>>>>> ad.local (sitename NULL)
>>>>>>>
>>>>>>> everything else works though, I can getent users and group just fine.
>>>>>>>
>>>>>>> Can you please help me?
>>>>>>>
>>>>>>>  We don't use wbinfo and don't recommend it with FreeIPA AD trusts
>>>>>>> -- at
>>>>>>>
>>>>>> least with Fedora 18+ and RHEL7+. When your FreeIPA server is deployed
>>>>>> on those platforms, SSSD is used to resolve users, not winbindd.
>>>>>> Winbindd is only used to manage forest topology.
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> / Alexander Bokovoy
>>>>>>
>>>>>>
>>>>>>   --
>>>>
>>>>> 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
>>>>>
>>>>>
>>>>
>>>> --
>>>> / Alexander Bokovoy
>>>>
>>>>
>> --
>> / Alexander Bokovoy
>>
>
>
-- 
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

Reply via email to