Re: [389-users] Issues with group names on RHEL6

[Gerente de Sistemas]

remove


2013/10/22 

>
> (In my haste to post this, my first email didn't have a subject.  My
> apologies!)
>
>
> We have been working this problem for two weeks debugging. We have 389-ds
> running and multi-master with 3 RHEL6 servers and a RHEL5. The RHEL5 ldap
> clients authenticate correctly to the RHEL6 389-ds directory server and
> with 'id' command can see all groups a user belongs too.
>
> The same command in a RHEL6 ldap client using sssd shows ONLY the primary
> group. If we change the ldap clients to point at the RHEL5 389-ds directory
> server the same results occur. The one consistency is any RHEL6 ldap client
> we setup will authenticate to either RHEL5 or RHEL6 but the entire list of
> groups that user belongs to do not transfer independent of server version.
> We have enumerate set to true and we have ldap_group_member set to
> uniqueMember. These seems to point to the ldap client as RHEL5 client works
> just fine and both RHEL5 and RHEL6 389-ds servers react the same but we're
> not sure how to correct or is it a bug. HELP?
>
> Thanks!
>
> Harry Devine
> Common ARTS Software Development
> AJM-245
> (609)485-4218
> harry.dev...@faa.gov
> --
> 389 users mailing list
> 389-users@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-users
>

​remove​


--
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] MemberOf Plugin - experiences?

[Rich Megginson]

On 10/22/2013 11:44 AM, Jonathan Vaughn wrote:
That was exactly the way we ran it, per that documentation, but it 
didn't appear to do anything.


You can check the /var/log/dirsrv/slapd-INST/errors log file to see if 
it ran and if there were any errors.


So, I figured out that just adding/removing users from groups would 
trigger it to update ALL groups for that user,


Yes, it does.


so I just bulk added everyone to a group and problem solved.


On Tue, Oct 22, 2013 at 12:01 PM, Rich Megginson > wrote:


On 10/22/2013 10:52 AM, Jonathan Vaughn wrote:

Existing entries are not added automatically when enabling the
plugin, you have to either run the fixup-memberof.pl
 script (if it works for you - it never
did anything for us),


This is the documented way to do it.


https://access.redhat.com/site/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Advanced_Entry_Management.html#groups-cmd-memberof

6.1.4.5. Synchronizing memberOf Values
The MemberOf Plug-in automatically manages the memberOf attribute
on group member entries, based on the configuration in the group
entry itself. However, the memberOf attribute can be edited on a
user entry directly (which is improper) or new entries can be
imported or replicated over to the server that have a memberOf
attribute already set. These situations create inconsistencies
between the memberOf configuration managed by the server plug-in
and the actual memberships defined for an entry.
Directory Server has a memberOf repair task which manually runs
the plug-in to make sure the appropriate memberOf attributes are
set on entries. There are three ways to trigger this task:

In the Directory Server Console
Using the fixup-memberof.pl  script
Running a cn=memberof task,cn=tasks,cn=config tasks entry

6.1.4.5.1. Initializing and Regenerating memberOf Attributes Using
fixup-memberof.pl 
The fixup-memberof.pl  script launches a
special task to regenerate all of the memberOf attributes on user
entries based on the defined member attributes in the group
entries. This is a clean-up task which synchronizes the membership
defined in group entries and the corresponding user entries and
overwrites any accidental or improper edits on the user entries.

Open the tool directory for the Directory Server instance,
/usr/lib/dirsrv/slapd-instance_name/.
Run the script, binding as the Directory Manager.

./fixup-memberof.pl  -D
"cn=Directory Manager" -w password

The fixup-memberof.pl  command is
described in more detail in the Configuration and Command-Line
Tool Reference.

If it is not working for you, then please describe the steps you
took.



or you have to make a change to each pre-existing user to trigger
the memberOf updating. The easiest way to do that is to simply
create a group and add everyone to it, then remove it (unless of
course you actually have a use for said group). If you already
have a group with everyone in it, you can probably create a new
group, and add that group as a member of the new group.



On Tue, Oct 22, 2013 at 12:33 AM, Lars Remes
mailto:lars.re...@symbio.com>> wrote:

I'm not sure if existing entries are added automatically when
you enable the plugin.
I would assume so, but in any case at any time you can run
the fix-up task that will sync the attributes.
You can define the scope for the task using a filter, for
example, fix only ou=orgunit,ou=People,... branch of the DIT.

--
Lars Remes / Service Quality

lars.re...@symbio.com 
www.symbio.com 


> -Original Message-
> From: 389-users-boun...@lists.fedoraproject.org

[mailto:389-users- 
> boun...@lists.fedoraproject.org
] On Behalf Of Vesa Alho
> Sent: 21. lokakuuta 2013 15:50
> To: 389-users@lists.fedoraproject.org

> Subject: Re: [389-users] MemberOf Plugin - experiences?
>
> On 10/21/2013 01:37 PM, Lars Remes wrote:
> > We are using the memberOf plugin in a global,
multi-master-multi-slave
> setup, and so far we have not encountered any major issues.
> >
> > You can easily change the membership attribute, for
example, to
> memberUid.
> > MMR is handled by not replicating the memberOf attribute
between
> masters, but the at

Re: [389-users] MemberOf Plugin - experiences?

[Jonathan Vaughn]

That was exactly the way we ran it, per that documentation, but it didn't
appear to do anything. So, I figured out that just adding/removing users
from groups would trigger it to update ALL groups for that user, so I just
bulk added everyone to a group and problem solved.


On Tue, Oct 22, 2013 at 12:01 PM, Rich Megginson wrote:

>  On 10/22/2013 10:52 AM, Jonathan Vaughn wrote:
>
> Existing entries are not added automatically when enabling the plugin, you
> have to either run the fixup-memberof.pl script (if it works for you - it
> never did anything for us),
>
>
> This is the documented way to do it.
>
>
> https://access.redhat.com/site/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Advanced_Entry_Management.html#groups-cmd-memberof
>
> 6.1.4.5. Synchronizing memberOf Values
> The MemberOf Plug-in automatically manages the memberOf attribute on group
> member entries, based on the configuration in the group entry itself.
> However, the memberOf attribute can be edited on a user entry directly
> (which is improper) or new entries can be imported or replicated over to
> the server that have a memberOf attribute already set. These situations
> create inconsistencies between the memberOf configuration managed by the
> server plug-in and the actual memberships defined for an entry.
> Directory Server has a memberOf repair task which manually runs the
> plug-in to make sure the appropriate memberOf attributes are set on
> entries. There are three ways to trigger this task:
>
> In the Directory Server Console
> Using the fixup-memberof.pl script
> Running a cn=memberof task,cn=tasks,cn=config tasks entry
>
> 6.1.4.5.1. Initializing and Regenerating memberOf Attributes Using
> fixup-memberof.pl
> The fixup-memberof.pl script launches a special task to regenerate all of
> the memberOf attributes on user entries based on the defined member
> attributes in the group entries. This is a clean-up task which synchronizes
> the membership defined in group entries and the corresponding user entries
> and overwrites any accidental or improper edits on the user entries.
>
> Open the tool directory for the Directory Server instance,
> /usr/lib/dirsrv/slapd-instance_name/.
> Run the script, binding as the Directory Manager.
>
> ./fixup-memberof.pl -D "cn=Directory Manager" -w password
>
> The fixup-memberof.pl command is described in more detail in the
> Configuration and Command-Line Tool Reference.
>
> If it is not working for you, then please describe the steps you took.
>
>
>  or you have to make a change to each pre-existing user to trigger the
> memberOf updating. The easiest way to do that is to simply create a group
> and add everyone to it, then remove it (unless of course you actually have
> a use for said group). If you already have a group with everyone in it, you
> can probably create a new group, and add that group as a member of the new
> group.
>
>
>
> On Tue, Oct 22, 2013 at 12:33 AM, Lars Remes wrote:
>
>> I'm not sure if existing entries are added automatically when you enable
>> the plugin.
>> I would assume so, but in any case at any time you can run the fix-up
>> task that will sync the attributes.
>> You can define the scope for the task using a filter, for example, fix
>> only ou=orgunit,ou=People,... branch of the DIT.
>>
>> --
>> Lars Remes / Service Quality
>>
>> lars.re...@symbio.com
>> www.symbio.com
>>
>>
>> > -Original Message-
>> > From: 389-users-boun...@lists.fedoraproject.org [mailto:389-users-
>> > boun...@lists.fedoraproject.org] On Behalf Of Vesa Alho
>>  > Sent: 21. lokakuuta 2013 15:50
>> > To: 389-users@lists.fedoraproject.org
>> > Subject: Re: [389-users] MemberOf Plugin - experiences?
>> >
>> > On 10/21/2013 01:37 PM, Lars Remes wrote:
>> > > We are using the memberOf plugin in a global, multi-master-multi-slave
>> > setup, and so far we have not encountered any major issues.
>> > >
>> > > You can easily change the membership attribute, for example, to
>> > memberUid.
>> > > MMR is handled by not replicating the memberOf attribute between
>> > masters, but the attribute IS copied to slaves. Each master runs own
>> instance
>> > of the plugin.
>> > >
>> > > Sometimes you may need to manual launch the fix-up task, but that has
>> > been quite rare.
>> > > If necessary, you can schedule it to run periodically.
>> >
>> > How does it work for already existing entries if I enable the plugin? Do
>> > I need add them "manually" or does the plugin add them automatically?
>> >
>> > Naturally I will test this well before changing production, but just
>> > interested what it takes to start using it.
>> >
>> > Thanks for replying!
>> >
>> > -Vesa
>> >
>> > --
>> > 389 users mailing list
>> > 389-users@lists.fedoraproject.org
>> > https://admin.fedoraproject.org/mailman/listinfo/389-users
>> --
>> 389 users mailing list
>> 389-users@lists.fedoraproject.org
>> https://admin.fedoraproject.org/mailman/listinfo/389-users
>>
>
>
>
> --
> 389 

[389-users] HELP - ClusterMon

[Denise Cosso]

Hello,



Translate text or webpage

Could anyone help me??

I configured in the pacemaker ClusterMON but get no email. Already tested the 
email from the command line and all is right.

  I am sending configuration I did. What's wrong??

  I will deploy the environment this weekend and would like to deploy 
ClusterMon.

Anyone have any tips ???
Type text or a website address or translate a document.
Cancel
Did you mean: Alguém poderia me ajudar??? Eu configurei no pacemaker o Cluster
   
Denise


crm configure

primitive resMON ocf:pacemaker:ClusterMon \
op monitor interval="180" timeout="20" \
params extra_options="--mail-to guanae...@yahoo.com.br --mail-host 
smtp.x.xx" 

clone ClusterMon-clone resMON

daemon

root
 15811 1  0 16:34 ?    00:00:00 /usr/sbin/crm_mon -p 
/tmp/ClusterMon_resMON.pid -d -i 15 --mail-to guanae...@yahoo.com.br 
--mail-host smtp..xx -h
 /tmp/ClusterMon_resMON.html--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] MemberOf Plugin - experiences?

[Rich Megginson]

On 10/22/2013 10:52 AM, Jonathan Vaughn wrote:
Existing entries are not added automatically when enabling the plugin, 
you have to either run the fixup-memberof.pl 
 script (if it works for you - it never did 
anything for us),


This is the documented way to do it.

https://access.redhat.com/site/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Advanced_Entry_Management.html#groups-cmd-memberof

6.1.4.5. Synchronizing memberOf Values
The MemberOf Plug-in automatically manages the memberOf attribute on 
group member entries, based on the configuration in the group entry 
itself. However, the memberOf attribute can be edited on a user entry 
directly (which is improper) or new entries can be imported or 
replicated over to the server that have a memberOf attribute already 
set. These situations create inconsistencies between the memberOf 
configuration managed by the server plug-in and the actual memberships 
defined for an entry.
Directory Server has a memberOf repair task which manually runs the 
plug-in to make sure the appropriate memberOf attributes are set on 
entries. There are three ways to trigger this task:


In the Directory Server Console
Using the fixup-memberof.pl script
Running a cn=memberof task,cn=tasks,cn=config tasks entry

6.1.4.5.1. Initializing and Regenerating memberOf Attributes Using 
fixup-memberof.pl
The fixup-memberof.pl script launches a special task to regenerate all 
of the memberOf attributes on user entries based on the defined member 
attributes in the group entries. This is a clean-up task which 
synchronizes the membership defined in group entries and the 
corresponding user entries and overwrites any accidental or improper 
edits on the user entries.


Open the tool directory for the Directory Server instance, 
/usr/lib/dirsrv/slapd-instance_name/.

Run the script, binding as the Directory Manager.

./fixup-memberof.pl -D "cn=Directory Manager" -w password

The fixup-memberof.pl command is described in more detail in the 
Configuration and Command-Line Tool Reference.


If it is not working for you, then please describe the steps you took.

or you have to make a change to each pre-existing user to trigger the 
memberOf updating. The easiest way to do that is to simply create a 
group and add everyone to it, then remove it (unless of course you 
actually have a use for said group). If you already have a group with 
everyone in it, you can probably create a new group, and add that 
group as a member of the new group.




On Tue, Oct 22, 2013 at 12:33 AM, Lars Remes > wrote:


I'm not sure if existing entries are added automatically when you
enable the plugin.
I would assume so, but in any case at any time you can run the
fix-up task that will sync the attributes.
You can define the scope for the task using a filter, for example,
fix only ou=orgunit,ou=People,... branch of the DIT.

--
Lars Remes / Service Quality

lars.re...@symbio.com 
www.symbio.com 


> -Original Message-
> From: 389-users-boun...@lists.fedoraproject.org

[mailto:389-users- 
> boun...@lists.fedoraproject.org
] On Behalf Of Vesa Alho
> Sent: 21. lokakuuta 2013 15:50
> To: 389-users@lists.fedoraproject.org

> Subject: Re: [389-users] MemberOf Plugin - experiences?
>
> On 10/21/2013 01:37 PM, Lars Remes wrote:
> > We are using the memberOf plugin in a global,
multi-master-multi-slave
> setup, and so far we have not encountered any major issues.
> >
> > You can easily change the membership attribute, for example, to
> memberUid.
> > MMR is handled by not replicating the memberOf attribute between
> masters, but the attribute IS copied to slaves. Each master runs
own instance
> of the plugin.
> >
> > Sometimes you may need to manual launch the fix-up task, but
that has
> been quite rare.
> > If necessary, you can schedule it to run periodically.
>
> How does it work for already existing entries if I enable the
plugin? Do
> I need add them "manually" or does the plugin add them
automatically?
>
> Naturally I will test this well before changing production, but just
> interested what it takes to start using it.
>
> Thanks for replying!
>
> -Vesa
>
> --
> 389 users mailing list
> 389-users@lists.fedoraproject.org

> https://admin.fedoraproject.org/mailman/listinfo/389-users
--
389 users mailing list
389-users@lists.fedoraproject.org

https://admin.fedoraproject.org/mailman/listinfo

Re: [389-users] MemberOf Plugin - experiences?

[Jonathan Vaughn]

Existing entries are not added automatically when enabling the plugin, you
have to either run the fixup-memberof.pl script (if it works for you - it
never did anything for us), or you have to make a change to each
pre-existing user to trigger the memberOf updating. The easiest way to do
that is to simply create a group and add everyone to it, then remove it
(unless of course you actually have a use for said group). If you already
have a group with everyone in it, you can probably create a new group, and
add that group as a member of the new group.



On Tue, Oct 22, 2013 at 12:33 AM, Lars Remes  wrote:

> I'm not sure if existing entries are added automatically when you enable
> the plugin.
> I would assume so, but in any case at any time you can run the fix-up task
> that will sync the attributes.
> You can define the scope for the task using a filter, for example, fix
> only ou=orgunit,ou=People,... branch of the DIT.
>
> --
> Lars Remes / Service Quality
>
> lars.re...@symbio.com
> www.symbio.com
>
>
> > -Original Message-
> > From: 389-users-boun...@lists.fedoraproject.org [mailto:389-users-
> > boun...@lists.fedoraproject.org] On Behalf Of Vesa Alho
> > Sent: 21. lokakuuta 2013 15:50
> > To: 389-users@lists.fedoraproject.org
> > Subject: Re: [389-users] MemberOf Plugin - experiences?
> >
> > On 10/21/2013 01:37 PM, Lars Remes wrote:
> > > We are using the memberOf plugin in a global, multi-master-multi-slave
> > setup, and so far we have not encountered any major issues.
> > >
> > > You can easily change the membership attribute, for example, to
> > memberUid.
> > > MMR is handled by not replicating the memberOf attribute between
> > masters, but the attribute IS copied to slaves. Each master runs own
> instance
> > of the plugin.
> > >
> > > Sometimes you may need to manual launch the fix-up task, but that has
> > been quite rare.
> > > If necessary, you can schedule it to run periodically.
> >
> > How does it work for already existing entries if I enable the plugin? Do
> > I need add them "manually" or does the plugin add them automatically?
> >
> > Naturally I will test this well before changing production, but just
> > interested what it takes to start using it.
> >
> > Thanks for replying!
> >
> > -Vesa
> >
> > --
> > 389 users mailing list
> > 389-users@lists.fedoraproject.org
> > https://admin.fedoraproject.org/mailman/listinfo/389-users
> --
> 389 users mailing list
> 389-users@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-users
>
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] (no subject)

[Rob Crittenden]

harry.dev...@faa.gov wrote:


We tried that and, sadly, it made no difference.  In fact, we get LESS
information that before.  It appears as though we get the main group,
and it does not know how to dig further to get the sub-groups and group
members.  Also, we found that our ldap_group_member is called
uniqueMember and not memberUid.  Perhaps that's unique to your
installation?

Any other ideas?  Should we post our sssd.conf?


You may want to cross-post this on the sssd-users mailing list, 
https://lists.fedorahosted.org/mailman/listinfo/sssd-users


rob



Thanks,
Harry

Harry Devine
Common ARTS Software Development
AJM-245
(609)485-4218
harry.dev...@faa.gov


From:   Justin Edmands 
To: "General discussion list for the 389 Directory server project."
<389-users@lists.fedoraproject.org>
Date:   10/22/2013 10:22 AM
Subject:Re: [389-users] (no subject)
Sent by:389-users-boun...@lists.fedoraproject.org






On Tue, Oct 22, 2013 at 9:51 AM, <_harry.devine@faa.gov_
> wrote:

We have been working this problem for two weeks debugging. We have
389-ds running and multi-master with 3 RHEL6 servers and a RHEL5. The
RHEL5 ldap clients authenticate correctly to the RHEL6 389-ds directory
server and with 'id' command can see all groups a user belongs too.

The same command in a RHEL6 ldap client using sssd shows ONLY the
primary group. If we change the ldap clients to point at the RHEL5
389-ds directory server the same results occur. The one consistency is
any RHEL6 ldap client we setup will authenticate to either RHEL5 or
RHEL6 but the entire list of groups that user belongs to do not transfer
independent of server version. We have enumerate set to true and we have
ldap_group_member set to uniqueMember. These seems to point to the ldap
client as RHEL5 client works just fine and both RHEL5 and RHEL6 389-ds
servers react the same but we're not sure how to correct or is it a bug.
HELP?

Thanks!

Harry Devine
Common ARTS Software Development
AJM-245_
__(609)485-4218_ _
__Harry.Devine@faa.gov_ 
--
389 users mailing list_
__389-users@lists.fedoraproject.org_
_
__https://admin.fedoraproject.org/mailman/listinfo/389-users_


I had the same issue. SSSD needs to be told where to pull these from.

I had to add this to the global section of the sssd.conf (you may need
to disable all caching devices as well. they will hold the old "id" lookups)

ldap_group_member = memberUid
ldap_group_search_base = ou=,dc=sagedining,dc=com
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users



--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users



--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] (no subject)

[Justin Edmands]

On Tue, Oct 22, 2013 at 11:25 AM,  wrote:

>
> We tried that and, sadly, it made no difference.  In fact, we get LESS
> information that before.  It appears as though we get the main group, and
> it does not know how to dig further to get the sub-groups and group
> members.  Also, we found that our ldap_group_member is called uniqueMember
> and not memberUid.  Perhaps that's unique to your installation?
>
> Any other ideas?  Should we post our sssd.conf?
>
> Thanks,
> Harry
>
> Harry Devine
> Common ARTS Software Development
> AJM-245
> (609)485-4218
> harry.dev...@faa.gov
>
>
>  From: Justin Edmands 
>  To: "General discussion list for the 389 Directory server project." <
> 389-users@lists.fedoraproject.org> Date: 10/22/2013 10:22 AM Subject: Re:
> [389-users] (no subject) Sent by:
> 389-users-boun...@lists.fedoraproject.org
> --
>
>
>
> On Tue, Oct 22, 2013 at 9:51 AM, 
> <*harry.dev...@faa.gov*>
> wrote:
>
> We have been working this problem for two weeks debugging. We have 389-ds
> running and multi-master with 3 RHEL6 servers and a RHEL5. The RHEL5 ldap
> clients authenticate correctly to the RHEL6 389-ds directory server and
> with 'id' command can see all groups a user belongs too.
>
> The same command in a RHEL6 ldap client using sssd shows ONLY the primary
> group. If we change the ldap clients to point at the RHEL5 389-ds directory
> server the same results occur. The one consistency is any RHEL6 ldap client
> we setup will authenticate to either RHEL5 or RHEL6 but the entire list of
> groups that user belongs to do not transfer independent of server version.
> We have enumerate set to true and we have ldap_group_member set to
> uniqueMember. These seems to point to the ldap client as RHEL5 client works
> just fine and both RHEL5 and RHEL6 389-ds servers react the same but we're
> not sure how to correct or is it a bug. HELP?
>
> Thanks!
>
> Harry Devine
> Common ARTS Software Development
> AJM-245*
> **(609)485-4218* <%28609%29485-4218>*
> **harry.dev...@faa.gov* 
> --
> 389 users mailing list*
> **389-users@lists.fedoraproject.org* <389-users@lists.fedoraproject.org>*
> **https://admin.fedoraproject.org/mailman/listinfo/389-users*
>
>
> I had the same issue. SSSD needs to be told where to pull these from.
>
> I had to add this to the global section of the sssd.conf (you may need to
> disable all caching devices as well. they will hold the old "id" lookups)
>
> ldap_group_member = memberUid
> ldap_group_search_base = ou=,dc=sagedining,dc=com
> --
> 389 users mailing list
> 389-users@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-users
>
>
> --
> 389 users mailing list
> 389-users@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-users
>


Please do
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] (no subject)

[harry . devine]

We tried that and, sadly, it made no difference.  In fact, we get LESS 
information that before.  It appears as though we get the main group, and 
it does not know how to dig further to get the sub-groups and group 
members.  Also, we found that our ldap_group_member is called uniqueMember 
and not memberUid.  Perhaps that's unique to your installation?

Any other ideas?  Should we post our sssd.conf?

Thanks,
Harry

Harry Devine
Common ARTS Software Development
AJM-245
(609)485-4218
harry.dev...@faa.gov



From:
Justin Edmands 

To:
"General discussion list for the 389 Directory server project." 
<389-users@lists.fedoraproject.org>
Date:
10/22/2013 10:22 AM
Subject:
Re: [389-users] (no subject)
Sent by:
389-users-boun...@lists.fedoraproject.org



On Tue, Oct 22, 2013 at 9:51 AM,  wrote:

We have been working this problem for two weeks debugging. We have 389-ds 
running and multi-master with 3 RHEL6 servers and a RHEL5. The RHEL5 ldap 
clients authenticate correctly to the RHEL6 389-ds directory server and 
with 'id' command can see all groups a user belongs too. 

The same command in a RHEL6 ldap client using sssd shows ONLY the primary 
group. If we change the ldap clients to point at the RHEL5 389-ds 
directory server the same results occur. The one consistency is any RHEL6 
ldap client we setup will authenticate to either RHEL5 or RHEL6 but the 
entire list of groups that user belongs to do not transfer independent of 
server version. We have enumerate set to true and we have 
ldap_group_member set to uniqueMember. These seems to point to the ldap 
client as RHEL5 client works just fine and both RHEL5 and RHEL6 389-ds 
servers react the same but we're not sure how to correct or is it a bug. 
HELP? 

Thanks! 

Harry Devine
Common ARTS Software Development
AJM-245
(609)485-4218
harry.dev...@faa.gov
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users


I had the same issue. SSSD needs to be told where to pull these from.

I had to add this to the global section of the sssd.conf (you may need to 
disable all caching devices as well. they will hold the old "id" lookups)

ldap_group_member = memberUid
ldap_group_search_base = ou=,dc=sagedining,dc=com
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] (no subject)

[Justin Edmands]

On Tue, Oct 22, 2013 at 9:51 AM,  wrote:

>
> We have been working this problem for two weeks debugging. We have 389-ds
> running and multi-master with 3 RHEL6 servers and a RHEL5. The RHEL5 ldap
> clients authenticate correctly to the RHEL6 389-ds directory server and
> with 'id' command can see all groups a user belongs too.
>
> The same command in a RHEL6 ldap client using sssd shows ONLY the primary
> group. If we change the ldap clients to point at the RHEL5 389-ds directory
> server the same results occur. The one consistency is any RHEL6 ldap client
> we setup will authenticate to either RHEL5 or RHEL6 but the entire list of
> groups that user belongs to do not transfer independent of server version.
> We have enumerate set to true and we have ldap_group_member set to
> uniqueMember. These seems to point to the ldap client as RHEL5 client works
> just fine and both RHEL5 and RHEL6 389-ds servers react the same but we're
> not sure how to correct or is it a bug. HELP?
>
> Thanks!
>
> Harry Devine
> Common ARTS Software Development
> AJM-245
> (609)485-4218
> harry.dev...@faa.gov
> --
> 389 users mailing list
> 389-users@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-users
>


I had the same issue. SSSD needs to be told where to pull these from.

I had to add this to the global section of the sssd.conf (you may need to
disable all caching devices as well. they will hold the old "id" lookups)

ldap_group_member = memberUid
ldap_group_search_base = ou=,dc=sagedining,dc=com
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

[389-users] Issues with group names on RHEL6

[harry . devine]

(In my haste to post this, my first email didn't have a subject.  My 
apologies!)


We have been working this problem for two weeks debugging. We have 389-ds 
running and multi-master with 3 RHEL6 servers and a RHEL5. The RHEL5 ldap 
clients authenticate correctly to the RHEL6 389-ds directory server and 
with 'id' command can see all groups a user belongs too. 

The same command in a RHEL6 ldap client using sssd shows ONLY the primary 
group. If we change the ldap clients to point at the RHEL5 389-ds 
directory server the same results occur. The one consistency is any RHEL6 
ldap client we setup will authenticate to either RHEL5 or RHEL6 but the 
entire list of groups that user belongs to do not transfer independent of 
server version. We have enumerate set to true and we have 
ldap_group_member set to uniqueMember. These seems to point to the ldap 
client as RHEL5 client works just fine and both RHEL5 and RHEL6 389-ds 
servers react the same but we're not sure how to correct or is it a bug. 
HELP? 

Thanks!

Harry Devine
Common ARTS Software Development
AJM-245
(609)485-4218
harry.dev...@faa.gov--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

[389-users] (no subject)

[harry . devine]

We have been working this problem for two weeks debugging. We have 389-ds 
running and multi-master with 3 RHEL6 servers and a RHEL5. The RHEL5 ldap 
clients authenticate correctly to the RHEL6 389-ds directory server and 
with 'id' command can see all groups a user belongs too.

The same command in a RHEL6 ldap client using sssd shows ONLY the primary 
group. If we change the ldap clients to point at the RHEL5 389-ds 
directory server the same results occur. The one consistency is any RHEL6 
ldap client we setup will authenticate to either RHEL5 or RHEL6 but the 
entire list of groups that user belongs to do not transfer independent of 
server version. We have enumerate set to true and we have 
ldap_group_member set to uniqueMember. These seems to point to the ldap 
client as RHEL5 client works just fine and both RHEL5 and RHEL6 389-ds 
servers react the same but we're not sure how to correct or is it a bug. 
HELP? 

Thanks!

Harry Devine
Common ARTS Software Development
AJM-245
(609)485-4218
harry.dev...@faa.gov--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users