Bug 1266407 - IPA (external users) not able to authenticate using hammer CLI: invalid user / SSO failed [NEEDINFO]
IPA (external users) not able to authenticate using hammer CLI: invalid user ...
Status: NEW
Product: Red Hat Satellite 6
Classification: Red Hat
Component: Users & Roles (Show other bugs)
x86_64 Linux
high Severity high with 2 votes (vote)
: Unspecified
: --
Assigned To: Tomas Strachota
Katello QA List
: FieldEngineering, PrioBumpPM, Triaged
: 1331689 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2015-09-25 04:23 EDT by Sebastian Hetze
Modified: 2018-01-19 01:38 EST (History)
29 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
bkearney: needinfo? (mhulan)

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Foreman Issue Tracker 11317 None None None 2016-09-09 04:18 EDT

  None (edit)
Description Sebastian Hetze 2015-09-25 04:23:27 EDT
Description of problem:

IPA users are not able to authenticate via hammer CLI.
Foreman gives
[I] invalid user
[W] SSO failed

Steps to Reproduce:
1. Configure IPA backend for authentication.
2. Login via Web-UI, assing roles to IPA user (this works)
3. Try something like "hammer organization list"

Actual results:

Invalid username or password

Expected results:

ID | NAME           | LABEL          | DESCRIPTION
1  | Default Org    | Default_Org    |            

Additional info:
Comment 3 Jan Pazdziora 2016-01-05 07:50:23 EST
I'm not sure what the [I] and [W] in comment 0 mean exactly but Kerberos authentication RFEs are in bug 1181394 (server side) and bug 1264161 (hammer CLI).

Per bug 1181394 comment 5, the external authentication is not handled by API at this point at all so if part of this use-case is password-based authentication, we can track that use-case here.
Comment 4 Jan Pazdziora 2016-01-05 07:51:18 EST
(In reply to Sebastian Hetze from comment #0)
> 3. Try something like "hammer organization list"
> Actual results:
> Invalid username or password

Will hammer prompt for the login and password or just fail with this error message right away?
Comment 5 Sebastian Hetze 2016-01-05 08:20:11 EST
[I] and [W] are information and warning messages from /var/log/foreman/production.log

This is still easy to reproduce with Sat 6.1.5

I use .hammer/cli_config.yml for authentication, so no prompt here.

However, if I remove the cli_config.yml hammer prompts for username and password (and gives "Invalid username or password" message for external users).

As you see this is clear text password authentication and has nothing to do with the Kerberos RFE.
Comment 6 Tony 2016-02-04 03:42:27 EST
Still same issue on Satellite 6.1.6
Comment 9 Ivan Necas 2016-04-26 12:12:57 EDT
I don't think it's realistic to get the changed needed into the code
in 6.2 timeframe.

Here is a solution I propose as a workaround:


cat <<EOF > /etc/httpd/conf.d/05-foreman-ssl.d/api_ext_auth.conf
<Location /api>
  AuthType Basic
  AuthName "private area"
  AuthBasicProvider PAM
  AuthPAMService $IPA_SERVER
  Require valid-user
service httpd restart
foreman-rake config -- -k authorize_login_delegation_api -v true

This will configure the apache to perform the idm integration calls for api requests. The downside of this solution is that in this case, other auth methods (such as internal users) will not work (that's one of the reasons I don't think it would be accepted upstream).

I propose documenting this as a KCS and postponing the bug to 6.3 to have a proper solution together with https://bugzilla.redhat.com/show_bug.cgi?id=1181394
Comment 13 Marek Hulan 2016-09-08 10:25:15 EDT
Just to clarify, I think this issue is not about using kerberos for authentication, as Jan said there are already separate BZs for kerberos authentication.

This BZ is about logging in users which auth source is not internal nor "EXTERNAL", but native LDAP-based one through hammer. It works fine for me with Satellite 6.2.0 and IPA.

Sebastian or Tony, could you please verify with the newer version? In case you still experience the issue, could you change the log level to debug and send a production.log while user tries to login via hammer?
Comment 14 Jan Pazdziora 2016-09-08 10:38:10 EDT
Actually, my understanding is this is exactly about authenticating with Kerberos, but not on WebUI but with hammer.
Comment 15 Marek Hulan 2016-09-08 11:11:22 EDT
I think in comment 5 it's said by the reporter that it has nothing to do with the Kerberos. Hammer should be able to take username and password and do authentication against LDAP auth source. If the auth source is "EXTERNAL" (not LDAP), there's no LDAP server to ask and yes, as a different authentication mechanism we could use Kerberos ticket, but that's a different RFE.
Comment 16 Sebastian Hetze 2016-09-08 11:18:06 EDT
The problem persists with current Sat6.2.1.

Authentication is using IPA as documented in https://access.redhat.com/documentation/en/red-hat-satellite/6.2/paged/server-administration-guide/92-using-identity-management

Changed config.log_level = :debug in
and restarted httpd

This is the output in /var/log/foreman/production.log:

2016-09-08 16:56:08 [app] [I] Started GET "/katello/api/organizations" for at 2016-09-08 16:56:08 +0200
2016-09-08 16:56:08 [app] [I] Processing by Katello::Api::V2::OrganizationsController#index as JSON
2016-09-08 16:56:08 [app] [I]   Parameters: {"api_version"=>"v2", "organization"=>{}}
2016-09-08 16:56:08 [app] [W] SSO failed
2016-09-08 16:56:08 [app] [I]   Rendered api/v2/errors/unauthorized.json.rabl within api/v2/layouts/error_layout (1.1ms)
2016-09-08 16:56:08 [app] [I] Filter chain halted as :authorize rendered or redirected
2016-09-08 16:56:08 [app] [I] Completed 401 Unauthorized in 36ms (Views: 4.7ms | ActiveRecord: 2.7ms)
Comment 17 Sebastian Hetze 2016-09-08 11:40:00 EDT
(In reply to Jan Pazdziora from comment #14)
> Actually, my understanding is this is exactly about authenticating with
> Kerberos, but not on WebUI but with hammer.

While it would be nice to have hammer re-use an existing Kerberos ticket obtained previously with IPA authentication, this is not the issue here.

The expectation is, that authentication with hammer works for external IPA users like it does with the WebUI.
Comment 18 Marek Hulan 2016-09-09 04:18:35 EDT
Ok, thanks Sebastian for clarification. I thought you have configured the external authentication using LDAP auth source which would have worked in your case for both WebUI and CLI since you don't use Kerberos tickets.
Comment 19 Bryan Kearney 2016-10-17 16:26:07 EDT
Marek, so is this a dupe of https://bugzilla.redhat.com/show_bug.cgi?id=1264161
Comment 20 Marek Hulan 2016-10-18 02:33:42 EDT
Not entirely, this BZ requests support on server side to talk to kerberos and keeping hammer asking for username and password. The authentication would happen through negotiation.

BZ 1264161 asks for using existing kerberos ticket obtained from kinit instead of username and password.
Comment 22 Jan Pazdziora 2016-10-18 02:38:47 EDT
(In reply to Bryan Kearney from comment #19)
> Marek, so is this a dupe of
> https://bugzilla.redhat.com/show_bug.cgi?id=1264161

It might or might not be.

My current understanding is that the request here is to be able to login + password for external users (for example users from IPA/IdM), with no Kerberos involved. The solution would likely involve PAM setup on the server as shown in comment 9, but ideally in such a way that falling back is possible.

For that fall back, some refactoring on the client might be needed and that refactoring might be similar to what bug 1264161 might need.

It shouldn't be treated as duplicate because the test plan / QA effort will be different. The solution however might be very close to / part of the one for that bug.
Comment 23 Bryan Kearney 2016-11-29 10:03:52 EST
Upstream bug assigned to tstrachota@redhat.com
Comment 26 Brad Buckingham 2017-06-14 08:28:26 EDT
*** Bug 1331689 has been marked as a duplicate of this bug. ***

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