Re: [Freeipa-users] Odd problem with SSSD and SSH keys
On 14.1.2014 12:34, Bret Wortman wrote: The key in /etc/ssh/ssh_host_rsa_key.pub matches what's in IPA for the host in question. It should not have had any connectivity issues; it's co-located with several of our IPA masters. Can you also check if the MD5 fingerprint reported by ssh (e.g. 2a:1e:1c:87:33:44:fb:87:ab:6f:ee:80:d5:21:7e:ab in your original post) matches the MD5 fingerprint for the host in IPA? I'd be happy to run sss_ssh_knownhostsproxy manually but haven't been able to locate the proxy command to use via Google yet. Any guidance? I don't think you need to do that, it will just update /var/lib/sss/pubconf/known_hosts again. On 01/14/2014 05:43 AM, Jan Cholasta wrote: On 13.1.2014 22:18, Jakub Hrozek wrote: On Mon, Jan 13, 2014 at 02:44:29PM -0500, Bret Wortman wrote: They're definitely different. I deleted the one in the file, then tried again. It put the bad key back in the file. I blew the whole file away and the same thing happened. Where is this key coming from if not from IPA? Can you try running sss_ssh_knownhostsproxy manually to see what key does it return? The keys are propagated to the file from the sssd database. If the client was offline, the client could use stale records. Can you verify the client has no connectivity issues? Honza (CC-ed) might have some more hints. Compare the public key in /etc/ssh/ssh_host_rsa_key.pub on the host with the public key for that host in IPA. If they do not match, the host key was changed after IPA client was installed and the host record in IPA must be manually updated with the new key. Honza -- Jan Cholasta ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] sudo log errors
On Wed, Jan 15, 2014 at 6:49 AM, Simo Sorce s...@redhat.com wrote: On Tue, 2014-01-14 at 11:34 -0500, Dmitri Pal wrote: On 01/14/2014 06:17 AM, Natxo Asenjo wrote: Is there anything else I can do or do I just have to live with the error on syslog? I wonder if putting this user into the local sssd provider would silence it... Just a thought... Probably not, the question is, why is sudo trying to use roots kerberos credentials ? no idea. According to /etc/nsswitch.conf, it should read local sudoers first: $ grep sudo /etc/nsswitch.conf sudoers:files ldap The nagios user is a local user that gets installed when installing nrpe (the nagios agent). This is what gets polled remote by the nagios server. On what platform are you ? With sudo-sssd integration you shouldn't use directly ldap anymore. centos 6.5 on these hosts. So if I use sssd insted of ldap for sudo this could go away? However if you need, what you can do is to have a cronjob generate the /tmp/krb5cc_0 ccache from the machine keytab. This will silence the error, although it will turn into a full bind and search of data in LDAP. Not sure which you prefer. yes, I had thought of that. Is that a potential risk in your opinion? I mean, in order to use it, they need root rights and if they have, well, it could be generated as well. What do you think? Besides, it should not have to bind because files comes first. Thanks for taking the time to look into this. Regards, -- natxo ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] sudo log errors
On Wed, Jan 15, 2014 at 10:09:20AM +0100, Natxo Asenjo wrote: On what platform are you ? With sudo-sssd integration you shouldn't use directly ldap anymore. centos 6.5 on these hosts. So if I use sssd insted of ldap for sudo this could go away? I believe so, with the sssd integration, the sudo fetches all data from the SSSD. One catch though, there is no sudo_provider=ipa in 6.5, but man sssd-sudo should contain an example of setting up sudo_provider=ldap on an IPA client. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] sudo log errors
On Wed, Jan 15, 2014 at 10:59 AM, Jakub Hrozek jhro...@redhat.com wrote: On Wed, Jan 15, 2014 at 10:09:20AM +0100, Natxo Asenjo wrote: On what platform are you ? With sudo-sssd integration you shouldn't use directly ldap anymore. centos 6.5 on these hosts. So if I use sssd insted of ldap for sudo this could go away? I believe so, with the sssd integration, the sudo fetches all data from the SSSD. One catch though, there is no sudo_provider=ipa in 6.5, but man sssd-sudo should contain an example of setting up sudo_provider=ldap on an IPA client. ok. If I configure sssd.conf like that, do I need to configure anything in /etc/sudo-ldap.conf or are those mutually exclusive? I have now this in /etc/sudo-ldap.conf: TLS_CACERT /etc/ipa/ca.crt TLS_REQCERT demand SASL_MECH GSSAPI BASE dc=sub,dc=domain,dc=tld URI ldaps://kdc01.sub.domain.tld ldaps://kdc02.sub.domain.tld ROOTUSE_SASL on SUDOERS_BASE ou=sudoers,dc=sub,dc=domain,dc=tld SUDOERS_DEBUG 0 and this in sssd.conf [sssd] domains = sub.domain.tld services = nss, pam, ssh config_file_version = 2 [nss] [pam] [domain/sub.domain.tld] cache_credentials = True krb5_store_password_if_offline = True ipa_domain = sub.domain.tld id_provider = ipa auth_provider = ipa access_provider = ipa chpass_provider = ipa ipa_dyndns_update = True ipa_server = _srv_, kdc01.sub.domain.tld ldap_tls_cacert = /etc/ipa/ca.crt entry_cache_netgroup_timeout = 300 [sudo] [autofs] [ssh] -- Groeten, natxo ___ 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] Odd problem with SSSD and SSH keys
The fingerprint does match. On 01/15/2014 03:33 AM, Jan Cholasta wrote: On 14.1.2014 12:34, Bret Wortman wrote: The key in /etc/ssh/ssh_host_rsa_key.pub matches what's in IPA for the host in question. It should not have had any connectivity issues; it's co-located with several of our IPA masters. Can you also check if the MD5 fingerprint reported by ssh (e.g. 2a:1e:1c:87:33:44:fb:87:ab:6f:ee:80:d5:21:7e:ab in your original post) matches the MD5 fingerprint for the host in IPA? I'd be happy to run sss_ssh_knownhostsproxy manually but haven't been able to locate the proxy command to use via Google yet. Any guidance? I don't think you need to do that, it will just update /var/lib/sss/pubconf/known_hosts again. On 01/14/2014 05:43 AM, Jan Cholasta wrote: On 13.1.2014 22:18, Jakub Hrozek wrote: On Mon, Jan 13, 2014 at 02:44:29PM -0500, Bret Wortman wrote: They're definitely different. I deleted the one in the file, then tried again. It put the bad key back in the file. I blew the whole file away and the same thing happened. Where is this key coming from if not from IPA? Can you try running sss_ssh_knownhostsproxy manually to see what key does it return? The keys are propagated to the file from the sssd database. If the client was offline, the client could use stale records. Can you verify the client has no connectivity issues? Honza (CC-ed) might have some more hints. Compare the public key in /etc/ssh/ssh_host_rsa_key.pub on the host with the public key for that host in IPA. If they do not match, the host key was changed after IPA client was installed and the host record in IPA must be manually updated with the new key. Honza smime.p7s Description: S/MIME Cryptographic Signature ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Odd problem with SSSD and SSH keys
No, that was me conflating this problem on two different machines, rs512 and zw131. Sorry about that. Bret On 01/15/2014 12:53 AM, Simo Sorce wrote: On Tue, 2014-01-14 at 06:46 -0500, Bret Wortman wrote: I was assuming that the key was being re-inserted by the ssh authentication request, but to eliminate puppet, I just tried this sequence: # puppet agent --disable # rm -f /var/lib/sss/pubconf/known_hosts # ls -l /var/lib/sss/pubconf/known_hosts # ssh zw131 : : (errors about the key being incorrect) : # cat /var/lib/sss/pubconf/known_hosts : it now contained the bad key again. Just a shot in the dark. Your log files say ' host rs512 ', are you having reverse DNS issues ? Simo. smime.p7s Description: S/MIME Cryptographic Signature ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Sudo policy not working with group of servers
Setting the nis domain resolved the issue with the host groups. Thanks Dimitar On Tue, Jan 14, 2014 at 10:41 AM, Martin Kosek mko...@redhat.com wrote: On 01/14/2014 04:27 PM, Dimitar Georgievski wrote: Hi, I've been trying to create a simple sudo policy, that would grant certain privileges to a group of users on a group of hosts. The policy would not work unless I specify the hosts individually in the *Sudo Rule* definition page under *Access this hos*t section. I am using FreeIPA v3.0 and SSSD v1.9.2 on CentOS 6.5 Thanks, Dimitar Hello Dimitar, I would recommend starting investigation by following this article: http://www.freeipa.org/page/Troubleshooting#sudo_does_not_work_for_hostgroups Martin ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] HP ILO Authentication via LDAP (or even kerberos)
For the record, I spent quite a long time on this and finally gave up. I never found a work-around other than providing the entire DN, which I wasn't about to do. On Tue, Jan 14, 2014 at 11:53 PM, Alexander Bokovoy aboko...@redhat.comwrote: On Wed, 15 Jan 2014, Les Stott wrote: I can confirm that the password was typed in correctly. Maybe its not matching the account because it's the compat tree? No, it is not matching because BIND over compat tree is only supported with slapi-nis 0.48+ which is not RHEL 6.x feature. As Dmitri said, it is feature available with FreeIPA 3.3.x, not 3.0. -- / Alexander Bokovoy ___ 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] One way trusts
I think that the requirement is to have two distinct sets of users while you don't have control over one set (AD users) but you have to manage the other set (IPA users) somehow. Yup. I'm yet to see what is the benefit over having only IPA users. Given single sign-on wasn't a concern, it makes no difference then to specify IPA's user name during logon from AD machines, so no integration would really be needed. Difference #1 (user experience): Users in AD do not have a new password to remember and/or manage. Difference #2 (administration overhead): I don't have to create users which are already in AD. Difference #3 (political): I'm not duplicating effort of our IT division, I'm serving an un-served community, so there's less turf violation. An attempt to keep users in AD but use IPA features is really asking for collaboration between the two infrastructure setups. Well, part of the confusion may lie in the fact that much of the functionality in IPA and AD is unfamiliar to me, particularly at the beginning. First and foremost, I'm viewing both AD and IPA as identity stores which can provide Authentication services and store some information about the users which can be used by clients for various purposes: access decisions being a big one. I've been using the LDAP interface to AD because it's easier to understand, and because I can graft in my external users via an LDAP metadirectory. This can be done without any infrastructure collaboration, and it provides support for applications which do not allow you to configure more than one domain. Then I started looking at trying to authenticate using Kerberos. Didn't know much about Kerberos when I started. It's supposed to have all sorts of good features. But it also seems to be the layer that introduces the need to collaborate, where before there was none. Early testing seems to indicate that I can in fact kinit against AD using a machine not joined to the domain. This gets me a no-address, forwardable TGT, and should suffice to tell the machine that the AD server believes I'm me. I suspect I will run into problems if I then try to use my TGT to get a login ticket for this host-unknown-to-AD. I'm in the middle of trying to configure sssd on my test VM to use krb5/ldap authentication. It appears I cannot have sssd bind against AD's LDAP interface using Kerberos, or I just haven't figured out how, so the next step is to type my DN and password into another plain text file. Once this works, I'll configure IPA as a second domain on this host. If machines on my research network (which does not share DNS namespace with AD) are joined to any domain, it would be to the FreeIPA domain. I do not quite understand the implications of this with regard to user principles from AD. It seems like it should be possible for me to make groups in FreeIPA which name members from other directories. It also seems like sssd should be capable of making access decisions based on a user principle from one domain and a group from another. But if I understand Kerberos correctly, it will be impossible for the FreeIPA TGS to issue a cross-realm ticket without the required cross realm trust and the associated remote principle entries in both directories. I think my ability to make use of FreeIPA's extra (beyond authentication) functionality may depend on exactly where the access control decision is made, and how the information to support that decision is gathered. I'm hoping that sssd can be convinced to make these decisions based on information returned from an LDAP query on the freeIPA server and the TGT from the AD server. Contrary-wise, I'm hoping that I don't need a cross-realm Kerberos ticket from either domain. Thanks for your patience. Sorry its taking so long to come up to speed. Bryce This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] HP ILO Authentication via LDAP (or even kerberos)
On 15.1.2014 23:13, KodaK wrote: For the record, I spent quite a long time on this and finally gave up. I never found a work-around other than providing the entire DN, which I wasn't about to do. Did you try the slapi-nis from FreeIPA 3.3.3? Just for the record, so we will know if it works or not. Petr^2 Spacek On Tue, Jan 14, 2014 at 11:53 PM, Alexander Bokovoy aboko...@redhat.comwrote: On Wed, 15 Jan 2014, Les Stott wrote: I can confirm that the password was typed in correctly. Maybe its not matching the account because it's the compat tree? No, it is not matching because BIND over compat tree is only supported with slapi-nis 0.48+ which is not RHEL 6.x feature. As Dmitri said, it is feature available with FreeIPA 3.3.x, not 3.0. -- / Alexander Bokovoy ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
