Description of problem: We have a dedicated VM in amazon which is created regularly from template. It is not included in domain at all, even there is no dns record for that machine. The goal is to execute ipa commands from that vm(ipa host-add/ipa host-del etc.) So I installed ipa-admin-tools and ipa-client/sssd packages as dependencies. When executing some simple command I get an error: ipa: ERROR: cert validation failed for "CN=xxx,O=xxx" ((SEC_ERROR_UNTRUSTED_ISSUER) Peer's certificate issuer has been marked as not trusted by the user.) ipa: ERROR: cert validation failed for "CN=xx,O=xxx" ((SEC_ERROR_UNTRUSTED_ISSUER) Peer's certificate issuer has been marked as not trusted by the user.) ipa: ERROR: cert validation failed for "CN=xxx,O=xxx" ((SEC_ERROR_UNTRUSTED_ISSUER) Peer's certificate issuer has been marked as not trusted by the user.) ipa: ERROR: cannot connect to Gettext('any of the configured servers', domain='ipa', localedir=None): https://<ldapserver>/ipa/xml, https://<ldapserver2>/ipa/xml, https://<ldapserver3>/ipa/xml So my first question - whether I can run ipa shell against domain from host not joined to domain? If I can then how to solve above problem? Thanks ahead! Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
For this system to be able to connect t oIPA and run commands it needs to be trusted by IPA. This means that IPA needs to authenticate this system. The easiest is to install the client. Why is that a problem? We would like to understand the the reason for the constraint. If you do not want to install the client I think you need to manually get a public cert of IPA CA copied to this system and configure it to use kerberos. You also would need to configure ipa.conf manually to know where is the server (but I am not sure). The easiest would probably to copy cert and config files from an enrolled client. There might be some other pieces that need updating. resolv.conf comes to mind. Even if you managed to do that the main question here is what are you going to use to authenticate to IPA? If you plan to create an admin user and hardcode the password then it is not a good idea. It seems that you are creating a provisioning system. To do that we recommend to use the smart proxy the patches for which landed recently on the list. It least this is how we plan to integrate with Foreman. Some references: First patches with SmartProxy were posted to devel mailing list some time ago: https://www.redhat.com/archives/freeipa-devel/2014-January/msg00213.html Ticket See ticket https://fedorahosted.org/freeipa/ticket/4128 Foreman page: http://projects.theforeman.org/projects/foreman/wiki/RealmJoinIntegration
Hi, Thanks for your comment. The easiest is to install the client. Why is that a problem? - We tend to have a kind of on-demand machine in amazon cloud which is provisioned for us under some conditions. So it should be a temporary instance deployed from a template. My guess is that the problem is with certificate, but I can't spot where exactly. What is configured on this host: 1. Installed ipa-client, sssd and ipa-admin-tools, but client is not configured, so only package exists. 2. host is not in dns 3. Content of sssd.conf [domain/improve] cache_credentials = True krb5_store_password_if_offline = True ipa_domain = improve id_provider = ipa auth_provider = ipa access_provider = ipa chpass_provider = ipa ipa_dyndns_update = True ipa_server = _srv_, ldap.improve, ldap2.improve ldap_tls_cacert = /etc/ipa/ca.crt [sssd] services = nss, pam config_file_version = 2 domains = improve [nss] [pam] [sudo] [autofs] [ssh] [pac] 4. Content of ipa.conf file [global] basedn = dc=improve realm = IMPROVE domain = IMPROVE server = ldap.improve xmlrpc_uri = https://ldap.improve/ipa/xml enable_ra = True 5. I copied ca.crt from enrolled node to this host in /etc/ipa/ca.crt Even if you managed to do that the main question here is what are you going to use to authenticate to IPA? - As I mentioned above, the goal is to have a temporary jump station where we can launch commands against ldap: remove/add host, add/remove dns records and so on. Please look over my configs I listed if there are some oddities. And how can I obtain certificate from IPA for this jump station? Thanks ahead! Sergey
(In reply to s.zemlyanoy from comment #2) > Hi, > Thanks for your comment. > > The easiest is to install the client. Why is that a problem? - We tend to > have a kind of on-demand machine in amazon cloud which is provisioned for us > under some conditions. So it should be a temporary instance deployed from a > template. But once it is provisioned it needs to have a Kerberos key or password to authenticate to IPA to perform any operation. To run any command you need to do kinit <someone> or use the keytab of the client. So if this account can do admin commands then the same account can provision the client. What you are trying to do is: 1) Configure system manually 2) Kinit <someone> 3) Run command What I suggest is 1) install client as this <someone>, it will do kinit for you 2) Run command The result is the same but spares you from the manual step and us for providing a manual procedure for something that is automated an is polished of the course of 6 years. The problem you have now is probably with the cert configuration but it is just the first problem. The main problem as I mentioned is what account you would use and how you plan to authenticate. You skipped the answer. You stated the goal. The goal is to run commands - fine but you need to authenticate to run the commands.
Hi, Yes we have a dedicated ldap user for that # kinit svc_removal@IMPROVE -k -t /opt/svc_removal.keytab This user can authenticate against ipa and kerebros tickets are assigned # klist Ticket cache: FILE:/tmp/krb5cc_0 Default principal: svc_removal@IMPROVE Valid starting Expires Service principal 02/02/14 18:35:27 02/03/14 18:35:27 krbtgt/IMPROVE@IMPROVE But any ipa command with this user fail with error in subject post.
I think it is reasonable to require IPA admin tools to work on a host enrolled into IPA domain through standard means. I can understand allowing other hosts to access IPA services (KDC, LDAP, ...) directly with a manual or semi-automatic configuration but for admin tools we need to assume certain level of integrity of the configuration of the host.
I think the bare minimum is /etc/ipa/default.conf, a working krb5 configuration (either in /etc/krb5.conf or via environment, and the IPA CA in /etc/ipa/ca.crt.
Right. Please report if all this information was of help. If yes, I would vouch for closing this bug.
It seems to me that the discussion and target of upstream ticket https://fedorahosted.org/freeipa/ticket/3960 may help also in this Bugzilla. If yes, I can link these 2 together.
Linking this bug to 3960.