> On 29 Feb 2020, at 05:45, Mark Reynolds <mreyno...@redhat.com> wrote:
>
>
> On 2/28/20 1:15 PM, Alberto Viana wrote:
>> Mark,
>>
>> Yes, it solves the problem!!!!!!!!. Can you explain what exactly that config
>> does? It's suppose to be on?
>> Found some old CVE about it and just want to be sure about what I'm doing.
> Well we used to keep this set to "on" but changed the default to "off",
> because when it's "on" it writes the clear text password in the replication
> changelog and retro changelog (if enabled). It was considered a security
> risk to do this by default. The problem here was that it is not documented
> anywhere that you need to turn it back "on" for winsync to send DS passwords
> to AD.
>
> We missed this, and I will make sure it gets documented right away in the
> Admin guide.
You're a wizard Mark.
>
> Regards,
>
> Mark
>
>>
>> Thanks
>>
>> Alberto Viana
>>
>>
>> On Fri, Feb 28, 2020 at 12:39 PM Mark Reynolds <mreyno...@redhat.com> wrote:
>> Alberto,
>>
>> We might know what's going on. Can you sent nsslapd-unhashed-pw-switch to
>> "on" in cn=config and see if it solves the problem?
>>
>> Thanks,
>>
>> Mark
>>
>> On 2/19/20 8:01 AM, Alberto Viana wrote:
>>> WIlliam,
>>>
>>> Would be helpful if I provide to you guys a test environment? It's not hard
>>> for me to do that.
>>>
>>> I'm really interesting in find out what is going on and some other projects
>>> over here are depending on my 389 upgrade.
>>>
>>> Thanks
>>>
>>> Alberto Viana
>>>
>>> On Mon, Feb 17, 2020 at 7:21 PM William Brown <wbr...@suse.de> wrote:
>>> Mark, any ideas what to look at next :S
>>>
>>> Besides actually trying to setup and reproduce it which I think would be
>>> the next step ....
>>>
>>> > On 18 Feb 2020, at 05:45, Alberto Viana <alberto...@gmail.com> wrote:
>>> >
>>> > Hi Guys,
>>> >
>>> > Setup another environment 389 1.4.1.14 + windows 2016, still not working,
>>> > exactly the same behavior.
>>> >
>>> > :/
>>> >
>>> > Cheers,
>>> >
>>> > Alberto Viana
>>> >
>>> > On Wed, Jan 29, 2020 at 8:19 PM Alberto Viana <alberto...@gmail.com>
>>> > wrote:
>>> > William,
>>> >
>>> > Yes, *other* attributes are replicated to AD normally (in all versions
>>> > that I tested).
>>> >
>>> > Thanks.
>>> >
>>> >
>>> >
>>> >
>>> > On Wed, Jan 29, 2020 at 8:16 PM William Brown <wbr...@suse.de> wrote:
>>> >
>>> >
>>> > > On 30 Jan 2020, at 08:04, Alberto Viana <alberto...@gmail.com> wrote:
>>> > >
>>> > > Mark
>>> > >
>>> > > Again (my bad on copy and paste):
>>> > >
>>> > > dn: cn=AD-DF-DC01,cn=replica,cn=dc\3Dmy\2Cdc\3Ddomain,cn=mapping
>>> > > tree,cn=config
>>> > > objectClass: top
>>> > > objectClass: nsDSWindowsReplicationAgreement
>>> > > cn: AD-DF-DC01
>>> > > nsDS5ReplicaRoot: dc=my,dc=domain
>>> > > description: AD-DF-DC01
>>> > > nsDS5ReplicaHost: gti-df-dc01.domain.local
>>> > > nsDS5ReplicaPort: 636
>>> > > nsDS5ReplicaTransportInfo: LDAPS
>>> > > nsDS5ReplicaBindDN: CN=Conta de sincronizacao do AD com LDAP
>>> > > 389,OU=APLICACOES,dc=my,dc=domain
>>> > > nsds7WindowsReplicaSubtree: dc=my,dc=domain
>>> > > nsds7DirectoryReplicaSubtree: dc=my,dc=domain
>>> > > nsds7WindowsDomain: RNP
>>> > > nsds7NewWinUserSyncEnabled: on
>>> > > nsds7NewWinGroupSyncEnabled: on
>>> > > nsDS5ReplicaCredentials:
>>> > > {AES-RERBNEJDUTBPV1psTXpoak15MDNPRFZrTXpZMg0KTnkxaE56VXhZMkUwWlMxbE5UazJNemhrWkFBQ
>>> > >
>>> > > RERBNEJDUTBPV1psTXpoak15MDNPRFZrTXpZMg0KTnkxaE56VXhZMkUwWlMxbE5UazJNemhrWkFBQ
>>> > >
>>> > > 0FRSUNBU0F3Q2dZSUtvWklodmNOQWdjd0hRWUpZSVpJQVdVRA0KQkFFcUJCQTJRME5QSmRXNWVLQW
>>> > > NFaXczVmFXWQ==}F/Jp/zDrXdzGs4/tMIPZZw==
>>> > > internalCreatorsName: cn=directory manager
>>> > > internalModifiersName: cn=directory manager
>>> > > creatorsName: cn=directory manager
>>> > > modifiersName: cn=directory manager
>>> > > createTimestamp: 20200129214430Z
>>> > > modifyTimestamp: 20200129214431Z
>>> > > nsds5BeginReplicaRefresh: start
>>> > >
>>> > >
>>> > > How are you changing the password in DS?
>>> > > Tried 3 different ways:
>>> > > 1. ldapmodify
>>> > > 2. password Selfservice (application that we have here)
>>> > > 3. Apache directory (LDAP client)
>>> >
>>> > I can't remember if I asked this, but do *other* non-password attributes
>>> > replicate correctly from 389 to AD?
>>> >
>>> > >
>>> > > Question, the The AD machine (gti-df-dc01.my.domain) is the Domain
>>> > > Controller, right?
>>> > > The entry looks off, but it might be because you did some find/replace
>>> > > on some text. See comments below...
>>> > >
>>> > > Yes, this is my domain controller(AD). I have 6 domain controllers
>>> > > (2012 R2) over here, tried at least in 4.
>>> > >
>>> > > Another info is that I reconfigured my old server(1.3.7.4) and
>>> > > everything works as expect.
>>> > >
>>> > > So far, I have no idea where the problem is, so I decided that tomorrow
>>> > > I will bring up again my old server, (and after that, rebuild my lab
>>> > > environment e try to figure it out).
>>> > >
>>> > > Right now, I'm testing with 3 different versions:
>>> > > 1.4.1.14
>>> > > 1.4.3.2
>>> > > 1.4.2.5 => This one with Fedora packages (not compiled by myself)
>>> > >
>>> > > None of them is working with same behavior, just the password is not
>>> > > sent from 389 to AD. In all versions, attributes are replicated(except
>>> > > password) from 389 to AD, and everything is working fine from AD to 389.
>>> > >
>>> > > Please let me know if need some more info.
>>> > >
>>> > > Thanks
>>> > >
>>> > > Alberto Viana
>>> > >
>>> > > On Wed, Jan 29, 2020 at 5:24 PM Mark Reynolds <mreyno...@redhat.com>
>>> > > wrote:
>>> > > How are you changing the password in DS?
>>> > >
>>> > > Question, the The AD machine (gti-df-dc01.my.domain) is the Domain
>>> > > Controller, right?
>>> > >
>>> > > The entry looks off, but it might be because you did some find/replace
>>> > > on some text. See comments below...
>>> > >
>>> > > On 1/29/20 1:26 PM, Alberto Viana wrote:
>>> > >> Mark,
>>> > >>
>>> > >> here's:
>>> > >>
>>> > >> dn: cn=AD-DF-DC01,cn=replica,cn=dc\3Drnp\2Cdc\3Dlocal,cn=mapping
>>> > >> tree,cn=config
>>> > >> objectClass: top
>>> > >> objectClass: nsDSowsReplicationAgreement
>>> > >> cn: AD-DF-DC01
>>> > >> nsDS5ReplicaRoot: dc=rnp,dc=local
>>> > >> description: AD-DF-DC01
>>> > >> nsDS5ReplicaHost: gti-df-dc01.my.domain
>>> > >> nsDS5ReplicaPort: 636
>>> > >> nsDS5ReplicaTransportInfo: LDAPS
>>> > >> nsDS5ReplicaBindDN: CN=my user on AD,OU=APLICACOES,DC=my,DC=domain
>>> > >> nsds7owsReplicaSubtree: dc=my,dc=domain
>>> > > This is the wrong attribute, it should be: nsds7WindowsReplicaSubtree
>>> > >> nsds7DirectoryReplicaSubtree: dc=my,dc=domain
>>> > >> nsds7owsDomain: RNP
>>> > > Same here, it should be: nsds7WindowsDomain.
>>> > >
>>> > > Mark
>>> > >
>>> > >> nsds7NewWinUserSyncEnabled: on
>>> > >> nsds7NewWinGroupSyncEnabled: on
>>> > >> nsDS5ReplicaCredentials: {AES-E56VXhZMkUwWlMxbE5UazJNemhrWkFBQ
>>> > >>
>>> > >> 0FRSUNBU0F3Q2dZSUtvWklodmNOQWdjd0hRWUpZSVpJQVdVRA0KQkFFcUJCRFl0ZGNTUGZoV2xEZE
>>> > >> 5rMUZNZWp4Rw==}UxxEid4L9eUthSplmxIoy4woEEB4YoihY1++Vv60ibM=
>>> > >> internalCreatorsName: cn=directory manager
>>> > >> internalModifiersName: cn=directory manager
>>> > >>
>>> > >> Thanks
>>> > >>
>>> > >> On Wed, Jan 29, 2020 at 2:27 PM Mark Reynolds <mreyno...@redhat.com>
>>> > >> wrote:
>>> > >>
>>> > >>
>>> > >> On 1/29/20 12:17 PM, Alberto Viana wrote:
>>> > >>> Mark,
>>> > >>>
>>> > >>> Already did that twice hehehehe
>>> > >>>
>>> > >>> Do you think that's about config once all attributes except password
>>> > >>> are sync'ed to AD? If it's about config, the log does not suppose to
>>> > >>> show something?
>>> > >>>
>>> > >>> 389 -> AD (all attributes except password)
>>> > >>> AD -> 389 (everthing works, including password)
>>> > >>>
>>> > >>> Tried almost everything over here, without success.
>>> > >>>
>>> > >>> There's another way to trace it? replication log does not shows me
>>> > >>> anything related to it.
>>> > >> Replication logging is the only option on the DS side.
>>> > >>
>>> > >> Can you share your replication agreement from dse.ldif? From what I
>>> > >> saw from the command line you set everything correctly, but maybe it
>>> > >> didn't write it correctly to the entry. You have to use LDAPS for
>>> > >> passwords to sync to AD, and you specified that, but lets confirm what
>>> > >> is actually in the agreement.
>>> > >>
>>> > >> Thanks,
>>> > >>
>>> > >> Mark
>>> > >>
>>> > >>>
>>> > >>> Thanks
>>> > >>>
>>> > >>> On Wed, Jan 29, 2020 at 12:35 PM Mark Reynolds <mreyno...@redhat.com>
>>> > >>> wrote:
>>> > >>> Alberto,
>>> > >>>
>>> > >>> Sorry I'm not sure what is wrong. Please review the documentation
>>> > >>> and make sure you have everything setup correctly:
>>> > >>>
>>> > >>> https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html/administration_guide/managing_the_password_policy-synchronizing_passwords
>>> > >>>
>>> > >>> HTH,
>>> > >>>
>>> > >>> Mark
>>> > >>>
>>> > >>> On 1/29/20 10:22 AM, Alberto Viana wrote:
>>> > >>>> Hi Guys,
>>> > >>>>
>>> > >>>> My messages to list are being moderated (no sure why), trying again
>>> > >>>>
>>> > >>>> William,
>>> > >>>>
>>> > >>>> Right, so if you change a password on AD, does it properly change
>>> > >>>> the password to 389?
>>> > >>>>
>>> > >>>> Yes.
>>> > >>>>
>>> > >>>> And are you using a "ldapmodify userpassword" or "ldappasswd" to
>>> > >>>> change the password? What's the exact command you run against 389 to
>>> > >>>> change the password?
>>> > >>>>
>>> > >>>> Tried 3 different ways:
>>> > >>>> 1. ldapmodify
>>> > >>>> 2. An application that we have here (password selfservice)
>>> > >>>> 3. Apache directory studio
>>> > >>>>
>>> > >>>> The password is always updated locally in 389 but never sent to AD.
>>> > >>>>
>>> > >>>> And it's seems that not even trying, I'm tracking on event viewer.
>>> > >>>> Another thing that when I used to change the password, the passync
>>> > >>>> always intercepts the change and tries to send back the (same)
>>> > >>>> password and it's not happening.
>>> > >>>>
>>> > >>>> Please let me know if you anything else.
>>> > >>>>
>>> > >>>>
>>> > >>>>
>>> > >>>> On Tue, Jan 28, 2020 at 9:40 PM Alberto Viana <alberto...@gmail.com>
>>> > >>>> wrote:
>>> > >>>> William,
>>> > >>>>
>>> > >>>> Right, so if you change a password on AD, does it properly change
>>> > >>>> the password to 389?
>>> > >>>>
>>> > >>>> Yes.
>>> > >>>>
>>> > >>>> And are you using a "ldapmodify userpassword" or "ldappasswd" to
>>> > >>>> change the password? What's the exact command you run against 389 to
>>> > >>>> change the password?
>>> > >>>>
>>> > >>>> Tried 3 different ways:
>>> > >>>> 1. ldapmodify
>>> > >>>> 2. An application that we have here (password selfservice)
>>> > >>>> 3. Apache directory studio
>>> > >>>>
>>> > >>>> The password is always updated locally in 389 but never sent to AD.
>>> > >>>>
>>> > >>>> And it's seems that not even trying, I'm tracking on event viewer.
>>> > >>>> Another thing that when I used to change the password, the passync
>>> > >>>> always intercepts the change and tries to send back the (same)
>>> > >>>> password and it's not happening.
>>> > >>>>
>>> > >>>> Please let me know if you anything else.
>>> > >>>>
>>> > >>>> Thanks
>>> > >>>>
>>> > >>>>
>>> > >>>>
>>> > >>>> On Tue, Jan 28, 2020 at 9:31 PM William Brown <wbr...@suse.de> wrote:
>>> > >>>>
>>> > >>>>
>>> > >>>> > On 29 Jan 2020, at 10:15, Alberto Viana <alberto...@gmail.com>
>>> > >>>> > wrote:
>>> > >>>> >
>>> > >>>> > William,
>>> > >>>> >
>>> > >>>> > Sorry, my bad, it's not working
>>> > >>>> >
>>> > >>>> >
>>> > >>>> > The problem is the password is never sent to AD and it's just
>>> > >>>> > about password, any other replicated attribute that I modify sends
>>> > >>>> > the modification to AD normally.
>>> > >>>>
>>> > >>>>
>>> > >>>> Right, so if you change a password on AD, does it properly change
>>> > >>>> the password to 389?
>>> > >>>>
>>> > >>>> And are you using a "ldapmodify userpassword" or "ldappasswd" to
>>> > >>>> change the password? What's the exact command you run against 389 to
>>> > >>>> change the password?
>>> > >>>>
>>> > >>>> >
>>> > >>>> > When you say "I think that perhaps we need to exclude
>>> > >>>> > objectClass=* from notes=U."
>>> > >>>>
>>> > >>>> No, this is something for the team and I to do, not you :)
>>> > >>>>
>>> > >>>> >
>>> > >>>> > Where should I do that? Do you need further information?
>>> > >>>> >
>>> > >>>> >
>>> > >>>> > Thanks
>>> > >>>> >
>>> > >>>> > Alberto Viana
>>> > >>>> >
>>> > >>>> >
>>> > >>>> > On Tue, Jan 28, 2020 at 9:09 PM William Brown <wbr...@suse.de>
>>> > >>>> > wrote:
>>> > >>>> >
>>> > >>>> >
>>> > >>>> > > On 29 Jan 2020, at 10:01, Alberto Viana <alberto...@gmail.com>
>>> > >>>> > > wrote:
>>> > >>>> > >
>>> > >>>> > > WIlliam,
>>> > >>>> > >
>>> > >>>> > > Thanks, I put in my company's roadmap to think about pay for
>>> > >>>> > > support,
>>> > >>>> >
>>> > >>>> > Great!
>>> > >>>> >
>>> > >>>> > > I found the problem, it's about aci (the user manager
>>> > >>>> > > replication permission)
>>> > >>>> >
>>> > >>>> > Can you please describe the problem and solution more? That way I
>>> > >>>> > and others can learn from what you just solved :) It will help
>>> > >>>> > many others. Thank you!
>>> > >>>> >
>>> > >>>> > >
>>> > >>>> > > After add permission to read the userpassword field, starts to
>>> > >>>> > > works.
>>> > >>>> > >
>>> > >>>> > > Again, Thanks!!!
>>> > >>>> > >
>>> > >>>> > >
>>> > >>>> > >
>>> > >>>> > > On Tue, Jan 28, 2020 at 8:58 PM William Brown <wbr...@suse.de>
>>> > >>>> > > wrote:
>>> > >>>> > >
>>> > >>>> > >
>>> > >>>> > > > On 29 Jan 2020, at 09:24, Alberto Viana <alberto...@gmail.com>
>>> > >>>> > > > wrote:
>>> > >>>> > > >
>>> > >>>> > > > Hey Guys,
>>> > >>>> > > >
>>> > >>>> > > > Really lost here, don't know what else look or test, it's not
>>> > >>>> > > > working at all :/
>>> > >>>> > >
>>> > >>>> > > Hey there,
>>> > >>>> > >
>>> > >>>> > > Remember, the team is distributed around the world - I'm
>>> > >>>> > > Australian for example, so sometimes mailing list questions can
>>> > >>>> > > take 24 hours. Sometimes personal things go wrong. It's just the
>>> > >>>> > > annoying nature, that we will potentially take time to respond
>>> > >>>> > > :(
>>> > >>>> > >
>>> > >>>> > > If you do want an SLA, and it's super important to have things
>>> > >>>> > > fixed, do consider convincing your business to take a SUSE (SLE)
>>> > >>>> > > or Red Hat (RHDS) contract, as there are support teams that can
>>> > >>>> > > assist, and there are going to be better response times rather
>>> > >>>> > > than just us developers :)
>>> > >>>> > >
>>> > >>>> > > >
>>> > >>>> > > > Any help is appreciated
>>> > >>>> > > >
>>> > >>>> > > > Thanks
>>> > >>>> > > >
>>> > >>>> > > > On Tue, Jan 28, 2020 at 3:48 PM Alberto Viana
>>> > >>>> > > > <alberto...@gmail.com> wrote:
>>> > >>>> > > > Hi Guys,
>>> > >>>> > > > 389-Directory/1.4.3.2
>>> > >>>> > > >
>>> > >>>> > > >
>>> > >>>> > > > The password sync from 389 to windows(2012) is not working:
>>> > >>>> > >
>>> > >>>> > > One of these days I really need to setup winsync at home to
>>> > >>>> > > really learn more about it ...
>>> > >>>> > >
>>> > >>>> > > >
>>> > >>>> > > > # dsconf RNP repl-winsync-agmt create --suffix=dc=rnp,dc=local
>>> > >>>> > > > --host=gti-df-dc01 --port=636 --conn-protocol=LDAPS
>>> > >>>> > > > --bind-dn="CN=my_win_account" --bind-passwd=password
>>> > >>>> > > > --win-subtree=dc=my,dc=domain --ds-subtree=dc=my,dc=domain
>>> > >>>> > > > --win-domain=RNP --sync-users=on --sync-groups=on --init
>>> > >>>> > > > AD-DF-DC01
>>> > >>>> > > >
>>> > >>>> > > >
>>> > >>>> > > > Double checked everything including the user permissions on
>>> > >>>> > > > windows AD side , also checked the windows log and passync
>>> > >>>> > > > log, could not found anything related (at least the 389 trying
>>> > >>>> > > > to update my user's password or any error)
>>> > >>>> > > >
>>> > >>>> > > > From windows to 389 works fine.
>>> > >>>> > > >
>>> > >>>> > > > Attaching the log (in replication debug mode)
>>> > >>>> > >
>>> > >>>> > > Looking at the log I can see changes happening.
>>> > >>>> > >
>>> > >>>> > >
>>> > >>>> > > This error seems surprising, but shouldn't really cause a
>>> > >>>> > > problem.
>>> > >>>> > >
>>> > >>>> > > [28/Jan/2020:15:14:05.423481115 -0300] - ERR - log_result -
>>> > >>>> > > Internal unindexed search: source (cn=Multimaster Replication
>>> > >>>> > > Plugin,cn=plugins,cn=config) search base="dc=my,dc=domain"
>>> > >>>> > > filter="(&(|(objectclass=*)(objectclass=ldapsubentry))(nsUniqueid=0c57800e-050011e8-b998ed08-97c36f4f))"
>>> > >>>> > > etime=0.000798288 nentries=1 notes=U details="Partially
>>> > >>>> > > Unindexed Filter
>>> > >>>> > >
>>> > >>>> > > I think that perhaps we need to exclude objectClass=* from
>>> > >>>> > > notes=U.
>>> > >>>> > >
>>> > >>>> > >
>>> > >>>> > > Anyway, you say it's "not working". I'm going to ask you to
>>> > >>>> > > describe what "not working means". Did you change a group on AD
>>> > >>>> > > and the changes aren't appearing in 389? Or the other way? Can
>>> > >>>> > > you be more specific about what's not working?
>>> > >>>> > >
>>> > >>>> > > Thanks,
>>> > >>>> > >
>>> > >>>> > > >
>>> > >>>> > > > Don't know what else to look
>>> > >>>> > > >
>>> > >>>> > > > Thanks.
>>> > >>>> > > >
>>> > >>>> > > >
>>> > >>>> > > >
>>> > >>>> > > > _______________________________________________
>>> > >>>> > > > 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 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
>>> > >>> --
>>> > >>>
>>> > >>> 389 Directory Server Development Team
>>> > >>>
>>> > >> --
>>> > >>
>>> > >> 389 Directory Server Development Team
>>> > >>
>>> > >>
>>> > >>
>>> > >> _______________________________________________
>>> > >> 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 Directory Server Development Team
>>> > >
>>> > > _______________________________________________
>>> > > 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 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 Directory Server Development Team
>>
> --
>
> 389 Directory Server Development Team
>
> _______________________________________________
> 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
