On ke, 16 marras 2022, Giuseppe Calo via FreeIPA-devel wrote:
It seem I don't have these logs:
[root@master ~]# systemctl list-units | grep ipa
ipa-custodia.service
loaded active running IPA Custodia Service
ipa-dnskeysyncd.service
loaded active running IPA key daemon
ipa.service
loaded active exited Identity, Policy, Audit
ipa-otpd.socket
loaded active listening ipa-otpd socket
ipa-ccache-sweep.timer
loaded active elapsed Remove Expired Kerberos
Credential Caches
[root@master ~]# systemctl status ipa-otpd.socket
● ipa-otpd.socket - ipa-otpd socket
Loaded: loaded (/usr/lib/systemd/system/ipa-otpd.socket; disabled;
vendor preset: disabled)
Active: active (listening) since Wed 2022-11-16 17:32:04 CET; 4h 4min
ago
Until: Wed 2022-11-16 17:32:04 CET; 4h 4min ago
Listen: /run/krb5kdc/DEFAULT.socket (Stream)
Accepted: 0; Connected: 0;
CGroup: /system.slice/ipa-otpd.socket
Nov 16 17:32:04 master.idm.cmcc.scc systemd[1]: Listening on ipa-otpd
socket.
[root@master ~]# journalctl -xeu ipa-otpd
~
~
Where can I check?
In any case, is it right to insert as first factor the password of user
defined in ipa and as second factor the password defined in radius?
That is certainly not supported. When RADIUS proxy is used for user's
authentication, both factors passed unchanged to the RADIUS server and
the result of authentication by the RADIUS server is expected to define
whether user is authenticated or not.
This also only works over Kerberos. Please see detailed flow described
in
https://freeipa.readthedocs.io/en/latest/designs/ldap_pam_passthrough.html
where LDAP passthrough is not implemented (that's a design page, not
documentation for existing feature) but the current flow is discussed.
Looks like your setup is incomplete. In order to help, we need to see
exact steps that you have done to configure and test the setup and
output you have received. Please provide the exact output, not
paraphrase.
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland