Re: [Freeipa-users] SSSD client (amazon linux) + IPA server (Redhat)

2015-09-17 Thread Jakub Hrozek 
On Wed, Sep 16, 2015 at 11:28:49AM -0700, Gustavo Mateus wrote:
> Hi,
> 
> I have an IPA server running on redhat and I'm trying find the best way to
> get my amazon linux instances to use it for authentication, ssh key
> management and sudo rules.
> 
> I'm now trying to use SSSD to achieve those goals. Authentication is
> working but I'm having problems to get the user public ssh keys using
> /usr/bin/sss_ssh_authorizedkeys.
> 
> 
> This is my sssd.conf:
> 
> [sssd]
> services = nss, pam, ssh, sudo
> config_file_version = 2
> domains = default
> re_expression = (?P.+)
> 
> [domain/default]
> debug_level = 8
> cache_credentials = True
> id_provider = ldap
> auth_provider = ldap
> ldap_uri = ldap://ipa.my.domain.com
> ldap_search_base = cn=compat,dc=my,dc=domain,dc=com
> ldap_tls_cacert = /etc/openldap/cacerts/ipa.crt
> ldap_user_ssh_public_key = ipaSshPubKey
> 
> 
> The original configuration was done using ipa-advise ipa-advise
> config-redhat-sssd-before-1-9.

Is there any particular reason do keep doing this versus joining the
client to the domain and using id_provider=ipa ?

> I just hanged the services parameter to
> include "ssh, sudo" and "ldap_user_ssh_public_key"

I don't think sudo would work unless you authenticate the LDAP
connection.

> 
> When I run it on the client I get no response or error. Even running it in
> debug mode:
> 
> /usr/bin/sss_ssh_authorizedkeys admin --debug 10

I would check if:
- debug_level in the [ssh] section reveals anything. Is the ssh
  responder being contacted, are there any errors?
- check with ldbsearch (ldb-tools package) if there ssh key
  attribute is really fetched from IPA LDAP and is stored along the
  user entry

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] rhel 6.7 upgrade - sssd/sudo

2015-09-17 Thread Andy Thompson 
I've narrowed it down a bit doing some testing.  The sudo rules work when I 
remove the user group restriction from them.  My sudo rules all have my ad 
groups in the rule

  Rule name: ad_linux_admins
  Enabled: TRUE
  Host category: all
  Command category: all
  RunAs User category: all
  RunAs Group category: all
  User Groups: ad_linux_admins  <- if I remove this then the rule gets applied
  Sudo Option: !authenticate

-andy

> -Original Message-
> From: freeipa-users-boun...@redhat.com [mailto:freeipa-users-
> boun...@redhat.com] On Behalf Of Jakub Hrozek
> Sent: Tuesday, September 15, 2015 8:37 AM
> To: freeipa-users@redhat.com
> Subject: Re: [Freeipa-users] rhel 6.7 upgrade - sssd/sudo
> 
> Sorry for not replying sooner, many of us were mostly offline last week.
> 
> I'll try to reproduce locally..
> 
> On Tue, Sep 15, 2015 at 12:24:45PM +, Andy Thompson wrote:
> > I just updated several machines to RHEL 6.7 and seem to have broken my
> sudo rules.  I've tracked the problem down to having
> >
> > Default_domain_suffix = ad.domain
> >
> > In the sssd.conf.  If I remove that I can login using the fqn from AD and
> sudo rules are applied as configured.  However I don't want to force my users
> to change to using their fqn to login, and due to having db2 in the
> environment our usernames are limited to 8 characters so we cannot use the
> fqn regardless.
> >
> > I tested adding a local sudo rule for %ad_domain_group@ipa.domain and it
> worked, but any IPA rules are not working.  A rule in the sudoers would not
> work unless it was a fqn either which I expected with the default domain
> suffix set.
> >
> > Update installed sssd-1.12.4-47.el6.x86_64.  Redhat wants me to test
> downgrading my sssd, which I'm not entirely opposed to in order to get
> things working, but there are some fixes in this release I kinda want to keep.
> >
> > -andy
> >
> >
> >
> > *** This communication may contain privileged and/or confidential
> information. It is intended solely for the use of the addressee. If you are 
> not
> the intended recipient, you are strictly prohibited from disclosing, copying,
> distributing or using any of this information. If you received this
> communication in error, please contact the sender immediately and destroy
> the material in its entirety, whether electronic or hard copy. ***
> >
> >
> > --
> > Manage your subscription for the Freeipa-users mailing list:
> > https://www.redhat.com/mailman/listinfo/freeipa-users
> > Go to http://freeipa.org for more info on the project
> >
> >
> > *** This communication may contain privileged and/or confidential
> information. It is intended solely for the use of the addressee. If you are 
> not
> the intended recipient, you are strictly prohibited from disclosing, copying,
> distributing or using any of this information. If you received this
> communication in error, please contact the sender immediately and destroy
> the material in its entirety, whether electronic or hard copy. ***
> >
> >
> > --
> > Manage your subscription for the Freeipa-users mailing list:
> > https://www.redhat.com/mailman/listinfo/freeipa-users
> > Go to http://freeipa.org for more info on the project
> 
> --
> Manage your subscription for the Freeipa-users mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-users
> Go to http://freeipa.org for more info on the project

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Failed to start pki-tomcatd Service

2015-09-17 Thread Alexandre Ellert 
My FreeIPA  PKI is totally broken since upgrade from 3.0 (RHEL 6.6) to 4.1
(RHEL 7.1)
This thread started on July and still no resolution... Can someone please
advice ?
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] last step in retiring old RHEL 6 (IPA 3.0.0) servers

2015-09-17 Thread Petr Vobornik 

On 09/17/2015 01:15 PM, Martin Kosek wrote:

On 09/16/2015 06:54 PM, Craig White wrote:

Virtually completed the steps listed here...
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/migrating-ipa-proc.html

Managed to get IPA2 deleted and removed from 'ipa-replica-manage list' so now 
it is down to IPA1. No amount of effort will seem to kill that sucker off.

ipa-replica-manage del ipa1.stt.local --force
Connection to 'ipa1.stt.local' failed:
Forcing removal of ipa1.stt.local
Skipping calculation to determine if one or more masters would be orphaned.
No RUV records found.

$ ipa-replica-manage del ipa1.stt.local --force -c
Connection to 'ipa1.stt.local' failed:
Forcing removal of ipa1.stt.local
Skipping calculation to determine if one or more masters would be orphaned.
No RUV records found.

$ ipa-replica-manage list
ipa1.stt.local: master
ipa3.stt.local: master
ipa4.stt.local: master

Obviously connection to ipa1 failed because in previous step, I had to shut it 
down on ipa1 (ipactl stop)

What's the trick to get rid of an old, discontinued 'master' ?

Craig White


Quickly looking at ipa-replica-manage code, the del command will end if there
is no RUV. So it seems that in some of your previous RUV was deleted, but
server record was not.

What does
# ipa-replica-manage list-ruv
show?

Petr or Honza, is the only option here to
1) Use ldapdelete to delete the master record in cn=masters as a hotfix for
this issue


It will fix the replica manage output but replica cleanup does more 
things than just a removal of master entry. It also:

deletes services of the host
removes s4u2proxy configuration
removes some ACIs

More info:
https://git.fedorahosted.org/cgit/freeipa.git/tree/ipaserver/install/replication.py#n1185



2) File a ticket to avoid get_ruv function exit the whole "del" command when
--force is in play to fix this long-term


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







--
Petr Vobornik

--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] last step in retiring old RHEL 6 (IPA 3.0.0) servers

2015-09-17 Thread Martin Kosek 
On 09/16/2015 06:54 PM, Craig White wrote:
> Virtually completed the steps listed here...
> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/migrating-ipa-proc.html
> 
> Managed to get IPA2 deleted and removed from 'ipa-replica-manage list' so now 
> it is down to IPA1. No amount of effort will seem to kill that sucker off.
> 
> ipa-replica-manage del ipa1.stt.local --force
> Connection to 'ipa1.stt.local' failed:
> Forcing removal of ipa1.stt.local
> Skipping calculation to determine if one or more masters would be orphaned.
> No RUV records found.
> 
> $ ipa-replica-manage del ipa1.stt.local --force -c
> Connection to 'ipa1.stt.local' failed:
> Forcing removal of ipa1.stt.local
> Skipping calculation to determine if one or more masters would be orphaned.
> No RUV records found.
> 
> $ ipa-replica-manage list
> ipa1.stt.local: master
> ipa3.stt.local: master
> ipa4.stt.local: master
> 
> Obviously connection to ipa1 failed because in previous step, I had to shut 
> it down on ipa1 (ipactl stop)
> 
> What's the trick to get rid of an old, discontinued 'master' ?
> 
> Craig White

Quickly looking at ipa-replica-manage code, the del command will end if there
is no RUV. So it seems that in some of your previous RUV was deleted, but
server record was not.

What does
# ipa-replica-manage list-ruv
show?

Petr or Honza, is the only option here to
1) Use ldapdelete to delete the master record in cn=masters as a hotfix for
this issue
2) File a ticket to avoid get_ruv function exit the whole "del" command when
--force is in play to fix this long-term

>

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

[Freeipa-users] Cleanly Removing a Stubborn IPA Replica Server

2015-09-17 Thread Traiano Welcome 
Hi All

I'm trying to delete replication agreements between a 'master' ipa server and
a replica, but it seems the directory server has gotten into a state where the
replication agreements can't be removed (or some other stale meta-data is
still hanging around).

 (CentOS Linux release 7.1.1503, IPA VERSION: 4.1.0, API_VERSION: 2.112)

When I try to delete replication agreements between master and replica, I get:

---
[root@lolpr-idm-mstr ~]# ipa-replica-manage disconnect
lolsitepr-idm-slve.ipa.local
'lolpr-idm-mstr.ipa.local' has no replication agreement for
'lolsitepr-idm-slve.ipa.local'
---

However, attempts to re-add the replica with  ipa-replica-install ... fails
with "The host lolsitepr-idm-slve.ipa.local already exists on the master server"

Here is the process I'm following to try and delete the replication
agreements:

Try to disconnect the ipa master and replica:

---
[root@lolpr-idm-mstr ~]#
[root@lolpr-idm-mstr ~]# ipa-replica-manage disconnect
lolsitepr-idm-slve.ipa.local
'lolpr-idm-mstr.ipa.local' has no replication agreement for
'lolsitepr-idm-slve.ipa.local'
[root@lolpr-idm-mstr ~]#
---

After re-generating the new .gpg for the replica, copying it to the
ipa replica server, try to re-create the ipa replica:

---
[root@lolsitepr-idm-slve ~]#  ipa-replica-install --setup-ca
--setup-dns --no-forwarders
/var/lib/ipa/replica-info-lolsitepr-idm-slve.ipa.local.gpg
Directory Manager (existing master) password:

Run connection check to master
Check connection from replica to remote master 'lolpr-idm-mstr.ipa.local':
   Directory Service: Unsecure port (389): OK
   Directory Service: Secure port (636): OK
   Kerberos KDC: TCP (88): OK
   Kerberos Kpasswd: TCP (464): OK
   HTTP Server: Unsecure port (80): OK
   HTTP Server: Secure port (443): OK

The following list of ports use UDP protocol and would need to be
checked manually:
   Kerberos KDC: UDP (88): SKIPPED
   Kerberos Kpasswd: UDP (464): SKIPPED

Connection from replica to master is OK.
Start listening on required ports for remote master check
Get credentials to log in to remote master
admin@IDM.LOCAL password:

Check SSH connection to remote master
Execute check on remote master
Check connection from master to remote replica 'lolsitepr-idm-slve.ipa.local':
   Directory Service: Unsecure port (389): OK
   Directory Service: Secure port (636): OK
   Kerberos KDC: TCP (88): OK
   Kerberos KDC: UDP (88): OK
   Kerberos Kpasswd: TCP (464): OK
   Kerberos Kpasswd: UDP (464): OK
   HTTP Server: Unsecure port (80): OK
   HTTP Server: Secure port (443): OK

Connection from master to replica is OK.

Connection check OK
Using reverse zone(s) xxx.yy.zzz.in-addr.arpa.
The host lolsitepr-idm-slve.ipa.local already exists on the master server.
You should remove it before proceeding:
% ipa host-del lolsitepr-idm-slve.ipa.local
---

Trying to run "ipa host-del lolsitepr-idm-slve.ipa.local" on the
'master' replica server:

---
[root@lolpr-idm-mstr ~]# ipa host-del lolsitepr-idm-slve.ipa.local
ipa: ERROR: invalid 'hostname': An IPA master host cannot be deleted or disabled
[root@lolpr-idm-mstr ~]#
---

This makes no sense to me, are the differences in versions of IPA
between the two hosts? NO:

---

Replica:

[root@lolsitepr-idm-slve ~]# rpm -qa  |grep ipa
ipa-client-4.1.0-18.el7.centos.3.x86_64
ipa-server-trust-ad-4.1.0-18.el7.centos.3.x86_64
python-iniparse-0.4-9.el7.noarch
libipa_hbac-python-1.12.2-58.el7_1.6.x86_64
ipa-admintools-4.1.0-18.el7.centos.3.x86_64
sssd-ipa-1.12.2-58.el7_1.6.x86_64
iniparser-3.1-5.el7.x86_64
ipa-python-4.1.0-18.el7.centos.3.x86_64
ipa-server-4.1.0-18.el7.centos.3.x86_64
libipa_hbac-1.12.2-58.el7_1.6.x86_64

Master:

[root@lolpr-idm-mstr ~]# rpm -qa | grep ipa
ipa-client-4.1.0-18.el7.centos.3.x86_64
ipa-server-trust-ad-4.1.0-18.el7.centos.3.x86_64
iniparser-3.1-5.el7.x86_64
libipa_hbac-python-1.12.2-58.el7_1.6.x86_64
sssd-ipa-1.12.2-58.el7_1.6.x86_64
ipa-server-4.1.0-18.el7.centos.3.x86_64
python-iniparse-0.4-9.el7.noarch
ipa-python-4.1.0-18.el7.centos.3.x86_64
ipa-admintools-4.1.0-18.el7.centos.3.x86_64
libipa_hbac-1.12.2-58.el7_1.6.x86_64
---

So I tried using ipa-replica-manage disconnect:

---
[root@lolpr-idm-mstr ~]# ipa-replica-manage disconnect
lolsitepr-idm-slve.ipa.local
'lolpr-idm-mstr.ipa.local' has no replication agreement for
'lolsitepr-idm-slve.ipa.local'
---

[root@lolpr-idm-mstr ~]#
---

How do I force delete the replication agreements between the two hosts
in this case?

Thanks in advance for any help!

Traiano

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Red Hat 5 and 6 with IPA Client v. 4

2015-09-17 Thread Andrey Ptashnik 
Any ideas on that?

Regards,

Andrey Ptashnik | Network Architect
CCC Information Services Inc.
222 Merchandise Mart Plaza, Suite 900 Chicago, IL 60654
Office: +1-312-229-2533 | Cell : +1-773-315-0200 | aptash...@cccis.com







On 9/16/15, 11:30 AM, "freeipa-users-boun...@redhat.com on behalf of Andrey 
Ptashnik"  
wrote:

>Alexander,
>
>Thank you for your feedback!
>
>In my environment I noticed that client machines that are on Red Hat 6 have 
>version 3.0.0 of IPA client installed.
>
>[root@ptr-test-6 ~]# yum list installed | grep ipa
>ipa-client.x86_64  3.0.0-47.el6
>ipa-python.x86_64  3.0.0-47.el6
>
>
>[root@ptr-test-6 ~]# yum list installed | grep sssd
>python-sssdconfig.noarch   1.12.4-47.el6
>sssd.x86_641.12.4-47.el6
>sssd-ad.x86_64 1.12.4-47.el6
>sssd-client.x86_64 1.12.4-47.el6
>sssd-common.x86_64 1.12.4-47.el6
>sssd-common-pac.x86_64 1.12.4-47.el6
>sssd-ipa.x86_641.12.4-47.el6
>sssd-krb5.x86_64   1.12.4-47.el6
>sssd-krb5-common.x86_641.12.4-47.el6
>sssd-ldap.x86_64   1.12.4-47.el6
>sssd-proxy.x86_64  1.12.4-47.el6
>[root@ptr-test-6 ~]# 
>
>
>And I noticed particular behavior with IPA client 3.0.0 and IPA server 4.1 - 
>when I add machines to the domain using command below:
>
># ipa-client-install --enable-dns-updates --ssh-trust-dns —mkhomedir
>
>DNS record populate in Forward lookup zone, but no PTR records appear in 
>Reverse lookup zones. That behavior is not the same with IPA client 4.1 and 
>IPA server 4.1 version combination.
>
>Also during IPA client v. 3.0.0 configuration on version 6 of Red Hat I see 
>output below:
>
>Synchronizing time with KDC...
>Enrolled in IPA realm X.COM
>Attempting to get host TGT...
>Created /etc/ipa/default.conf
>New SSSD config will be created
>Configured sudoers in /etc/nsswitch.conf
>Configured /etc/sssd/sssd.conf
>Configured /etc/krb5.conf for IPA realm X.COM
>trying https://ipa-idm.X.COM/ipa/xml
>Forwarding 'env' to server u'https://ipa-idm.X.COM/ipa/xml'
>Failed to update DNS records.
>Adding SSH public key from /etc/ssh/ssh_host_rsa_key.pub
>Adding SSH public key from /etc/ssh/ssh_host_dsa_key.pub
>Forwarding 'host_mod' to server u'https://ipa-idm.X.COM/ipa/xml'
>SSSD enabled
>Configuring X.COM as NIS domain
>Configured /etc/openldap/ldap.conf
>NTP enabled
>Configured /etc/ssh/ssh_config
>Configured /etc/ssh/sshd_config
>Client configuration complete.
>
>
>Regards,
>
>Andrey Ptashnik
>
>
>
>
>
>
>On 9/16/15, 8:43 AM, "Alexander Bokovoy"  wrote:
>
>>On Wed, 16 Sep 2015, Andrey Ptashnik wrote:
>>>Dear IPA Team,
>>>
>>>We have a situation in our datacenter where we deployed Red Hat 7.1
>>>with IPA server 4.1 and on the other hand we still have older machines
>>>with Red Hat 5 and 6. I noticed that repositories associated with
>>>version 6 have older version of the client software – v.3.0. Therefore
>>>some functionality is missing from client package 3 vs 4, like
>>>automatic update of both forward and reverse DNS records.
>>>
>>>Is it possible to install IPA client v. 4 on Red Hat 5 and 6 without
>>>much breaking dependencies in OS?
>>You don't need to install IPA python packages on older machines. These
>>packages are mostly for administration purposes.
>>
>>Automatic update of forward/reverse DNS zones is done by SSSD. RHEL 6
>>version of SSSD is on par with RHEL 7 version in the recent updates.
>>Additionally, MIT Kerberos backports were done in the recent updates to
>>allow OTP functionality in RHEL6 as well. So most of features are there
>>already, client-wise.
>>
>>RHEL5 version does not have such updates and you can implement most of
>>the support with existing SSSD and output of 'ipa-advise' tool on IPA
>>masters. nsupdate integration would probably need to be done
>>differently.
>>
>>Backporting IPA v4.x client code to RHEL 5 or 6 in general makes not
>>much sense.
>>
>>-- 
>>/ Alexander Bokovoy
>
>-- 
>Manage your subscription for the Freeipa-users mailing list:
>https://www.redhat.com/mailman/listinfo/freeipa-users
>Go to http://freeipa.org for more info on the project

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Red Hat 5 and 6 with IPA Client v. 4

2015-09-17 Thread Rob Crittenden 
Andrey Ptashnik wrote:
> Any ideas on that?

/var/log/ipaclient-install.log probably has more details on the DNS
update failure.

rob

> 
> Regards,
> 
> Andrey Ptashnik | Network Architect
> CCC Information Services Inc.
> 222 Merchandise Mart Plaza, Suite 900 Chicago, IL 60654
> Office: +1-312-229-2533 | Cell : +1-773-315-0200 | aptash...@cccis.com
> 
> 
> 
> 
> 
> 
> 
> On 9/16/15, 11:30 AM, "freeipa-users-boun...@redhat.com on behalf of Andrey 
> Ptashnik"  
> wrote:
> 
>> Alexander,
>>
>> Thank you for your feedback!
>>
>> In my environment I noticed that client machines that are on Red Hat 6 have 
>> version 3.0.0 of IPA client installed.
>>
>> [root@ptr-test-6 ~]# yum list installed | grep ipa
>> ipa-client.x86_64  3.0.0-47.el6
>> ipa-python.x86_64  3.0.0-47.el6
>>
>>
>> [root@ptr-test-6 ~]# yum list installed | grep sssd
>> python-sssdconfig.noarch   1.12.4-47.el6
>> sssd.x86_641.12.4-47.el6
>> sssd-ad.x86_64 1.12.4-47.el6
>> sssd-client.x86_64 1.12.4-47.el6
>> sssd-common.x86_64 1.12.4-47.el6
>> sssd-common-pac.x86_64 1.12.4-47.el6
>> sssd-ipa.x86_641.12.4-47.el6
>> sssd-krb5.x86_64   1.12.4-47.el6
>> sssd-krb5-common.x86_641.12.4-47.el6
>> sssd-ldap.x86_64   1.12.4-47.el6
>> sssd-proxy.x86_64  1.12.4-47.el6
>> [root@ptr-test-6 ~]# 
>>
>>
>> And I noticed particular behavior with IPA client 3.0.0 and IPA server 4.1 - 
>> when I add machines to the domain using command below:
>>
>> # ipa-client-install --enable-dns-updates --ssh-trust-dns —mkhomedir
>>
>> DNS record populate in Forward lookup zone, but no PTR records appear in 
>> Reverse lookup zones. That behavior is not the same with IPA client 4.1 and 
>> IPA server 4.1 version combination.
>>
>> Also during IPA client v. 3.0.0 configuration on version 6 of Red Hat I see 
>> output below:
>>
>> Synchronizing time with KDC...
>> Enrolled in IPA realm X.COM
>> Attempting to get host TGT...
>> Created /etc/ipa/default.conf
>> New SSSD config will be created
>> Configured sudoers in /etc/nsswitch.conf
>> Configured /etc/sssd/sssd.conf
>> Configured /etc/krb5.conf for IPA realm X.COM
>> trying https://ipa-idm.X.COM/ipa/xml
>> Forwarding 'env' to server u'https://ipa-idm.X.COM/ipa/xml'
>> Failed to update DNS records.
>> Adding SSH public key from /etc/ssh/ssh_host_rsa_key.pub
>> Adding SSH public key from /etc/ssh/ssh_host_dsa_key.pub
>> Forwarding 'host_mod' to server u'https://ipa-idm.X.COM/ipa/xml'
>> SSSD enabled
>> Configuring X.COM as NIS domain
>> Configured /etc/openldap/ldap.conf
>> NTP enabled
>> Configured /etc/ssh/ssh_config
>> Configured /etc/ssh/sshd_config
>> Client configuration complete.
>>
>>
>> Regards,
>>
>> Andrey Ptashnik
>>
>>
>>
>>
>>
>>
>> On 9/16/15, 8:43 AM, "Alexander Bokovoy"  wrote:
>>
>>> On Wed, 16 Sep 2015, Andrey Ptashnik wrote:
 Dear IPA Team,

 We have a situation in our datacenter where we deployed Red Hat 7.1
 with IPA server 4.1 and on the other hand we still have older machines
 with Red Hat 5 and 6. I noticed that repositories associated with
 version 6 have older version of the client software – v.3.0. Therefore
 some functionality is missing from client package 3 vs 4, like
 automatic update of both forward and reverse DNS records.

 Is it possible to install IPA client v. 4 on Red Hat 5 and 6 without
 much breaking dependencies in OS?
>>> You don't need to install IPA python packages on older machines. These
>>> packages are mostly for administration purposes.
>>>
>>> Automatic update of forward/reverse DNS zones is done by SSSD. RHEL 6
>>> version of SSSD is on par with RHEL 7 version in the recent updates.
>>> Additionally, MIT Kerberos backports were done in the recent updates to
>>> allow OTP functionality in RHEL6 as well. So most of features are there
>>> already, client-wise.
>>>
>>> RHEL5 version does not have such updates and you can implement most of
>>> the support with existing SSSD and output of 'ipa-advise' tool on IPA
>>> masters. nsupdate integration would probably need to be done
>>> differently.
>>>
>>> Backporting IPA v4.x client code to RHEL 5 or 6 in general makes not
>>> much sense.
>>>
>>> -- 
>>> / Alexander Bokovoy
>>
>> -- 
>> Manage your subscription for the Freeipa-users mailing list:
>> https://www.redhat.com/mailman/listinfo/freeipa-users
>> Go to http://freeipa.org for more info on the project
> 

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] last step in retiring old RHEL 6 (IPA 3.0.0) servers

2015-09-17 Thread Craig White 
-Original Message-
From: Petr Vobornik [mailto:pvobo...@redhat.com] 
Sent: Thursday, September 17, 2015 4:59 AM
To: Martin Kosek; Craig White; freeipa-users@redhat.com; Jan Cholasta
Subject: Re: [Freeipa-users] last step in retiring old RHEL 6 (IPA 3.0.0) 
servers

On 09/17/2015 01:15 PM, Martin Kosek wrote:
> On 09/16/2015 06:54 PM, Craig White wrote:
>> Virtually completed the steps listed here...
>> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linu
>> x/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/migrat
>> ing-ipa-proc.html
>>
>> Managed to get IPA2 deleted and removed from 'ipa-replica-manage list' so 
>> now it is down to IPA1. No amount of effort will seem to kill that sucker 
>> off.
>>
>> ipa-replica-manage del ipa1.stt.local --force Connection to 
>> 'ipa1.stt.local' failed:
>> Forcing removal of ipa1.stt.local
>> Skipping calculation to determine if one or more masters would be orphaned.
>> No RUV records found.
>>
>> $ ipa-replica-manage del ipa1.stt.local --force -c Connection to 
>> 'ipa1.stt.local' failed:
>> Forcing removal of ipa1.stt.local
>> Skipping calculation to determine if one or more masters would be orphaned.
>> No RUV records found.
>>
>> $ ipa-replica-manage list
>> ipa1.stt.local: master
>> ipa3.stt.local: master
>> ipa4.stt.local: master
>>
>> Obviously connection to ipa1 failed because in previous step, I had 
>> to shut it down on ipa1 (ipactl stop)
>>
>> What's the trick to get rid of an old, discontinued 'master' ?
>>
>> Craig White
>
> Quickly looking at ipa-replica-manage code, the del command will end 
> if there is no RUV. So it seems that in some of your previous RUV was 
> deleted, but server record was not.
>
> What does
> # ipa-replica-manage list-ruv
> show?
>
> Petr or Honza, is the only option here to
> 1) Use ldapdelete to delete the master record in cn=masters as a 
> hotfix for this issue

It will fix the replica manage output but replica cleanup does more things than 
just a removal of master entry. It also:
 deletes services of the host
 removes s4u2proxy configuration
 removes some ACIs

More info:
https://git.fedorahosted.org/cgit/freeipa.git/tree/ipaserver/install/replication.py#n1185


> 2) File a ticket to avoid get_ruv function exit the whole "del" 
> command when --force is in play to fix this long-term

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

OK - I think I see the LDAP entries and just wanting confirmation before I do 
great harm  :-)

Dn: cn=ipa1.stt.local,cn=masters,cn=ipa,cn=etc,dc=stt,dc=local
Dn: cn=ipa-http-delegation,cn=s4u2proxy,cn=etc,dc=stt,dc=local - attribute 
memberPrincipal ipa1_ETC
Dn: cn=ipa-ldap-delegation-targets,cn=s4u2proxy,cn=etc,dc=stt,dc=local - 
attribute memberPrincipal ipa1_ETC

The one DN and the 2 attributes are what I should delete to get rid of this 
dead master?

Rummaging around, I do see other hanging chads (pardon the election season 
humor)...

DN: dnaHostname ipa1.stt.local + 0,cn=posix-ids,cn=dna,cn=etc,dc=stt,dc=local 
(that is apparently 'dnaPortNum 0 and dnaSecurePortNum 636)
DN: dnaHostname ipa1.stt.local + 389,cn=posix-ids,cn=dna,cn=etc,dc=stt,dc=local 
(that is apparently 'dnaPortNum 389 and dnaSecurePortNum 636)

And if I were to delete the first one, there wouldn't be any entries pointing 
to port '0' but that just looks strange to me anyway. If I delete both the 
above, then all that is left is just the 2 new RHEL 7 IPA/iDM servers on ports 
389/636 which seems right to me.

If there are actual ACI's to edit, I am afraid I don't have a tool to do that 
very easily.

Thanks

Craig

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Missing data encountered + Incremental update failed and requires administrator action

2015-09-17 Thread Benjamin Reed 
Sorry it's taken a while to get back to you, I was gone for a few
weeks.  This seemed to get us back up and running and things looked like
they were working, but looking at the logs, it appears we're hitting the
next issue that is going to eventually bite us.  :)

Here's what I'm seeing in the logs:

> [15/Sep/2015:08:57:29 -0400] ipalockout_postop - [file ipa_lockout.c,
> line 503]: Failed to retrieve entry "david": 32
> [15/Sep/2015:09:56:20 -0400] ipalockout_preop - [file ipa_lockout.c,
> line 749]: Failed to retrieve entry "emily": 32
> [15/Sep/2015:09:56:20 -0400] ipalockout_postop - [file ipa_lockout.c,
> line 503]: Failed to retrieve entry "emily": 32
> [15/Sep/2015:11:50:34 -0400] ldbm_back_delete - conn=0 op=0 [retry: 1]
> No original_tombstone for changenumber=102502,cn=changelog!!
> [15/Sep/2015:12:02:19 -0400] ipalockout_preop - [file ipa_lockout.c,
> line 749]: Failed to retrieve entry "tina": 32
> [15/Sep/2015:12:02:19 -0400] ipalockout_postop - [file ipa_lockout.c,
> line 503]: Failed to retrieve entry "tina": 32

I've found some references to this stuff in google searches, but I'm not
real clear on what the implications are, nor how to go about
understanding it well enough to know the right fix.

There are two hosts (ipa and ipa2).  These logs are from the "ipa"
server, the one I had to rebuild.  I do eventually get this:

> [15/Sep/2015:12:58:46 -0400] NSMMReplicationPlugin -
> agmt="cn=meToipa2.XXX" (ipa2:389): Replication bind with GSSAPI auth
> resumed

...but the original_tombstone thing makes me thing something is still
not in sync.

Any clues as to what else I might need to do to make sure this server is
back in 100% working order?

Thanks,
Ben

On 8/24/15 2:42 AM, Martin Kosek wrote:
>> > I fear this means that something is still not properly in sync and will
>> > eventually come back to bite me.  Any ideas what's going on here, and
>> > how to fix it?
> Yup, this looks as something that can eventually bite you. It looks like your
> replica's CA database got somehow corrupted and stopped replicating with other
> master. This could lead to outdated data on the replica, like certificates,
> CRL, etc.
>
> You can re-initialize the Dogtag database from other healthy master with CA,
> using "ipa-csreplica-manage" command. Some advise should be for example here:
>
> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/managing-topology.html#initialize
>
> (Note that we need "ipa-csreplica-manage" in this case, as the reported faulty
> agreement is Dogtag/CA agreement)

-- 
Benjamin Reed
The OpenNMS Group
http://www.opennms.org/



-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

[Freeipa-users] Announcing FreeIPA 4.2.1

2015-09-17 Thread Petr Vobornik 

The FreeIPA team would like to announce FreeIPA v4.2.1 bug fixing release!

It can be downloaded from http://www.freeipa.org/page/Downloads. The 
builds are available for Fedora 23 and rawhide. Builds for Fedora 22 are 
available in the official COPR repository 
.


This announcement is also available at 
.


== Highlights in 4.2.1 ==
=== Enhancements ===
* Added support for multiple IP addresses during client installation

=== Bug fixes ===
* Various fixes for new Vault feature
* Various fixes for new Certificates Profiles feature
* Fixed ACI issue in search for hbac rules, sudo rules, users and other 
IPA objects by non-admin users

* Backup and restore fixes, mostly related to DNSSEC
* ipa-client-install is able to request a certificate in kickstart 
environment

* Fixed server upgrade failure in "Enabling KDC proxy" step
* Added option to establish bidirectional trust in Web UI

== Upgrading ==
Upgrade instructions are available on Upgrade page 
.


== Feedback ==
Please provide comments, bugs and other feedback via the freeipa-users 
mailing list (http://www.redhat.com/mailman/listinfo/freeipa-users) or 
#freeipa channel on Freenode.


== Detailed Changelog since 4.2.0 ==

=== Alexander Bokovoy (5) ===
* selinux: enable httpd_run_ipa to allow communicating with oddjobd services
* oddjob: avoid chown keytab to sssd if sssd user does not exist
* Fix selector of protocol for LSA RPC binding string
* trusts: harden trust-fetch-domains oddjobd-based script
* trusts: format Kerberos principal properly when fetching trust topology

=== Christian Heimes (10) ===
* Start dirsrv for kdcproxy upgrade
* Fix selinux denial during kdcproxy user creation
* certprofile-import: improve profile format documentation
* otptoken: use ipapython.nsslib instead of Python's ssl module
* Require Dogtag PKI >= 10.2.6
* Validate vault's file parameters
* certprofile-import: do not require profileId in profile data
* Asymmetric vault: validate public key in client
* Add flag to list all service and user vaults
* Change internal rsa_(public|private)_key variable names

=== David Kupka (9) ===
* migration: Use api.env variables.
* cermonger: Use private unix socket when DBus SystemBus is not available.
* ipa-client-install: Do not (re)start certmonger and DBus daemons.
* user-undel: Fix error messages.
* client: Add support for multiple IP addresses during installation.
* client: Add description of --ip-address and --all-ip-addresses to man page
* Backup/resore authentication control configuration
* vault: Limit size of data stored in vault
* ipactl: Do not start/stop/restart single service multiple times

=== Endi Sukma Dewata (6) ===
* Fixed missing KRA agent cert on replica.
* Added CLI param and ACL for vault service operations.
* Fixed vault container ownership.
* Added support for changing vault encryption.
* Removed clear text passwords from KRA install log.
* Using LDAPI to setup CA and KRA agents.

=== Fraser Tweedale (14) ===
* user-show: add --out option to save certificates to file
* Fix otptoken-remove-managedby command summary
* Give more info on virtual command access denial
* Allow SAN extension for cert-request self-service
* Add profile for DNP3 / IEC 62351-8 certificates
* Work around python-nss bug on unrecognised OIDs
* Fix default CA ACL added during upgrade
* Fix KRB5PrincipalName / UPN SAN comparison
* certprofile: add profile format explanation
* Add permission for bypassing CA ACL enforcement
* Prohibit deletion of predefined profiles
* cert-request: remove allowed extensions check
* certprofile: prevent rename (modrdn)
* certprofile: remove 'rename' option

=== Jan Cholasta (14) ===
* spec file: Move /etc/ipa/kdcproxy to the server subpackage
* spec file: Update minimum required version of krb5
* install: Fix server and replica install options
* ULC: Prevent preserved users from being assigned membership
* spec file: Fix install with the server-dns subpackage
* baseldap: Allow overriding member param label in LDAPModMember
* vault: Fix param labels in output of vault owner commands
* install: Fix replica install with custom certificates
* vault: Fix vault-find with criteria
* vault: Add container information to vault command results
* spec file: Add Requires(post) on selinux-policy
* cert renewal: Include KRA users in Dogtag LDAP update
* cert renewal: Automatically update KRA agent PEM file
* ldap: Make ldap2 connection management thread-safe again

=== Lenka Doudova (2) ===
* Automated test for stageuser plugin
* Fix user tracker to reflect new user-del message

=== Martin Babinsky (12) ===
* ipa-ca-install: print more specific errors when CA is already installed
* enable debugging of ntpd during client installation
* fix broken search for users by their manager
* ACI plugin: correctly parse bind rules enclosed in parentheses
* test suite for user/host/service

Re: [Freeipa-users] Red Hat 5 and 6 with IPA Client v. 4

2015-09-17 Thread Martin Basti 



On 09/16/2015 06:30 PM, Andrey Ptashnik wrote:

Alexander,

Thank you for your feedback!

In my environment I noticed that client machines that are on Red Hat 6 have 
version 3.0.0 of IPA client installed.

[root@ptr-test-6 ~]# yum list installed | grep ipa
ipa-client.x86_64  3.0.0-47.el6
ipa-python.x86_64  3.0.0-47.el6


[root@ptr-test-6 ~]# yum list installed | grep sssd
python-sssdconfig.noarch   1.12.4-47.el6
sssd.x86_641.12.4-47.el6
sssd-ad.x86_64 1.12.4-47.el6
sssd-client.x86_64 1.12.4-47.el6
sssd-common.x86_64 1.12.4-47.el6
sssd-common-pac.x86_64 1.12.4-47.el6
sssd-ipa.x86_641.12.4-47.el6
sssd-krb5.x86_64   1.12.4-47.el6
sssd-krb5-common.x86_641.12.4-47.el6
sssd-ldap.x86_64   1.12.4-47.el6
sssd-proxy.x86_64  1.12.4-47.el6
[root@ptr-test-6 ~]#


And I noticed particular behavior with IPA client 3.0.0 and IPA server 4.1 - 
when I add machines to the domain using command below:

# ipa-client-install --enable-dns-updates --ssh-trust-dns —mkhomedir

DNS record populate in Forward lookup zone, but no PTR records appear in 
Reverse lookup zones. That behavior is not the same with IPA client 4.1 and IPA 
server 4.1 version combination.


Do you have enables PTR sync in forward zone configuration and do you 
have allowed dynamic updates for reverse zones?


How does the ipa41 client work, does it populate PTR record?



Also during IPA client v. 3.0.0 configuration on version 6 of Red Hat I see 
output below:

Synchronizing time with KDC...
Enrolled in IPA realm X.COM
Attempting to get host TGT...
Created /etc/ipa/default.conf
New SSSD config will be created
Configured sudoers in /etc/nsswitch.conf
Configured /etc/sssd/sssd.conf
Configured /etc/krb5.conf for IPA realm X.COM
trying https://ipa-idm.X.COM/ipa/xml
Forwarding 'env' to server u'https://ipa-idm.X.COM/ipa/xml'
Failed to update DNS records.
Adding SSH public key from /etc/ssh/ssh_host_rsa_key.pub
Adding SSH public key from /etc/ssh/ssh_host_dsa_key.pub
Forwarding 'host_mod' to server u'https://ipa-idm.X.COM/ipa/xml'
SSSD enabled
Configuring X.COM as NIS domain
Configured /etc/openldap/ldap.conf
NTP enabled
Configured /etc/ssh/ssh_config
Configured /etc/ssh/sshd_config
Client configuration complete.


Regards,

Andrey Ptashnik






On 9/16/15, 8:43 AM, "Alexander Bokovoy"  wrote:


On Wed, 16 Sep 2015, Andrey Ptashnik wrote:

Dear IPA Team,

We have a situation in our datacenter where we deployed Red Hat 7.1
with IPA server 4.1 and on the other hand we still have older machines
with Red Hat 5 and 6. I noticed that repositories associated with
version 6 have older version of the client software – v.3.0. Therefore
some functionality is missing from client package 3 vs 4, like
automatic update of both forward and reverse DNS records.

Is it possible to install IPA client v. 4 on Red Hat 5 and 6 without
much breaking dependencies in OS?

You don't need to install IPA python packages on older machines. These
packages are mostly for administration purposes.

Automatic update of forward/reverse DNS zones is done by SSSD. RHEL 6
version of SSSD is on par with RHEL 7 version in the recent updates.
Additionally, MIT Kerberos backports were done in the recent updates to
allow OTP functionality in RHEL6 as well. So most of features are there
already, client-wise.

RHEL5 version does not have such updates and you can implement most of
the support with existing SSSD and output of 'ipa-advise' tool on IPA
masters. nsupdate integration would probably need to be done
differently.

Backporting IPA v4.x client code to RHEL 5 or 6 in general makes not
much sense.

--
/ Alexander Bokovoy


--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] SSSD client (amazon linux) + IPA server (Redhat)

2015-09-17 Thread Gustavo Mateus 
When I use id_provider=ipa I get:

[sssd[be[default]]] [main] (0x0010): Could not initialize backend [2]


Adding a [ssh] section with just "debug_level = 10"on it, I get:

(Thu Sep 17 17:27:12 2015) [sssd[ssh]] [get_client_cred] (0x4000): Client
creds: euid[174221] egid[174221] pid[6295].
(Thu Sep 17 17:27:12 2015) [sssd[ssh]] [reset_idle_timer] (0x4000): Idle
timer re-set for client [0xd34eb0][17]
(Thu Sep 17 17:27:12 2015) [sssd[ssh]] [accept_fd_handler] (0x0400): Client
connected!
(Thu Sep 17 17:27:12 2015) [sssd[ssh]] [reset_idle_timer] (0x4000): Idle
timer re-set for client [0xd34eb0][17]
(Thu Sep 17 17:27:12 2015) [sssd[ssh]] [sss_cmd_get_version] (0x0200):
Received client version [0].
(Thu Sep 17 17:27:12 2015) [sssd[ssh]] [sss_cmd_get_version] (0x0200):
Offered version [0].
(Thu Sep 17 17:27:12 2015) [sssd[ssh]] [reset_idle_timer] (0x4000): Idle
timer re-set for client [0xd34eb0][17]
(Thu Sep 17 17:27:12 2015) [sssd[ssh]] [reset_idle_timer] (0x4000): Idle
timer re-set for client [0xd34eb0][17]
(Thu Sep 17 17:27:12 2015) [sssd[ssh]] [ssh_cmd_parse_request] (0x0400):
Requested domain []
(Thu Sep 17 17:27:12 2015) [sssd[ssh]] [ssh_cmd_parse_request] (0x0400):
Parsing name [admin][]
(Thu Sep 17 17:27:12 2015) [sssd[ssh]] [sss_parse_name] (0x0100): Domain
not provided!
(Thu Sep 17 17:27:12 2015) [sssd[ssh]] [sss_parse_name_for_domains]
(0x0200): name 'admin' matched without domain, user is admin
(Thu Sep 17 17:27:12 2015) [sssd[ssh]] [sss_ssh_cmd_get_user_pubkeys]
(0x0400): Requesting SSH user public keys for [admin] from []
(Thu Sep 17 17:27:12 2015) [sssd[ssh]] [sss_dp_issue_request] (0x0400):
Issuing request for [0x40aba0:1:admin@default]
(Thu Sep 17 17:27:12 2015) [sssd[ssh]] [sss_dp_get_account_msg] (0x0400):
Creating request for [default][1][1][name=admin]
(Thu Sep 17 17:27:12 2015) [sssd[ssh]] [sbus_add_timeout] (0x2000): 0xd32ba0
(Thu Sep 17 17:27:12 2015) [sssd[ssh]] [sss_dp_internal_get_send] (0x0400):
Entering request [0x40aba0:1:admin@default]
(Thu Sep 17 17:27:12 2015) [sssd[ssh]] [sbus_remove_timeout] (0x2000):
0xd32ba0
(Thu Sep 17 17:27:12 2015) [sssd[ssh]] [sbus_dispatch] (0x4000): dbus conn:
0xd310f0
(Thu Sep 17 17:27:12 2015) [sssd[ssh]] [sbus_dispatch] (0x4000):
Dispatching.
(Thu Sep 17 17:27:12 2015) [sssd[ssh]] [sss_dp_get_reply] (0x1000): Got
reply from Data Provider - DP error code: 0 errno: 0 error message: Success
(Thu Sep 17 17:27:12 2015) [sssd[ssh]] [ssh_user_pubkeys_search_next]
(0x0400): Requesting SSH user public keys for [admin@default]
(Thu Sep 17 17:27:12 2015) [sssd[ssh]] [sss_parse_name] (0x0100): Domain
not provided!
(Thu Sep 17 17:27:12 2015) [sssd[ssh]] [ldb] (0x4000): Added timed event
"ltdb_callback": 0xd3f3b0

(Thu Sep 17 17:27:12 2015) [sssd[ssh]] [ldb] (0x4000): Added timed event
"ltdb_timeout": 0xd3f470

(Thu Sep 17 17:27:12 2015) [sssd[ssh]] [ldb] (0x4000): Running timer event
0xd3f3b0 "ltdb_callback"

(Thu Sep 17 17:27:12 2015) [sssd[ssh]] [ldb] (0x4000): Destroying timer
event 0xd3f470 "ltdb_timeout"

(Thu Sep 17 17:27:12 2015) [sssd[ssh]] [ldb] (0x4000): Ending timer event
0xd3f3b0 "ltdb_callback"

(Thu Sep 17 17:27:12 2015) [sssd[ssh]] [sss_dp_req_destructor] (0x0400):
Deleting request: [0x40aba0:1:admin@default]
(Thu Sep 17 17:27:12 2015) [sssd[ssh]] [reset_idle_timer] (0x4000): Idle
timer re-set for client [0xd34eb0][17]
(Thu Sep 17 17:27:12 2015) [sssd[ssh]] [reset_idle_timer] (0x4000): Idle
timer re-set for client [0xd34eb0][17]
(Thu Sep 17 17:27:12 2015) [sssd[ssh]] [client_recv] (0x0200): Client
disconnected!
(Thu Sep 17 17:27:12 2015) [sssd[ssh]] [client_destructor] (0x2000):
Terminated client [0xd34eb0][17]




ldbsearch shows this (ldbsearch -H /var/lib/sss/db/cache_default.ldb
name=admin):


asq: Unable to register control with rootdse!
# record 1
dn: name=admin,cn=users,cn=default,cn=sysdb
createTimestamp: 1442509579
fullName: Administrator
gecos: Administrator
gidNumber: 174220
homeDirectory: /home/admin
loginShell: /bin/bash
name: admin
objectClass: user
uidNumber: 174220
originalDN: uid=admin,cn=users,cn=compat,dc=my,dc=domain,dc=com
originalModifyTimestamp: 20150829000451Z
entryUSN: 1428
lastUpdate: 1442509579
dataExpireTimestamp: 1442514979
distinguishedName: name=admin,cn=users,cn=default,cn=sysdb

# returned 1 records
# 1 entries
# 0 referrals




Thanks,
Gustavo





On Thu, Sep 17, 2015 at 12:25 AM, Jakub Hrozek  wrote:

> On Wed, Sep 16, 2015 at 11:28:49AM -0700, Gustavo Mateus wrote:
> > Hi,
> >
> > I have an IPA server running on redhat and I'm trying find the best way
> to
> > get my amazon linux instances to use it for authentication, ssh key
> > management and sudo rules.
> >
> > I'm now trying to use SSSD to achieve those goals. Authentication is
> > working but I'm having problems to get the user public ssh keys using
> > /usr/bin/sss_ssh_authorizedkeys.
> >
> >
> > This is my sssd.conf:
> >
> > [sssd]
> > services = nss, pam, ssh, sudo
> > config_file_version = 2
> > domains = default
> >

[Freeipa-users] 4.1 -> 4.2

2015-09-17 Thread Janelle 
Here is an interesting problem. Currently running 4.1 on RHEL 7.1 -- I 
would like to migrate to 4.2, but that seems to only be running on 
Fedora these days.  Is there a way to bring up a 4.2.1c and migrate to 
it from 4.1c using the ipa migrate tool? Or is theree another way possible??


thank you
~Janelle

--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] 4.1 -> 4.2

2015-09-17 Thread Alexander Bokovoy 

On Thu, 17 Sep 2015, Janelle wrote:
Here is an interesting problem. Currently running 4.1 on RHEL 7.1 -- I 
would like to migrate to 4.2, but that seems to only be running on 
Fedora these days.  Is there a way to bring up a 4.2.1c and migrate to 
it from 4.1c using the ipa migrate tool? Or is theree another way 
possible??

Just wait for RHEL 7.2 release. Beta version is already out and it
includes IPA 4.2.

http://red.ht/1i65UND

--
/ Alexander Bokovoy

--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Missing data encountered + Incremental update failed and requires administrator action

2015-09-17 Thread Martin Kosek 

On 09/17/2015 04:48 PM, Benjamin Reed wrote:

Sorry it's taken a while to get back to you, I was gone for a few
weeks.  This seemed to get us back up and running and things looked like
they were working, but looking at the logs, it appears we're hitting the
next issue that is going to eventually bite us.  :)

Here's what I'm seeing in the logs:


[15/Sep/2015:08:57:29 -0400] ipalockout_postop - [file ipa_lockout.c,
line 503]: Failed to retrieve entry "david": 32
[15/Sep/2015:09:56:20 -0400] ipalockout_preop - [file ipa_lockout.c,
line 749]: Failed to retrieve entry "emily": 32
[15/Sep/2015:09:56:20 -0400] ipalockout_postop - [file ipa_lockout.c,
line 503]: Failed to retrieve entry "emily": 32
[15/Sep/2015:11:50:34 -0400] ldbm_back_delete - conn=0 op=0 [retry: 1]
No original_tombstone for changenumber=102502,cn=changelog!!
[15/Sep/2015:12:02:19 -0400] ipalockout_preop - [file ipa_lockout.c,
line 749]: Failed to retrieve entry "tina": 32
[15/Sep/2015:12:02:19 -0400] ipalockout_postop - [file ipa_lockout.c,
line 503]: Failed to retrieve entry "tina": 32


I've found some references to this stuff in google searches, but I'm not
real clear on what the implications are, nor how to go about
understanding it well enough to know the right fix.


This is https://fedorahosted.org/freeipa/ticket/4889. So it should be benign, 
it just seems that some software of yours is using user name instead of DN to 
log user in. More info in the ticket.




There are two hosts (ipa and ipa2).  These logs are from the "ipa"
server, the one I had to rebuild.  I do eventually get this:


[15/Sep/2015:12:58:46 -0400] NSMMReplicationPlugin -
agmt="cn=meToipa2.XXX" (ipa2:389): Replication bind with GSSAPI auth
resumed


...but the original_tombstone thing makes me thing something is still
not in sync.


This message is actually OK, it means replication plugin was connected. Not 
sure about the tombstone though, if you are still hitting issues, I would 
suggest including bigger chunk of your server logs.



Any clues as to what else I might need to do to make sure this server is
back in 100% working order?

Thanks,
Ben

On 8/24/15 2:42 AM, Martin Kosek wrote:

I fear this means that something is still not properly in sync and will
eventually come back to bite me.  Any ideas what's going on here, and
how to fix it?

Yup, this looks as something that can eventually bite you. It looks like your
replica's CA database got somehow corrupted and stopped replicating with other
master. This could lead to outdated data on the replica, like certificates,
CRL, etc.

You can re-initialize the Dogtag database from other healthy master with CA,
using "ipa-csreplica-manage" command. Some advise should be for example here:

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/managing-topology.html#initialize

(Note that we need "ipa-csreplica-manage" in this case, as the reported faulty
agreement is Dogtag/CA agreement)




--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] 4.1 -> 4.2

2015-09-17 Thread Janelle 

thank you - just downloaded the beta to check it out.

~J

On 9/17/15 10:20 AM, Alexander Bokovoy wrote:

On Thu, 17 Sep 2015, Janelle wrote:
Here is an interesting problem. Currently running 4.1 on RHEL 7.1 -- 
I would like to migrate to 4.2, but that seems to only be running on 
Fedora these days.  Is there a way to bring up a 4.2.1c and migrate 
to it from 4.1c using the ipa migrate tool? Or is theree another way 
possible??

Just wait for RHEL 7.2 release. Beta version is already out and it
includes IPA 4.2.

http://red.ht/1i65UND



--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

[Freeipa-users] user delete command hangs kdc and ldap stop responding

2015-09-17 Thread HECTOR LOPEZ 
This is rhel 7.1 with ipa version 4.1.0

user-show shows the user. However, if the user contains
ipaNTSecurityIdentifier: attribute, user-del hangs with no response.

Meanwhile, the KDC and 389ds stop working. The only way to recover
functionality is to reboot the machine.  ipactl restart does nothing.

In the ldap access log I see this when trying to delete user sclown:

[14/Sep/2015:09:28:27 -0700] conn=326 op=18 RESULT err=0 tag=101 nentries=0
etime=0
[14/Sep/2015:09:28:27 -0700] conn=326 op=19 DEL
dn="uid=sclown,cn=users,cn=accounts,dc=some,dc=domain,dc=org"
[14/Sep/2015:09:30:03 -0700] conn=12 op=442 MOD
dn="cn=MasterCRL,ou=crlIssuingPoints,ou=ca,o=ipaca"
[14/Sep/2015:09:30:03 -0700] conn=12 op=442 RESULT err=1 tag=103 nentries=0
etime=0
[14/Sep/2015:09:30:06 -0700] conn=20 op=288 SRCH
base="ou=sessions,ou=Security Domain,o=ipaca" scope=2
filter="(objectClass=securityDomainSessionEntry)" attrs="cn"
[14/Sep/2015:09:30:06 -0700] conn=20 op=288 RESULT err=32 tag=101
nentries=0 etime=0
[14/Sep/2015:09:30:08 -0700] conn=12 op=444 SRCH
base="ou=certificateRepository,ou=ca,o=ipaca" scope=1
filter="(certStatus=INVALID)" attrs="objectClass serialno notBefore
notAfter duration extension subjectName userCertificate version algorithmId
signingAlgorithmId publicKeyData"
[14/Sep/2015:09:30:08 -0700] conn=12 op=444 SORT notBefore
[14/Sep/2015:09:30:08 -0700] conn=12 op=444 VLV 200:0:20150914093009Z 1:0
(0)
[14/Sep/2015:09:30:08 -0700] conn=12 op=444 RESULT err=0 tag=101 nentries=0
etime=0
[14/Sep/2015:09:30:08 -0700] conn=12 op=445 SRCH
base="ou=certificateRepository,ou=ca,o=ipaca" scope=1
filter="(certStatus=VALID)" attrs="objectClass serialno notBefore notAfter
duration extension subjectName userCertificate version algorithmId
signingAlgorithmId publicKeyData"
[14/Sep/2015:09:30:08 -0700] conn=12 op=445 SORT notAfter
[14/Sep/2015:09:30:08 -0700] conn=12 op=445 VLV 200:0:20150914093009Z 1:10
(0)
[14/Sep/2015:09:30:08 -0700] conn=12 op=445 RESULT err=0 tag=101 nentries=1
etime=0
[14/Sep/2015:09:30:08 -0700] conn=12 op=446 SRCH
base="ou=certificateRepository,ou=ca,o=ipaca" scope=1
filter="(certStatus=REVOKED)" attrs="objectClass revokedOn serialno revInfo
notAfter notBefore duration extension subjectName userCertificate version
algorithmId signingAlgorithmId publicKeyData"
[14/Sep/2015:09:30:08 -0700] conn=12 op=446 VLV 200:0:20150914093009Z 0:0
(0)
[14/Sep/2015:09:30:08 -0700] conn=12 op=446 RESULT err=0 tag=101 nentries=0
etime=0 notes=U
[14/Sep/2015:09:30:08 -0700] conn=12 op=447 SRCH
base="ou=certificateRepository,ou=ca,o=ipaca" scope=0
filter="(|(objectClass=*)(objectClass=ldapsubentry))" attrs="description"
[14/Sep/2015:09:30:08 -0700] conn=12 op=447 RESULT err=0 tag=101 nentries=1
etime=0
[14/Sep/2015:09:30:19 -0700] conn=322 op=6 UNBIND

Then in the ldap error log I see this, which makes me think there is a
problem with the changelog:

[14/Sep/2015:09:30:03 -0700] - dn2entry_ext: Failed to get id for
changenumber=91314,cn=changelog from entryrdn index (-30993)
[14/Sep/2015:09:30:03 -0700] - Operation error fetching
changenumber=91314,cn=changelog (null), error -30993.
[14/Sep/2015:09:30:03 -0700] DSRetroclPlugin - replog: an error occured
while adding change number 91314, dn = changenumber=91314,cn=changelog:
Operations error.
[14/Sep/2015:09:30:03 -0700] retrocl-plugin - retrocl_postob: operation
failure [1]

After this both kdc and ldap stop responding. In the krb5kdc.log I see
server errors after the user-del command is run. The only way to resume
normal operations is to restart the whole machine. ipactl restart doesn't
work.

Any help would be highly appreciated!
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project