[Freeipa-users] FreeIPA Training Series

2013-06-05 Thread Martin Kosek 
Hello FreeIPA and SSSD users,

Our team just published FreeIPA&SSSD training presentations created in the
event of finishing FreeIPA 3.0 and SSSD 1.9.2 back in beginning of 2013.

I would like to welcome you to look at the presentations, they contain useful
information with aim to help you with understanding, configuring or even
debugging the features. All presentations were uploaded to the FreeIPA.org wiki:

http://www.freeipa.org/page/Documentation#FreeIPA_Training_Series

-- 
Martin Kosek 
Supervisor, Software Engineering - Identity Management Team
Red Hat Inc.

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

Re: [Freeipa-users] IPA different ID results on different nodes

2013-06-05 Thread Sumit Bose 
On Tue, Jun 04, 2013 at 09:40:21AM -0400, Aly Khimji wrote:
> I re-logged in this morning into the server and i see the following on the
> server
> Any thoughts?
> 
> Thx again.
> 
> SERVER:
> -sh-4.1$ id
> uid=59401108(akhi...@corpnonprd..com) gid=59401108(
> akhi...@corpnonprd..com) groups=59401108(akhi...@corpnonprd..com)
> context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
> 
> CLIENT:
> -sh-4.1$ id
> uid=59401108(akhi...@corpnonprd..com) gid=59401108(
> akhi...@corpnonprd..com)
> groups=59401108(akhi...@corpnonprd..com),59400512(domain
> adm...@corpnonprd..com),59400513(domain us...@corpnonprd..com
> ),59401123(mirra-supapp-admin-corp-...@corpnonprd..com),162200012(mirra-supapp-admin-nix-cde)
> context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
> -sh-4.1$

so the client side still looks ok. Can you send the logs from the server
as well? Besides the log of the domain the krb5_child and sssd_pac log
would be interesting as well. If you do not want to disclose the logs on
public mailing lists feel free to send them to me directly.

bye,
Sumit

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

[Freeipa-users] Announcing bind-dyndb-ldap version 3.3

2013-06-05 Thread Petr Spacek 

The FreeIPA team is proud to announce bind-dyndb-ldap version 3.2.

It can be downloaded from https://fedorahosted.org/released/bind-dyndb-ldap/. 
The new version has also been built for Fedora 19 and now it in updates-testing:

https://admin.fedoraproject.org/updates/FEDORA-2013-10003

This release includes several fixes.

== Changes in 3.3 ==

[1] Crash triggered by missing sasl_user parameter was fixed.

[2] IPv6 handling in PTR record synchronization was fixed.
https://fedorahosted.org/bind-dyndb-ldap/ticket/118

[3] Authentication settings are validated more strictly.
Conflicting options are reported and prevent named from starting.

[4] Automatic empty zones defined in RFC 6303 are automatically unloaded
if conflicting master or forward zone is defined in LDAP.
https://fedorahosted.org/bind-dyndb-ldap/ticket/119

[5] Configuration without persistent search is now deprecated
and informational message is logged. Support for zone_refresh
will be removed in 4.x release.
https://fedorahosted.org/bind-dyndb-ldap/ticket/120


== Upgrading ==

An server can be upgraded simply by installing updated rpms. BIND has to be 
restarted manually after the RPM installation.


You will need to clean up configuration file /etc/named.conf if your 
configuration contains typos or other unsupported options.


Downgrading back to any 2.x version is supported under following conditions:
- new object class idnsForwardZone is not utilized
- record types not supported by 2.x versions are not utilized
- configured connection count is >= 3 (to prevent deadlocks in 2.x releases)


== Feedback ==

Please provide comments, bugs and other feedback via the freeipa-users mailing
list: http://www.redhat.com/mailman/listinfo/freeipa-users

--
Petr Spacek
Software engineer
Red Hat

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

Re: [Freeipa-users] Fedora 19 test day: OTP based 2FA using FreeIPA

2013-06-05 Thread Petr Spacek 

On 28.5.2013 17:41, Dmitri Pal wrote:

To read more about the test day and suggested tests see the following
link
https://fedoraproject.org/wiki/Test_Day:2013-06-06_FreeIPA_Two_Factor_Authentication


Links to LiveCD ISOs on "Test Day" Wiki page are broken. There is too many "0" 
in links.


i686 image doesn't exist at all. Is it intentional?

--
Petr^2 Spacek

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

Re: [Freeipa-users] Fedora 19 test day: OTP based 2FA using FreeIPA

2013-06-05 Thread Rob Crittenden 

Petr Spacek wrote:

On 28.5.2013 17:41, Dmitri Pal wrote:

To read more about the test day and suggested tests see the following
link
https://fedoraproject.org/wiki/Test_Day:2013-06-06_FreeIPA_Two_Factor_Authentication



Links to LiveCD ISOs on "Test Day" Wiki page are broken. There is too
many "0" in links.

i686 image doesn't exist at all. Is it intentional?



The scripts/liveCD are still being worked on. Should be done soon.

rob

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

[Freeipa-users] sudo rules user and host group bugs?

2013-06-05 Thread KodaK 
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.

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

Re: [Freeipa-users] sudo rules user and host group bugs?

2013-06-05 Thread Dmitri Pal 
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?

> 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


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


---
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/



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

Re: [Freeipa-users] sudo rules user and host group bugs?

2013-06-05 Thread Jakub Hrozek 
On Wed, Jun 05, 2013 at 10:20:24AM -0500, 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.
> 
> Thanks,
> 
> --Jason

Do you use the SSSD integration? If so, then I can think of one bug that
might apply to your situation:
https://bugzilla.redhat.com/show_bug.cgi?id=880150

If you fetch sudo rules with nss_ldap, then describing what problems you
are seeing in more detail would help.

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

Re: [Freeipa-users] sudo rules user and host group bugs?

2013-06-05 Thread Lukáš Bezdička 
Hi,
lately I spent some time with debugging sudo, what I ended up with was:
I created sudo rule in ipa called defaults with sudo option fqdn. defaults
is being checked by sssd as default setting.

I set up NIS domain on hosts same as ipa domain. See getent netgroup


sudo seems to work fine.


On Wed, Jun 5, 2013 at 9:45 PM, Dmitri Pal  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?
>
>  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 
> listFreeipa-users@redhat.comhttps://www.redhat.com/mailman/listinfo/freeipa-users
>
>
>
> --
> Thank you,
> Dmitri Pal
>
> Sr. Engineering Manager for IdM portfolio
> Red Hat Inc.
>
>
> ---
> Looking to carve out IT costs?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] sudo rules user and host group bugs?

2013-06-05 Thread KodaK 
Sorry, for some reason gmail makes me forget about "reply all."

On Wed, Jun 5, 2013 at 2:45 PM, Dmitri Pal  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 ~]#
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

[Freeipa-users] Ubunto client?

2013-06-05 Thread Guy Matz 
Hi!  Can anyone recommend a PPA that contains a freeIPA client that:
1. works
2. Also contains an openssh-server that uses AuthorizedKeysCommand

Thanks a lot,
Guy

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

Re: [Freeipa-users] Ubunto client?

2013-06-05 Thread Lukas Slebodnik 
On (05/06/13 21:53), Guy Matz wrote:
>Hi!  Can anyone recommend a PPA that contains a freeIPA client that:
>1. works
Ubuntu 13.04 have already had freeipa-client-3.1.2 [1] and sssd-1.9.4 [2]
But I did not test them.

>2. Also contains an openssh-server that uses AuthorizedKeysCommand
I am adding Timo Aaltonen (Ubuntu freeipa/sssd package mantainer) to CC.
He could know answer to your question about
openssh-server and AuthorizedKeysCommand

>
>Thanks a lot,
>Guy
>

LS

[1] http://packages.ubuntu.com/raring/freeipa-client
[2] http://packages.ubuntu.com/raring/sssd

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

Re: [Freeipa-users] Limiting Host access by UID/GID

2013-06-05 Thread Chandan Kumar 
Sorry for late reply. Thanks for helping out. Yes after deleting the sssd
cache from /var/lib it does not allow user groups outside min/max_id.


Thanks
Chandan

On Tuesday, June 4, 2013, Jakub Hrozek wrote:

> On Fri, May 31, 2013 at 08:50:29AM -0700, Chandan Kumar wrote:
> > As far as my understanding goes it does not stop even if I disable cache
> > credentials. I set following parameters in sssd.conf but still UID 2
> is
> > able to login.
> >
>
> Sorry, there was some terminology confusion. I didn't ask for disabling
> cache credentials, but removing the on-disk cache and starting afresh.
>
> The cache is stored in /var/lib/sss/db/cache_$domname.ldb, so you can mv
> or rm it and check again if the IDs are still allowed.
>
> > cache_credentials = False
> > krb5_store_password_if_offline = False
> > min_id=5000
> > max_id=5010
> > enumerate = False
> > entry_cache_timeout=3
> >
> > Package Info:
> > Client;
> > sssd-client-1.9.2-82.7.el6_4.x86_64
> >
> > Server:
> > ipa-server-2.2.0-16.el6.x86_64
> >
> > Thanks
> > Chandan
> >
> > On Friday, May 31, 2013, Jakub Hrozek wrote:
> >
> > > On Fri, May 31, 2013 at 09:26:40AM -0400, Simo Sorce wrote:
> > > > On Fri, 2013-05-31 at 11:55 +0200, Jakub Hrozek wrote:
> > > > > On Thu, May 30, 2013 at 07:23:38PM -0400, Dmitri Pal wrote:
> > > > > > On 05/30/2013 06:52 PM, Chandan Kumar wrote:
> > > > > > > Hello,
> > > > > > >
> > > > > > > As part of migration from passwd/shadow to IPA, I want to roll
> out
> > > > > > > IPA/SSSD based password first for a small number of users and
> then
> > > for
> > > > > > > all. (same goes with host. first small number of host and then
> > > all).
> > > > > > >
> > > > > > > I was trying to limit it using max_id/min_id parameters in sssd
> > > but it
> > > > > > > does not seems to work the way I expected.
> > > > > > > ---
> > > > > > > min_id = 5000
> > > > > > > max_id = 5100
> > > > > > > --
> > > > > > > So there is a user "kchandan" with UID/GID 2
> > > > > > > --
> > > > > > > [root@tipa1 ~]# id kchandan
> > > > > > > uid=2(kchandan) gid=2 groups=2
> > > > > > > ---
> > > > > > >
> > > > > > > But It is allowing me to login with that ID with only error
> showing
> > > > > > > GID 2 not found.
> > > > > > > ---
> > > > > > > ssh 10.2.3.105 -l kchandan
> > > > > > > kchandan@10.2.3.105 's password:
> > > > > > > id: cannot find name for group ID 2
> > > > > > > -
> > > > > > >
> > > > > > > Is there any way to achieve this?
> > > > > >
> > > > > > So you want to allow only a subset of users with a specific
> range to
> > > log
> > > > > > into the systems controlled by SSSD before you open it to a
> broader
> > > public?
> > > > > > I would defer to SSSD gurus but the hack that comes to mind is to
> > > > > > configure a simple access provider to limit the access to just
> the
> > > users
> > > > > > you care about (man sssd-simple) or configure ldap access
> provider
> > > based
> > > > > > on a filter (man sssd-ldap).
> > > > >
> > > > > Hi,
> > > > >
> > > > > The user shouldn't be even saved to cache if it's filtered out of
> > > range.
> > > > >
> > > > > But looking at the current NSS code, the entry would have been
> > > returned if
> > > > > it was saved *before* you changed the min_id/max_id parameters.
> Could
> > > that be
> > > > > the case? Can you check if after removing the cache the entry still
> > > shows up?
> > > > >
> > > > > I think that the fact that the entry is returned from cache even
> if it
> > > > > should be filtered out is a bug:
> > > > > https://fedorahosted.org/sssd/ticket/1954
> > > >
> > > > So far we always maintained that if you consistently change
> > > > configuration (and a change of ranges is a big change) then it's on
> the
> > > > admin to wipe the cache file.
> > >
> > > Yes, that's why the ticket is minor. But mostly I don't like the
> > > inconsistency where some requests check the ranges even in the
> responder
> > > and some don't.
> > >
> > > ___
> > > Freeipa-users mailing list
> > > Freeipa-users@redhat.com
> > > 



-- 

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

[Freeipa-users] IPA Replica Issue

2013-06-05 Thread JR Aquino 
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
http://www.citrixonline.com


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

Re: [Freeipa-users] IPA Replica Issue

2013-06-05 Thread Rich Megginson 

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?

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=---))'




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
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

2013-06-05 Thread JR Aquino 
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
>> 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

2013-06-05 Thread Rich Megginson 

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.





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
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

2013-06-05 Thread JR Aquino 
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
 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] Ubunto client?

2013-06-05 Thread Timo Aaltonen 
On 06.06.2013 00:53, Guy Matz wrote:
> Hi!  Can anyone recommend a PPA that contains a freeIPA client that:
> 1. works

and what's wrong with the one I gave you on #ubuntu-freeipa?
(https://launchpad.net/~freeipa/+archive/ppa)

IOW, why ask here and not contact me directly.. especially since you
said the backport worked.

> 2. Also contains an openssh-server that uses AuthorizedKeysCommand

looks like it's quite fresh and in saucy:

https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/911747

no idea of a ppa with it

-- 
t

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

Re: [Freeipa-users] sudo rules user and host group bugs?

2013-06-05 Thread 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

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



Powering mobile workstyles and cloud services






___
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