Yes, it does.
Currently i am porting this bug https://bugzilla.redhat.com/show_bug.cgi?id=170520
I think with help of this script it will be impossible to port it .
Do you have any advice .
Regards
Anuj Borah
On Fri, Jun 7, 2019 at 2:47 PM William Brown <wbrown@xxxxxxx> wrote:
I haven't read the link but maybe there is some confusion about TLS binding here. You do the create_rsa_user and that only set's up the certificates.
> On 4 Jun 2019, at 17:51, Anuj Borah <aborah@xxxxxxxxxx> wrote:
>
> @William Brown
>
> Thanks , I am doing the same . Trying to follow it . (i have make this script 99% pass)
>
> But its way too old . It uses some like :
>
> standalone.nss_ssl.create_rsa_user('testuser') ---- not valid (NssSsl(standalone).create_rsa_user('testuser'))
>
> standalone.nss_ssl.get_rsa_user('testuser') ------ not valid (NssSsl(standalone).get_rsa_user('testuser'))
IIRC this syntax is valid, but maybe the linking type was removed.
>
> standalone.openConnection --- I dont know what is it . May be bind.
Yes, i think this is bind now. If you grep for create_rsa_user in the tests you may find another example.
>
> And Most importantly, after i have make this script 99% pass . I am not able to see the usercertificate field in the test user that was created during the test . while i do _unsafe_raw_entry()
Because you don't need it. The certificate's cn is mapped to the cn in the directory, and then because the certificate was issued be the ca, it "confirms" the users identity. No userCertificate attribute required.
There is a configuration that DOES require the certificate to not only be signed, but also in userCertificate for binary matching, but this is a configuration option, not the default. I seem to recall helping document all this with Marc, so it should be in the latest RHDS documentation. Generally though, the userCertificate attribute today would be used to allow a client like SSSD to read the userCertificate to allow smartCard authentication to a workstation.
Does that help a bit?
>
> Also mind changing the lib389 doc https://spichugi.fedorapeople.org/html/guidelines.html#setting-up-ssl-tls . Its the same test case given there , which is not relevant now .
>
> Regards
> Anuj Borah
>
>
>
>
>
>
>
> On Tue, Jun 4, 2019 at 9:08 PM William Brown <wbrown@xxxxxxx> wrote:
> I'm currently traveling at the moment, but I can have a look later to update this to work on latest lib389 etc.
>
> You can read it and use it as an example though, even if it doesn't pass ...
>
>
>
>
> > On 4 Jun 2019, at 16:32, Anuj Borah <aborah@xxxxxxxxxx> wrote:
> >
> > @William Brown
> >
> > This test script does not pass . Its too old .
> >
> > Regards
> > Anuj Borah
> >
> > On Tue, Jun 4, 2019 at 8:00 PM William Brown <wbrown@xxxxxxx> wrote:
> > Have a look at this test case if you want to do usercertificate generation and authentication :)
> >
> > https://pagure.io/389-ds-base/blob/master/f/src/lib389/lib389/tests/tls_external_test.py
> >
> > > On 4 Jun 2019, at 14:31, Anuj Borah <aborah@xxxxxxxxxx> wrote:
> > >
> > > Hi all,
> > >
> > > Let say i want to create a user with userCertificate fileld. My user will look like bellow.
> > >
> > > users_people = UserAccounts(topo.standalone, DEFAULT_SUFFIX)
> > > users_people.create(properties={
> > > 'uid': 'certUser2',
> > > 'cn': 'CUser2',
> > > 'sn': 'CertificateUser2',
> > > 'givenName': 'CU2',
> > > 'description': "This is certUser2's description",
> > > 'mail': 'certUser1@xxxxxxxxxxx',
> > > 'userPassword': PW_DM,
> > > 'userCertificate': 'some_cert_+++NUhz+Rigq7xT5g0Jqo1gXq1jJFdCw==',
> > > 'manager': f'uid=certUser2,ou=People,{DEFAULT_SUFFIX}',
> > > 'homeDirectory': '/home/' + 'certUser2',
> > > 'uidNumber': '1000',
> > > 'gidNumber': '2000'
> > > })
> > >
> > > Here i have put userCertificate field manually (which i dont want to do). But how can i achieve this without putting userCertificate field manually . Like create a user and userCertificate field will be auto field with auto generated certificates .
> > >
> > > Regards
> > > Anuj Borah
> > > _______________________________________________
> > > 389-devel mailing list -- 389-devel@xxxxxxxxxxxxxxxxxxxxxxx
> > > To unsubscribe send an email to 389-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
> > > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > > List Archives: https://lists.fedoraproject.org/archives/list/389-devel@xxxxxxxxxxxxxxxxxxxxxxx
> >
> > —
> > Sincerely,
> >
> > William Brown
> >
> > Senior Software Engineer, 389 Directory Server
> > SUSE Labs
> > _______________________________________________
> > 389-devel mailing list -- 389-devel@xxxxxxxxxxxxxxxxxxxxxxx
> > To unsubscribe send an email to 389-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
> > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives: https://lists.fedoraproject.org/archives/list/389-devel@xxxxxxxxxxxxxxxxxxxxxxx
>
> —
> Sincerely,
>
> William Brown
>
> Senior Software Engineer, 389 Directory Server
> SUSE Labs
>
—
Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server
SUSE Labs
_______________________________________________ 389-devel mailing list -- 389-devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to 389-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-devel@xxxxxxxxxxxxxxxxxxxxxxx
