from:"JR Aquino"

On Jun 5, 2013, at 1:47 PM, KodaK wrote:

Sorry, for some reason gmail makes me forget about "reply all."

On Wed, Jun 5, 2013 at 2:45 PM, Dmitri Pal 
mailto:d...@redhat.com>> wrote:
On 06/05/2013 11:20 AM, KodaK wrote:
I know this has been discussed before, but I didn't see anything with a cursory 
search.

There are bugs when using user and host groups with sudo rules.  I have to 
split out my users and hosts into individual entries.  I'm running ipa 3.0.0-26 
on RHEL.

All I really want to know is if this is fixed upstream.


I am not sure I recall a bug you are referring to. A quick scan against the 
open tickets does not reveal anything like what you describe.
Can you provide the description of the issue or point to the earlier thread on 
the matter?


I'm going off of memory on seeing the previous bug.  It very well could be a 
false memory.

I have a rule like this:

[jebalicki@mo0033802 ~]$ ipa sudorule-show esolutions-sandbox-root-access
  Rule name: esolutions-sandbox-root-access
  Enabled: TRUE
  Users: slfries, awellard
  Hosts: slnessbxl01.unix.magellanhealth.com
  Sudo Allow Commands: /bin/su -

This works.  However, if I change the rule to use hostgroups instead of listing 
the hosts individually the rule will not work.

The groups still exist and look like this:

[jebalicki@mo0033802 ~]$ ipa hostgroup-show esolutions-sandbox-hosts
  Host-group: esolutions-sandbox-hosts
  Description: esolutions sandbox hosts
  Member hosts: slnessbxl01.unix.magellanhealth.com
  Member of HBAC rule: esolutions-sandbox-access

[jebalicki@mo0033802 ~]$ ipa group-show esolutions
  Group name: esolutions
  Description: esolutions group
  GID: 1115600250
  Member users: awellard, slfries
  Member of HBAC rule: esolutions-sandbox-access

Client machine is pretty much default-out-of-the-box IRT IPA configuration, 
here's the installer output (installs during kickstart):

[root@slnessbxl01 ~]# cat ks-post.log
Discovery was successful!
Hostname: slnessbxl01.unix.magellanhealth.com
Realm: UNIX.MAGELLANHEALTH.COM
DNS Domain: UNIX.MAGELLANHEALTH.COM
IPA Server: slpidml01.unix.magellanhealth.com
BaseDN: dc=unix,dc=magellanhealth,dc=com


Synchronizing time with KDC...

Enrolled in IPA realm UNIX.MAGELLANHEALTH.COM
Created /etc/ipa/default.conf
New SSSD config will be created.
Configured /etc/sssd/sssd.conf
Configured /etc/krb5.conf for IPA realm UNIX.MAGELLANHEALTH.COM
Warning: Hostname (slnessbxl01.unix.magellanhealth.com) not found in DNS
DNS server record set to: slnessbxl01.unix.magellanhealth.com -> 10.200.12.104
SSSD enabled
NTP enabled
Client configuration complete.

[root@slnessbxl01 ~]# rpm -qa | grep ipa
python-iniparse-0.3.1-2.1.el6.noarch
libipa_hbac-python-1.8.0-32.el6.x86_64
libipa_hbac-1.8.0-32.el6.x86_64
ipa-client-2.2.0-16.el6.x86_64
ipa-python-2.2.0-16.el6.x86_64
[root@slnessbxl01 ~]# cat /etc/redhat-release
Red Hat Enterprise Linux Server release 6.3 (Santiago)
[root@slnessbxl01 ~]#

Troubleshooting:

Can you confirm that the output of the following commands:
1. $ domainname
* does it match your domain?
2. $ hostname
* does match match your fqdn?
3. $ getent netgroup esolutions-sandbox-hosts
* does this list your host?
4. Does /etc/nsswitch.conf contain the line: "netgroup:   files sss"?


Another important Sudo Troubleshooting step is to edit: /etc/sudo-ldap.conf (or 
/etc/ldap.conf, depending on what version of RHEL/Sudo you're running):

At the top, add the line: sudoers_debug 2

Then try another sudo command. sudo -l for example.

This should result in a long list of search criteria and status.  The last few 
lines should indicate where any matches occurred.

"Keeping your head in the cloud"
~
JR Aquino

Senior Information Security Specialist, Technical Operations
T: +1 805 690 3478 | F: +1 805 879 3730 | M: +1 805 717 0365
GIAC Certified Exploit Researcher and Advanced Penetration Tester |
GIAC WebApplication Penetration Tester | GIAC Certified Incident Handler
jr.aqu...@citrix.com<mailto:jr.aqu...@citrix.com>

[cid:image002.jpg@01CD4A37.5451DC00]



Powering mobile workstyles and cloud services






___
Freeipa-users mailing list
Freeipa-users@redhat.com<mailto:Freeipa-users@redhat.com>
https://www.redhat.com/mailman/listinfo/freeipa-users

<>___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] IPA Replica Issue

On Jun 5, 2013, at 6:48 PM, Rich Megginson wrote:

> On 06/05/2013 07:20 PM, JR Aquino wrote:
>> On Jun 5, 2013, at 5:26 PM, Rich Megginson wrote:
>> 
>>> On 06/05/2013 05:49 PM, JR Aquino wrote:
>>>> I have been having replication issues since the update to RHEL6.4 and 
>>>> 389-ds-base-1.2.11.15-12.
>>>> 
>>>> It is entirely possible that we have more than just 1 problem.
>>>> 
>>>> Frequently we seeing errors in our replication monitoring indicating:  -1 
>>>> Incremental update has failed and requires administrator actionLDAP error: 
>>>> Can't contact LDAP server
>>>> 
>>>> This problem cannot be solved via ipa-replication-managment force-sync and 
>>>> it does not get permanently solved with a re-initializeation or a dirsrv 
>>>> restart either (the problem eventually comes back or appears on a 
>>>> different server)
>>>> 
>>>> Have any of you also seen this error when you could verify that the 
>>>> servers can communicate over ldap?
>>>> 
>>>> When checking with Rich today in IRC, we turned on debugging for 
>>>> replication and did not see a smoking gun.
>>>> 
>>>> We -did- see log messages showing things like: (auth1:389): CSN 
>>>> 51ad2c5500090066 not found, we aren't as up to date, or we purged
>>> On replicaID 0x66 - I think dbscan -f 
>>> /var/lib/dirsrv/slapd-INST/cldb/xx.db4 will tell you what are the purge 
>>> and max CSNs, somewhere near the beginning - what are they?
>> I've looked up and down the dbscan output and there is no sign of the word 
>> 'purge' or 'max'
> ok - try this
> dbscan -k 00de -f /var/lib/dirsrv/slapd-INST/cldb/xx.db4
> and
> dbscan -k 014d -f /var/lib/dirsrv/slapd-INST/cldb/xx.db4
> 
> If that gives you nothing, then just tell me what the first and last csns are.

It looks like -none- of my 42 servers seem to have that key present or a 'max' 
or a 'purge' csn.

The first CSN is:
dbid: 514543d200060077
replgen: 1363737222 Tue Mar 19 16:53:42 2013
csn: 514543d200060077
uniqueid: ---
dn: cn=start iteration
operation: delete

the last CSN is:
dbid: 51afe52a00090038
replgen: 1370480270 Wed Jun  5 17:57:50 2013
csn: 51afe52a00090038
uniqueid: 34b69984-244d11e2-9c3ddd59-5d298bd5
dn: uid=user,cn=users,cn=accounts,dc=example,dc=com
operation: modify
ntUserLastLogon: 130149214165556521
manager: uid=manager,cn=users,cn=accounts,dc=example,dc=com
manager: uid=manager,cn=users,cn=accounts,dc=example,dc=com
modifiersName: cn=Multimaster Replication 
Plugin,cn=plugins,cn=config
modifyTimestamp: 20130606005748Z


>> 
>>> Also, what is the database RUV on 0x66?  that is, do
>>> 
>>> ldapsearch -xLLL -h 0x66hostname -D "cn=directory manager" -w password -b 
>>> dc=expertcity,dc=com 
>>> '(&(objectclass=nsTombstone)(nsuniqueid=---))'
>> I've sent you a private email from for the above output
>> 
>>>> When looking for this change, it was determined that the originating IPA 
>>>> server who was responsible for the change show that this was a 
>>>> modification by the MemberOf plugin associating a host with a hostgroup or 
>>>> vice versa.
>>>> 
>>>> This change was -not- found on the IPA server who is reporting the 
>>>> replication troubles.
>>>> 
>>>> IPA deliberately excludes memberof changes during incremental updates for 
>>>> performance reasons.  This is because each server does replicate the 
>>>> 'member' info, where by the local MemberOf plugin will fire off and 
>>>> perform its respective fixups accordingly.
>>>> 
>>>> Rich asked me to bring this issue up to the attention of the mailing list 
>>>> so that we could continue to track the root cause of the issue(s) and 
>>>> hopefully come to a conclusion about how to fix them.
>>>> 
>>>> 
>>>> "Keeping your head in the cloud"
>>>> ~
>>>> Jr Aquino | Sr. Information Security Specialist
>>>> GXPN | GIAC Exploit Researcher and Advanced Penetration Tester
>>>> GCIH | GIAC Certified Incident Handler
>>>> GWAPT | GIAC WebApp Penetration Tester
>>>> 
>>>> Citrix Online | 7408 Hollister Avenue | Goleta, CA 
>>>> 93117
>>>> T:  +1 805.690.3478
>>>> C: +1 805.717.0365
>>>> jr.aqu...@citrix.com<mailto:jr.aqu...@citrixonline.com>
>>>> http://www.citrixonline.com<http://www.citrixonline.com/>
>>>> 
>>>> 
>>>> ___
>>>> Freeipa-users mailing list
>>>> Freeipa-users@redhat.com
>>>> https://www.redhat.com/mailman/listinfo/freeipa-users
> 
>> 


___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] IPA Replica Issue

On Jun 5, 2013, at 5:26 PM, Rich Megginson wrote:

> On 06/05/2013 05:49 PM, JR Aquino wrote:
>> I have been having replication issues since the update to RHEL6.4 and 
>> 389-ds-base-1.2.11.15-12.
>> 
>> It is entirely possible that we have more than just 1 problem.
>> 
>> Frequently we seeing errors in our replication monitoring indicating:  -1 
>> Incremental update has failed and requires administrator actionLDAP error: 
>> Can't contact LDAP server
>> 
>> This problem cannot be solved via ipa-replication-managment force-sync and 
>> it does not get permanently solved with a re-initializeation or a dirsrv 
>> restart either (the problem eventually comes back or appears on a different 
>> server)
>> 
>> Have any of you also seen this error when you could verify that the servers 
>> can communicate over ldap?
>> 
>> When checking with Rich today in IRC, we turned on debugging for replication 
>> and did not see a smoking gun.
>> 
>> We -did- see log messages showing things like: (auth1:389): CSN 
>> 51ad2c5500090066 not found, we aren't as up to date, or we purged
> 
> On replicaID 0x66 - I think dbscan -f 
> /var/lib/dirsrv/slapd-INST/cldb/xx.db4 will tell you what are the purge 
> and max CSNs, somewhere near the beginning - what are they?

I've looked up and down the dbscan output and there is no sign of the word 
'purge' or 'max'

> Also, what is the database RUV on 0x66?  that is, do
> 
> ldapsearch -xLLL -h 0x66hostname -D "cn=directory manager" -w password -b 
> dc=expertcity,dc=com 
> '(&(objectclass=nsTombstone)(nsuniqueid=---))'

I've sent you a private email from for the above output

> 
>> 
>> When looking for this change, it was determined that the originating IPA 
>> server who was responsible for the change show that this was a modification 
>> by the MemberOf plugin associating a host with a hostgroup or vice versa.
>> 
>> This change was -not- found on the IPA server who is reporting the 
>> replication troubles.
>> 
>> IPA deliberately excludes memberof changes during incremental updates for 
>> performance reasons.  This is because each server does replicate the 
>> 'member' info, where by the local MemberOf plugin will fire off and perform 
>> its respective fixups accordingly.
>> 
>> Rich asked me to bring this issue up to the attention of the mailing list so 
>> that we could continue to track the root cause of the issue(s) and hopefully 
>> come to a conclusion about how to fix them.
>> 
>> 
>> "Keeping your head in the cloud"
>> ~
>> Jr Aquino | Sr. Information Security Specialist
>> GXPN | GIAC Exploit Researcher and Advanced Penetration Tester
>> GCIH | GIAC Certified Incident Handler
>> GWAPT | GIAC WebApp Penetration Tester
>> 
>> Citrix Online | 7408 Hollister Avenue | Goleta, CA 
>> 93117
>> T:  +1 805.690.3478
>> C: +1 805.717.0365
>> jr.aqu...@citrix.com<mailto:jr.aqu...@citrixonline.com>
>> http://www.citrixonline.com<http://www.citrixonline.com/>
>> 
>> 
>> ___
>> Freeipa-users mailing list
>> Freeipa-users@redhat.com
>> https://www.redhat.com/mailman/listinfo/freeipa-users
> 


___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

[Freeipa-users] IPA Replica Issue

I have been having replication issues since the update to RHEL6.4 and 
389-ds-base-1.2.11.15-12.

It is entirely possible that we have more than just 1 problem.

Frequently we seeing errors in our replication monitoring indicating:  -1 
Incremental update has failed and requires administrator actionLDAP error: 
Can't contact LDAP server

This problem cannot be solved via ipa-replication-managment force-sync and it 
does not get permanently solved with a re-initializeation or a dirsrv restart 
either (the problem eventually comes back or appears on a different server)

Have any of you also seen this error when you could verify that the servers can 
communicate over ldap?

When checking with Rich today in IRC, we turned on debugging for replication 
and did not see a smoking gun.

We -did- see log messages showing things like: (auth1:389): CSN 
51ad2c5500090066 not found, we aren't as up to date, or we purged

When looking for this change, it was determined that the originating IPA server 
who was responsible for the change show that this was a modification by the 
MemberOf plugin associating a host with a hostgroup or vice versa.

This change was -not- found on the IPA server who is reporting the replication 
troubles.

IPA deliberately excludes memberof changes during incremental updates for 
performance reasons.  This is because each server does replicate the 'member' 
info, where by the local MemberOf plugin will fire off and perform its 
respective fixups accordingly.

Rich asked me to bring this issue up to the attention of the mailing list so 
that we could continue to track the root cause of the issue(s) and hopefully 
come to a conclusion about how to fix them.


"Keeping your head in the cloud"
~~~~~
Jr Aquino | Sr. Information Security Specialist
GXPN | GIAC Exploit Researcher and Advanced Penetration Tester
GCIH | GIAC Certified Incident Handler
GWAPT | GIAC WebApp Penetration Tester

Citrix Online | 7408 Hollister Avenue | Goleta, CA 
93117
T:  +1 805.690.3478
C: +1 805.717.0365
jr.aqu...@citrix.com<mailto:jr.aqu...@citrixonline.com>
http://www.citrixonline.com<http://www.citrixonline.com/>


___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] automember issues

I've got about 30mins before I get into my next meeting.

Are you able to hop into IRC in Freenode to work in realtime on #freeipa?

"Keeping your head in the cloud"
~~~~~~~~~
Jr Aquino | Sr. Information Security Specialist
GXPN | GIAC Exploit Researcher and Advanced Penetration Tester
GCIH | GIAC Certified Incident Handler
GWAPT | GIAC WebApp Penetration Tester

Citrix Online | 7408 Hollister Avenue | Goleta, CA 
93117
T:  +1 805.690.3478
C: +1 805.717.0365
jr.aqu...@citrix.com<mailto:jr.aqu...@citrixonline.com>
http://www.citrixonline.com<http://www.citrixonline.com/>

On Apr 30, 2013, at 12:23 PM, John Moyer 
mailto:john.mo...@digitalreasoning.com>>
 wrote:

So I must have looked at the wrong server name, I just tried to add 4 more 
servers and none of them worked.   Anymore ideas?   The target is specified by 
the rule name test-group is the target.

Thanks,
_
John Moyer


On Apr 30, 2013, at 2:25 PM, Dmitri Pal 
mailto:d...@redhat.com>> wrote:

On 04/30/2013 02:17 PM, JR Aquino wrote:
On Apr 30, 2013, at 11:12 AM, John Moyer 
mailto:john.mo...@digitalreasoning.com>>
wrote:

I tried adding it in addition to the current rule and that didn't work.  I then 
deleted the old rule to only leave the rule with the full name 
(uid=build,cn=users,cn=accounts,dc=example,dc=com) and that didn't work either.

This is the new output of that command you had me run earlier:

ipa automember-find --type=hostgroup
---
1 rules matched
---
Automember Rule: test-group
Inclusive Regex: enrolledby=uid=build,cn=users,cn=accounts,dc=example,dc=com

Number of entries returned 1


Interesting.

What about if you just do something silly like: ".*build.*"

Nathan... I believe the plugin is set to expect string values... how does it 
handle a DN such as the enrolled by above?


Don't you need to specify target group?
It might be that the filter is working but it is not placing it anywhere
because nothing is specifying where to place it.




Thanks,
_________
John Moyer


On Apr 30, 2013, at 2:07 PM, JR Aquino 
mailto:jr.aqu...@citrix.com>> wrote:

On Apr 30, 2013, at 11:02 AM, John Moyer 
mailto:john.mo...@digitalreasoning.com>>
wrote:

It comes back with a ton of stuff the row you are probably interested in is 
this one:

enrolledby: uid=build,cn=users,cn=accounts,dc=example,dc=com
Bingo!

Ok, try to adjust your automember rule.

Delete your previous inclusive regex, and replace it with 
uid=build,cn=users,cn=accounts,dc=example,dc=com

See if that does the trick

Thanks,
_________
John Moyer


On Apr 30, 2013, at 1:57 PM, JR Aquino 
mailto:jr.aqu...@citrix.com>> wrote:

On Apr 30, 2013, at 10:52 AM, John Moyer 
mailto:john.mo...@digitalreasoning.com>>
wrote:

Not a problem, here is the output

ipa automember-find --type=hostgroup
---
1 rules matched
---
Automember Rule: test-group
Inclusive Regex: enrolledby=build

Number of entries returned 1


interesting.

When you do an: ipa host-show 
test-hostname.example.com<http://test-hostname.example.com> --all --raw

Does it clearly show that enrolledby=build?


Thanks,
_
John Moyer


On Apr 30, 2013, at 1:48 PM, JR Aquino 
mailto:jr.aqu...@citrix.com>> wrote:

On Apr 30, 2013, at 10:43 AM, John Moyer 
mailto:john.mo...@digitalreasoning.com>>
wrote:

One thing to add is that this build user only has the following access:

Host Administrators
Host enrollment

Would he need more access to do the membership?  My original thought was that 
technically the user is not doing the addition to the group it's the system 
technically doing it so there shouldn't be a permissions issue.

The user's roles shouldn't really matter to the best of my knowledge (Nathan 
Kinder may need to refresh my memory), but the 389 plugin, should be catching 
the insertion of the new object, then match the watched-attribute, and execute 
the hostgroup assignment based upon the rights of the plugin rather than that 
of the user.

Would it be possible to ask you to do an automember-find --type=hostgroup on 
the CLI and send it back to the thread?

If we are missing something or if we have any bugs in there, we need to get 
them identified and fixed.


Thanks,
_
John Moyer
On Apr 30, 2013, at 1:21 PM, JR Aquino 
mailto:jr.aqu...@citrix.com>> wrote:

On Apr 30, 2013, at 9:30 AM, John Moyer 
mailto:john.mo...@digitalreasoning.com><mailto:john.mo...@digitalreasoning.com>>
 wrote:

Anyone have any suggestions to using the auto member function

Re: [Freeipa-users] automember issues

On Apr 30, 2013, at 11:23 AM, John Moyer 
 wrote:

> Ha!  I tried .*build and build.* before contacting you guys, I didn't try 
> .*build.* 
> 
> That worked, it automatically added the machine to the group! 
> 
> Thanks!  That will save me s much time! 
> 

Not a problem John, thanks for your patience!

Glad to be of help!

I'm very happy to see that some of the stuff that I use daily saves other folks 
time and headaches too!

-JR

> 
> Thanks, 
> _
> John Moyer
> 
> 
> On Apr 30, 2013, at 2:17 PM, JR Aquino  wrote:
> 
>> On Apr 30, 2013, at 11:12 AM, John Moyer 
>> wrote:
>> 
>>> I tried adding it in addition to the current rule and that didn't work.  I 
>>> then deleted the old rule to only leave the rule with the full name 
>>> (uid=build,cn=users,cn=accounts,dc=example,dc=com) and that didn't work 
>>> either.
>>> 
>>> This is the new output of that command you had me run earlier: 
>>> 
>>> ipa automember-find --type=hostgroup
>>> ---
>>> 1 rules matched
>>> ---
>>> Automember Rule: test-group
>>> Inclusive Regex: enrolledby=uid=build,cn=users,cn=accounts,dc=example,dc=com
>>> 
>>> Number of entries returned 1
>>> 
>>> 
>> 
>> Interesting.
>> 
>> What about if you just do something silly like: ".*build.*"
>> 
>> Nathan... I believe the plugin is set to expect string values... how does it 
>> handle a DN such as the enrolled by above?
>> 
>>> 
>>> 
>>> Thanks, 
>>> _
>>> John Moyer
>>> 
>>> 
>>> On Apr 30, 2013, at 2:07 PM, JR Aquino  wrote:
>>> 
>>>> On Apr 30, 2013, at 11:02 AM, John Moyer 
>>>> wrote:
>>>> 
>>>>> It comes back with a ton of stuff the row you are probably interested in 
>>>>> is this one: 
>>>>> 
>>>>> enrolledby: uid=build,cn=users,cn=accounts,dc=example,dc=com
>>>> 
>>>> Bingo!
>>>> 
>>>> Ok, try to adjust your automember rule.
>>>> 
>>>> Delete your previous inclusive regex, and replace it with 
>>>> uid=build,cn=users,cn=accounts,dc=example,dc=com
>>>> 
>>>> See if that does the trick
>>>> 
>>>>> Thanks, 
>>>>> _
>>>>> John Moyer
>>>>> 
>>>>> 
>>>>> On Apr 30, 2013, at 1:57 PM, JR Aquino  wrote:
>>>>> 
>>>>>> On Apr 30, 2013, at 10:52 AM, John Moyer 
>>>>>> 
>>>>>> wrote:
>>>>>> 
>>>>>>> Not a problem, here is the output
>>>>>>> 
>>>>>>> ipa automember-find --type=hostgroup
>>>>>>> ---
>>>>>>> 1 rules matched
>>>>>>> ---
>>>>>>> Automember Rule: test-group
>>>>>>> Inclusive Regex: enrolledby=build
>>>>>>> 
>>>>>>> Number of entries returned 1
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>> interesting.
>>>>>> 
>>>>>> When you do an: ipa host-show test-hostname.example.com --all --raw
>>>>>> 
>>>>>> Does it clearly show that enrolledby=build?
>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> Thanks, 
>>>>>>> _
>>>>>>> John Moyer
>>>>>>> 
>>>>>>> 
>>>>>>> On Apr 30, 2013, at 1:48 PM, JR Aquino  wrote:
>>>>>>> 
>>>>>>>> On Apr 30, 2013, at 10:43 AM, John Moyer 
>>>>>>>> 
>>>>>>>> wrote:
>>>>>>>> 
>>>>>>>>> One thing to add is that this build user only has the following 
>>>>>>>>> access: 
>>>>>>>>> 
>>>>>>>>> Host Administrators
>>>>>>>>> Host enrollment 
>>>>>>>>&g

Re: [Freeipa-users] automember issues

On Apr 30, 2013, at 11:12 AM, John Moyer 
 wrote:

> I tried adding it in addition to the current rule and that didn't work.  I 
> then deleted the old rule to only leave the rule with the full name 
> (uid=build,cn=users,cn=accounts,dc=example,dc=com) and that didn't work 
> either.
> 
> This is the new output of that command you had me run earlier: 
> 
> ipa automember-find --type=hostgroup
> ---
> 1 rules matched
> ---
>  Automember Rule: test-group
>  Inclusive Regex: enrolledby=uid=build,cn=users,cn=accounts,dc=example,dc=com
> 
> Number of entries returned 1
> 
> 

Interesting.

What about if you just do something silly like: ".*build.*"

Nathan... I believe the plugin is set to expect string values... how does it 
handle a DN such as the enrolled by above?

> 
> 
> Thanks, 
> _________
> John Moyer
> 
> 
> On Apr 30, 2013, at 2:07 PM, JR Aquino  wrote:
> 
>> On Apr 30, 2013, at 11:02 AM, John Moyer 
>> wrote:
>> 
>>> It comes back with a ton of stuff the row you are probably interested in is 
>>> this one: 
>>> 
>>> enrolledby: uid=build,cn=users,cn=accounts,dc=example,dc=com
>> 
>> Bingo!
>> 
>> Ok, try to adjust your automember rule.
>> 
>> Delete your previous inclusive regex, and replace it with 
>> uid=build,cn=users,cn=accounts,dc=example,dc=com
>> 
>> See if that does the trick
>> 
>>> Thanks, 
>>> _
>>> John Moyer
>>> 
>>> 
>>> On Apr 30, 2013, at 1:57 PM, JR Aquino  wrote:
>>> 
>>>> On Apr 30, 2013, at 10:52 AM, John Moyer 
>>>> wrote:
>>>> 
>>>>> Not a problem, here is the output
>>>>> 
>>>>> ipa automember-find --type=hostgroup
>>>>> ---
>>>>> 1 rules matched
>>>>> ---
>>>>> Automember Rule: test-group
>>>>> Inclusive Regex: enrolledby=build
>>>>> 
>>>>> Number of entries returned 1
>>>>> 
>>>>> 
>>>> 
>>>> interesting.
>>>> 
>>>> When you do an: ipa host-show test-hostname.example.com --all --raw
>>>> 
>>>> Does it clearly show that enrolledby=build?
>>>> 
>>>>> 
>>>>> 
>>>>> Thanks, 
>>>>> _
>>>>> John Moyer
>>>>> 
>>>>> 
>>>>> On Apr 30, 2013, at 1:48 PM, JR Aquino  wrote:
>>>>> 
>>>>>> On Apr 30, 2013, at 10:43 AM, John Moyer 
>>>>>> 
>>>>>> wrote:
>>>>>> 
>>>>>>> One thing to add is that this build user only has the following access: 
>>>>>>> 
>>>>>>> Host Administrators
>>>>>>> Host enrollment 
>>>>>>> 
>>>>>>> Would he need more access to do the membership?  My original thought 
>>>>>>> was that technically the user is not doing the addition to the group 
>>>>>>> it's the system technically doing it so there shouldn't be a 
>>>>>>> permissions issue. 
>>>>>>> 
>>>>>> 
>>>>>> The user's roles shouldn't really matter to the best of my knowledge 
>>>>>> (Nathan Kinder may need to refresh my memory), but the 389 plugin, 
>>>>>> should be catching the insertion of the new object, then match the 
>>>>>> watched-attribute, and execute the hostgroup assignment based upon the 
>>>>>> rights of the plugin rather than that of the user.
>>>>>> 
>>>>>> Would it be possible to ask you to do an automember-find 
>>>>>> --type=hostgroup on the CLI and send it back to the thread?
>>>>>> 
>>>>>> If we are missing something or if we have any bugs in there, we need to 
>>>>>> get them identified and fixed.
>>>>>> 
>>>>>> 
>>>>>>> Thanks, 
>>>>>>> _
>>>>>>> John Moyer
>>>>>>> On Apr 30, 2013, at 1:21 PM, JR Aquino  wrote:
>&

Re: [Freeipa-users] automember issues

On Apr 30, 2013, at 11:02 AM, John Moyer 
 wrote:

> It comes back with a ton of stuff the row you are probably interested in is 
> this one: 
> 
> enrolledby: uid=build,cn=users,cn=accounts,dc=example,dc=com

Bingo!

Ok, try to adjust your automember rule.

Delete your previous inclusive regex, and replace it with 
uid=build,cn=users,cn=accounts,dc=example,dc=com

See if that does the trick

> Thanks, 
> _
> John Moyer
> 
> 
> On Apr 30, 2013, at 1:57 PM, JR Aquino  wrote:
> 
>> On Apr 30, 2013, at 10:52 AM, John Moyer 
>> wrote:
>> 
>>> Not a problem, here is the output
>>> 
>>> ipa automember-find --type=hostgroup
>>> ---
>>> 1 rules matched
>>> ---
>>> Automember Rule: test-group
>>> Inclusive Regex: enrolledby=build
>>> 
>>> Number of entries returned 1
>>> 
>>> 
>> 
>> interesting.
>> 
>> When you do an: ipa host-show test-hostname.example.com --all --raw
>> 
>> Does it clearly show that enrolledby=build?
>> 
>>> 
>>> 
>>> Thanks, 
>>> _
>>> John Moyer
>>> 
>>> 
>>> On Apr 30, 2013, at 1:48 PM, JR Aquino  wrote:
>>> 
>>>> On Apr 30, 2013, at 10:43 AM, John Moyer 
>>>> wrote:
>>>> 
>>>>> One thing to add is that this build user only has the following access: 
>>>>> 
>>>>> Host Administrators
>>>>> Host enrollment 
>>>>> 
>>>>> Would he need more access to do the membership?  My original thought was 
>>>>> that technically the user is not doing the addition to the group it's the 
>>>>> system technically doing it so there shouldn't be a permissions issue. 
>>>>> 
>>>> 
>>>> The user's roles shouldn't really matter to the best of my knowledge 
>>>> (Nathan Kinder may need to refresh my memory), but the 389 plugin, should 
>>>> be catching the insertion of the new object, then match the 
>>>> watched-attribute, and execute the hostgroup assignment based upon the 
>>>> rights of the plugin rather than that of the user.
>>>> 
>>>> Would it be possible to ask you to do an automember-find --type=hostgroup 
>>>> on the CLI and send it back to the thread?
>>>> 
>>>> If we are missing something or if we have any bugs in there, we need to 
>>>> get them identified and fixed.
>>>> 
>>>> 
>>>>> Thanks, 
>>>>> _
>>>>> John Moyer
>>>>> On Apr 30, 2013, at 1:21 PM, JR Aquino  wrote:
>>>>> 
>>>>>> 
>>>>>> On Apr 30, 2013, at 9:30 AM, John Moyer 
>>>>>> mailto:john.mo...@digitalreasoning.com>>
>>>>>>  wrote:
>>>>>> 
>>>>>> Anyone have any suggestions to using the auto member function in IPA?  
>>>>>> I've tried to set it up so if a server is enrolled by a user called 
>>>>>> "build" then it should add it to a specific server group.   I put in an 
>>>>>> inclusive rule and the expression is just "build", but it doesn't work.  
>>>>>> Do I need to specify more than just build in the expression area?
>>>>>> 
>>>>>> 
>>>>>> That -should- be enough to catch new hosts that are built by the 'build' 
>>>>>> user.
>>>>>> 
>>>>>> Can you verify that the Attribute you are matching on is: "enrolledby" ?
>>>>>> 
>>>>>> 
>>>>>> "Keeping your head in the cloud"
>>>>>> ~
>>>>>> Jr Aquino | Sr. Information Security Specialist
>>>>>> GXPN | GIAC Exploit Researcher and Advanced Penetration Tester
>>>>>> GCIH | GIAC Certified Incident Handler
>>>>>> GWAPT | GIAC WebApp Penetration Tester
>>>>>> 
>>>>>> Citrix Online | 7408 Hollister Avenue | Goleta, CA 
>>>>>> 93117
>>>>>> T:  +1 805.690.3478
>>>>>> C: +1 805.717.0365
>>>>>> jr.aqu...@citrix.com<mailto:jr.aqu...@citrixonline.com>
>>>>>> http://www.citrixonline.com<http://www.citrixonline.com/>
>>>>>> 
>>>>>> "Keeping your head in the cloud"
>>>>>> ~
>>>>>> Jr Aquino | Sr. Information Security Specialist
>>>>>> GXPN | GIAC Exploit Researcher and Advanced Penetration Tester
>>>>>> GCIH | GIAC Certified Incident Handler
>>>>>> GWAPT | GIAC WebApp Penetration Tester
>>>>>> 
>>>>>> Citrix Online | 7408 Hollister Avenue | Goleta, CA 
>>>>>> 93117
>>>>>> T:  +1 805.690.3478
>>>>>> C: +1 805.717.0365
>>>>>> jr.aqu...@citrix.com<mailto:jr.aqu...@citrixonline.com>
>>>>>> http://www.citrixonline.com<http://www.citrixonline.com/>
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> Thanks,
>>>>>> _
>>>>>> John Moyer
>>>>>> 
>>>>>> 
>>>>>> ___
>>>>>> Freeipa-users mailing list
>>>>>> Freeipa-users@redhat.com<mailto:Freeipa-users@redhat.com>
>>>>>> https://www.redhat.com/mailman/listinfo/freeipa-users
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 


___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] automember issues

On Apr 30, 2013, at 10:52 AM, John Moyer 
 wrote:

> Not a problem, here is the output
> 
> ipa automember-find --type=hostgroup
> ---
> 1 rules matched
> ---
>  Automember Rule: test-group
>  Inclusive Regex: enrolledby=build
> 
> Number of entries returned 1
> 
> 

interesting.

When you do an: ipa host-show test-hostname.example.com --all --raw

Does it clearly show that enrolledby=build?

> 
> 
> Thanks, 
> _
> John Moyer
> 
> 
> On Apr 30, 2013, at 1:48 PM, JR Aquino  wrote:
> 
>> On Apr 30, 2013, at 10:43 AM, John Moyer 
>> wrote:
>> 
>>> One thing to add is that this build user only has the following access: 
>>> 
>>> Host Administrators
>>> Host enrollment 
>>> 
>>> Would he need more access to do the membership?  My original thought was 
>>> that technically the user is not doing the addition to the group it's the 
>>> system technically doing it so there shouldn't be a permissions issue. 
>>> 
>> 
>> The user's roles shouldn't really matter to the best of my knowledge (Nathan 
>> Kinder may need to refresh my memory), but the 389 plugin, should be 
>> catching the insertion of the new object, then match the watched-attribute, 
>> and execute the hostgroup assignment based upon the rights of the plugin 
>> rather than that of the user.
>> 
>> Would it be possible to ask you to do an automember-find --type=hostgroup on 
>> the CLI and send it back to the thread?
>> 
>> If we are missing something or if we have any bugs in there, we need to get 
>> them identified and fixed.
>> 
>> 
>>> Thanks, 
>>> _
>>> John Moyer
>>> On Apr 30, 2013, at 1:21 PM, JR Aquino  wrote:
>>> 
>>>> 
>>>> On Apr 30, 2013, at 9:30 AM, John Moyer 
>>>> mailto:john.mo...@digitalreasoning.com>> 
>>>> wrote:
>>>> 
>>>> Anyone have any suggestions to using the auto member function in IPA?  
>>>> I've tried to set it up so if a server is enrolled by a user called 
>>>> "build" then it should add it to a specific server group.   I put in an 
>>>> inclusive rule and the expression is just "build", but it doesn't work.  
>>>> Do I need to specify more than just build in the expression area?
>>>> 
>>>> 
>>>> That -should- be enough to catch new hosts that are built by the 'build' 
>>>> user.
>>>> 
>>>> Can you verify that the Attribute you are matching on is: "enrolledby" ?
>>>> 
>>>> 
>>>> "Keeping your head in the cloud"
>>>> ~
>>>> Jr Aquino | Sr. Information Security Specialist
>>>> GXPN | GIAC Exploit Researcher and Advanced Penetration Tester
>>>> GCIH | GIAC Certified Incident Handler
>>>> GWAPT | GIAC WebApp Penetration Tester
>>>> 
>>>> Citrix Online | 7408 Hollister Avenue | Goleta, CA 
>>>> 93117
>>>> T:  +1 805.690.3478
>>>> C: +1 805.717.0365
>>>> jr.aqu...@citrix.com<mailto:jr.aqu...@citrixonline.com>
>>>> http://www.citrixonline.com<http://www.citrixonline.com/>
>>>> 
>>>> "Keeping your head in the cloud"
>>>> ~
>>>> Jr Aquino | Sr. Information Security Specialist
>>>> GXPN | GIAC Exploit Researcher and Advanced Penetration Tester
>>>> GCIH | GIAC Certified Incident Handler
>>>> GWAPT | GIAC WebApp Penetration Tester
>>>> 
>>>> Citrix Online | 7408 Hollister Avenue | Goleta, CA 
>>>> 93117
>>>> T:  +1 805.690.3478
>>>> C: +1 805.717.0365
>>>> jr.aqu...@citrix.com<mailto:jr.aqu...@citrixonline.com>
>>>> http://www.citrixonline.com<http://www.citrixonline.com/>
>>>> 
>>>> 
>>>> 
>>>> Thanks,
>>>> _
>>>> John Moyer
>>>> 
>>>> 
>>>> ___
>>>> Freeipa-users mailing list
>>>> Freeipa-users@redhat.com<mailto:Freeipa-users@redhat.com>
>>>> https://www.redhat.com/mailman/listinfo/freeipa-users
>>>> 
>>> 
>> 
> 


___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] automember issues

On Apr 30, 2013, at 10:43 AM, John Moyer 
 wrote:

> One thing to add is that this build user only has the following access: 
> 
> Host Administrators
> Host enrollment 
> 
> Would he need more access to do the membership?  My original thought was that 
> technically the user is not doing the addition to the group it's the system 
> technically doing it so there shouldn't be a permissions issue. 
> 

The user's roles shouldn't really matter to the best of my knowledge (Nathan 
Kinder may need to refresh my memory), but the 389 plugin, should be catching 
the insertion of the new object, then match the watched-attribute, and execute 
the hostgroup assignment based upon the rights of the plugin rather than that 
of the user.

Would it be possible to ask you to do an automember-find --type=hostgroup on 
the CLI and send it back to the thread?

If we are missing something or if we have any bugs in there, we need to get 
them identified and fixed.


> Thanks, 
> _____
> John Moyer
> On Apr 30, 2013, at 1:21 PM, JR Aquino  wrote:
> 
>> 
>> On Apr 30, 2013, at 9:30 AM, John Moyer 
>> mailto:john.mo...@digitalreasoning.com>> 
>> wrote:
>> 
>> Anyone have any suggestions to using the auto member function in IPA?  I've 
>> tried to set it up so if a server is enrolled by a user called "build" then 
>> it should add it to a specific server group.   I put in an inclusive rule 
>> and the expression is just "build", but it doesn't work.  Do I need to 
>> specify more than just build in the expression area?
>> 
>> 
>> That -should- be enough to catch new hosts that are built by the 'build' 
>> user.
>> 
>> Can you verify that the Attribute you are matching on is: "enrolledby" ?
>> 
>> 
>> "Keeping your head in the cloud"
>> ~
>> Jr Aquino | Sr. Information Security Specialist
>> GXPN | GIAC Exploit Researcher and Advanced Penetration Tester
>> GCIH | GIAC Certified Incident Handler
>> GWAPT | GIAC WebApp Penetration Tester
>> 
>> Citrix Online | 7408 Hollister Avenue | Goleta, CA 
>> 93117
>> T:  +1 805.690.3478
>> C: +1 805.717.0365
>> jr.aqu...@citrix.com<mailto:jr.aqu...@citrixonline.com>
>> http://www.citrixonline.com<http://www.citrixonline.com/>
>> 
>> "Keeping your head in the cloud"
>> ~
>> Jr Aquino | Sr. Information Security Specialist
>> GXPN | GIAC Exploit Researcher and Advanced Penetration Tester
>> GCIH | GIAC Certified Incident Handler
>> GWAPT | GIAC WebApp Penetration Tester
>> 
>> Citrix Online | 7408 Hollister Avenue | Goleta, CA 
>> 93117
>> T:  +1 805.690.3478
>> C: +1 805.717.0365
>> jr.aqu...@citrix.com<mailto:jr.aqu...@citrixonline.com>
>> http://www.citrixonline.com<http://www.citrixonline.com/>
>> 
>> 
>> 
>> Thanks,
>> _
>> John Moyer
>> 
>> 
>> ___
>> Freeipa-users mailing list
>> Freeipa-users@redhat.com<mailto:Freeipa-users@redhat.com>
>> https://www.redhat.com/mailman/listinfo/freeipa-users
>> 
> 


___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] automember issues


On Apr 30, 2013, at 9:30 AM, John Moyer 
mailto:john.mo...@digitalreasoning.com>> wrote:

Anyone have any suggestions to using the auto member function in IPA?  I've 
tried to set it up so if a server is enrolled by a user called "build" then it 
should add it to a specific server group.   I put in an inclusive rule and the 
expression is just "build", but it doesn't work.  Do I need to specify more 
than just build in the expression area?


That -should- be enough to catch new hosts that are built by the 'build' user.

Can you verify that the Attribute you are matching on is: "enrolledby" ?


"Keeping your head in the cloud"
~
Jr Aquino | Sr. Information Security Specialist
GXPN | GIAC Exploit Researcher and Advanced Penetration Tester
GCIH | GIAC Certified Incident Handler
GWAPT | GIAC WebApp Penetration Tester

Citrix Online | 7408 Hollister Avenue | Goleta, CA 
93117
T:  +1 805.690.3478
C: +1 805.717.0365
jr.aqu...@citrix.com<mailto:jr.aqu...@citrixonline.com>
http://www.citrixonline.com<http://www.citrixonline.com/>

"Keeping your head in the cloud"
~
Jr Aquino | Sr. Information Security Specialist
GXPN | GIAC Exploit Researcher and Advanced Penetration Tester
GCIH | GIAC Certified Incident Handler
GWAPT | GIAC WebApp Penetration Tester

Citrix Online | 7408 Hollister Avenue | Goleta, CA 
93117
T:  +1 805.690.3478
C: +1 805.717.0365
jr.aqu...@citrix.com<mailto:jr.aqu...@citrixonline.com>
http://www.citrixonline.com<http://www.citrixonline.com/>



Thanks,
_
John Moyer


___
Freeipa-users mailing list
Freeipa-users@redhat.com<mailto:Freeipa-users@redhat.com>
https://www.redhat.com/mailman/listinfo/freeipa-users


___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] openldap to ipa

2013-01-11 Thread JR Aquino

Try editing /etc/openldap/ldap.conf:

TLS_CACERT  /etc/ipa/ca.crt
TLS_REQCERT allow


See if that helps

"Keeping your head in the cloud"
~~~~~
Jr Aquino | Sr. Information Security Specialist
GIAC Exploit Researcher and Advanced Penetration Tester |
GIAC Certified Incident Handler | GIAC WebApp Penetration Tester
Citrix Online | 7408 Hollister Avenue | Goleta, CA 
93117
T:  +1 805.690.3478
C: +1 805.717.0365
jr.aqu...@citrix.com<mailto:jr.aqu...@citrixonline.com>
http://www.citrixonline.com<http://www.citrixonline.com/>

On Jan 11, 2013, at 8:05 AM, Johnathan Phan 
mailto:j...@ox-consulting.com>> wrote:

Hi There,

This is driving me up the wall.

I have two servers. 1 is a live openldap/kerberous AAA server running on RHEL6. 
The LDAP service has SSL/TS support. The second server is a test environment 
running on fedora and has 3.1 IPA installed.

As a last step of my POC I need to migrate the users and passwords from the 
LDAP server to IPA server.

I ran this command perfectly fine.

ipa config-mod --enable-migration=TRUE

However the next step was where my issues began.

In the end after a lot of IRC communication and troubleshooting I now run the 
following command.

ipa migrate-ds --bind-dn="cn=admin,dc=example,dc=com" 
--user-container="ou=users,ou=live,dc=example,dc=com" 
--group-container="ou=groups,ou=live,dc=example,dc=com" 
ldaps://ldap1.live.example.com<http://ldap1.live.example.com/>

I get the following error.

ipa: DEBUG: Caught fault 4203 from server 
http://fedoraipaserver.test.example.com/ipa/xml: Can't contact LDAP server: TLS 
error -8179:Peer's Certificate issuer is not recognized.
ipa: DEBUG: Destroyed connection context.xmlclient
ipa: ERROR: Can't contact LDAP server: TLS error -8179:Peer's Certificate 
issuer is not recognized.

I have summarized that the IPA server does not trust the cert served by the 
openldap or the other way around. Does anyone know how to get around this? Or 
allow me to finish the migration of user data.

Regards

John

--
Johnathan Phan

T: +44 (0)784 118 7080



___
Freeipa-users mailing list
Freeipa-users@redhat.com<mailto:Freeipa-users@redhat.com>
https://www.redhat.com/mailman/listinfo/freeipa-users


___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

[Freeipa-users] RHEL6.3 Install Problem with IPA

2012-11-29 Thread JR Aquino

I have a weird ipa-replica-install problem that I have not been able to work 
around.

I have managed to successfully reproduce and identify the root cause of my 
pain, but I don't understand why its coming up...

My install fails with:
Starting httpd: (98)Address already in use: make_sock: could not bind to 
address 0.0.0.0:80


After much head scratching, I finally was able to reproduce the problem:

If you start httpd as the install script does, it gives the following:

service httpd start
Starting httpd: Please enter password for "internal" token:

This process doesn't create the pidfile and essentially hangs httpd on 80 and 
443

When the restart process is later called, you get the message that the 
installer is throwing:

service httpd restart
Stopping httpd:[FAILED]
Starting httpd: (98)Address already in use: make_sock: could not bind to 
address 0.0.0.0:80
no listening sockets available, shutting down
Unable to open logs
[FAILED]


I've verified that the content of /etc/httpd/conf/password.conf is valid and 
will 'authenticate' if passed to that internal token prompt...

mod_nss is clearly the piece that is causing the prompting but I'm not sure 
what is breaking here or how I can work around it.

Can someone help?

"Keeping your head in the cloud"
~
Jr Aquino | Sr. Information Security Specialist
GIAC Exploit Researcher and Advanced Penetration Tester |
GIAC Certified Incident Handler | GIAC WebApp Penetration Tester
Citrix Online | 7408 Hollister Avenue | Goleta, CA 
93117
T:  +1 805.690.3478
C: +1 805.717.0365
jr.aqu...@citrix.com<mailto:jr.aqu...@citrixonline.com>
http://www.citrixonline.com<http://www.citrixonline.com/>


___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] Managing Sudo through FreeIPA

2012-11-08 Thread JR Aquino

If you go to the CLI on the FreeIPA server and type: ipa sudorule 

It will give you some useful info.  I believe you asked about the sudo user 
(which your log shows as currently unset, and configured as anonymous)

Here is a snipit:

-=-=-=-=-=-
...
FreeIPA provides a designated binddn to use with Sudo located at:
uid=sudo,cn=sysaccounts,cn=etc,dc=example,dc=com

To enable the binddn run the following command to set the password:
LDAPTLS_CACERT=/etc/ipa/ca.crt /usr/bin/ldappasswd -S -W -h 
ipa.example.com<http://ipa.example.com> -ZZ -D "cn=Directory Manager" 
uid=sudo,cn=sysaccounts,cn=etc,dc=example,dc=com

For more information, see the FreeIPA Documentation to Sudo.
-=-=-=-=-=-

The resulting user needs to be configured in your sudo-ldap.conf with:
binddn uid=sudo,cn=sysaccounts,cn=etc,dc=example,dc=com
bindpw 



"Keeping your head in the cloud"
~~~~~
Jr Aquino | Sr. Information Security Specialist

GIAC Certified Incident Handler | GIAC WebApp Penetration Tester
Citrix Online | 7408 Hollister Avenue | Goleta, CA 
93117
T:  +1 805.690.3478
C: +1 805.717.0365
jr.aqu...@citrix.com<mailto:jr.aqu...@citrixonline.com>
http://www.citrixonline.com<http://www.citrixonline.com/>

On Nov 8, 2012, at 9:11 AM, William Muriithi 
mailto:william.murii...@gmail.com>> wrote:

Steven,

Thanks for the pointers. I remember finding a post on this, but having
problem finding it now

I assume rhel6.3 by the el6 in the rpm

1) Make sure the host and IPA server are fully patched/updated.
I am current already

2) Edit nsswitch.conf to have "sudoers: files ldap" as the last line, may or 
may not be there.

Done

3) add lines to /etc/sudo-ldap.conf, takes a recent upgrade/patch of 6.3 for 
that file to "appear"  Im not at work so I odnt have a pastable set
Yes, the file was there already.  Wonder if you can paste it now.
Mine was like this

uri ldap://ipa1-yyz-int.example.loc

sudoers_base ou=SUDOers,dc=example,dc=loc

ssl  start_tls
tls_checkpeer(yes)
tls_cacertfile   /etc/ipa/ca.crt


4) Add "nisdomainname example.com<http://example.com>" to /etc/rc.d/rc.local.
Done
5) Add or enable the sudo "connection" user in IPA with a password.
?  Lost me here, mind explaining a bit please if you have a chance?
6) reboot the host

If it doesnt work set the debug level in sudo-ldap.conf to 2 and re-try to see 
the output..restart sssd.

sh-4.1$ sudo less /var/log/secure
LDAP Config Summary
===
uri  ldap://ipa1-yyz-int.example.loc
ldap_version 3
sudoers_base ou=SUDOers,dc=example,dc=loc
binddn   (anonymous)
bindpw   (anonymous)
ssl  start_tls
tls_checkpeer(no)
tls_cacertfile   /etc/ipa/ca.crt
===
sudo: ldap_set_option: debug -> 0
sudo: ldap_set_option: tls_checkpeer -> 0
sudo: ldap_set_option: tls_cacertfile -> /etc/ipa/ca.crt
sudo: ldap_set_option: tls_cacert -> /etc/ipa/ca.crt
sudo: ldap_initialize(ld, ldap://ipa1-yyz-int.example.loc)
sudo: ldap_set_option: ldap_version -> 3
sudo: ldap_start_tls_s() ok
sudo: ldap_sasl_bind_s() ok
sudo: no default options found in ou=SUDOers,dc=example,dc=loc
sudo: ldap search
'(|(sudoUser=williamm)(sudoUser=%williamm)(sudoUser=%operations)(sudoUser=ALL))'
sudo: ldap search 'sudoUser=+*'
sudo: user_matches=0
sudo: host_matches=0
sudo: sudo_ldap_lookup(0)=0x60
[sudo] password for williamm:
williamm is not in the sudoers file.  This incident will be reported.


Thank you again for your help

Regards,

William
regards
Steven Jones
Technical Specialist - Linux RHCE
Victoria University, Wellington, NZ
0064 4 463 6272




From: freeipa-users-boun...@redhat.com<mailto:freeipa-users-boun...@redhat.com> 
[freeipa-users-boun...@redhat.com<mailto:freeipa-users-boun...@redhat.com>] on 
behalf of William Muriithi 
[william.murii...@gmail.com<mailto:william.murii...@gmail.com>]
Sent: Thursday, 8 November 2012 10:28 a.m.
To: freeipa-users@redhat.com<mailto:freeipa-users@redhat.com>
Subject: [Freeipa-users] Managing Sudo through FreeIPA

Hello

I have been trying to setup user access through sudo file managed by
FreeIPA and it don't seem to be working.  I am not sure how to go
about fixing it, but I guess the best place to start is ask what I
should expect the IPA installation script should set up and what
should be done manually

[root@demo2 wmuriithi]# rpm -qa | grep sssd
sssd-client-1.8.0-32.el6.x86_64
sssd-1.8.0-32.el6.x86_64
[root@demo2 wmuriithi]#



[root@demo2 wmuriithi]# rpm -qa | grep sudo
sudo-1.7.4p5-13.el6_3.x86_64

The only errors related to sudo that I can find is on apache error logs

[Wed Nov 07 13:16:18 2012] [error] ipa: INFO: 
ad...@example.loc<mailto:ad...@example.loc>:
sudorule_add_user(u'read_only_viewiers', all=False, raw=False,
version=u'2.34'

Re: [Freeipa-users] Sudo works for full access, but not on a per command or host level.

2012-10-16 Thread JR Aquino

If you look closely, the reason that your admin works is because it appears to 
be matching a sudo rule who has the "ALL" hosts value set.

When you run the non working user, it is attempting to match the 
hostname/hostgroup to the rule and fails to do so.

Try this. Type: getent netgroup hostgroupname <- your host's hostgroup goes 
there.

^ that command should return all of the hosts in your hostgroup. If it does 
not, then check /etc/nsswitch.conf and make sure that netgroup is set to use 
sss.

You will also need to make sure that the output of: domainname or nisdomainname 
matches your expected domain.

Let me know how things look after trying that.

~~~~~
Jr Aquino | Sr. Information Security Specialist
GIAC Certified Incident Handler | GIAC WebApp Penetration Tester
Citrix Online | 7408 Hollister Avenue | Goleta, CA 93117
T:  +1 805.690.3478
C: +1 805.717.0365
jr.aqu...@citrixonline.com<mailto:jr.aqu...@citrixonline.com>
http://www.citrixonline.com

On Oct 16, 2012, at 8:34 AM, "Macklin, Jason" 
mailto:jason.mack...@roche.com>> wrote:

Working user:

[jmacklin@dbduwdu062 log]$ sudo -l
LDAP Config Summary
===
uri  ldap://dbduvdu145.dbr.roche.com
ldap_version 3
sudoers_base ou=SUDOers,dc=dbr,dc=roche,dc=com
binddn   uid=sudo,cn=sysaccounts,cn=etc,dc=dbr,dc=roche,dc=com
bindpw   Roche454
bind_timelimit   5000
timelimit15
ssl  start_tls
tls_checkpeer(yes)
tls_cacertfile   /etc/ipa/ca.crt
===
sudo: ldap_set_option: debug -> 0
sudo: ldap_set_option: tls_checkpeer -> 1
sudo: ldap_set_option: tls_cacertfile -> /etc/ipa/ca.crt
sudo: ldap_set_option: tls_cacert -> /etc/ipa/ca.crt
sudo: ldap_initialize(ld, ldap://dbduvdu145.dbr.roche.com)
sudo: ldap_set_option: ldap_version -> 3
sudo: ldap_set_option: timelimit -> 15
sudo: ldap_set_option(LDAP_OPT_NETWORK_TIMEOUT, 5)
sudo: ldap_start_tls_s() ok
sudo: ldap_sasl_bind_s() ok
sudo: no default options found in ou=SUDOers,dc=dbr,dc=roche,dc=com
sudo: ldap sudoHost 'ALL' ... MATCH!
sudo: user_matches=1
sudo: host_matches=1
sudo: sudo_ldap_lookup(52)=0x82
Matching Defaults entries for jmacklin on this host:
requiretty, !visiblepw, always_set_home, env_reset, env_keep="COLORS 
DISPLAY HOSTNAME HISTSIZE INPUTRC KDEDIR LS_COLORS", env_keep+="MAIL PS1
PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE", env_keep+="LC_COLLATE 
LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES", env_keep+="LC_MONETARY
LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE", env_keep+="LC_TIME LC_ALL 
LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY",
secure_path=/sbin\:/bin\:/usr/sbin\:/usr/bin

sudo: ldap search 
'(|(sudoUser=jmacklin)(sudoUser=%jmacklin)(sudoUser=%dbr)(sudoUser=%admins)(sudoUser=ALL))'
sudo: ldap sudoHost 'ALL' ... MATCH!
sudo: ldap search 'sudoUser=+*'
User jmacklin may run the following commands on this host:
(root) ALL

Non-working user:

  Rule name: test4
  Enabled: TRUE
  Command category: all
  Users: asteinfeld
  Hosts: dbduwdu062.some.domain.com<http://dbduwdu062.some.domain.com>

LDAP Config Summary
===
uri  ldap://dbduvdu145.dbr.roche.com
ldap_version 3
sudoers_base ou=SUDOers,dc=dbr,dc=roche,dc=com
binddn   uid=sudo,cn=sysaccounts,cn=etc,dc=dbr,dc=roche,dc=com
bindpw   Roche454
bind_timelimit   5000
timelimit15
ssl  start_tls
tls_checkpeer(yes)
tls_cacertfile   /etc/ipa/ca.crt
===
sudo: ldap_set_option: debug -> 0
sudo: ldap_set_option: tls_checkpeer -> 1
sudo: ldap_set_option: tls_cacertfile -> /etc/ipa/ca.crt
sudo: ldap_set_option: tls_cacert -> /etc/ipa/ca.crt
sudo: ldap_initialize(ld, ldap://dbduvdu145.dbr.roche.com)
sudo: ldap_set_option: ldap_version -> 3
sudo: ldap_set_option: timelimit -> 15
sudo: ldap_set_option(LDAP_OPT_NETWORK_TIMEOUT, 5)
sudo: ldap_start_tls_s() ok
sudo: ldap_sasl_bind_s() ok
sudo: no default options found in ou=SUDOers,dc=dbr,dc=roche,dc=com
sudo: ldap sudoHost 'dbduwdu062.dbr.roche.com<http://dbduwdu062.dbr.roche.com>' 
... not
sudo: user_matches=1
sudo: host_matches=0
sudo: sudo_ldap_lookup(52)=0x84
[sudo] password for asteinfeld:
Sorry, user asteinfeld may not run sudo on dbduwdu062.

Cheers,
Jason
From: Dmitri Pal [mailto:d...@redhat.com]
Sent: Tuesday, October 16, 2012 11:22 AM
To: Macklin, Jason {DASB~Branford}
Cc: freeipa-users@redhat.com<mailto:freeipa-users@redhat.com>
Subject: Re: [Freeipa-users] Sudo works for full access, but not on a per 
command or host level.

On 10/16/2012 11:09 AM, Macklin, Jason wrote:
Dmitri,

I will give you everything I’ve got.  If I can provide something else, let me 
know!

Working User:

Sudo debug output:

[jmacklin@dbduwdu062 log]$ sudo -l
sudo: ldap_set_option: debug -> 0
sudo: ldap_set_op

Re: [Freeipa-users] Setting up sudo in FreeIPA v2.2

2012-10-16 Thread JR Aquino

On the host in question Run the command: domainname

That wants to match whatever your domain is. If it doesn't it will fail even if 
you have all the server rules configured correctly. This is a sudo + 
netgroups/hostgroups 'feature'

~~~~~~~~~
Jr Aquino | Sr. Information Security Specialist
GIAC Certified Incident Handler | GIAC WebApp Penetration Tester
Citrix Online | 7408 Hollister Avenue | Goleta, CA 93117
T:  +1 805.690.3478
C: +1 805.717.0365
jr.aqu...@citrixonline.com
http://www.citrixonline.com

On Oct 16, 2012, at 2:26 PM, "Toasted Penguin"  
wrote:

> I have the server setup to manage sudo and I configured a target client to 
> use the IPA server for sudo.  When a user tries to use sudo (in this case 
> "sudo su -") it fails and they get the error "user is not allowed to run sudo 
> on client-host.  This incident will be reported." I verified via the log 
> files that the client is making requests to the IPA server when the user is 
> attemping to use sudo and it fails.  I temporarily disabled using the IPA 
> server for sudo and I get the standard "User not in the sudoers file" 
>  
> Its starting to look like the server rules maybe the issue but I believe I 
> have the sudo rule setup correctly.  I created a sudo command "/bin/su", 
> created a sudo rule "Sudo to root" , added the group the user in question is 
> a part of to the WHO-->User Groups; Added the Host Group the target client 
> host is part of to Access This Host-->Host Groups and added the sudo command 
> to the sudo rule via Allow-->Sudo Allow Commands.  When I delete the sudo 
> rule I get the same result as I did when I temporarily disbled the client 
> host using tghe IPA server for sudo verification.
>  
> Any ideas why or where to look to figure out this issue?
>  
> Thanks,
> David 
> ___
> Freeipa-users mailing list
> Freeipa-users@redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] Password requirements too stringent

2012-09-17 Thread JR Aquino


On Sep 17, 2012, at 7:53 PM, Tim Hildred wrote:

> JR
> 
> I had that line. I commented it out. Thank you.
> 
> Now, what do I have to restart?

I believe it should take effect in real time, but you may need to test to be 
sure.  If it is still happening, you may need to double check that some other 
pam cfg doesn't also have it present: $ cd /etc/pam.d/ && grep pam_cracklib *

If you have removed it from everything and it is still giving you the same 
error, then I would try a reboot... perhaps getty needs to reinitialize or 
something.  But I'd try those steps before a reboot!

;)

> Tim Hildred, RHCE
> Content Author II - Engineering Content Services, Red Hat, Inc.
> Brisbane, Australia
> Email: thild...@redhat.com
> Internal: 8588287
> Mobile: +61 4 666 25242
> IRC: thildred
> 
> - Original Message -
>> From: "JR Aquino" 
>> To: "Tim Hildred" 
>> Cc: "freeipa-users" 
>> Sent: Tuesday, September 18, 2012 12:37:48 PM
>> Subject: Re: [Freeipa-users] Password requirements too stringent
>> 
>> Tim, please check your /etc/pam.d/system-auth with the password
>> block.  If you see passwordrequisite pam_cracklib.so, then
>> this is why you are having a problem.
>> 
>> $ man pam_cracklib
>> 
>> It is a local security library for enforcing strong password
>> practices from the unix cli.
>> 
>> ProTip:
>> If you don't need this, you can remove it from pam
>> If you want to work around this, set your password from the IPA webui
>> or via the cli: "ipa passwd username"
>> 
>> Hope this info helps!
>> 
>> "Keeping your head in the cloud"
>> ~
>> JR Aquino
>> 
>> Senior Information Security Specialist, Technical Operations
>> T: +1 805 690 3478 | F: +1 805 879 3730 | M: +1 805 717 0365
>> GIAC Certified Incident Handler | GIAC WebApplication Penetration
>> Tester
>> jr.aqu...@citrix.com<mailto:jr.aqu...@citrix.com>
>> 
>> 
>> [cid:image002.jpg@01CD4A37.5451DC00]
>> 
>> Powering mobile workstyles and cloud services
>> 
>> 
>> 
>> 
>> 
>> On Sep 17, 2012, at 6:25 PM, Tim Hildred wrote:
>> 
>> Hey all;
>> 
>> I'm running IPA internally to control access to our cloud
>> environment.
>> 
>> I must admit, I do not understand the password requirements. I have
>> had them set to the defaults. I read this:
>> https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/user-pwdpolicy.html
>> 
>> I have the minimum character classes set to 0. When people use SSH to
>> change their passwords, they get "Based on a dictionary word" for
>> passwords that have nothing to do with dictionary words.
>> 
>> I can't find anywhere in the documentation a break down of what makes
>> an unacceptable versus acceptable password.
>> 
>> Can anyone help me figure out what to tell my users? I think people
>> would get a lot less frustrated if they knew why "C679V375" was "too
>> simple" when the password policy has 0 required classes.
>> 
>> Tim Hildred, RHCE
>> Content Author II - Engineering Content Services, Red Hat, Inc.
>> Brisbane, Australia
>> Email: thild...@redhat.com
>> Internal: 8588287
>> Mobile: +61 4 666 25242
>> IRC: thildred
>> 
>> ps: funny exchange with user:
>> Jul 12 14:12:33  i feel like im being punked
>> Jul 12 14:12:40  it is based on a dictionary word
>> Jul 12 14:12:43  it is too short
>> Jul 12 14:12:49  is does not have enough unique letters
>> Jul 12 14:12:51  etc
>> 
>> ___
>> Freeipa-users mailing list
>> Freeipa-users@redhat.com
>> https://www.redhat.com/mailman/listinfo/freeipa-users
>> 
>> 


___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] Password requirements too stringent

2012-09-17 Thread JR Aquino

Tim, please check your /etc/pam.d/system-auth with the password block. If you
see passwordrequisite pam_cracklib.so, then this is why you are having
a problem.

$ man pam_cracklib

It is a local security library for enforcing strong password practices from the
unix cli.

ProTip:
If you don't need this, you can remove it from pam
If you want to work around this, set your password from the IPA webui or via
the cli: "ipa passwd username"

Hope this info helps!

"Keeping your head in the cloud"
~~~~~~~~~
JR Aquino

Senior Information Security Specialist, Technical Operations
T: +1 805 690 3478 | F: +1 805 879 3730 | M: +1 805 717 0365
GIAC Certified Incident Handler | GIAC WebApplication Penetration Tester
jr.aqu...@citrix.com<mailto:jr.aqu...@citrix.com>

[cid:image002.jpg@01CD4A37.5451DC00]

Powering mobile workstyles and cloud services

On Sep 17, 2012, at 6:25 PM, Tim Hildred wrote:

Hey all;

I'm running IPA internally to control access to our cloud environment.

I must admit, I do not understand the password requirements. I have had them
set to the defaults. I read this:
https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/user-pwdpolicy.html

I have the minimum character classes set to 0. When people use SSH to change
their passwords, they get "Based on a dictionary word" for passwords that have
nothing to do with dictionary words.

I can't find anywhere in the documentation a break down of what makes an
unacceptable versus acceptable password.

Can anyone help me figure out what to tell my users? I think people would get a
lot less frustrated if they knew why "C679V375" was "too simple" when the
password policy has 0 required classes.

Tim Hildred, RHCE
Content Author II - Engineering Content Services, Red Hat, Inc.
Brisbane, Australia
Email: thild...@redhat.com
Internal: 8588287
Mobile: +61 4 666 25242
IRC: thildred

ps: funny exchange with user:
Jul 12 14:12:33 i feel like im being punked
Jul 12 14:12:40 it is based on a dictionary word
Jul 12 14:12:43 it is too short
Jul 12 14:12:49 is does not have enough unique letters
Jul 12 14:12:51 etc

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

<>___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] hostgroups not working for Sudo commands

2012-08-05 Thread JR Aquino

On Aug 5, 2012, at 1:54 PM, "Steven Jones"  wrote:

> Hi,
> 
> I have setup a sudo command but no matter what I do I cannot get a host-group 
> to work, but I can specify a specific host without issue.I assume this is 
> a problem with the sssd deamon on the RHEL6.3 client?  So what info/logs are 
> needed to fault find this please?
> 
> 
> 

Set sudoers_debug 2 On your sudo-ldap.conf

Run the sudo command. You should see it scroll a list of hostgroups etc.

If you do not have your domainname set, your sudo commands will fail on the 
hostgroup because they expect to see the nis domain match.

> regards
> 
> Steven Jones
> 
> Technical Specialist - Linux RHCE
> 
> Victoria University, Wellington, NZ
> 
> 0064 4 463 6272
> 
> ___
> Freeipa-users mailing list
> Freeipa-users@redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] self service password reset

2012-07-11 Thread JR Aquino

On Jul 11, 2012, at 3:23 PM, Dmitri Pal wrote:

On 07/11/2012 06:15 PM, JR Aquino wrote:
Note that this is also a future feature planned for 3.x

https://fedorahosted.org/freeipa/ticket/2276


Slightly different issue. This ticket is about allowing you to change
your password when it is expired when one logs into the web UI.
It is a more narrow use case than the mentioned utility.



Hrm. while the pwm tool DOES offer a great deal of other really cool looking 
features, it looks like it was only sited as an example in the BZ, and that the 
core problem described was "self password reset without ssh/kerb/etc)  The 
corresponding fix also seems only to implement only that one feature.

I am interested in the other features that pwm advertises though!  Perhaps I 
will get a free moment to test it out and report back on compatibility.


Benjamin Reed<mailto:ran...@opennms.org> 2011-09-30 14:06:31 EDT

Not a bug per se, but an enhancement request.

While it's possible for a user to reset their own password, it currently 
requires being hooked into some level of "real" account access, like SSH'ing in 
or providing kerberos credentials.  We are using FreeIPA to provide a 
user-management backend for web-based services we are providing to our 
customers, and don't want them to have to configure Kerberos, or SSH into an 
account, just to set their password.

It would be nice to have a "password reset" tool that is accessible securely 
(like over HTTPS) which doesn't require special credentials other than 
knowledge of the existing username and password.  One such example I'll be 
evaluating since there is no built-in facility for this is PWM:



^ That sounds like needing an HTTPS interface to perform self password resets 
on accounts that are expired :)

The detailed notes in the corresponding FreeIPA ticket seem to be in parallel 
as well:

https://fedorahosted.org/freeipa/ticket/1907


~
Jr Aquino | Sr. Information Security Specialist
GIAC Certified Incident Handler | GIAC WebApp Penetration Tester
Citrix Online | 7408 Hollister Avenue | Goleta, CA 
93117
T:  +1 805.690.3478
C: +1 805.717.0365
jr.aqu...@citrixonline.com<mailto:jr.aqu...@citrixonline.com><mailto:jr.aqu...@citrixonline.com>
http://www.citrixonline.com<http://www.citrixonline.com/>

On Jul 11, 2012, at 11:59 AM, KodaK wrote:

Has anyone rolled out a self-service password reset utility for IPA?
If so did you use something off the shelf that speaks LDAP or roll
your own?

I'm looking at this:

http://code.google.com/p/pwm/

But I'm just starting down this path.

Thanks,

--Jason

--
The government is going to read our mail anyway, might as well make it
tough for them.  GPG Public key ID:  B6A1A7C6

___
Freeipa-users mailing list
Freeipa-users@redhat.com<mailto:Freeipa-users@redhat.com>
https://www.redhat.com/mailman/listinfo/freeipa-users


___
Freeipa-users mailing list
Freeipa-users@redhat.com<mailto:Freeipa-users@redhat.com>
https://www.redhat.com/mailman/listinfo/freeipa-users


--
Thank you,
Dmitri Pal

Sr. Engineering Manager IPA project,
Red Hat Inc.


---
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/<http://www.redhat.com/carveoutcosts/>



___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users


___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] self service password reset

2012-07-11 Thread JR Aquino

Note that this is also a future feature planned for 3.x

https://fedorahosted.org/freeipa/ticket/2276

~
Jr Aquino | Sr. Information Security Specialist
GIAC Certified Incident Handler | GIAC WebApp Penetration Tester
Citrix Online | 7408 Hollister Avenue | Goleta, CA 
93117
T:  +1 805.690.3478
C: +1 805.717.0365
jr.aqu...@citrixonline.com<mailto:jr.aqu...@citrixonline.com>
http://www.citrixonline.com<http://www.citrixonline.com/>

On Jul 11, 2012, at 11:59 AM, KodaK wrote:

Has anyone rolled out a self-service password reset utility for IPA?
If so did you use something off the shelf that speaks LDAP or roll
your own?

I'm looking at this:

http://code.google.com/p/pwm/

But I'm just starting down this path.

Thanks,

--Jason

--
The government is going to read our mail anyway, might as well make it
tough for them.  GPG Public key ID:  B6A1A7C6

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users


___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] sudo hostgroup sanity check, please?

2012-07-10 Thread JR Aquino


On Jul 10, 2012, at 12:28 PM, KodaK wrote:

> Further information:
> 
> I do have:
> 
> ldap_netgroup_search_base = cn=ng,cn=compat,dc=validdomain,dc=com

Go ahead and remove this line.  Previous legacy versions of sssd required it.  
I believe it just gets in the way now.

You also want to run: $ domainanme

Make sure it comes back with your domain, if not, please set your domainname.  
(/etc/rc.local is currently the place recommended to set this value)

Netgroups will come back as a tuple like: (testhost.domain.com, -, domain.com)  

Sudo will do the netgroup look up and wants to see that the hostname matches 
the hostname of the server, and that the domain also matches.

You can double-check this by doing: getent netgroup 

It should return a tuple like the one above.

If you are still having difficulty, you can add sudoers_debug 2 in your 
/etc/sudo-ldap.conf file then re-run your sudo command.  IT should show the 
various tests it performs and the output of the FreeIPA server.  It wants to 
match, user, host, and command.


> In /etc/sssd/sssd.conf
> 
> Is cn=ng,cn=compat correct?
> 
> --Jason
> 
> On Tue, Jul 10, 2012 at 2:15 PM, KodaK  wrote:
>> I'm running IPA 2.2.0 on RHEL6
>> 
>> Server:
>> 
>> [root@validserver ~]# rpm -qa | grep ipa
>> ipa-client-2.2.0-16.el6.x86_64
>> ipa-pki-common-theme-9.0.3-7.el6.noarch
>> libipa_hbac-python-1.8.0-32.el6.x86_64
>> ipa-python-2.2.0-16.el6.x86_64
>> ipa-server-2.2.0-16.el6.x86_64
>> ipa-server-selinux-2.2.0-16.el6.x86_64
>> ipa-pki-ca-theme-9.0.3-7.el6.noarch
>> python-iniparse-0.3.1-2.1.el6.noarch
>> libipa_hbac-1.8.0-32.el6.x86_64
>> ipa-admintools-2.2.0-16.el6.x86_64
>> 
>> Client:
>> 
>> [root@validhost ~]# rpm -qa | grep ipa
>> ipa-client-2.2.0-16.el6.x86_64
>> ipa-pki-common-theme-9.0.3-7.el6.noarch
>> libipa_hbac-python-1.8.0-32.el6.x86_64
>> ipa-python-2.2.0-16.el6.x86_64
>> ipa-server-2.2.0-16.el6.x86_64
>> ipa-server-selinux-2.2.0-16.el6.x86_64
>> ipa-pki-ca-theme-9.0.3-7.el6.noarch
>> python-iniparse-0.3.1-2.1.el6.noarch
>> libipa_hbac-1.8.0-32.el6.x86_64
>> ipa-admintools-2.2.0-16.el6.x86_64
>> 
>> My sudo-ldap.conf file:
>> 
>> binddn uid=sudo,cn=sysaccounts,cn=etc,dc=validserver,dc=com
>> bindpw validpassword
>> 
>> ssl start_tls
>> tls_cacertfile /etc/ipa/ca.crt
>> tls_checkpeer yes
>> 
>> bind_timelimit 5
>> timelimit 15
>> 
>> uri ldap://validserver ldap://validserver2
>> sudoers_base ou=SUDOers,dc=unix,dc=magellanhealth,dc=com
>> 
>> What I'm trying to do:  I have a group of users that I'd like to have
>> restart apache on a group of hosts.
>> 
>> What I've done:  created a user group, created a group of hosts (in a
>> grouplist.)
>> 
>> I can successfully run sudo in any configuration, *except* when using
>> a host group.  When I try I get:
>> 
>> Sorry, user validuser is not allowed to execute
>> '/etc/rc.d/init.d/httpd status' as root on validhost1.fqdn.com.
>> 
>> I can edit the same rule, change the host group (that only contains
>> two hosts) and specify the two hosts directly and it works fine.
>> 
>> Can someone else just try this and see if I've hit a bug?  I'm certain
>> I couldn't have messed up creating the host group, but I suppose it's
>> possible.
>> 
>> I get the same behavior when I try a simple "/bin/cat" command through
>> sudo, too.
>> 
>> Is there a special config for using host groups?  I suspect I may have
>> missed some obvious documentation.
>> 
>> --
>> The government is going to read our mail anyway, might as well make it
>> tough for them.  GPG Public key ID:  B6A1A7C6
> 
> 
> 
> -- 
> The government is going to read our mail anyway, might as well make it
> tough for them.  GPG Public key ID:  B6A1A7C6
> 
> ___
> Freeipa-users mailing list
> Freeipa-users@redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users


___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] 389-ds memory usage

2012-06-06 Thread JR Aquino

On Jun 6, 2012, at 12:30 AM, "Sigbjorn Lie"  wrote:

> On Wed, June 6, 2012 00:54, JR Aquino wrote:
>> On Jun 5, 2012, at 3:42 PM, Sigbjorn Lie wrote:
>> 
>> 
>>> On 06/06/2012 12:26 AM, JR Aquino wrote:
>>> 
>>>> On Jun 5, 2012, at 3:12 PM, Sigbjorn Lie wrote:
>>>> 
>>>> 
>>>>> On 06/05/2012 11:44 PM, JR Aquino wrote:
>>>>> 
>>>>>> On Jun 5, 2012, at 1:54 PM, Sigbjorn Lie wrote:
>>>>>> 
>>>>>> 
>>>>>>> On 06/05/2012 10:42 PM, Steven Jones wrote:
>>>>>>> 
>>>>>>>> Hi
>>>>>>>> 
>>>>>>>> 
>>>>>>>> This has bug has pretty much destroyed my IPA deployment...I had a 
>>>>>>>> pretty bad
>>>>>>>> memory leak had to reboot every 36 hours...made worse by trying later 
>>>>>>>> 6.3? rpms didnt
>>>>>>>> fix the leak and it went split brain2 months and no fixboy 
>>>>>>>> did that open
>>>>>>>> up a can of worms.
>>>>>>>> 
>>>>>>>> :/
>>>>>>>> 
>>>>>>>> 
>>>>>>>> In my case I cant see how its churn as I have so few entries (<50) and 
>>>>>>>> Im adding no
>>>>>>>> more items at presentunless a part of ipa is "replicating and 
>>>>>>>> diffing" in the
>>>>>>>> background to check consistency?
>>>>>>>> 
>>>>>>>> I also have only one way replication now at most,  master to replica 
>>>>>>>> and no memory
>>>>>>>> leak shows in Munin at present.
>>>>>>>> 
>>>>>>>> but I seem to be faced with a rebuild from scratch...
>>>>>>> Did you do the "max entry cache size" tuning? If you did, what did you 
>>>>>>> set it to?
>>>>>>> 
>>>>>>> 
>>>>>>> Did you do any other tuning from the 389-ds tuning guide?
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> Rgds,
>>>>>>> Siggi
>>>>>>> 
>>>>>> When I had similar problems using Feodra (Not Redhat or CentOS) my 
>>>>>> underlying issues
>>>>>> were: managed entries firing off any time an object was updated (every 
>>>>>> time someone
>>>>>> successfully authenticates, kerberos updates the user object, which in 
>>>>>> turn would touch
>>>>>> the mepmanaged entry for the user's private group)  Similar things 
>>>>>> happened when
>>>>>> hostgroups were modified...
>>>>>> 
>>>>>> This was further complicated by inefficiencies in the way that slapi-nis 
>>>>>> was processing
>>>>>> the compat pieces for the sudo rules and the netgroups (which are 
>>>>>> automatically create
>>>>>> from every hostgroup)
>>>>>> 
>>>>>> Thus, when memberof fired off, slapi-nis recomputed a great deal of its 
>>>>>> chunk...
>>>>>> 
>>>>>> 
>>>>>> After getting those issues resolved, I tuned the max entry cache size.  
>>>>>> But it took all
>>>>>> the fixes to finally resolve the memory creep problem.
>>>>>> 
>>>>>> It is not at all clear to me whether or not the bug fixes for my problem 
>>>>>> have made it up
>>>>>> into Redhat / CentOS though...  The slapi-nis versions definitely don't 
>>>>>> line up between
>>>>>> fedora and redhat/centos...
>>>>>> 
>>>>>> Perhaps Nalin Or Rich can speak to some of that.
>>>>>> 
>>>>>> 
>>>>>> The bug itself was easiest to replicate with _big_ changes like deleting 
>>>>>> a group that had
>>>>>> a great number of members for example, but the symptoms were similar for 
>>>>>> me were similar
>>>>>> for day to date operation resulting in consumption that never freed.
>>>>>&g

Re: [Freeipa-users] 389-ds memory usage

On Jun 5, 2012, at 3:42 PM, Sigbjorn Lie wrote:

> On 06/06/2012 12:26 AM, JR Aquino wrote:
>> On Jun 5, 2012, at 3:12 PM, Sigbjorn Lie wrote:
>> 
>>> On 06/05/2012 11:44 PM, JR Aquino wrote:
>>>> On Jun 5, 2012, at 1:54 PM, Sigbjorn Lie wrote:
>>>> 
>>>>> On 06/05/2012 10:42 PM, Steven Jones wrote:
>>>>>> Hi
>>>>>> 
>>>>>> This has bug has pretty much destroyed my IPA deployment...I had a 
>>>>>> pretty bad memory leak had to reboot every 36 hours...made worse by 
>>>>>> trying later 6.3? rpms didnt fix the leak and it went split 
>>>>>> brain2 months and no fixboy did that open up a can of 
>>>>>> worms.
>>>>>> 
>>>>>> :/
>>>>>> 
>>>>>> In my case I cant see how its churn as I have so few entries (<50) and 
>>>>>> Im adding no more items at presentunless a part of ipa is 
>>>>>> "replicating and diffing" in the background to check consistency?
>>>>>> 
>>>>>> I also have only one way replication now at most,  master to replica and 
>>>>>> no memory leak shows in Munin at present.
>>>>>> 
>>>>>> but I seem to be faced with a rebuild from scratch...
>>>>> Did you do the "max entry cache size" tuning? If you did, what did you 
>>>>> set it to?
>>>>> 
>>>>> Did you do any other tuning from the 389-ds tuning guide?
>>>>> 
>>>>> 
>>>>> 
>>>>> Rgds,
>>>>> Siggi
>>>> When I had similar problems using Feodra (Not Redhat or CentOS) my 
>>>> underlying issues were: managed entries firing off any time an object was 
>>>> updated (every time someone successfully authenticates, kerberos updates 
>>>> the user object, which in turn would touch the mepmanaged entry for the 
>>>> user's private group)  Similar things happened when hostgroups were 
>>>> modified...
>>>> 
>>>> This was further complicated by inefficiencies in the way that slapi-nis 
>>>> was processing the compat pieces for the sudo rules and the netgroups 
>>>> (which are automatically create from every hostgroup)
>>>> 
>>>> Thus, when memberof fired off, slapi-nis recomputed a great deal of its 
>>>> chunk...
>>>> 
>>>> After getting those issues resolved, I tuned the max entry cache size.  
>>>> But it took all the fixes to finally resolve the memory creep problem.
>>>> 
>>>> It is not at all clear to me whether or not the bug fixes for my problem 
>>>> have made it up into Redhat / CentOS though...  The slapi-nis versions 
>>>> definitely don't line up between fedora and redhat/centos...
>>>> 
>>>> Perhaps Nalin Or Rich can speak to some of that.
>>>> 
>>>> The bug itself was easiest to replicate with _big_ changes like deleting a 
>>>> group that had a great number of members for example, but the symptoms 
>>>> were similar for me were similar for day to date operation resulting in 
>>>> consumption that never freed.
>>>> 
>>>> https://bugzilla.redhat.com/show_bug.cgi?id=771493
>>>> 
>>>> Are either of you currently utilizing sudo?
>>>> 
>>> I read your bug report a while back, and made sure that slapi-nis was 
>>> disabled.
>>> 
>>> I have tuned my cache size to 256MB. I believe that should be OK as my 
>>> cache hit ratio sits at 97-99% ?
>>> 
>>> I understand you have a farily large deployment, what cache size are you 
>>> using? Are you using Fedora or Red Hat / CentOS as your production 
>>> environment?
>>> 
>>> I do not use sudo with IPA yet, I am planning for doing that later. Is 
>>> there any issues I should be aware of with sudo integration?
>>> 
>>> Rich/Nalin,
>>> Was there a bug in managed entries that's been fixed in the current 389-ds 
>>> versions available in Red Hat / CentOS  6?
>>> 
>>> 
>>> Regards,
>>> Siggi
>>> 
>> Ya it is true that I do have a large environment, but some of the hurdles 
>> that I had to jump appeared to be ones that weren't related so much to the 
>> number of hosts I had, but rather their amount of activity.  I.e. automated 
>>

Re: [Freeipa-users] 389-ds memory usage

On Jun 5, 2012, at 3:12 PM, Sigbjorn Lie wrote:

> On 06/05/2012 11:44 PM, JR Aquino wrote:
>> On Jun 5, 2012, at 1:54 PM, Sigbjorn Lie wrote:
>> 
>>> On 06/05/2012 10:42 PM, Steven Jones wrote:
>>>> Hi
>>>> 
>>>> This has bug has pretty much destroyed my IPA deployment...I had a 
>>>> pretty bad memory leak had to reboot every 36 hours...made worse by trying 
>>>> later 6.3? rpms didnt fix the leak and it went split brain2 months 
>>>> and no fixboy did that open up a can of worms.
>>>> 
>>>> :/
>>>> 
>>>> In my case I cant see how its churn as I have so few entries (<50) and Im 
>>>> adding no more items at presentunless a part of ipa is "replicating 
>>>> and diffing" in the background to check consistency?
>>>> 
>>>> I also have only one way replication now at most,  master to replica and 
>>>> no memory leak shows in Munin at present.
>>>> 
>>>> but I seem to be faced with a rebuild from scratch...
>>> 
>>> Did you do the "max entry cache size" tuning? If you did, what did you set 
>>> it to?
>>> 
>>> Did you do any other tuning from the 389-ds tuning guide?
>>> 
>>> 
>>> 
>>> Rgds,
>>> Siggi
>> When I had similar problems using Feodra (Not Redhat or CentOS) my 
>> underlying issues were: managed entries firing off any time an object was 
>> updated (every time someone successfully authenticates, kerberos updates the 
>> user object, which in turn would touch the mepmanaged entry for the user's 
>> private group)  Similar things happened when hostgroups were modified...
>> 
>> This was further complicated by inefficiencies in the way that slapi-nis was 
>> processing the compat pieces for the sudo rules and the netgroups (which are 
>> automatically create from every hostgroup)
>> 
>> Thus, when memberof fired off, slapi-nis recomputed a great deal of its 
>> chunk...
>> 
>> After getting those issues resolved, I tuned the max entry cache size.  But 
>> it took all the fixes to finally resolve the memory creep problem.
>> 
>> It is not at all clear to me whether or not the bug fixes for my problem 
>> have made it up into Redhat / CentOS though...  The slapi-nis versions 
>> definitely don't line up between fedora and redhat/centos...
>> 
>> Perhaps Nalin Or Rich can speak to some of that.
>> 
>> The bug itself was easiest to replicate with _big_ changes like deleting a 
>> group that had a great number of members for example, but the symptoms were 
>> similar for me were similar for day to date operation resulting in 
>> consumption that never freed.
>> 
>> https://bugzilla.redhat.com/show_bug.cgi?id=771493
>> 
>> Are either of you currently utilizing sudo?
>> 
> I read your bug report a while back, and made sure that slapi-nis was 
> disabled.
> 
> I have tuned my cache size to 256MB. I believe that should be OK as my cache 
> hit ratio sits at 97-99% ?
> 
> I understand you have a farily large deployment, what cache size are you 
> using? Are you using Fedora or Red Hat / CentOS as your production 
> environment?
> 
> I do not use sudo with IPA yet, I am planning for doing that later. Is there 
> any issues I should be aware of with sudo integration?
> 
> Rich/Nalin,
> Was there a bug in managed entries that's been fixed in the current 389-ds 
> versions available in Red Hat / CentOS  6?
> 
> 
> Regards,
> Siggi
> 

Ya it is true that I do have a large environment, but some of the hurdles that 
I had to jump appeared to be ones that weren't related so much to the number of 
hosts I had, but rather their amount of activity.  I.e. automated single-sign 
on scripts, people authenticating, general binds taking place all over...

I am using Fedora with FreeIPA 2.2 pending a migration to RHEL 6.3 and IPA 2.2

My measurements... ;)

dn: cn=monitor,cn=userRoot,cn=ldbm database,cn=plugins,cn=config
objectClass: top
objectClass: extensibleObject
cn: monitor
database: ldbm database
readonly: 0
entrycachehits: 904077
entrycachetries: 923802
entrycachehitratio: 97
currententrycachesize: 79607895
maxentrycachesize: 104857600
currententrycachecount: 10301
maxentrycachecount: -1
dncachehits: 3
dncachetries: 10302
dncachehitratio: 0
currentdncachesize: 1861653
maxdncachesize: 10485760
currentdncachecount: 10301
maxdncachecount: -1



___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] 389-ds memory usage

On Jun 5, 2012, at 1:54 PM, Sigbjorn Lie wrote:

> On 06/05/2012 10:42 PM, Steven Jones wrote:
>> Hi
>> 
>> This has bug has pretty much destroyed my IPA deployment...I had a 
>> pretty bad memory leak had to reboot every 36 hours...made worse by trying 
>> later 6.3? rpms didnt fix the leak and it went split brain2 months 
>> and no fixboy did that open up a can of worms.
>> 
>> :/
>> 
>> In my case I cant see how its churn as I have so few entries (<50) and Im 
>> adding no more items at presentunless a part of ipa is "replicating and 
>> diffing" in the background to check consistency?
>> 
>> I also have only one way replication now at most,  master to replica and no 
>> memory leak shows in Munin at present.
>> 
>> but I seem to be faced with a rebuild from scratch...
> 
> 
> Did you do the "max entry cache size" tuning? If you did, what did you set it 
> to?
> 
> Did you do any other tuning from the 389-ds tuning guide?
> 
> 
> 
> Rgds,
> Siggi

When I had similar problems using Feodra (Not Redhat or CentOS) my underlying 
issues were: managed entries firing off any time an object was updated (every 
time someone successfully authenticates, kerberos updates the user object, 
which in turn would touch the mepmanaged entry for the user's private group)  
Similar things happened when hostgroups were modified...

This was further complicated by inefficiencies in the way that slapi-nis was 
processing the compat pieces for the sudo rules and the netgroups (which are 
automatically create from every hostgroup)

Thus, when memberof fired off, slapi-nis recomputed a great deal of its chunk...

After getting those issues resolved, I tuned the max entry cache size.  But it 
took all the fixes to finally resolve the memory creep problem.

It is not at all clear to me whether or not the bug fixes for my problem have 
made it up into Redhat / CentOS though...  The slapi-nis versions definitely 
don't line up between fedora and redhat/centos...

Perhaps Nalin Or Rich can speak to some of that.

The bug itself was easiest to replicate with _big_ changes like deleting a 
group that had a great number of members for example, but the symptoms were 
similar for me were similar for day to date operation resulting in consumption 
that never freed.

https://bugzilla.redhat.com/show_bug.cgi?id=771493

Are either of you currently utilizing sudo?

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] FreeIPA webserver cert expired.