#3242 [RFE] IPA WebUI login for AD Trusted User fails
Closed: fixed 6 years ago Opened 11 years ago by mkosek.

https://bugzilla.redhat.com/show_bug.cgi?id=872671 (Red Hat Enterprise Linux 7)

Description of problem:

Attemps to log into IPA WebUI with an AD Trusted user fails.

Version-Release number of selected component (if applicable):
ipa-server-3.0.0-106.20121026T1837zgitf14dd98.el6.x86_64
sssd-1.9.90-0.el6.x86_64
httpd-2.2.15-22.el6.x86_64

How reproducible:
alwayys

Steps to Reproduce:
1.  Setup IPA Master
2.  Setup AD Trust and create user on AD side
3.  Attempt to log into WebUI with AD user adtestuser@addomain.com

Actual results:
fails:

And I see this in /var/log/httpd/error_log:

[Thu Nov 01 10:42:18 2012] [error] ipa: INFO: *** PROCESS START ***
[Thu Nov 01 10:46:35 2012] [error] ipa: INFO: 401 Unauthorized: kinit: Client
'adtestuser1@TESTRELM.COM' not found in Kerberos database while getting initial
credentials
[Thu Nov 01 10:46:35 2012] [error]
[Thu Nov 01 10:47:02 2012] [error] [client 192.168.122.23]
gss_accept_sec_context() failed: No credentials were supplied, or the
credentials were unavailable or inaccessible (, Unknown error), referer:
https://rhel6-1.testrelm.com/ipa/ui/index.html
[Thu Nov 01 10:47:46 2012] [error] ipa: INFO: 401 Unauthorized: kinit:
Malformed representation of principal when parsing name
adtestuser1@adtestdom.com@TESTRELM.COM
[Thu Nov 01 10:47:46 2012] [error]
[Thu Nov 01 10:49:45 2012] [error] ipa: INFO: 401 Unauthorized: kinit: Client
'ADTESTDOMadtestuser1@TESTRELM.COM' not found in Kerberos database while
getting initial credentials

Expected results:
can log in like with normal IPA user.

Additional info:

This is an RFE to actually do something about the external users and let them do something in the system. We could map to an 'external' group, but to do it right we'd need to parse the PAC in the DS bind code. This would require a DS RFE too.

Move all uncompleted tickets to next month bucket.

With the new SASL mapping fallback code we can allow login from trusted members by mapping their principal name.

By default all users should probably be mapped to a single DN that represent a 'generic trusted user'. It should be completely powerless and should not be allowed to write to 'self' either.

The next setp would be to create some additional schema to be able to add trusted user objetcs. This trusted user would be identified by a new attribute to store the principal so that an additional sasl fallback mapping can be created to map specific principal names from trusted domains to this object. This object can then be used in delegation ACIs so that these users can actually be allow to do 'something' on the server.

A new objetclass named something like 'ipaTrustedUser' would have as an allowed attribute like 'ipaTrustedUserPrincipal', which will contain a string like: userX@TRUSTED.REALM.NAME

There would be 2 additional SASL mappings per trusted realm then:
1. To map explicitly created trusted users.
2. to map any other user to the catch all 'generic trusted user'.

There are two cases:

  1. Users from trusted domain are mapped to one generic "fall back" account in IPA that has least privileges.
  2. Users from trusted domains are synced so that we can take advantage of the UID/GID already defined in AD in the past (this is covered by other tickets). In this case it would makes sense to leverage user entry created by winsync. We might want to have an option in winsync to apply ipaTrustedUser object class to the synced users. Then we can update self-service ACI to factor presence of the ipaTrustedUserPrincipal attribute. If it is present the entry should become read only for the logged in user.

Replying to [comment:8 dpal]:

There are two cases:

  1. Users from trusted domain are mapped to one generic "fall back" account in IPA that has least privileges.
  2. Users from trusted domains are synced so that we can take advantage of the UID/GID already defined in AD in the past (this is covered by other tickets). In this case it would makes sense to leverage user entry created by winsync. We might want to have an option in winsync to apply ipaTrustedUser object class to the synced users. Then we can update self-service ACI to factor presence of the ipaTrustedUserPrincipal attribute. If it is present the entry should become read only for the logged in user.

Case 2 is only a special case for migration (from winsync to turst) scenarios.

In general for the normal case there is no trusted user entry in the FreeIPA tree so we have to create custom entries (this means CLI and UI to do that) to be able to map a principal to a DN and use that DN to delegate permissions to this trusted user.

So we have 2 main cases:
1. mapping of all trusted user to generic entry
2. mapping of specific trusted users to a custom entry

and then a third special case:
3. mapping of specific user to specially synced users

This last case is only a special case of 2 where the object entry is an actual synced user.
As you noted this will require special attention and careful consideration about what ACIs should be applied to these users, but for self-service and other uses.

Dmitri has requested in this forum post that I add a comment to this ticket : https://www.redhat.com/archives/freeipa-users/2015-May/msg00171.html

I would like to request that work on this feature proceed.

In our organization, we have all of our users in Active Directory and will be using a trust relationship to allow them to login to FreeIPA joined Linux machines. Some of those users are system administrators and need to make updates to DNS. I see that FreeIPA has an RBAC DNS Administrator role, but even though I can add my groups / external groups containing AD users, they cannot login to the webui.

I would also like to be able to allow AD Domain Administrators to be FreeIPA administrators so we don't have to create special internal accounts for every AD user who needs to administer FreeIPA. The point of creating a trust was to avoid having 2 different sets of users and passwords and it would be great to be able to extend that to FreeIPA administration.

AD User self-service is a stretch target for 4.4.

Prerequisite for the feature was pushed:

master:

b506fd178edbf1553ca581c44ac6697f88ead125 adtrust: support GSSAPI authentication to LDAP as Active Directory user

4.4.0 was released, moving open tickets to 4.4.1

Metadata Update from @mkosek:
- Issue assigned to pvomacka
- Issue set to the milestone: FreeIPA 4.5

7 years ago

Metadata Update from @pvoborni:
- Issue close_status updated to: None
- Issue tagged with: webui

7 years ago

Metadata Update from @pvoborni:
- Issue priority set to: 2 (was: 3)

7 years ago

Metadata Update from @mbasti:
- Issue set to the milestone: FreeIPA 4.5.1 (was: FreeIPA 4.5)

7 years ago

Metadata Update from @pvomacka:
- Custom field on_review adjusted to https://github.com/freeipa/freeipa/pull/639 (was: 0)

6 years ago

master:

  • 1dcdcd1 WebUI: check principals in lowercase
  • 2992e3c WebUI: add method for disabling item in user dropdown menu
  • ceedc3f WebUI: Add support for login for AD users

ipa-4-5:

  • bee9c9f WebUI: check principals in lowercase
  • 01a0a38 WebUI: add method for disabling item in user dropdown menu
  • 228e039 WebUI: Add support for login for AD users

Metadata Update from @mbabinsk:
- Issue close_status updated to: fixed
- Issue status updated to: Closed (was: Open)

6 years ago

Login to comment on this ticket.

Metadata