Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1060283 - Passing IPA commands from host not included in domain
Summary: Passing IPA commands from host not included in domain
Keywords:
Status: CLOSED CANTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: freeipa
Version: 20
Hardware: Unspecified
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Rob Crittenden
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-01-31 17:04 UTC by s.zemlyanoy
Modified: 2014-11-10 12:13 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-11-10 12:13:26 UTC


Attachments (Terms of Use)

Description s.zemlyanoy 2014-01-31 17:04:03 UTC
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:

Comment 1 Dmitri Pal 2014-01-31 18:13:19 UTC
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

Comment 2 s.zemlyanoy 2014-02-02 11:03:43 UTC
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

Comment 3 Dmitri Pal 2014-02-02 16:02:47 UTC
(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.

Comment 4 s.zemlyanoy 2014-02-02 17:42:23 UTC
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.

Comment 5 Alexander Bokovoy 2014-02-02 18:53:07 UTC
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.

Comment 6 Rob Crittenden 2014-02-03 10:38:49 UTC
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.

Comment 7 Martin Kosek 2014-02-06 09:07:26 UTC
Right. Please report if all this information was of help. If yes, I would vouch for closing this bug.

Comment 8 Martin Kosek 2014-02-11 12:20:56 UTC
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.

Comment 9 Martin Kosek 2014-02-18 16:37:40 UTC
Linking this bug to 3960.


Note You need to log in before you can comment on or make changes to this bug.