[389-users] Re: 389-DS Failed to get the default state of cipher
> > we have another host with same version and suppose same cfg but never saw the > error, > > [24/Jun/2020:09:22:54.687024072 -0700] - ERR - Security Initialization - > _conf_setallciphers - Failed to get the default state of cipher (null) I'm curious - how did you make a host with the same config? Normally with 389 you need to configure both individually to look the same but you can't copy-paste config files etc. My guess here is that perhaps your nss db isn't configured properly, so I'd want to see the output of certutil -L -d /etc/dirsrv/slapd-/ on the affected host. — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs ___ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org 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.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
[389-users] Re: DNA Plugin NextValue automatically added every time for same uid
> On 24 Jun 2020, at 16:43, DaV wrote: > > Yes, it is. > So I have to change the UidNumber to 5007 on AD side manually after the first > winsync. > emm, not convenient. > Yep ... I think DNA was designed with different use cases in mind :( Your best bet may to be avoiding DNA completely, and using AD/an external source to allocate uidNumbers that flow to 389 instead. :( > Sincerely, > -- > DaV > > On Wed, Jun 24, 2020, at 09:56, William Brown wrote: >> >> >>> On 23 Jun 2020, at 17:08, DaV wrote: >>> >>> Hi, >>> I find the DNA Plugin NextValue attribute will automatically added every >>> time for same uid. >>> >>> version: 389-ds-base-1.3.8.4-15.el7.x86_64 >>> >>> This is the server side configuration: dn: cn=uidNumber,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config objectClass: top objectClass: extensibleObject cn: uidNumber dnaType: uidNumber dnaMagicRegen: 9 dnaFilter: (objectclass=posixAccount) dnaScope: dc=example,dc=com dnaNextValue: 5007 dnaMaxValue: dnaThreshold: 200 creatorsName: cn=directory manager modifiersName: cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config createTimestamp: 20190822054416Z modifyTimestamp: 2020061904Z >>> >>> User attribute source is Windows AD, I have nsDSWindowsReplicationAgreement >>> which sync posix attribute from AD to 389ds. >>> When I fill magic number 9 on AD side, user will get a UidNumber >>> through DNA plugin. For example, an user get a uidNumber 5007 for the first >>> sync, when I update user entry attribute(add telephone), this user will get >>> a new uidNumber 5008 for the second sync. >>> I don't know whether this is normal. >> >> >> So every time you winsync, it says "oh, ad has uidnumber 9, 389 is >> 5007" and it will change it to 9. When the dna plugin run it then >> sees "well it's , better generate a new id" >> >> The conflict is occuring here because you sync in the 9 attr from >> ad. You probably should remove that, and it will prevent the issue. >> >> How to make this work with DNA though, is another question ... >> >> >>> >>> Sincerely, >>> -- >>> DaV >>> >>> >>> >>> ___ >>> 389-users mailing list -- 389-users@lists.fedoraproject.org >>> To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org >>> 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.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org >> >> — >> Sincerely, >> >> William Brown >> >> Senior Software Engineer, 389 Directory Server >> SUSE Labs >> ___ >> 389-users mailing list -- 389-users@lists.fedoraproject.org >> To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org >> 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.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org >> > ___ > 389-users mailing list -- 389-users@lists.fedoraproject.org > To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org > 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.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs ___ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org 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.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
[389-users] Re: 389 + sssd: Give user information about 389 server password policy
I wonder if there is some sssd configuration issue going on? Honestly I'm not very experienced with this part of the code base and these interactions ... > On 23 Jun 2020, at 18:19, Nicolas Martin wrote: > > I have installed 389 server on its own; I'm not using FreeIPA. > > On Mon, Jun 22, 2020 at 4:26 PM William Brown wrote: > > > > On 19 Jun 2020, at 23:15, Mark Reynolds wrote: > > > > Directory Server has its own internal password policy that it manages > > itself. It does not communicate with other services. 389's password > > policy does say why it rejects passwords. But in IPA deployments IPA also > > has its own unique password policy plugin, and it does NOT use 389's > > password policy. > > > >> > > To follow up what Mark said, can you confirm if this is 389 ds on it's own, > or a FreeIPA installation? > > — > Sincerely, > > William Brown > > Senior Software Engineer, 389 Directory Server > SUSE Labs > — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs ___ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org 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.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
[389-users] Re: 389-DS Failed to get the default state of cipher
I will let others confirm, but the message "_conf_setallciphers - Failed to get the default state of cipher" may not be an actual error, but more a warning that could be ignored, as the the default ciphers are configured later, per the log entries provided. Could you add the nss package version, as well as the details from the entry rpm -q nss nspr ldapsearch -LLLxD 'cn=directory manager' -W -b cn=encryption,cn=config -s base sslVersionMin sslVersionMax allowWeakCipher nsSSL3Ciphers nsSSLSupportedCiphers nsSSLEnabledCiphers ? Thanks, M. On Wed, Jun 24, 2020 at 9:57 AM Ghiurea, Isabella < isabella.ghiu...@nrc-cnrc.gc.ca> wrote: > Our new DS env is running: > > 389-ds-base-libs-1.3.9.1-10.el7.x86_64 > > 389-ds-base-1.3.9.1-10.el7.x86_64 > > After DS was upgrade to above version seeing this error when restarting > the DS, we have another host with same version and suppose same cfg but > never saw the error, please advise a fix for this issue in this version: > > Thank you > > ERR - Security Initialization - _conf_setallciphers - Failed to get the > default state of cipher (null) > > [24/Jun/2020:09:22:54.686777541 -0700] - ERR - Security Initialization - > _conf_setallciphers - Failed to get the default state of cipher (null) > > [24/Jun/2020:09:22:54.687024072 -0700] - ERR - Security Initialization - > _conf_setallciphers - Failed to get the default state of cipher (null) > > [ > > [24/Jun/2020:09:22:54.688953359 -0700] - INFO - Security Initialization - > SSL info: Enabling default cipher set. > > [24/Jun/2020:09:22:54.689229153 -0700] - INFO - Security Initialization - > SSL info: Configured NSS Ciphers > ___ > 389-users mailing list -- 389-users@lists.fedoraproject.org > To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org > 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.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org > ___ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org 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.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
[389-users] 389-DS Failed to get the default state of cipher
Our new DS env is running: 389-ds-base-libs-1.3.9.1-10.el7.x86_64 389-ds-base-1.3.9.1-10.el7.x86_64 After DS was upgrade to above version seeing this error when restarting the DS, we have another host with same version and suppose same cfg but never saw the error, please advise a fix for this issue in this version: Thank you ERR - Security Initialization - _conf_setallciphers - Failed to get the default state of cipher (null) [24/Jun/2020:09:22:54.686777541 -0700] - ERR - Security Initialization - _conf_setallciphers - Failed to get the default state of cipher (null) [24/Jun/2020:09:22:54.687024072 -0700] - ERR - Security Initialization - _conf_setallciphers - Failed to get the default state of cipher (null) [ [24/Jun/2020:09:22:54.688953359 -0700] - INFO - Security Initialization - SSL info: Enabling default cipher set. [24/Jun/2020:09:22:54.689229153 -0700] - INFO - Security Initialization - SSL info: Configured NSS Ciphers ___ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org 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.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
[389-users] Re: DNA Plugin NextValue automatically added every time for same uid
Yes, it is. So I have to change the UidNumber to 5007 on AD side manually after the first winsync. emm, not convenient. Sincerely, -- DaV On Wed, Jun 24, 2020, at 09:56, William Brown wrote: > > > > On 23 Jun 2020, at 17:08, DaV wrote: > > > > Hi, > > I find the DNA Plugin NextValue attribute will automatically added every > > time for same uid. > > > > version: 389-ds-base-1.3.8.4-15.el7.x86_64 > > > > This is the server side configuration: > >> dn: cn=uidNumber,cn=Distributed Numeric Assignment > >> Plugin,cn=plugins,cn=config > >> objectClass: top > >> objectClass: extensibleObject > >> cn: uidNumber > >> dnaType: uidNumber > >> dnaMagicRegen: 9 > >> dnaFilter: (objectclass=posixAccount) > >> dnaScope: dc=example,dc=com > >> dnaNextValue: 5007 > >> dnaMaxValue: > >> dnaThreshold: 200 > >> creatorsName: cn=directory manager > >> modifiersName: cn=Distributed Numeric Assignment > >> Plugin,cn=plugins,cn=config > >> createTimestamp: 20190822054416Z > >> modifyTimestamp: 2020061904Z > > > > User attribute source is Windows AD, I have nsDSWindowsReplicationAgreement > > which sync posix attribute from AD to 389ds. > > When I fill magic number 9 on AD side, user will get a UidNumber > > through DNA plugin. For example, an user get a uidNumber 5007 for the first > > sync, when I update user entry attribute(add telephone), this user will get > > a new uidNumber 5008 for the second sync. > > I don't know whether this is normal. > > > So every time you winsync, it says "oh, ad has uidnumber 9, 389 is > 5007" and it will change it to 9. When the dna plugin run it then > sees "well it's , better generate a new id" > > The conflict is occuring here because you sync in the 9 attr from > ad. You probably should remove that, and it will prevent the issue. > > How to make this work with DNA though, is another question ... > > > > > > Sincerely, > > -- > > DaV > > > > > > > > ___ > > 389-users mailing list -- 389-users@lists.fedoraproject.org > > To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org > > 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.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org > > — > Sincerely, > > William Brown > > Senior Software Engineer, 389 Directory Server > SUSE Labs > ___ > 389-users mailing list -- 389-users@lists.fedoraproject.org > To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org > 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.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org > ___ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org 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.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
