On ti, 30 maalis 2021, Kevin Fenzi wrote:
On Tue, Mar 30, 2021 at 09:30:33AM +0300, Alexander Bokovoy wrote:
Could you please explain where you want to do it? Noggin (Fedora
Accounts app) does handle the login itself, not FreeIPA. In the context
of what Fedora contributors interact with, FreeIPA is only directly
exposed via Kerberos authentication flow.
Well, I don't know. I am not implementing anything myself.
I should leave that to the people who would be implemnting things (the
noggin team).
Noggin can be modified to accept separate password and token values. In
fact, FreeIPA Web UI does have password-based login implemented in this
way -- there are separate password and token value login fields if user
has OTP associated.
Yeah, note that we are using IPA / RHEL8. It does not have seperate
password and token fields, so I assume this is something coming to IPA
soon. :)
This split of fields in FreeIPA Web UI exists since FreeIPA 4.0 which
was part of early RHEL 7 deliveries (the code for separate OTP field was
added in 2014).
There is nothing specific about it -- Noggin developers simply missed
this part, as well as they missed OTP token sycnhronization
functionality.
Security query/response pairs are something that Noggin would need to
manage on top of FreeIPA as well and thus would handle login with them.
We do not have any mechanism in FreeIPA to allow you to handle this on
behalf of Noggin.
ok
For security query/response pairs to be useful in FreeIPA context,
they'd need to be plugged into the main password change flows. There are
currently two major ones and the rest just piggy-backs on either of
them:
- a password change via LDAP protocol
- a password change via Kerberos protocol
Our current scheme for resetting forgotten or unknown passwords in
FreeIPA requires administrators to initiate a reset with a temporary
password, pre-set or randomly generated. Then a user changes the
password via one of the two methods above -- either directly or with the
help of one of applications that utilize those, by specifying the
temporary password first and providing a new one afterwards.
Kerberos password change protocol implements a single request and a
single reply message where the request is initiated by a client and the
server replies with a success or an error, after which the password is
either updated or not. The request sent by the client includes a single
user-data component (part of generic Kerberos KRB_PRIV message as per
RFC4120 section 5.7.1).
I don't think this is supported via KDCproxy is it?
It is supported. We don't expose DNS URI record for
_kpasswd.fedoraproject.org but if you'd add 'kpasswd_server' to
/etc/krb5.conf.d/fedoraproject_org with the same value as 'kdc', it will
allow you to change the password:
[934873] 1617273694.628547: Sending DNS URI query for _kpasswd.FEDORAPROJECT.ORG.
[934873] 1617273694.628548: No URI records found
...
[modify fedoraproject_org snippet]
...
$ cat /etc/krb5.conf.d/fedoraproject_org
[realms]
FEDORAPROJECT.ORG = {
kdc = https://id.fedoraproject.org/KdcProxy
pkinit_anchors = FILE:/etc/pki/ipa/fedoraproject_ipa_ca.crt
kpasswd_server = https://id.fedoraproject.org/KdcProxy
}
[domain_realm]
.fedoraproject.org = FEDORAPROJECT.ORG
fedoraproject.org = FEDORAPROJECT.ORG
$ KRB5_TRACE=/dev/stderr kpasswd abbra@xxxxxxxxxxxxxxxxx
...
Enter OTP Token Value:
...
Enter new password:
Enter it again:
[935146] 1617273825.195267: Creating authenticator for abbra@xxxxxxxxxxxxxxxxx -> kadmin/changepw@xxxxxxxxxxxxxxxxx, seqnum 0, subkey aes256-cts/9584, session key aes256-cts/4F2B
[935146] 1617273825.195269: Resolving hostname id.fedoraproject.org
[935146] 1617273825.195270: TLS certificate name matched "id.fedoraproject.org"
[935146] 1617273825.195271: Sending HTTPS request to https 8.43.85.67:443
[935146] 1617273825.195272: Received answer (236 bytes) from https 8.43.85.67:443
[935146] 1617273825.195273: Terminating TCP connection to https 8.43.85.67:443
[935146] 1617273825.195274: Read AP-REP, time 1617273825.195268, subkey aes256-cts/9584, seqnum 834862168
Password changed.
Note that in 'kpasswd' and 'kinit' utilities you have to concatenate
password and OTP token value in the same string, unfortunately, because
these utilities don't use prompting facilities available in MIT Kerberos
library. SSSD does use them, so it is possible to change password
through SSSD with separate prompts.
Improving 'kpasswd' and 'kinit' utilities in on my todo list as I'll
need this for other use cases as well.
If we'd want to add security query/response pairs to allow users to
'securely' reset their passwords initiated by themselves, this would be
possible with an appropriate extension of an LDAP control and changes to
FreeIPA Web UI and Noggin to support that. The bigger problem is to find
a way to securely store these pairs encrypted per user. Right now the
only per-user secret we have is something generated with the help of its
password but since this is all about being able to reset that password
without knowing its content, we need somewhat different method that
would still be secure against others. In FreeIPA nobody, including
administrators, is able to discover the user's password from a hashed
form.
Yeah, this stuff is not at all easy... will talk with the noggin folks
and see if we can come up with anything that we might want to persue.
We have RPC end-points on IPA server side that FreeIPA Web UI already
uses to login with a token value and for synchronizing OTP values. They
just need to call those end-points.
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
