On Wed, Mar 04, 2020 at 07:29:14AM -0000, Hristina Marosevic wrote:
> Hello,
>
> I forgot to mention the LDAP implementation I am using - it is OUD (Oracle
> Unified Directory). Object class "strongAuthenticationUser" was added to the
> users for PKI based authentication. The mandatory attribute od this object
> class is "userCertificate" or "userCertificate;binary" in which I would store
> the value of the public key or the certificate.
> Case 1. I stored the certificate in the userCertificate;binary LDAP attribute
> as this was the default configuration
> Case 2. I also tried to store the certificate as a value of the LDAP
> attribute userCertificate and changed "ldap_user_certificate" to
> "userCertificate" in SSSD configuration (commented in the SSSD configuration
> bellow)
> Both of the cases resulted in password based authentication, instead of PKI
> based authentication.
> Also in the log I saw that SSSD mapped userCertificate(;binary) value to
> userCertificate parameter of the entry but I didn't see a derived public key
> in the logs.
> I am using x509 base64 encoded value od the certificate (also I tried with
> pkcs#7 but the result was the same)
>
> # SSSD configuration at this moment: I am using only public key stored as a
> value of the attribute "userCertificate" for authentication of the user which
> works fine - but this way, there is no certificate shown to SSSD client,
> hence - no certificate validation/verification mechanisms can be used
> (correct me if I am wrong)
> [sssd]
> config_file_version = 2
> domains = LDAP
> services = nss, pam, autofs, ssh
> reconnection_retries = 3
>
> [nss]
> reconnection_retries = 3
> debug_level = 2
> filter_users = root, oracle
> filter_groups = root
>
> [pam]
> reconnection_retries = 3
> debug_level = 2
>
> [domain/LDAP]
> id_provider = ldap
> access_provider = ldap
> chpass_provider = ldap
> ldap_schema = rfc2307
> ldap_uri = ldaps://<OUD_instance>:<LDAPs_port>
> ldap_default_bind_dn = <directory_manager>
> ldap_default_authtok = <password>
> ldap_default_authtok_type = password
> ldap_search_base = <suffix>
> ldap_user_search_base = <users_branch,suffix>
> ldap_group_search_base = <groups_branch,suffix>
> ldap_access_filter = isMemberOf=<access_filter_group>
> cache_credentials = true
> enumerate = false
> debug_level = 9
> ldap_id_use_start_tls = false
> ldap_tls_reqcert = demand
> ldap_tls_cacert = /etc/sssd/cacerts/<CA_cert.pem>
> ldap_tls_cacertdir = /etc/sssd/cacerts
> ldap_user_name = employeeNumber
> ldap_user_ssh_public_key = userCertificate
> #ldap_user_certificate = userCertificate
>
> # LDAP entry at this moment (only with public key value stored in
> "userCertificate" attribute)
> dn: uid=32000000001,<users_branch,suffix>
> givenName: testUser7
> objectClass: strongAuthenticationUser
> objectClass: person
> objectClass: inetOrgPerson
> objectClass: organizationalPerson
> objectClass: posixAccount
> objectClass: top
> uid: 32000000001
> cn: 32000000001
> sn: test
> loginShell: /bin/bash
> userPassword:
> {SSHA512}0QAWd8NQNpN5bVS/sS0CDjHzctpy54X/JflWRSzIk/zpgSEgm5IE003RX
> v35iEyt2LfqaXd5HGAwYrCaRbM7ylrg0syFXrLU
> homeDirectory: /ssh_users/32000000001
> ou: <directoy_manager>
> uidNumber: 1234567890
> userCertificate: ssh-rsa
> AAAAB3NzaC1yc2EAAAADAQABAAABAQCPZF7auTI3Tj/urnpX7YbG3jh
>
> Qq4z0HcqW8JA4CKGrNOeBSbyh4H1/WqVR72zKzSu/2rRTG3679YMWy6hZBz7Of7tnQ6OBlmZmAxyFkk
>
> UU1ZVRKFRyVWBzmT8YqOjetdaYEr4f9cjOV22EStPJCheZmyyMRMOtlTA32dQ7rWBLcjpkLFQZhInbn
>
> H5JUEEuiVTKXZ5xDRzpLCVNx/VFyLxHgPjfv0mWOGp3tVCBRYnmW/82pOcvYGQtSJbsL9LyIsuJWVNz
>
> JWQa2v4grNf3OCuWO6wIiPaJcnYNtvRtNHCtexPicJ7iaCmgjxgWsUKCyaVIFNn+STgR81zl59lrmfD
> D
> gidNumber: 9999
> employeeNumber: <employee_number>
Hi,
with 'ldap_user_ssh_public_key = userCertificate' this should work, i.e.
calling 'sss_ssh_authorizedkeys testUser7' should return the ssh key
from above. If there is no output I need the SSSD ssh and domain logs to
understand why this fails.
>
>
> When using certificate only or certificate and public key stored in the LDAP
> entry, the value of the certificate stored in the userCertificate;binary
> attribute is:
> MIIGMTCCBBmgAwIBAgIUfYWZ212wMteK0jjnnXd6dqlqkIkwDQYJKoZIhvcNAQELBQAwLTELMAkGA1UEBhMCS1oxHjAcBgNVBAMMFdKw0JrQniAzLjAgKFJTQSBURVNUKTAeFw0xOTA0MDQwODU0NTRaFw0yMTA0MDMwODU0NTRaMIGvMSIwIAYDVQQDDBnQotCV0KHQotCi0J7QkiDQotCV0KHQotCiMRcwFQYDVQQEDA7QotCV0KHQotCi0J7QkjEYMBYGA1UEBRMPSUlOMTIzNDU2Nzg5MDEyMQswCQYDVQQGEwJLWjEVMBMGA1UEBwwM0JDQodCi0JDQndCQMRUwEwYDVQQIDAzQkNCh0KLQkNCd0JAxGzAZBgNVBCoMEtCi0JXQodCi0KLQntCS0JjQpzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAI9kXtq5MjdOP+6uelfthsbeOFCrjPQdypbwkDgIoas054FJvKHgfX9apVHvbMrNK7/atFMbfrv1gxbLqFkHPs5/u2dDo4GWZmYDHIWSRRTVlVEoVHJVYHOZPxio6N611pgSvh/1yM5XbYRK08kKF5mbLIxEw62VMDfZ1DutYEtyOmQsVBmEiducfklQQS6JVMpdnnENHOksJU3H9UXIvEeA+N+/SZY4ane1UIFFieZb/zak5y9gZC1Iluwv0vIiy4lZU3MlZBra/iCs1/c4K5Y7rAiI9olydg229G00cK17E+JwnuJoKaCPGBaxQoLJpUgU2f5JOBHzXOXn2WuZ8MMCAwEAAaOCAcQwggHAMA4GA1UdDwEB/wQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKoMOAwMEAQEwHwYDVR0jBBgwFoAUpowWM3y46DVnBj5eQVdVoq80UGgwHQYDVR0OBBYEFLoJ735qnU1Q4y8AEtPdJI2lqQVfMF4GA1UdIARXMFUwUwYHKoMOAwMCBDBIMCEGCC
>
> sGAQUFBwIBFhVodHRwOi8vcGtpLmdvdi5rei9jcHMwIwYIKwYBBQUHAgIwFwwVaHR0cDovL3BraS5nb3Yua3ovY3BzMDwGA1UdHwQ1MDMwMaAvoC2GK2h0dHA6Ly90ZXN0LnBraS5nb3Yua3ovY3JsL25jYV9yc2FfdGVzdC5jcmwwPgYDVR0uBDcwNTAzoDGgL4YtaHR0cDovL3Rlc3QucGtpLmdvdi5rei9jcmwvbmNhX2RfcnNhX3Rlc3QuY3JsMHEGCCsGAQUFBwEBBGUwYzA4BggrBgEFBQcwAoYsaHR0cDovL3Rlc3QucGtpLmdvdi5rei9jZXJ0L25jYV9yc2FfdGVzdC5jZXIwJwYIKwYBBQUHMAGGG2h0dHA6Ly90ZXN0LnBraS5nb3Yua3ovb2NzcDANBgkqhkiG9w0BAQsFAAOCAgEACnYpytjbyuV3sRojnlyxEC7HG7BgcDDy6rS/kfOtK6X5+MGCT/zvwksZOumN5Jg5TPdJuKt3ebKJGIBVr474mHFk7Nq0F8WxuAWNffjoL0Lvcuon4Zwq/W8h4t6PYutD4NEauIPEa8X8BGPgMn+YqOc3sfEruXh8rmcSJ/zuT7uw1wD6ZQlNsniioengKIgapDVDHuzoV/r//rEANwIpntAyjXFh+fjx+CDCx2sLxYjlVgyxNzT53mD6ZqsMlg6NrajJe/GvS0A38jKNyxW/DPX06NToWP/hu7M4P2/WiskjKVgOxqQcc4yzTfKV41DmEmGGC7sT1r3YeZ4dH/KQRpjowBOSKmUZq4/XR0yXXhpTDtiiRwXkQgM1p4SKE19bBqGuc76lDgmffPPPj4B+3HZqaprIIDG3YA3/W4rwUoWBQPGGCXpOBvGEQptEHItx4YiEZTQuvdCtlW585kUyol39sKv2uIo/FgycBd8NufOInGCLUgpZec4zVLZN9Shj+M20BMUh+SiGoL/kJAi2XdM922U3po9a2FbULvJfOlsFY2Z
>
> 6n+TUZZVXBCUIEE6Ek4tTIGjHWj7uQVGLjw0PcHf11CtrMZO7Y+OTBb/Y0oyUY9JOyzSqhj4rt4nNkzR1vMGVYMNISoXbDgYBaAKuv2oSpG6yQdlufS8M/YWxAWw=
Are the line break added by you or is this the real output? For
certificates you have to user 'userCertificate;binary' and store the
certificates as binaries in LDAP. When you use the ldapsearch command
the output should be:
userCertificate;binary:: MIIGMTCC....
Please note the '::' which indicates that the attribute value is a
binary and that it is encoded in base64 to be able to print the output.
bye,
Sumit
>
>
> Thank you!
> BR,
> Hristina
> _______________________________________________
> 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]
