On Tue, Dec 22, 2020 at 01:50:55AM +0100, Abdelkader Chelouah wrote:
> Hello,
>
>
> I configured MIT Krb5-1.18.3 KDC to use FAST OTP with authentication
> indicator "*strong*".
>
> $ cat kdc.conf
>
> ...
>
> [otp]
> Â Â Â Â Â Â Â softid = {
> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â server = 192.168.0.68:1812
> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â secret = /etc/.radius.secret
> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â strip_realm = true
> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â indicator = strong
> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â #timeout = <integer> (default: 5 [seconds])
> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â #retries = <integer> (default: 3)
> Â Â Â Â Â Â Â }
>
>
> The kerberos Realm "DNS.PODMAN" has only two "otp" principals, *alice* and
> *bob.*
>
>
> $ kadmin.local getstrs alice
> otp: [{"type":"softid"}]
>
> $ kadmin.local getstrs bob
> otp: [{"type":"softid"}
>
>
> Alice's password was purged with the command
>
>
> kadmin.local purgekeys -all alice
>
>
> On the sssd host (RHEL 7.9), sssd service uses the following configuration
> file
>
>
> [sssd]
> domains = DNS.PODMAN
> services = nss,pam,ssh
> config_file_version = 2
> debug_level = 9
>
> [nss]
> filter_users = root
> filter_groups = root
> reconnection_retries = 3
> entry_cache_nowait_percentage = 75
> debug_level = 9
>
> [pam]
> reconnection_retries = 3
> offline_credentials_expiration = 2
> offline_failed_login_attempts = 3
> offline_failed_login_delay = 5
>
> [domain/DNS.PODMAN]
> debug_level = 0x04000
> id_provider = ldap
> ldap_uri = ldaps://kerb.dns.podman:636/
> ldap_search_base = dc=dns,dc=podman
> ldap_schema = rfc2307bis
> ldap_tls_reqcert = demand
> ldap_tls_cacert = /etc/pki/tls/certs/ca.crt
>
> ldap_sasl_mech = gssapi
> ldap_sasl_authid = sssd/sssd.dns.podman
> ldap_krb5_keytab = /etc/sssd/sssd.keytab
> ldap_krb5_init_creds = true
> ldap_krb5_ticket_lifetime = 86400
>
> ldap_user_search_base = ou=people,dc=dns,dc=podman
> ldap_user_object_class = posixAccount
>
> ldap_group_search_base = ou=groups,dc=dns,dc=podman
> ldap_group_object_class = groupOfNames
> ldap_group_gid_number = gidNumber
> ldap_group_member = member
>
> auth_provider = krb5
> krb5_server = kerb.dns.podman
> krb5_realm = DNS.PODMAN
> cache_credentials = true
> krb5_keytab = /etc/krb5.keytab
> krb5_use_fast = try
> krb5_fast_principal = host/sssd.dns.podman
>
> min_id = 10000
> max_id = 20000
> #enumerate = False
> enumerate = True
>
> [ssh]
> debug_level = 9
>
> # klist -k /etc/krb5.keytab
> Keytab name: FILE:/etc/krb5.keytab
> KVNO Principal
> ----
> --------------------------------------------------------------------------
> Â Â 2 host/[email protected]
> Â Â 2 host/[email protected]
> Â Â 2 host/[email protected]
> Â Â 2 host/[email protected]
> Â Â 2 host/[email protected]
> Â Â 2 host/[email protected]
>
> The service principal host/sssd.dns.podman is configured to require the
> "strong" authentication indicator value.
>
> $ kadmin getstrs host/sssd.dns.podman
> require_auth: strong
>
>
> When ssh to the sssd host with *alice* account, authentication using otp is
> working fine
>
> [root@client /]# ssh alice@sssd
> alice@sssd's password: <otp value>
> Last login: Sat Dec 19 19:06:36 2020 from client.dns.podman
> [alice@sssd ~]
>
>
> However, if I ssh to the sssd host with *bob* account, I can login with
> bob's password even if the service principal host/sssd.dns.podman is
> configured to require the "strong" authentication indicator value
>
> [root@client /]# ssh bob@sssd
> bob@sssd's password: <bob's password>
> Last login: Mon Dec 21 19:05:03 2020 from client.dns.podman
> [bob@sssd ~]$
>
>
> 1. Why password authentication for bob principal succeeded while
> authentication indicator is "strong" ?
> 2. Is it possible to configure sssd to enforce "otp" authentication ?
Hi,
I think it should work as you expect it if you add
krb5_validate = True
to the [domain/...] section of sssd.conf.
This option is needed because with the default Kerberos authentication
only user related operations are preformed. If FAST is left aside it is
only asking the KDC for a TGT for the user, the KDC at this point cannot
know for which service you would like to use it.
With 'krb5_validate = True' after getting the TGT for the user SSSD will
try to validate it by requesting a service ticket for the principal from
the keytab. At this point the KDC can check the requirements configured
for the host and reject a TGT which does not has the needed
authentication indicators. If the KDC rejects the request the ticket
validation and hence the authentication will fail.
HTH
bye,
Sumit
>
> _______________________________________________
> sssd-users mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
> 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.fedorahosted.org/archives/list/[email protected]
_______________________________________________
sssd-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
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.fedorahosted.org/archives/list/[email protected]
