![]() ![]() If the rogue KDC picks the attempt up and replies, it will fail the host verification. Once these steps are complete, you can restart sssd on the workstation and perform the login. You can also do it on the KDC itself using kadmin.local, but you will have to store the keytab temporarily in another file and securely copy it over to the workstation. ![]() Then exit the tool and make sure the permissions on the keytab file are tight: sudo chmod 0600 /etc/krb5.keytab Kadmin: ktadd -k /etc/krb5.keytab host/Įntry for principal host/ with kvno 6, encryption type aes256-cts-hmac-sha1-96 added to keytab WRFILE:/etc/krb5.keytab.Įntry for principal host/ with kvno 6, encryption type aes128-cts-hmac-sha1-96 added to keytab WRFILE:/etc/krb5.keytab. Kadmin: addprinc -randkey no policy specified for defaulting to no policy This two step process can be easily done on the workstation itself via kadmin (not kadmin.local) to contact the KDC remotely: $ sudo kadmin -p ubuntu/admin It’s like a “machine account”, with a shared secret that the attacker cannot control and replicate in his rogue KDC…The host principal has the format the host principal is created, its keytab needs to be stored on the workstation. This is how the KDC’s authenticity is verified. The second step is to create a host principal on the KDC for this workstation. To enable it, edit /etc/sssd/nf and add this line to the domain section: This option is called krb5_validate, and it’s false by default. It will have SSSD authenticate the KDC, and block the login if the KDC cannot be verified. There is a configuration parameter that can be set to protect the workstation from this attack. If the workstation isn’t authenticating the KDC, it will accept the reply from the rogue server and let john in. What he has to do now is to have his rogue KDC respond to the login request from the workstation, before (or instead of) the real KDC. The attacker first deploys a rogue KDC server in the network, and creates the john principal there with a password of his choosing. Let’s say he knows john is a valid user on that machine. The objective of the attacker is to login on a workstation that is using Kerberos authentication. When using SSSD to manage kerberos logins on a Linux host, there is an attack scenario you should be aware of: KDC spoofing. Ticket cache: FILE:/tmp/krb5cc_10001_BOrxWrĠ4/17/20 20:29:50 04/18/20 06:29:50 until 04/18/20 logged in using the kerberos password, and user/group information from the LDAP server. Let’s try a login as this user: sudo login The user john should be known to the system: getent passwd john Note how the john user has no userPassword attribute. In this example, the LDAP server has the following user and group entry we are going to use for testing: dn: uid=john,ou=People,dc=example,dc=comĭn: cn=Engineering,ou=Group,dc=example,dc=com To enable automatic home directory creation, run the following command: sudo pam-auth-update -enable mkhomedir Start the sssd service: sudo systemctl start rvice This example uses two KDCs, which made it necessary to also specify the krb5_kpasswd server because the second KDC is a replica and is not running the admin server. SSSD ConfigurationĬreate the /etc/sssd/nf configuration file, with permissions 0600 and ownership root:root, and this content: For this guide, we are using EXAMPLE.COM.Īt this point, you should alreaedy be able to obtain tickets from your Kerberos server, assuming DNS records point at it like explained elsewhere in this guide: $ kinit ubuntuĭefault principal: starting Expires Service principalĠ4/17/20 19:51:06 04/18/20 05:51:06 until 04/18/20 19:51:05īut we want to be able to login as an LDAP user, authenticated via Kerberos. You may be asked about the default Kerberos realm. On the client host, install the following packages: sudo apt install sssd-ldap sssd-krb5 ldap-utils krb5-user a client host where we will install and configure SSSD.It doesn’t have to be using the OpenLDAP backend SSL support is recommended, but not strictly necessary because authentication in this setup is being done via Kerberos, and not LDAP. an existing OpenLDAP server using the RFC2307 schema for users and groups.Prerequisites, Assumptions, and Requirements Finally, we can mix it all together in a setup that is very similar to Active Directory in terms of the technologies used: use LDAP for users and groups, and Kerberos for authentication. ![]()
0 Comments
Leave a Reply. |