From jeldo26 at live.com  Mon Dec  1 04:46:55 2014
From: jeldo26 at live.com (Eldo Joseph)
Date: Mon, 1 Dec 2014 04:46:55 +0000
Subject: [Freeipa-users] IPA V3 Backup and recovery
In-Reply-To: <547A013C.10703@redhat.com>
References: <SNT147-W92263223536481E043F8D0CF7E0@phx.gbl>
	<547846DB.803@redhat.com>,<547A013C.10703@redhat.com>
Message-ID: <SNT147-W879470474E2DE02DEDAC56CF7D0@phx.gbl>

Thanks Guys :) 

> Date: Sat, 29 Nov 2014 12:24:12 -0500
> From: rcritten at redhat.com
> To: pvoborni at redhat.com; jeldo26 at live.com; freeipa-users at redhat.com
> Subject: Re: [Freeipa-users] IPA V3 Backup and recovery
> 
> Petr Vobornik wrote:
> > On 11/28/2014 10:39 AM, Eldo Joseph wrote:
> >> Hi All,
> >> Can some one help me, with the best practices which can be used for
> >> IPAV3 backup and recovery,  currently it is been a kind of single
> >> point of failure.
> >> Current infrastructure: One Master serverFive clients.
> >> I've tried with db2bak and bak2db features, I was able for a
> >> successful restore. how ever IPA admintools commands are failing with
> >> this error.
> >> (info): TGS_REQ (4 etypes {18 17 16 23}) xx.xx.xx.xx : PROCESS_TGS:
> >> authtime 0,  <unknown client> for <unknown server>, Decrypt integrity
> >> check failed
> >> Thanks,Eldo.                         
> >>
> > Hello Eldo,
> > 
> > sounds like: https://fedorahosted.org/freeipa/ticket/4726
> > 
> > try to run:
> >   sudo -u apache kdestroy
> > after the restore
> 
> You may also want to look at the design for backup and restore,
> http://www.freeipa.org/page/V3/Backup_and_Restore . Quite a lot needs to
> happen for a proper backup and restore, particularly since you have
> multiple masters.
> 
> rob
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141201/9e17906d/attachment.htm>

From mkosek at redhat.com  Mon Dec  1 07:54:12 2014
From: mkosek at redhat.com (Martin Kosek)
Date: Mon, 01 Dec 2014 08:54:12 +0100
Subject: [Freeipa-users] IPA V3 Backup and recovery
In-Reply-To: <SNT147-W879470474E2DE02DEDAC56CF7D0@phx.gbl>
References: <SNT147-W92263223536481E043F8D0CF7E0@phx.gbl>	<547846DB.803@redhat.com>,
	<547A013C.10703@redhat.com>
	<SNT147-W879470474E2DE02DEDAC56CF7D0@phx.gbl>
Message-ID: <547C1EA4.3050102@redhat.com>

On 12/01/2014 05:46 AM, Eldo Joseph wrote:
> Thanks Guys :) 
> 
>> Date: Sat, 29 Nov 2014 12:24:12 -0500
>> From: rcritten at redhat.com
>> To: pvoborni at redhat.com; jeldo26 at live.com; freeipa-users at redhat.com
>> Subject: Re: [Freeipa-users] IPA V3 Backup and recovery
>>
>> Petr Vobornik wrote:
>>> On 11/28/2014 10:39 AM, Eldo Joseph wrote:
>>>> Hi All,
>>>> Can some one help me, with the best practices which can be used for
>>>> IPAV3 backup and recovery,  currently it is been a kind of single
>>>> point of failure.
>>>> Current infrastructure: One Master serverFive clients.
>>>> I've tried with db2bak and bak2db features, I was able for a
>>>> successful restore. how ever IPA admintools commands are failing with
>>>> this error.
>>>> (info): TGS_REQ (4 etypes {18 17 16 23}) xx.xx.xx.xx : PROCESS_TGS:
>>>> authtime 0,  <unknown client> for <unknown server>, Decrypt integrity
>>>> check failed
>>>> Thanks,Eldo.                         
>>>>
>>> Hello Eldo,
>>>
>>> sounds like: https://fedorahosted.org/freeipa/ticket/4726
>>>
>>> try to run:
>>>   sudo -u apache kdestroy
>>> after the restore
>>
>> You may also want to look at the design for backup and restore,
>> http://www.freeipa.org/page/V3/Backup_and_Restore . Quite a lot needs to
>> happen for a proper backup and restore, particularly since you have
>> multiple masters.
>>
>> rob

Also, some of our thoughts and strategies on Backup and Restore are in this
general article:

http://www.freeipa.org/page/Backup_and_Restore

HTH,
Martin



From andreas.ladanyi at kit.edu  Mon Dec  1 10:53:11 2014
From: andreas.ladanyi at kit.edu (Andreas Ladanyi)
Date: Mon, 01 Dec 2014 11:53:11 +0100
Subject: [Freeipa-users] ipa-getkeytab -e des3-hmac-sha1 doesnt work
Message-ID: <547C4897.3080509@kit.edu>

Hi,

Server: FreeIPA 3.3.5, Fedora 20
Client: Ubuntu 14.04

ipa-getkeytab -s freeipaserver -p principal at REALM  -k
/tmp/principal.keytab -e des3-hmac-sha1 -P

only results in:

klist -k /tmp/principal.keytab -e
Keytab name: FILE:/tmp/principal.keytab
KVNO Principal
----
--------------------------------------------------------------------------
   5 principal at REALM (des3-cbc-sha1)


/var/kerberos/krb5kdc/kdc.conf:

[kdcdefaults]
 kdc_ports = 88
 kdc_tcp_ports = 88
 restrict_anonymous_to_tgt = true

[realms]
REALM = {
  master_key_type = aes256-cts
  max_life = 7d
  max_renewable_life = 14d
  acl_file = /var/kerberos/krb5kdc/kadm5.acl
  dict_file = /usr/share/dict/words
  default_principal_flags = +preauth
;  admin_keytab = /var/kerberos/krb5kdc/kadm5.keytab
  pkinit_identity = FILE:/var/kerberos/krb5kdc/kdc.pem
  pkinit_anchors = FILE:/var/kerberos/krb5kdc/cacert.pem
  supported_enctypes = aes256-cts-hmac-sha1-96:normal
aes128-cts-hmac-sha1-96:normal des3-cbc-sha1:normal
arcfour-hmac-md5:normal des-cbc-crc:v4 des3-hmac-sha1:normal
 }

I added the "des3-hmac-sha1:normal" entry in "supported_enctypes" parameter.

There is also an attributes entry krbDefaultEncSaltTypes and
krbSupportedEncSaltTypes with the value "des3-hmac-sha1:normal" in 389 LDAP.


cheers,
Andreas

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5306 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141201/8b43c8ed/attachment.p7s>

From simo at redhat.com  Mon Dec  1 16:15:14 2014
From: simo at redhat.com (Simo Sorce)
Date: Mon, 1 Dec 2014 11:15:14 -0500
Subject: [Freeipa-users] ipa-getkeytab -e des3-hmac-sha1 doesnt work
In-Reply-To: <547C4897.3080509@kit.edu>
References: <547C4897.3080509@kit.edu>
Message-ID: <20141201111514.6868d19f@willson.usersys.redhat.com>

On Mon, 01 Dec 2014 11:53:11 +0100
Andreas Ladanyi <andreas.ladanyi at kit.edu> wrote:

> Hi,
> 
> Server: FreeIPA 3.3.5, Fedora 20
> Client: Ubuntu 14.04
> 
> ipa-getkeytab -s freeipaserver -p principal at REALM  -k
> /tmp/principal.keytab -e des3-hmac-sha1 -P
> 
> only results in:
> 
> klist -k /tmp/principal.keytab -e
> Keytab name: FILE:/tmp/principal.keytab
> KVNO Principal

The 2 enctypes are equivalent and can be interchanged afaik.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York



From nicolas.zin at savoirfairelinux.com  Mon Dec  1 18:16:33 2014
From: nicolas.zin at savoirfairelinux.com (Nicolas Zin)
Date: Mon, 1 Dec 2014 13:16:33 -0500 (EST)
Subject: [Freeipa-users] freeipa-freeipa trust relationship
In-Reply-To: <1285330957.254080.1417457719901.JavaMail.root@mail>
Message-ID: <1728062521.254114.1417457793255.JavaMail.root@mail>

Hi,

I know that it is possible to connect a FreeIPA/idm to an Active Directory forest.

But is there a way to have a relationship between 2 freeipa domains, and if yes, is there any documentation.

Thanks in advance.



Nicolas Zin
nicolas.zin at savoirfairelinux.com
Ligne directe: 514-276-5468 poste 135

Fax : 514-276-5465
7275 Saint Urbain
Bureau 200
Montr?al, QC, H2R 2Y5





From abokovoy at redhat.com  Mon Dec  1 18:28:20 2014
From: abokovoy at redhat.com (Alexander Bokovoy)
Date: Mon, 1 Dec 2014 20:28:20 +0200
Subject: [Freeipa-users] freeipa-freeipa trust relationship
In-Reply-To: <1728062521.254114.1417457793255.JavaMail.root@mail>
References: <1285330957.254080.1417457719901.JavaMail.root@mail>
	<1728062521.254114.1417457793255.JavaMail.root@mail>
Message-ID: <20141201182820.GB16288@redhat.com>

On Mon, 01 Dec 2014, Nicolas Zin wrote:
>Hi,
>
>I know that it is possible to connect a FreeIPA/idm to an Active
>Directory forest.
>
>But is there a way to have a relationship between 2 freeipa domains,
>and if yes, is there any documentation.
Not implemented yet.

-- 
/ Alexander Bokovoy



From nicolas.zin at savoirfairelinux.com  Mon Dec  1 21:54:36 2014
From: nicolas.zin at savoirfairelinux.com (Nicolas Zin)
Date: Mon, 1 Dec 2014 16:54:36 -0500 (EST)
Subject: [Freeipa-users] freeipa-freeipa trust relationship
In-Reply-To: <20141201182820.GB16288@redhat.com>
Message-ID: <816284325.467741.1417470876289.JavaMail.root@mail>



> ----- Mail original -----
> De: "Alexander Bokovoy" <abokovoy at redhat.com>
> ?: "Nicolas Zin" <nicolas.zin at savoirfairelinux.com>
> Cc: freeipa-users at redhat.com
> Envoy?: Lundi 1 D?cembre 2014 19:28:20
> Objet: Re: [Freeipa-users] freeipa-freeipa trust relationship
> 
> On Mon, 01 Dec 2014, Nicolas Zin wrote:
> >Hi,
> >
> >I know that it is possible to connect a FreeIPA/idm to an Active
> >Directory forest.
> >
> >But is there a way to have a relationship between 2 freeipa domains,
> >and if yes, is there any documentation.
> Not implemented yet.


So even "manually" it is not possible? like following https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Managing_Smart_Cards/Setting_Up_Cross_Realm_Authentication.html ?

So far, I tried to:
kadmin.local -x ipa-setup-override-restrictions -r A.EXAMPLE.COM
 add_principal krbtgt/B.EXAMPLE.COM at A.EXAMPLE.COM

kadmin.local -x ipa-setup-override-restrictions -r B.EXAMPLE.COM
 add_principal krbtgt/A.EXAMPLE.COM at B.EXAMPLE.COM

edit /etc/krb5.conf to add element in sections [realms], [domain_realm] and [capaths]

and add a file into /var/lib/sss/pubconf/kdcinfo.B.EXAMPLE.COM (and /var/lib/sss/pubconf/kdcinfo.A.EXAMPLE.COM). Yes this is ugly.

I manage to kinit user1 at B.EXAMPLE.COM from A.EXAMPLE.COM and with this credential to ssh to the other host.

But I don't manage to do it transparently (i.e. ssh B.EXAMPLE.COM -l userA at A.EXAMPLE.COM with the good passord, or better: without password)

I guess this is not implemented in sssd and this is the problem I face?



Regards,


Nicolas



From abokovoy at redhat.com  Mon Dec  1 22:08:15 2014
From: abokovoy at redhat.com (Alexander Bokovoy)
Date: Tue, 2 Dec 2014 00:08:15 +0200
Subject: [Freeipa-users] freeipa-freeipa trust relationship
In-Reply-To: <816284325.467741.1417470876289.JavaMail.root@mail>
References: <20141201182820.GB16288@redhat.com>
	<816284325.467741.1417470876289.JavaMail.root@mail>
Message-ID: <20141201220815.GD16288@redhat.com>

On Mon, 01 Dec 2014, Nicolas Zin wrote:
>
>
>> ----- Mail original -----
>> De: "Alexander Bokovoy" <abokovoy at redhat.com>
>> ?: "Nicolas Zin" <nicolas.zin at savoirfairelinux.com>
>> Cc: freeipa-users at redhat.com
>> Envoy?: Lundi 1 D?cembre 2014 19:28:20
>> Objet: Re: [Freeipa-users] freeipa-freeipa trust relationship
>>
>> On Mon, 01 Dec 2014, Nicolas Zin wrote:
>> >Hi,
>> >
>> >I know that it is possible to connect a FreeIPA/idm to an Active
>> >Directory forest.
>> >
>> >But is there a way to have a relationship between 2 freeipa domains,
>> >and if yes, is there any documentation.
>> Not implemented yet.
>
>
>So even "manually" it is not possible? like following
>https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Managing_Smart_Cards/Setting_Up_Cross_Realm_Authentication.html
>?
That one is only covering a 'generic' Kerberos realm trust, not
specifically applied to FreeIPA.

>
>So far, I tried to:
>kadmin.local -x ipa-setup-override-restrictions -r A.EXAMPLE.COM
> add_principal krbtgt/B.EXAMPLE.COM at A.EXAMPLE.COM
>
>kadmin.local -x ipa-setup-override-restrictions -r B.EXAMPLE.COM
> add_principal krbtgt/A.EXAMPLE.COM at B.EXAMPLE.COM
>
>edit /etc/krb5.conf to add element in sections [realms], [domain_realm]
>and [capaths]
>
>and add a file into /var/lib/sss/pubconf/kdcinfo.B.EXAMPLE.COM (and
>/var/lib/sss/pubconf/kdcinfo.A.EXAMPLE.COM). Yes this is ugly.
>
>I manage to kinit user1 at B.EXAMPLE.COM from A.EXAMPLE.COM and with this
>credential to ssh to the other host.
>
>But I don't manage to do it transparently (i.e. ssh B.EXAMPLE.COM -l
>userA at A.EXAMPLE.COM with the good passord, or better: without password)
>
>I guess this is not implemented in sssd and this is the problem I face?
Yes, SSSD doesn't know that A.EXAMPLE.COM is a 'subdomain of
B.EXAMPLE.COM (this is how we manage all trusts), thus doesn't know how
to resolve users/groups from that realm and how to assign them POSIX
attributes locally.

Our approach is to get FreeIPA/AD trust case finished first and then
reuse as much as possible for FreeIPA/FreeIPA trust case. We anyway
would have to implement most of the same functionality -- ID range
handling, POSIX attributes management, caching of group membership
(MS-PAC or UNIX-PAD extensions in Kerberos tickets), discovery of forest
topology and so on.



-- 
/ Alexander Bokovoy



From Less at imagine-sw.com  Tue Dec  2 07:17:02 2014
From: Less at imagine-sw.com (Les Stott)
Date: Tue, 2 Dec 2014 07:17:02 +0000
Subject: [Freeipa-users] CA Replication Installation Failing
Message-ID: <4ED173A868981548967B4FCA270722262803F3C5@AACMBXP04.exchserver.com>

Hi All,

I have RHEL6 with ipa servers running standard ipa server 3.0.0-42. Pki components are also standard version 9.0.3-38.

Servera is the master
Serverb is the replica

Both have been running for many, many months. Serverb was initially setup as a replica, but not a CA replica.

I am now trying to add CA Replication to serverb but it is failing midway through and I cannot figure out why.

Annoyingly, I used the same method/command to setup a CA replica on test servers and it completed without issue.

Here is what I get....(for the sake of brevity, I am excluding the lines for connection check which were all OK)

=================
/usr/sbin/ipa-ca-install /var/lib/ipa/replica-info-serverb.mydomain.com.gpg
Directory Manager (existing master) password:
Get credentials to log in to remote master
admin at MYDOMAIN.COM password:
Execute check on remote master
Connection check OK
Configuring directory server for the CA (pkids): Estimated time 30 seconds
  [1/3]: creating directory server user
  [2/3]: creating directory server instance
  [3/3]: restarting directory server
Done configuring directory server for the CA (pkids).
Configuring certificate server (pki-cad): Estimated time 3 minutes 30 seconds
  [1/16]: creating certificate server user
  [2/16]: creating pki-ca instance
  [3/16]: configuring certificate server instance
ipa         : CRITICAL failed to configure ca instance Command '/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname serverb.mydomain.com -cs_port 9445 -client_certdb_dir /tmp/tmp-t3aHM7 -client_certdb_pwd XXXXXXXX -preop_pin exoyO2y7bawG5yjZMACM -domain_name IPA -admin_user admin -admin_email root at localhost -admin_password XXXXXXXX -agent_name ipa-ca-agent -agent_key_size 2048 -agent_key_type rsa -agent_cert_subject CN=ipa-ca-agent,O=MYDOMAIN.COM -ldap_host serverb.mydomain.com -ldap_port 7389 -bind_dn cn=Directory Manager -bind_password XXXXXXXX -base_dn o=ipaca -db_name ipaca -key_size 2048 -key_type rsa -key_algorithm SHA256withRSA -save_p12 true -backup_pwd XXXXXXXX -subsystem_name pki-cad -token_name internal -ca_subsystem_cert_subject_name CN=CA Subsystem,O=MYDOMAIN.COM -ca_subsystem_cert_subject_name CN=CA Subsystem,O=MYDOMAIN.COM -ca_ocsp_cert_subject_name CN=OCSP Subsystem,O=MYDOMAIN.COM -ca_server_cert_subject_name CN=serverb.mydomain.com,O=MYDOMAIN.COM -ca_audit_signing_cert_subject_name CN=CA Audit,O=MYDOMAIN.COM -ca_sign_cert_subject_name CN=Certificate Authority,O=MYDOMAIN.COM -external false -clone true -clone_p12_file ca.p12 -clone_p12_password XXXXXXXX -sd_hostname servera.mydomain.com -sd_admin_port 443 -sd_admin_name admin -sd_admin_password XXXXXXXX -clone_start_tls true -clone_uri https://servera.mydomain.com:443' returned non-zero exit status 255

Your system may be partly configured.
Run /usr/sbin/ipa-server-install --uninstall to clean up.

Configuration of CA failed
=================

Additional excerpt from the log file /var/log/ipareplica-ca-install.log at the point of failure....

=================

#############################################
Attempting to connect to: serverb.mydomain.com:9445
Connected.
Posting Query = https://serverb.mydomain.com:9445//ca/admin/console/config/wizard?p=7&op=next&xml=true&__password=XXXXXXXX&path=ca.p12
RESPONSE STATUS:  HTTP/1.1 200 OK
RESPONSE HEADER:  Server: Apache-Coyote/1.1
RESPONSE HEADER:  Content-Type: application/xml;charset=UTF-8
RESPONSE HEADER:  Date: Tue, 02 Dec 2014 05:44:19 GMT
RESPONSE HEADER:  Connection: close
<?xml version="1.0" encoding="UTF-8"?>
<!-- BEGIN COPYRIGHT BLOCK
     This program is free software; you can redistribute it and/or modify
     it under the terms of the GNU General Public License as published by
     the Free Software Foundation; version 2 of the License.

     This program is distributed in the hope that it will be useful,
     but WITHOUT ANY WARRANTY; without even the implied warranty of
     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
     GNU General Public License for more details.

     You should have received a copy of the GNU General Public License along
     with this program; if not, write to the Free Software Foundation, Inc.,
     51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.

     Copyright (C) 2007 Red Hat, Inc.
     All rights reserved.
     END COPYRIGHT BLOCK -->
<response>
  <panel>admin/console/config/restorekeycertpanel.vm</panel>
  <res/>
  <updateStatus>failure</updateStatus>
  <password/>
  <errorString>The pkcs12 file is not correct.</errorString>
  <size>19</size>
  <title>Import Keys and Certificates</title>
  <panels>
    <Vector>
      <Panel>
        <Id>welcome</Id>
        <Name>Welcome</Name>
      </Panel>
      <Panel>
        <Id>module</Id>
        <Name>Key Store</Name>
      </Panel>
      <Panel>
        <Id>confighsmlogin</Id>
        <Name>ConfigHSMLogin</Name>
      </Panel>
      <Panel>
        <Id>securitydomain</Id>
        <Name>Security Domain</Name>
      </Panel>
      <Panel>
        <Id>securitydomain</Id>
        <Name>Display Certificate Chain</Name>
      </Panel>
      <Panel>
        <Id>subsystem</Id>
        <Name>Subsystem Type</Name>
      </Panel>
      <Panel>
        <Id>clone</Id>
        <Name>Display Certificate Chain</Name>
      </Panel>
      <Panel>
        <Id>restorekeys</Id>
        <Name>Import Keys and Certificates</Name>
      </Panel>
      <Panel>
        <Id>cahierarchy</Id>
        <Name>PKI Hierarchy</Name>
      </Panel>
      <Panel>
        <Id>database</Id>
        <Name>Internal Database</Name>
      </Panel>
      <Panel>
        <Id>size</Id>
        <Name>Key Pairs</Name>
      </Panel>
      <Panel>
        <Id>subjectname</Id>
        <Name>Subject Names</Name>
      </Panel>
      <Panel>
        <Id>certrequest</Id>
        <Name>Requests and Certificates</Name>
      </Panel>
      <Panel>
        <Id>backupkeys</Id>
        <Name>Export Keys and Certificates</Name>
      </Panel>
      <Panel>
        <Id>savepk12</Id>
        <Name>Save Keys and Certificates</Name>
      </Panel>
      <Panel>
        <Id>importcachain</Id>
        <Name>Import CA's Certificate Chain</Name>
      </Panel>
      <Panel>
        <Id>admin</Id>
        <Name>Administrator</Name>
      </Panel>
      <Panel>
        <Id>importadmincert</Id>
        <Name>Import Administrator's Certificate</Name>
      </Panel>
      <Panel>
        <Id>done</Id>
        <Name>Done</Name>
      </Panel>
    </Vector>
  </panels>
  <name>CA Setup Wizard</name>
  <p>7</p>
  <path/>
  <req/>
  <panelname>restorekeys</panelname>
</response>
Error in RestoreKeyCertPanel(): updateStatus returns failure
ERROR: ConfigureCA: RestoreKeyCertPanel() failure
ERROR: unable to create CA

#######################################################################
2014-12-02T05:44:19Z DEBUG stderr=
2014-12-02T05:44:19Z CRITICAL failed to configure ca instance Command '/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname serverb.mydomain.com -cs_port 9445 -client_certdb_dir /tmp/tmp-1Tqws5 -client_certdb_pwd XXXXXXXX -preop_pin rdkE0y2CiGMKNcRRPKKc -domain_name IPA -admin_user admin -admin_email root at localhost -admin_password XXXXXXXX -agent_name ipa-ca-agent -agent_key_size 2048 -agent_key_type rsa -agent_cert_subject CN=ipa-ca-agent,O=MYDOMAIN.COM -ldap_host serverb.mydomain.com -ldap_port 7389 -bind_dn cn=Directory Manager -bind_password XXXXXXXX -base_dn o=ipaca -db_name ipaca -key_size 2048 -key_type rsa -key_algorithm SHA256withRSA -save_p12 true -backup_pwd XXXXXXXX -subsystem_name pki-cad -token_name internal -ca_subsystem_cert_subject_name CN=CA Subsystem,O=MYDOMAIN.COM -ca_subsystem_cert_subject_name CN=CA Subsystem,O=MYDOMAIN.COM -ca_ocsp_cert_subject_name CN=OCSP Subsystem,O=MYDOMAIN.COM -ca_server_cert_subject_name CN=serverb.mydomain.com,O=MYDOMAIN.COM -ca_audit_signing_cert_subject_name CN=CA Audit,O=MYDOMAIN.COM -ca_sign_cert_subject_name CN=Certificate Authority,O=MYDOMAIN.COM -external false -clone true -clone_p12_file ca.p12 -clone_p12_password XXXXXXXX -sd_hostname servera.mydomain.com -sd_admin_port 443 -sd_admin_name admin -sd_admin_password XXXXXXXX -clone_start_tls true -clone_uri https://servera.mydomain.com:443' returned non-zero exit status 255
2014-12-02T05:44:19Z INFO   File "/usr/lib/python2.6/site-packages/ipaserver/install/installutils.py", line 614, in run_script
    return_value = main_function()

  File "/usr/sbin/ipa-ca-install", line 149, in main
    (CA, cs) = cainstance.install_replica_ca(config, postinstall=True)

  File "/usr/lib/python2.6/site-packages/ipaserver/install/cainstance.py", line 1626, in install_replica_ca
    subject_base=config.subject_base)

  File "/usr/lib/python2.6/site-packages/ipaserver/install/cainstance.py", line 626, in configure_instance
    self.start_creation(runtime=210)

  File "/usr/lib/python2.6/site-packages/ipaserver/install/service.py", line 358, in start_creation
    method()

  File "/usr/lib/python2.6/site-packages/ipaserver/install/cainstance.py", line 888, in __configure_instance
    raise RuntimeError('Configuration of CA failed')

2014-12-02T05:44:19Z INFO The ipa-ca-install command failed, exception: RuntimeError: Configuration of CA failed

=================

I am not sure why this is happening.

Certutil shows that the setup isn't complete on serverb when comparing against the CA replica in my test servers which were successful.

# certutil -L -d /var/lib/pki-ca/alias

Certificate Nickname                                         Trust Attributes
                                                             SSL,S/MIME,JAR/XPI

Certificate Authority - MYDOMAIN.COM                      CT,c,
Server-Cert cert-pki-ca                                      CTu,Cu,Cu

# certutil -K -d /var/lib/pki-ca/alias
certutil: Checking token "NSS Certificate DB" in slot "NSS User Private Key and Certificate Services"
Enter Password or Pin for "NSS Certificate DB":
< 0> rsa      ef25de4fb656a27e297899509bc3dad582bcd643   NSS Certificate DB:Server-Cert cert-pki-ca


As yet, I have not tried "/usr/sbin/ipa-server-install -uninstall" in an attempt to cleanup as this is a production server and apart from CA replication, it is running fine. I have tried multiple times manually removing pki instances and reinstalling but it still won't get past the above error.

Can anyone shed any light on this?

Thanks in advance,

Les




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141202/e1466e9b/attachment.htm>

From andreas.ladanyi at kit.edu  Tue Dec  2 11:08:24 2014
From: andreas.ladanyi at kit.edu (Andreas Ladanyi)
Date: Tue, 02 Dec 2014 12:08:24 +0100
Subject: [Freeipa-users] ipa-getkeytab -e des3-hmac-sha1 doesnt work
In-Reply-To: <20141201111514.6868d19f@willson.usersys.redhat.com>
References: <547C4897.3080509@kit.edu>
	<20141201111514.6868d19f@willson.usersys.redhat.com>
Message-ID: <547D9DA8.4060606@kit.edu>

> On Mon, 01 Dec 2014 11:53:11 +0100
> Andreas Ladanyi <andreas.ladanyi at kit.edu> wrote:
>
>> Hi,
>>
>> Server: FreeIPA 3.3.5, Fedora 20
>> Client: Ubuntu 14.04
>>
>> ipa-getkeytab -s freeipaserver -p principal at REALM  -k
>> /tmp/principal.keytab -e des3-hmac-sha1 -P
>>
>> only results in:
>>
>> klist -k /tmp/principal.keytab -e
>> Keytab name: FILE:/tmp/principal.keytab
>> KVNO Principal
> The 2 enctypes are equivalent and can be interchanged afaik.
>
> Simo.
>
Ok.

Another question: Is it possible to generate keys with no salt instead
of Version 5 (normal) salt ?

I want to generate a des3 key with no salt:

ipa-getkeytab -s freeipaserver -p principal at REALM -k
/tmp/principal.keytab -e des3-hmac-sha1:v4 -P

The answer is:

Bad or unsupported salt type.
Failed to create key material

I configured the des3-hmac-sha1:v4 in LDAP and in kdc.conf


Andreas

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5306 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141202/318d386f/attachment.p7s>

From matthew.herzog at gmail.com  Tue Dec  2 16:28:38 2014
From: matthew.herzog at gmail.com (Matthew Herzog)
Date: Tue, 2 Dec 2014 11:28:38 -0500
Subject: [Freeipa-users] DNS configuration
Message-ID: <CABhyZ34TCzUz+fNUSCvdZ38MS7rsLMMdb_jTdfKUsmYs86fn_Q@mail.gmail.com>

I just realized that my IPA servers cannot resolve ANY servers in my
domain. What do I need to do to fix this? Below is my named.conf.


options {
        // turns on IPv6 for port 53, IPv4 is on by default for all ifaces
        listen-on-v6 {any;};

        // Put files that named is allowed to write in the data/ directory:
        directory "/var/named"; // the default
        dump-file               "data/cache_dump.db";
        statistics-file         "data/named_stats.txt";
        memstatistics-file      "data/named_mem_stats.txt";

        forward first;
        forwarders {
                10.100.8.41;
                10.100.8.40;
                10.100.4.13;
                10.100.4.14;
                10.100.4.19;
                10.100.4.44;
        };

        // Any host is permitted to issue recursive queries
        allow-recursion { any; };

        tkey-gssapi-keytab "/etc/named.keytab";
        pid-file "/run/named/named.pid";
};

/* If you want to enable debugging, eg. using the 'rndc trace' command,
 * By default, SELinux policy does not allow named to modify the /var/named
directory,
 * so put the default debug log file in data/ :
 */
logging {
        channel default_debug {
                file "data/named.run";
                severity dynamic;
                print-time yes;
        };
        };
};

zone "." IN {
        type hint;
        file "named.ca";
};

include "/etc/named.rfc1912.zones";

dynamic-db "ipa" {
        library "ldap.so";
        arg "uri ldapi://%2fvar%2frun%2fslapd-BO3-E-BOZO-COM.socket";
        arg "base cn=dns, dc=bo3,dc=e-bozo,dc=com";
        arg "fake_mname freeipa-poc01.bo3.e-bozo.com.";
        arg "auth_method sasl";
        arg "sasl_mech GSSAPI";
        arg "sasl_user DNS/freeipa-poc01.bo3.e-bozo.com";
        arg "serial_autoincrement yes";
};





-- 
If life gives you melons, you may be dyslexic.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141202/22b3c72d/attachment.htm>

From rcritten at redhat.com  Tue Dec  2 16:32:04 2014
From: rcritten at redhat.com (Rob Crittenden)
Date: Tue, 02 Dec 2014 11:32:04 -0500
Subject: [Freeipa-users] DNS configuration
In-Reply-To: <CABhyZ34TCzUz+fNUSCvdZ38MS7rsLMMdb_jTdfKUsmYs86fn_Q@mail.gmail.com>
References: <CABhyZ34TCzUz+fNUSCvdZ38MS7rsLMMdb_jTdfKUsmYs86fn_Q@mail.gmail.com>
Message-ID: <547DE984.3080707@redhat.com>

Matthew Herzog wrote:
> I just realized that my IPA servers cannot resolve ANY servers in my
> domain. What do I need to do to fix this? Below is my named.conf. 

You don't say how you're trying to resolve those hosts. It could also be
a broken /etc/resolv.conf.

rob

> 
> 
> options {
>         // turns on IPv6 for port 53, IPv4 is on by default for all ifaces
>         listen-on-v6 {any;};
> 
>         // Put files that named is allowed to write in the data/ directory:
>         directory "/var/named"; // the default
>         dump-file               "data/cache_dump.db";
>         statistics-file         "data/named_stats.txt";
>         memstatistics-file      "data/named_mem_stats.txt";
> 
>         forward first;
>         forwarders {
>                 10.100.8.41;
>                 10.100.8.40;
>                 10.100.4.13;
>                 10.100.4.14;
>                 10.100.4.19;
>                 10.100.4.44;
>         };
> 
>         // Any host is permitted to issue recursive queries
>         allow-recursion { any; };
> 
>         tkey-gssapi-keytab "/etc/named.keytab";
>         pid-file "/run/named/named.pid";
> };
> 
> /* If you want to enable debugging, eg. using the 'rndc trace' command,
>  * By default, SELinux policy does not allow named to modify the
> /var/named directory,
>  * so put the default debug log file in data/ :
>  */
> logging {
>         channel default_debug {
>                 file "data/named.run";
>                 severity dynamic;
>                 print-time yes;
>         };
>         };
> };
> 
> zone "." IN {
>         type hint;
>         file "named.ca <http://named.ca>";
> };
> 
> include "/etc/named.rfc1912.zones";
> 
> dynamic-db "ipa" {
>         library "ldap.so";
>         arg "uri ldapi://%2fvar%2frun%2fslapd-BO3-E-BOZO-COM.socket";
>         arg "base cn=dns, dc=bo3,dc=e-bozo,dc=com";
>         arg "fake_mname freeipa-poc01.bo3.e-bozo.com
> <http://freeipa-poc01.bo3.e-bozo.com>.";
>         arg "auth_method sasl";
>         arg "sasl_mech GSSAPI";
>         arg "sasl_user DNS/freeipa-poc01.bo3.e-bozo.com
> <http://freeipa-poc01.bo3.e-bozo.com>";
>         arg "serial_autoincrement yes";
> };
> 
> 
> 
> 
> 
> -- 
> 
> 
> If life gives you melons, you may be dyslexic.
> 
> 



From mbasti at redhat.com  Tue Dec  2 16:36:46 2014
From: mbasti at redhat.com (Martin Basti)
Date: Tue, 02 Dec 2014 17:36:46 +0100
Subject: [Freeipa-users] DNS configuration
In-Reply-To: <CABhyZ34TCzUz+fNUSCvdZ38MS7rsLMMdb_jTdfKUsmYs86fn_Q@mail.gmail.com>
References: <CABhyZ34TCzUz+fNUSCvdZ38MS7rsLMMdb_jTdfKUsmYs86fn_Q@mail.gmail.com>
Message-ID: <547DEA9E.2030203@redhat.com>

On 02/12/14 17:28, Matthew Herzog wrote:
> I just realized that my IPA servers cannot resolve ANY servers in my 
> domain. What do I need to do to fix this? Below is my named.conf.
>
>
> options {
>         // turns on IPv6 for port 53, IPv4 is on by default for all ifaces
>         listen-on-v6 {any;};
>
>         // Put files that named is allowed to write in the data/ 
> directory:
>         directory "/var/named"; // the default
>         dump-file               "data/cache_dump.db";
>         statistics-file         "data/named_stats.txt";
>         memstatistics-file  "data/named_mem_stats.txt";
>
>         forward first;
>         forwarders {
>                 10.100.8.41;
>                 10.100.8.40;
>                 10.100.4.13;
>                 10.100.4.14;
>                 10.100.4.19;
>                 10.100.4.44;
>         };
>
>         // Any host is permitted to issue recursive queries
>         allow-recursion { any; };
>
>         tkey-gssapi-keytab "/etc/named.keytab";
>         pid-file "/run/named/named.pid";
> };
>
> /* If you want to enable debugging, eg. using the 'rndc trace' command,
>  * By default, SELinux policy does not allow named to modify the 
> /var/named directory,
>  * so put the default debug log file in data/ :
>  */
> logging {
>         channel default_debug {
>                 file "data/named.run";
>                 severity dynamic;
>                 print-time yes;
>         };
>         };
> };
>
> zone "." IN {
>         type hint;
>         file "named.ca <http://named.ca>";
> };
>
> include "/etc/named.rfc1912.zones";
>
> dynamic-db "ipa" {
>         library "ldap.so";
>         arg "uri ldapi://%2fvar%2frun%2fslapd-BO3-E-BOZO-COM.socket";
>         arg "base cn=dns, dc=bo3,dc=e-bozo,dc=com";
>         arg "fake_mname freeipa-poc01.bo3.e-bozo.com 
> <http://freeipa-poc01.bo3.e-bozo.com>.";
>         arg "auth_method sasl";
>         arg "sasl_mech GSSAPI";
>         arg "sasl_user DNS/freeipa-poc01.bo3.e-bozo.com 
> <http://freeipa-poc01.bo3.e-bozo.com>";
>         arg "serial_autoincrement yes";
> };
>
>
>
>
Hello,

which version ipa do you use? which platform? Which version bind-dyndb-ldap?

Can you run these commands, and check if there any errors?
ipactl status
systemctl status named  (respectively journalctl -u named)

-- 
Martin Basti

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141202/a977adb7/attachment.htm>

From pspacek at redhat.com  Tue Dec  2 16:58:29 2014
From: pspacek at redhat.com (Petr Spacek)
Date: Tue, 02 Dec 2014 17:58:29 +0100
Subject: [Freeipa-users] DNS configuration
In-Reply-To: <547DEA9E.2030203@redhat.com>
References: <CABhyZ34TCzUz+fNUSCvdZ38MS7rsLMMdb_jTdfKUsmYs86fn_Q@mail.gmail.com>
	<547DEA9E.2030203@redhat.com>
Message-ID: <547DEFB5.1020205@redhat.com>

On 2.12.2014 17:36, Martin Basti wrote:
> On 02/12/14 17:28, Matthew Herzog wrote:
>> I just realized that my IPA servers cannot resolve ANY servers in my domain.
>> What do I need to do to fix this? Below is my named.conf.
>>
>>
>> options {
>>         // turns on IPv6 for port 53, IPv4 is on by default for all ifaces
>>         listen-on-v6 {any;};
>>
>>         // Put files that named is allowed to write in the data/ directory:
>>         directory "/var/named"; // the default
>>         dump-file               "data/cache_dump.db";
>>         statistics-file         "data/named_stats.txt";
>>         memstatistics-file  "data/named_mem_stats.txt";
>>
>>         forward first;
>>         forwarders {
>>                 10.100.8.41;
>>                 10.100.8.40;
>>                 10.100.4.13;
>>                 10.100.4.14;
>>                 10.100.4.19;
>>                 10.100.4.44;
>>         };
>>
>>         // Any host is permitted to issue recursive queries
>>         allow-recursion { any; };
>>
>>         tkey-gssapi-keytab "/etc/named.keytab";
>>         pid-file "/run/named/named.pid";
>> };
>>
>> /* If you want to enable debugging, eg. using the 'rndc trace' command,
>>  * By default, SELinux policy does not allow named to modify the /var/named
>> directory,
>>  * so put the default debug log file in data/ :
>>  */
>> logging {
>>         channel default_debug {
>>                 file "data/named.run";
>>                 severity dynamic;
>>                 print-time yes;
>>         };
>>         };
>> };
>>
>> zone "." IN {
>>         type hint;
>>         file "named.ca <http://named.ca>";
>> };
>>
>> include "/etc/named.rfc1912.zones";
>>
>> dynamic-db "ipa" {
>>         library "ldap.so";
>>         arg "uri ldapi://%2fvar%2frun%2fslapd-BO3-E-BOZO-COM.socket";
>>         arg "base cn=dns, dc=bo3,dc=e-bozo,dc=com";
>>         arg "fake_mname freeipa-poc01.bo3.e-bozo.com
>> <http://freeipa-poc01.bo3.e-bozo.com>.";
>>         arg "auth_method sasl";
>>         arg "sasl_mech GSSAPI";
>>         arg "sasl_user DNS/freeipa-poc01.bo3.e-bozo.com
>> <http://freeipa-poc01.bo3.e-bozo.com>";
>>         arg "serial_autoincrement yes";
>> };
>>
>>
>>
>>
> Hello,
> 
> which version ipa do you use? which platform? Which version bind-dyndb-ldap?
> 
> Can you run these commands, and check if there any errors?
> ipactl status
> systemctl status named  (respectively journalctl -u named)

We also may want to see information listed on page
https://fedorahosted.org/bind-dyndb-ldap/wiki/BugReporting

-- 
Petr^2 Spacek



From nicolas.zin at savoirfairelinux.com  Tue Dec  2 17:40:24 2014
From: nicolas.zin at savoirfairelinux.com (Nicolas Zin)
Date: Tue, 2 Dec 2014 12:40:24 -0500 (EST)
Subject: [Freeipa-users] sssd uid mapping from an ad trust
In-Reply-To: <816284325.467741.1417470876289.JavaMail.root@mail>
Message-ID: <1721728889.171428.1417542023984.JavaMail.root@mail>

Hi,

the question of the day I should say. In a Redhat7/FreeIPA 3.3 environment.
In an AD trust relationship, when I connect with an AD user to a IDM client, I append to login with a generated uid.

Is there a way to provide a custom algorithm to map the uid from Active Directory info.
In our AD, users have a specific login name: composed of one character and a uniq number. We wonder if we can translate this uniq number into a uid. 
I know : another solution the prefered way would be to use SFU (Service For Unix), but I wanted to ask before.
I guess I know the answer :-)


Regards,

Nicolas


PS: another question: is there a good tutorial to use freeIPA xml-rpc api (in python). I saw some code but not so much examples (https://github.com/encukou/freeipa/blob/master/doc/examples/python-api.py).



From pspacek at redhat.com  Tue Dec  2 17:42:54 2014
From: pspacek at redhat.com (Petr Spacek)
Date: Tue, 02 Dec 2014 18:42:54 +0100
Subject: [Freeipa-users] Announcing bind-dyndb-ldap version 6.1
Message-ID: <547DFA1E.9060301@redhat.com>

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

It can be downloaded from https://fedorahosted.org/released/bind-dyndb-ldap/

The new version has also been built for Fedora 21+ and and is on its way to
updates-testing:
https://admin.fedoraproject.org/updates/bind-dyndb-ldap-6.1-1.fc21

This version is also available from FreeIPA COPR repo:
http://copr.fedoraproject.org/coprs/mkosek/freeipa/


6.1
====
[1] Crash caused by interaction between forward and master zones was fixed.
    https://fedorahosted.org/bind-dyndb-ldap/ticket/145

[2] DNS NOTIFY messages are sent after any modification to the zone.
    https://fedorahosted.org/bind-dyndb-ldap/ticket/144

[3] Misleading error message about forward zones during reconnect was fixed.


== Upgrading ==
A server can be upgraded by installing updated RPM. BIND has to be restarted
manually after the RPM installation.

Downgrading back to any 5.x version is supported if idnsZoneActive is always
set to TRUE.


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

-- 
Petr^2 Spacek



From abokovoy at redhat.com  Tue Dec  2 17:58:33 2014
From: abokovoy at redhat.com (Alexander Bokovoy)
Date: Tue, 2 Dec 2014 19:58:33 +0200
Subject: [Freeipa-users] sssd uid mapping from an ad trust
In-Reply-To: <1721728889.171428.1417542023984.JavaMail.root@mail>
References: <816284325.467741.1417470876289.JavaMail.root@mail>
	<1721728889.171428.1417542023984.JavaMail.root@mail>
Message-ID: <20141202175833.GF16288@redhat.com>

On Tue, 02 Dec 2014, Nicolas Zin wrote:
>Hi,
>
>the question of the day I should say. In a Redhat7/FreeIPA 3.3
>environment.  In an AD trust relationship, when I connect with an AD
>user to a IDM client, I append to login with a generated uid.
>
>Is there a way to provide a custom algorithm to map the uid from Active
>Directory info.  In our AD, users have a specific login name: composed
>of one character and a uniq number. We wonder if we can translate this
>uniq number into a uid.  I know : another solution the prefered way
>would be to use SFU (Service For Unix), but I wanted to ask before.  I
>guess I know the answer :-)
In FreeIPA 4.1 we introduced support for ID overrides for users coming
from Active Directory. This will hopefully be available in RHEL7.1.

With ID overrides (ID views) you can assign specific POSIX attributes
per each AD user, including but not limited to their UIDs and GIDs (and
user names, if needed).

http://www.freeipa.org/page/V4/Migrating_existing_environments_to_Trust

You'd need an SSSD that understands ID views too, coming along with
updated IPA.

>PS: another question: is there a good tutorial to use freeIPA xml-rpc
>api (in python). I saw some code but not so much examples
>(https://github.com/encukou/freeipa/blob/master/doc/examples/python-api.py).
There are not so many examples yet. Best way to learn is to read the
code of ipalib/*/* components. ;)
-- 
/ Alexander Bokovoy



From matthew.herzog at gmail.com  Tue Dec  2 16:43:41 2014
From: matthew.herzog at gmail.com (Matthew Herzog)
Date: Tue, 2 Dec 2014 11:43:41 -0500
Subject: [Freeipa-users] DNS configuration
In-Reply-To: <547DEA9E.2030203@redhat.com>
References: <CABhyZ34TCzUz+fNUSCvdZ38MS7rsLMMdb_jTdfKUsmYs86fn_Q@mail.gmail.com>
	<547DEA9E.2030203@redhat.com>
Message-ID: <CABhyZ34_0SGkM4N9M3HZdKNv7bpzbf-0wJN-scVBM_jassgUVQ@mail.gmail.com>

I'm using freeipa 3.3.3 on Oracle Linux 7.
I have bind-dyndb-ldap-3.5-4.el7.x86_64 installed.

ipactl status:
Directory Service: RUNNING
krb5kdc Service: RUNNING
kadmin Service: RUNNING
named Service: RUNNING
ipa_memcached Service: RUNNING
httpd Service: RUNNING
pki-tomcatd Service: RUNNING
smb Service: RUNNING
winbind Service: RUNNING
ipa-otpd Service: RUNNING
ipa: INFO: The ipactl command was successful


systemctl status named:
Dec 02 11:08:50 freeipa-poc01.bo3.e-bozo.com named[27495]: zone
bo3.e-bozo.com/IN: loaded serial 1417535679
Dec 02 11:08:50 freeipa-poc01.bo3.e-bozo.com named[27495]: zone
1.0.0.127.in-addr.arpa/IN: loaded serial 0
Dec 02 11:08:50 freeipa-poc01.bo3.e-bozo.com named[27495]: zone
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa/IN:
loaded serial 0
Dec 02 11:08:50 freeipa-poc01.bo3.e-bozo.com named[27495]: zone
localhost/IN: loaded serial 0
Dec 02 11:08:50 freeipa-poc01.bo3.e-bozo.com named[27495]: zone
localhost.localdomain/IN: loaded serial 0
Dec 02 11:08:50 freeipa-poc01.bo3.e-bozo.com named[27495]: all zones loaded
Dec 02 11:08:50 freeipa-poc01.bo3.e-bozo.com named[27495]: running
Dec 02 11:08:50 freeipa-poc01.bo3.e-bozo.com systemd[1]: Started Berkeley
Internet Name Domain (DNS).
Dec 02 11:08:50 freeipa-poc01.bo3.e-bozo.com named[27495]: zone
4.100.10.in-addr.arpa/IN: loaded serial 1417535679
Dec 02 11:08:50 freeipa-poc01.bo3.e-bozo.com named[27495]: zone
e-bozo.com/IN: loaded serial 1417535679




On Tue, Dec 2, 2014 at 11:36 AM, Martin Basti <mbasti at redhat.com> wrote:

>  On 02/12/14 17:28, Matthew Herzog wrote:
>
> I just realized that my IPA servers cannot resolve ANY servers in my
> domain. What do I need to do to fix this? Below is my named.conf.
>
>
>  options {
>         // turns on IPv6 for port 53, IPv4 is on by default for all ifaces
>         listen-on-v6 {any;};
>
>          // Put files that named is allowed to write in the data/
> directory:
>         directory "/var/named"; // the default
>         dump-file               "data/cache_dump.db";
>         statistics-file         "data/named_stats.txt";
>         memstatistics-file      "data/named_mem_stats.txt";
>
>          forward first;
>         forwarders {
>                 10.100.8.41;
>                 10.100.8.40;
>                 10.100.4.13;
>                 10.100.4.14;
>                 10.100.4.19;
>                 10.100.4.44;
>         };
>
>          // Any host is permitted to issue recursive queries
>         allow-recursion { any; };
>
>          tkey-gssapi-keytab "/etc/named.keytab";
>         pid-file "/run/named/named.pid";
> };
>
>  /* If you want to enable debugging, eg. using the 'rndc trace' command,
>  * By default, SELinux policy does not allow named to modify the
> /var/named directory,
>  * so put the default debug log file in data/ :
>  */
> logging {
>         channel default_debug {
>                 file "data/named.run";
>                 severity dynamic;
>                 print-time yes;
>         };
>          };
> };
>
>  zone "." IN {
>         type hint;
>         file "named.ca";
> };
>
>  include "/etc/named.rfc1912.zones";
>
>  dynamic-db "ipa" {
>         library "ldap.so";
>         arg "uri ldapi://%2fvar%2frun%2fslapd-BO3-E-BOZO-COM.socket";
>         arg "base cn=dns, dc=bo3,dc=e-bozo,dc=com";
>         arg "fake_mname freeipa-poc01.bo3.e-bozo.com.";
>         arg "auth_method sasl";
>         arg "sasl_mech GSSAPI";
>         arg "sasl_user DNS/freeipa-poc01.bo3.e-bozo.com";
>         arg "serial_autoincrement yes";
> };
>
>
>
>
>    Hello,
>
> which version ipa do you use? which platform? Which version
> bind-dyndb-ldap?
>
> Can you run these commands, and check if there any errors?
> ipactl status
> systemctl status named  (respectively journalctl -u named)
>
> --
> Martin Basti
>
>


-- 
If life gives you melons, you may be dyslexic.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141202/e420d3ab/attachment.htm>

From simo at redhat.com  Tue Dec  2 18:47:30 2014
From: simo at redhat.com (Simo Sorce)
Date: Tue, 2 Dec 2014 13:47:30 -0500
Subject: [Freeipa-users] ipa-getkeytab -e des3-hmac-sha1 doesnt work
In-Reply-To: <547D9DA8.4060606@kit.edu>
References: <547C4897.3080509@kit.edu>
	<20141201111514.6868d19f@willson.usersys.redhat.com>
	<547D9DA8.4060606@kit.edu>
Message-ID: <20141202134730.1b9ceb57@willson.usersys.redhat.com>

On Tue, 02 Dec 2014 12:08:24 +0100
Andreas Ladanyi <andreas.ladanyi at kit.edu> wrote:

> > On Mon, 01 Dec 2014 11:53:11 +0100
> > Andreas Ladanyi <andreas.ladanyi at kit.edu> wrote:
> >
> >> Hi,
> >>
> >> Server: FreeIPA 3.3.5, Fedora 20
> >> Client: Ubuntu 14.04
> >>
> >> ipa-getkeytab -s freeipaserver -p principal at REALM  -k
> >> /tmp/principal.keytab -e des3-hmac-sha1 -P
> >>
> >> only results in:
> >>
> >> klist -k /tmp/principal.keytab -e
> >> Keytab name: FILE:/tmp/principal.keytab
> >> KVNO Principal
> > The 2 enctypes are equivalent and can be interchanged afaik.
> >
> > Simo.
> >
> Ok.
> 
> Another question: Is it possible to generate keys with no salt instead
> of Version 5 (normal) salt ?
> 
> I want to generate a des3 key with no salt:
> 
> ipa-getkeytab -s freeipaserver -p principal at REALM -k
> /tmp/principal.keytab -e des3-hmac-sha1:v4 -P
> 
> The answer is:
> 
> Bad or unsupported salt type.
> Failed to create key material
> 
> I configured the des3-hmac-sha1:v4 in LDAP and in kdc.conf

This works for me without needing to configure anything with Freeipa
4.1 ... probably because it uses the new getkeytab control and key
generation is done on the server side.

... and I looked at the ipa-getkeytab.c code and it appears we do not
support using the v4 salt type in ipa-getkeytab with the older protocol
code which is the one used with ipa < 4.x

I am not exactly sure why we don't, I have a comment in the code that
explicitly calls out SALTTYPE_V4 as not supported, explaining we do not
support krb v4 though.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York



From matthew.herzog at gmail.com  Wed Dec  3 01:54:12 2014
From: matthew.herzog at gmail.com (Matthew Herzog)
Date: Tue, 2 Dec 2014 20:54:12 -0500
Subject: [Freeipa-users] DNS configuration
In-Reply-To: <547DEFB5.1020205@redhat.com>
References: <CABhyZ34TCzUz+fNUSCvdZ38MS7rsLMMdb_jTdfKUsmYs86fn_Q@mail.gmail.com>
	<547DEA9E.2030203@redhat.com> <547DEFB5.1020205@redhat.com>
Message-ID: <CABhyZ347EU+Q85jQJGU30yx4njC3OtL_QsJZi1MMu1ZR2Lfd2Q@mail.gmail.com>

Any other ideas? I just spun up a new VM and took the defaults on
everything while running ipa-server-install (the defaults did make sense)
and my new VM can't resolve -anything- in the domain in which it lives. The
"old" VM (running the same versions of everything on the same OS) can't
even resolve the clients I have registered with it!

So I'm pretty frustrated and am wondering, what _exactly_ is the role of
bind in the IPA server and how is it expected to know anything about the
local DNS domain without becoming a bind slave server?

Thanks.

On Tue, Dec 2, 2014 at 11:58 AM, Petr Spacek <pspacek at redhat.com> wrote:

> On 2.12.2014 17:36, Martin Basti wrote:
> > On 02/12/14 17:28, Matthew Herzog wrote:
> >> I just realized that my IPA servers cannot resolve ANY servers in my
> domain.
> >> What do I need to do to fix this? Below is my named.conf.
> >>
> >>
> >> options {
> >>         // turns on IPv6 for port 53, IPv4 is on by default for all
> ifaces
> >>         listen-on-v6 {any;};
> >>
> >>         // Put files that named is allowed to write in the data/
> directory:
> >>         directory "/var/named"; // the default
> >>         dump-file               "data/cache_dump.db";
> >>         statistics-file         "data/named_stats.txt";
> >>         memstatistics-file  "data/named_mem_stats.txt";
> >>
> >>         forward first;
> >>         forwarders {
> >>                 10.100.8.41;
> >>                 10.100.8.40;
> >>                 10.100.4.13;
> >>                 10.100.4.14;
> >>                 10.100.4.19;
> >>                 10.100.4.44;
> >>         };
> >>
> >>         // Any host is permitted to issue recursive queries
> >>         allow-recursion { any; };
> >>
> >>         tkey-gssapi-keytab "/etc/named.keytab";
> >>         pid-file "/run/named/named.pid";
> >> };
> >>
> >> /* If you want to enable debugging, eg. using the 'rndc trace' command,
> >>  * By default, SELinux policy does not allow named to modify the
> /var/named
> >> directory,
> >>  * so put the default debug log file in data/ :
> >>  */
> >> logging {
> >>         channel default_debug {
> >>                 file "data/named.run";
> >>                 severity dynamic;
> >>                 print-time yes;
> >>         };
> >>         };
> >> };
> >>
> >> zone "." IN {
> >>         type hint;
> >>         file "named.ca <http://named.ca>";
> >> };
> >>
> >> include "/etc/named.rfc1912.zones";
> >>
> >> dynamic-db "ipa" {
> >>         library "ldap.so";
> >>         arg "uri ldapi://%2fvar%2frun%2fslapd-BO3-E-BOZO-COM.socket";
> >>         arg "base cn=dns, dc=bo3,dc=e-bozo,dc=com";
> >>         arg "fake_mname freeipa-poc01.bo3.e-bozo.com
> >> <http://freeipa-poc01.bo3.e-bozo.com>.";
> >>         arg "auth_method sasl";
> >>         arg "sasl_mech GSSAPI";
> >>         arg "sasl_user DNS/freeipa-poc01.bo3.e-bozo.com
> >> <http://freeipa-poc01.bo3.e-bozo.com>";
> >>         arg "serial_autoincrement yes";
> >> };
> >>
> >>
> >>
> >>
> > Hello,
> >
> > which version ipa do you use? which platform? Which version
> bind-dyndb-ldap?
> >
> > Can you run these commands, and check if there any errors?
> > ipactl status
> > systemctl status named  (respectively journalctl -u named)
>
> We also may want to see information listed on page
> https://fedorahosted.org/bind-dyndb-ldap/wiki/BugReporting
>
> --
> Petr^2 Spacek
>
> --
> 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
>



-- 
If life gives you melons, you may be dyslexic.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141202/a70601c1/attachment.htm>

From dpal at redhat.com  Wed Dec  3 03:35:56 2014
From: dpal at redhat.com (Dmitri Pal)
Date: Tue, 02 Dec 2014 22:35:56 -0500
Subject: [Freeipa-users] DNS configuration
In-Reply-To: <CABhyZ347EU+Q85jQJGU30yx4njC3OtL_QsJZi1MMu1ZR2Lfd2Q@mail.gmail.com>
References: <CABhyZ34TCzUz+fNUSCvdZ38MS7rsLMMdb_jTdfKUsmYs86fn_Q@mail.gmail.com>	<547DEA9E.2030203@redhat.com>
	<547DEFB5.1020205@redhat.com>
	<CABhyZ347EU+Q85jQJGU30yx4njC3OtL_QsJZi1MMu1ZR2Lfd2Q@mail.gmail.com>
Message-ID: <547E851C.1020407@redhat.com>

On 12/02/2014 08:54 PM, Matthew Herzog wrote:
> Any other ideas? I just spun up a new VM and took the defaults on 
> everything while running ipa-server-install (the defaults did make 
> sense) and my new VM can't resolve -anything- in the domain in which 
> it lives. The "old" VM (running the same versions of everything on the 
> same OS) can't even resolve the clients I have registered with it!
>
> So I'm pretty frustrated and am wondering, what _exactly_ is the role 
> of bind in the IPA server and how is it expected to know anything 
> about the local DNS domain without becoming a bind slave server?

I am not sure I am 100% with you but...
If you use the defaults and nothing else you get to the scenario when 
IPA has its DNS but it is a self contained environment. It seems that 
this is what you observe.
It is expected that you decide in advance what you want to do with DNS. 
There are several options:
1) You can delegate a zone to IPA to manage, then you need to connect 
your IPA DNS to your existing DNS during install or after.
In this case the systems joined to IPA will be a part of IPA domain/zone 
and would also be able to resolve other systems around
2) Not use IPA DNS if you do not want to take advantage of it
3) Have a self contained demo/lab environment that you currently observe.

What is the intent?

>
> Thanks.
>
> On Tue, Dec 2, 2014 at 11:58 AM, Petr Spacek <pspacek at redhat.com 
> <mailto:pspacek at redhat.com>> wrote:
>
>     On 2.12.2014 17:36, Martin Basti wrote:
>     > On 02/12/14 17:28, Matthew Herzog wrote:
>     >> I just realized that my IPA servers cannot resolve ANY servers
>     in my domain.
>     >> What do I need to do to fix this? Below is my named.conf.
>     >>
>     >>
>     >> options {
>     >>         // turns on IPv6 for port 53, IPv4 is on by default for
>     all ifaces
>     >>         listen-on-v6 {any;};
>     >>
>     >>         // Put files that named is allowed to write in the
>     data/ directory:
>     >>         directory "/var/named"; // the default
>     >>         dump-file  "data/cache_dump.db";
>     >>         statistics-file  "data/named_stats.txt";
>     >>         memstatistics-file "data/named_mem_stats.txt";
>     >>
>     >>         forward first;
>     >>         forwarders {
>     >>                 10.100.8.41;
>     >>                 10.100.8.40;
>     >>                 10.100.4.13;
>     >>                 10.100.4.14;
>     >>                 10.100.4.19;
>     >>                 10.100.4.44;
>     >>         };
>     >>
>     >>         // Any host is permitted to issue recursive queries
>     >>         allow-recursion { any; };
>     >>
>     >>         tkey-gssapi-keytab "/etc/named.keytab";
>     >>         pid-file "/run/named/named.pid";
>     >> };
>     >>
>     >> /* If you want to enable debugging, eg. using the 'rndc trace'
>     command,
>     >>  * By default, SELinux policy does not allow named to modify
>     the /var/named
>     >> directory,
>     >>  * so put the default debug log file in data/ :
>     >>  */
>     >> logging {
>     >>         channel default_debug {
>     >>                 file "data/named.run";
>     >>                 severity dynamic;
>     >>                 print-time yes;
>     >>         };
>     >>         };
>     >> };
>     >>
>     >> zone "." IN {
>     >>         type hint;
>     >>         file "named.ca <http://named.ca> <http://named.ca>";
>     >> };
>     >>
>     >> include "/etc/named.rfc1912.zones";
>     >>
>     >> dynamic-db "ipa" {
>     >>         library "ldap.so";
>     >>         arg "uri
>     ldapi://%2fvar%2frun%2fslapd-BO3-E-BOZO-COM.socket";
>     >>         arg "base cn=dns, dc=bo3,dc=e-bozo,dc=com";
>     >>         arg "fake_mname freeipa-poc01.bo3.e-bozo.com
>     <http://freeipa-poc01.bo3.e-bozo.com>
>     >> <http://freeipa-poc01.bo3.e-bozo.com>.";
>     >>         arg "auth_method sasl";
>     >>         arg "sasl_mech GSSAPI";
>     >>         arg "sasl_user DNS/freeipa-poc01.bo3.e-bozo.com
>     <http://freeipa-poc01.bo3.e-bozo.com>
>     >> <http://freeipa-poc01.bo3.e-bozo.com>";
>     >>         arg "serial_autoincrement yes";
>     >> };
>     >>
>     >>
>     >>
>     >>
>     > Hello,
>     >
>     > which version ipa do you use? which platform? Which version
>     bind-dyndb-ldap?
>     >
>     > Can you run these commands, and check if there any errors?
>     > ipactl status
>     > systemctl status named  (respectively journalctl -u named)
>
>     We also may want to see information listed on page
>     https://fedorahosted.org/bind-dyndb-ldap/wiki/BugReporting
>
>     --
>     Petr^2 Spacek
>
>     --
>     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
>
>
>
>
> -- 
> If life gives you melons, you may be dyslexic.
>
>


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141202/240a7311/attachment.htm>

From pspacek at redhat.com  Wed Dec  3 08:46:20 2014
From: pspacek at redhat.com (Petr Spacek)
Date: Wed, 03 Dec 2014 09:46:20 +0100
Subject: [Freeipa-users] DNS configuration
In-Reply-To: <547E851C.1020407@redhat.com>
References: <CABhyZ34TCzUz+fNUSCvdZ38MS7rsLMMdb_jTdfKUsmYs86fn_Q@mail.gmail.com>	<547DEA9E.2030203@redhat.com>	<547DEFB5.1020205@redhat.com>	<CABhyZ347EU+Q85jQJGU30yx4njC3OtL_QsJZi1MMu1ZR2Lfd2Q@mail.gmail.com>
	<547E851C.1020407@redhat.com>
Message-ID: <547ECDDC.3090001@redhat.com>

On 3.12.2014 04:35, Dmitri Pal wrote:
> On 12/02/2014 08:54 PM, Matthew Herzog wrote:
>> Any other ideas? I just spun up a new VM and took the defaults on everything
>> while running ipa-server-install (the defaults did make sense) and my new VM
>> can't resolve -anything- in the domain in which it lives. The "old" VM
>> (running the same versions of everything on the same OS) can't even resolve
>> the clients I have registered with it!
>>
>> So I'm pretty frustrated and am wondering, what _exactly_ is the role of
>> bind in the IPA server and how is it expected to know anything about the
>> local DNS domain without becoming a bind slave server?
> 
> I am not sure I am 100% with you but...
> If you use the defaults and nothing else you get to the scenario when IPA has
> its DNS but it is a self contained environment. It seems that this is what you
> observe.
> It is expected that you decide in advance what you want to do with DNS. There
> are several options:
> 1) You can delegate a zone to IPA to manage, then you need to connect your IPA
> DNS to your existing DNS during install or after.
> In this case the systems joined to IPA will be a part of IPA domain/zone and
> would also be able to resolve other systems around
> 2) Not use IPA DNS if you do not want to take advantage of it
> 3) Have a self contained demo/lab environment that you currently observe.
> 
> What is the intent?

I agree with Dmitri, we need more information from you:
- You said "my new VM can't resolve -anything- in the domain in which it
lives." - Which domain do you mean?

- Apparently you have configured FreeIPA to serve zone e-bozo.com. Do you have
this zone configured on some other DNS server at the same time?

Please keep in mind that authoritative servers should share the database. You
will get naming collisions if e-bozo.com is served by FreeIPA DNS servers and
some other servers at the same time. Maybe that is the problem you see right now.

As Dmitri said, the architecturally correct solution is to decide if you want
to use FreeIPA DNS or not. You have option to either remove non-FreeIPA DNS
servers and import data to FreeIPA or to add FreeIPA-specific DNS records to
existing DNS servers and do not configure FreeIPA to act as DNS server.

Petr^2 Spacek

>> Thanks.
>>
>> On Tue, Dec 2, 2014 at 11:58 AM, Petr Spacek <pspacek at redhat.com
>> <mailto:pspacek at redhat.com>> wrote:
>>
>>     On 2.12.2014 17:36, Martin Basti wrote:
>>     > On 02/12/14 17:28, Matthew Herzog wrote:
>>     >> I just realized that my IPA servers cannot resolve ANY servers
>>     in my domain.
>>     >> What do I need to do to fix this? Below is my named.conf.
>>     >>
>>     >>
>>     >> options {
>>     >>         // turns on IPv6 for port 53, IPv4 is on by default for
>>     all ifaces
>>     >>         listen-on-v6 {any;};
>>     >>
>>     >>         // Put files that named is allowed to write in the
>>     data/ directory:
>>     >>         directory "/var/named"; // the default
>>     >>         dump-file  "data/cache_dump.db";
>>     >>         statistics-file  "data/named_stats.txt";
>>     >>         memstatistics-file "data/named_mem_stats.txt";
>>     >>
>>     >>         forward first;
>>     >>         forwarders {
>>     >>                 10.100.8.41;
>>     >>                 10.100.8.40;
>>     >>                 10.100.4.13;
>>     >>                 10.100.4.14;
>>     >>                 10.100.4.19;
>>     >>                 10.100.4.44;
>>     >>         };
>>     >>
>>     >>         // Any host is permitted to issue recursive queries
>>     >>         allow-recursion { any; };
>>     >>
>>     >>         tkey-gssapi-keytab "/etc/named.keytab";
>>     >>         pid-file "/run/named/named.pid";
>>     >> };
>>     >>
>>     >> /* If you want to enable debugging, eg. using the 'rndc trace'
>>     command,
>>     >>  * By default, SELinux policy does not allow named to modify
>>     the /var/named
>>     >> directory,
>>     >>  * so put the default debug log file in data/ :
>>     >>  */
>>     >> logging {
>>     >>         channel default_debug {
>>     >>                 file "data/named.run";
>>     >>                 severity dynamic;
>>     >>                 print-time yes;
>>     >>         };
>>     >>         };
>>     >> };
>>     >>
>>     >> zone "." IN {
>>     >>         type hint;
>>     >>         file "named.ca <http://named.ca> <http://named.ca>";
>>     >> };
>>     >>
>>     >> include "/etc/named.rfc1912.zones";
>>     >>
>>     >> dynamic-db "ipa" {
>>     >>         library "ldap.so";
>>     >>         arg "uri
>>     ldapi://%2fvar%2frun%2fslapd-BO3-E-BOZO-COM.socket";
>>     >>         arg "base cn=dns, dc=bo3,dc=e-bozo,dc=com";
>>     >>         arg "fake_mname freeipa-poc01.bo3.e-bozo.com
>>     <http://freeipa-poc01.bo3.e-bozo.com>
>>     >> <http://freeipa-poc01.bo3.e-bozo.com>.";
>>     >>         arg "auth_method sasl";
>>     >>         arg "sasl_mech GSSAPI";
>>     >>         arg "sasl_user DNS/freeipa-poc01.bo3.e-bozo.com
>>     <http://freeipa-poc01.bo3.e-bozo.com>
>>     >> <http://freeipa-poc01.bo3.e-bozo.com>";
>>     >>         arg "serial_autoincrement yes";
>>     >> };
>>     >>
>>     >>
>>     >>
>>     >>
>>     > Hello,
>>     >
>>     > which version ipa do you use? which platform? Which version
>>     bind-dyndb-ldap?
>>     >
>>     > Can you run these commands, and check if there any errors?
>>     > ipactl status
>>     > systemctl status named  (respectively journalctl -u named)
>>
>>     We also may want to see information listed on page
>>     https://fedorahosted.org/bind-dyndb-ldap/wiki/BugReporting



From orkhan-azeri at mail.ru  Wed Dec  3 08:56:12 2014
From: orkhan-azeri at mail.ru (=?UTF-8?B?0J7RgNGF0LDQvSDQmtCw0YHRg9C80L7Qsg==?=)
Date: Wed, 03 Dec 2014 11:56:12 +0300
Subject: [Freeipa-users] =?utf-8?q?A_new_Quick_Start_Quide_for_FreeIPA_sof?=
	=?utf-8?q?tware?=
Message-ID: <1417596972.420092545@f337.i.mail.ru>


Hello, FreeIPA list!
About a month ago I promised to write a detailed tutorial about FreeIPA domain setup,
including both Linux and Unix (FreeBSD) clients, and now it's ready!
Use this link to download the tutorial:
https://cloud.mail.ru/public/c3209284323e/FreeIPA%20-%20FreeBSD.docx ?
I would highly appreciate if you find time to read the tutorial completely from the beginning to the end,
follow all instructions and post your comments regarding:
1) errors in wording / spelling (I'm not a native English speaker);
2) unnecessary actions (maybe the system will work perfectly well without performing some steps);
3) insufficient comments on some instructions (maybe you can give a better BRIEF description for some steps).
The only thing I would ask anyone willing to collaborate
is to read the tutorial completely before commenting on anything!
If you collaborate on this subject, we'll be able to prepare
a new and actual Quick Start Quide for FreeIPA software.
Thanks for your attention, time and efforts!

------------------------
Orkhan Gasymov.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141203/83f5cc8d/attachment.htm>

From michael.tiernan at gmail.com  Wed Dec  3 13:15:51 2014
From: michael.tiernan at gmail.com (Michael Tiernan)
Date: Wed, 03 Dec 2014 08:15:51 -0500
Subject: [Freeipa-users] A new Quick Start Quide for FreeIPA software
In-Reply-To: <1417596972.420092545@f337.i.mail.ru>
References: <1417596972.420092545@f337.i.mail.ru>
Message-ID: <547F0D07.5000408@gMail.com>

On 12/3/14 3:56 AM, ????? ??????? wrote:
>
> Hello, FreeIPA list!
>
> About a month ago I promised to write a detailed tutorial about
> FreeIPA domain setup,
> including both Linux and Unix (FreeBSD) clients, and now it's ready!
>
> Use this link to download the tutorial:
> https://cloud.mail.ru/public/c3209284323e/FreeIPA%20-%20FreeBSD.docx
>

How about posting it in an open format? OpenOffice or PDF would be
appreciated.



From andreas.ladanyi at kit.edu  Wed Dec  3 13:37:55 2014
From: andreas.ladanyi at kit.edu (Andreas Ladanyi)
Date: Wed, 03 Dec 2014 14:37:55 +0100
Subject: [Freeipa-users] Cross-Realm authentification
Message-ID: <547F1233.4020709@kit.edu>

Hi,

iam trying to setup a cross-realm relationship.

Generated krbtgt cross-realm principals on both KDCs with the same
password and kvno:

krbtgt/REALM_B (MIT Kerberos)@REALM_A (FreeIPA 3.3.5)
krbtgt/REALM_A at REALM_B

getprinc on REALM_A KDC for principal krbtgt/REALM_B at REALM_A:

Number of keys: 4
Key: vno 1, aes256-cts-hmac-sha1-96, Version 5
Key: vno 1, aes128-cts-hmac-sha1-96, Version 5
Key: vno 1, des3-cbc-sha1, Version 5
Key: vno 1, arcfour-hmac, Version 5
MKey: vno 1

getprinc on REALM_A KDC for principal krbtgt/REALM_A at REALM_B:

Number of keys: 4
Key: vno 1, aes256-cts-hmac-sha1-96, Version 5
Key: vno 1, aes128-cts-hmac-sha1-96, Version 5
Key: vno 1, des3-cbc-sha1, Version 5
Key: vno 1, arcfour-hmac, Version 5
MKey: vno 1

getprinc on REALM_B KDC for principal krbtgt/REALM_B at REALM_A:

Number of keys: 6
Key: vno 1, Triple DES cbc mode with HMAC/sha1, no salt
Key: vno 1, DES cbc mode with CRC-32, no salt
Key: vno 1, DES cbc mode with RSA-MD5, Version 4
Key: vno 1, DES cbc mode with RSA-MD5, Version 5 - No Realm
Key: vno 1, DES cbc mode with RSA-MD5, Version 5 - Realm Only
Key: vno 1, DES cbc mode with RSA-MD5, AFS version 3
MKey: vno 1

getprinc on REALM_B KDC for principal krbtgt/REALM_A at REALM_B:

Number of keys: 6
Key: vno 1, Triple DES cbc mode with HMAC/sha1, no salt
Key: vno 1, DES cbc mode with CRC-32, no salt
Key: vno 1, DES cbc mode with RSA-MD5, Version 4
Key: vno 1, DES cbc mode with RSA-MD5, Version 5 - No Realm
Key: vno 1, DES cbc mode with RSA-MD5, Version 5 - Realm Only
Key: vno 1, DES cbc mode with RSA-MD5, AFS version 3
MKey: vno 1


I set up the [capaths] section in the krb5.conf client config:

[capaths]
REALM_A = {
    REALM_B = .
    }
REALM_B = {
    REALM_A = .
    }



TEST for the REALM_B (FreeIPA) System:

1. kinit user: get a krbtgt/REALM_B at REALM_B

2. kvno krbtgt/REALM_A at REALM_B: get cross-realm ticket
krbtgt/REALM_A at REALM_B: kvno = 1

3. kvno host/( FQDN of host in REALM_A )@REALM_A:
kvno: KDC returned error string: PROCESS_TGS while getting credentials
for host/( FQDN of host in REALM_A )@REALM_A.

4. kvno user at REALM_A:
kvno: KDC returned error string: PROCESS_TGS while getting credentials
for user at REALM_A.


Because i get a cross realm ticket in step 2 iam the opinion i setup the
cross realm ticket correctly on both sides. I think only step 3/4 is the
problem because i dont get tickets for a user/host principal in the REALM_A


Any ideas ?

Andreas


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5306 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141203/df30b7bb/attachment.p7s>

From orkhan-azeri at mail.ru  Wed Dec  3 13:41:24 2014
From: orkhan-azeri at mail.ru (=?UTF-8?B?0J7RgNGF0LDQvSDQmtCw0YHRg9C80L7Qsg==?=)
Date: Wed, 03 Dec 2014 16:41:24 +0300
Subject: [Freeipa-users]
 =?utf-8?q?A_new_Quick_Start_Quide_for_FreeIPA_sof?=
 =?utf-8?q?tware?=
In-Reply-To: <547F0D07.5000408@gMail.com>
References: <1417596972.420092545@f337.i.mail.ru> <547F0D07.5000408@gMail.com>
Message-ID: <1417614084.596211507@f140.i.mail.ru>

 Of course:  https://cloud.mail.ru/public/a3f4a72d9744/freeipa-freebsd.odt



Wed, 03 Dec 2014 08:15:51 -0500 ?? Michael Tiernan <michael.tiernan at gmail.com>:
>On 12/3/14 3:56 AM, ????? ??????? wrote:
>>
>> Hello, FreeIPA list!
>>
>> About a month ago I promised to write a detailed tutorial about
>> FreeIPA domain setup,
>> including both Linux and Unix (FreeBSD) clients, and now it's ready!
>>
>> Use this link to download the tutorial:
>>  https://cloud.mail.ru/public/c3209284323e/FreeIPA%20-%20FreeBSD.docx
>>
>
>How about posting it in an open format? OpenOffice or PDF would be
>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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141203/7e542f8c/attachment.htm>

From abokovoy at redhat.com  Wed Dec  3 13:53:51 2014
From: abokovoy at redhat.com (Alexander Bokovoy)
Date: Wed, 3 Dec 2014 15:53:51 +0200
Subject: [Freeipa-users] Cross-Realm authentification
In-Reply-To: <547F1233.4020709@kit.edu>
References: <547F1233.4020709@kit.edu>
Message-ID: <20141203135351.GG16288@redhat.com>

On Wed, 03 Dec 2014, Andreas Ladanyi wrote:
>Hi,
>
>iam trying to setup a cross-realm relationship.
>
>Generated krbtgt cross-realm principals on both KDCs with the same
>password and kvno:
>
>krbtgt/REALM_B (MIT Kerberos)@REALM_A (FreeIPA 3.3.5)
>krbtgt/REALM_A at REALM_B
>
>getprinc on REALM_A KDC for principal krbtgt/REALM_B at REALM_A:
>
>Number of keys: 4
>Key: vno 1, aes256-cts-hmac-sha1-96, Version 5
>Key: vno 1, aes128-cts-hmac-sha1-96, Version 5
>Key: vno 1, des3-cbc-sha1, Version 5
>Key: vno 1, arcfour-hmac, Version 5
>MKey: vno 1
>
>getprinc on REALM_A KDC for principal krbtgt/REALM_A at REALM_B:
>
>Number of keys: 4
>Key: vno 1, aes256-cts-hmac-sha1-96, Version 5
>Key: vno 1, aes128-cts-hmac-sha1-96, Version 5
>Key: vno 1, des3-cbc-sha1, Version 5
>Key: vno 1, arcfour-hmac, Version 5
>MKey: vno 1
>
>getprinc on REALM_B KDC for principal krbtgt/REALM_B at REALM_A:
>
>Number of keys: 6
>Key: vno 1, Triple DES cbc mode with HMAC/sha1, no salt
>Key: vno 1, DES cbc mode with CRC-32, no salt
>Key: vno 1, DES cbc mode with RSA-MD5, Version 4
>Key: vno 1, DES cbc mode with RSA-MD5, Version 5 - No Realm
>Key: vno 1, DES cbc mode with RSA-MD5, Version 5 - Realm Only
>Key: vno 1, DES cbc mode with RSA-MD5, AFS version 3
>MKey: vno 1
>
>getprinc on REALM_B KDC for principal krbtgt/REALM_A at REALM_B:
>
>Number of keys: 6
>Key: vno 1, Triple DES cbc mode with HMAC/sha1, no salt
>Key: vno 1, DES cbc mode with CRC-32, no salt
>Key: vno 1, DES cbc mode with RSA-MD5, Version 4
>Key: vno 1, DES cbc mode with RSA-MD5, Version 5 - No Realm
>Key: vno 1, DES cbc mode with RSA-MD5, Version 5 - Realm Only
>Key: vno 1, DES cbc mode with RSA-MD5, AFS version 3
>MKey: vno 1
>
>
>I set up the [capaths] section in the krb5.conf client config:
>
>[capaths]
>REALM_A = {
>    REALM_B = .
>    }
>REALM_B = {
>    REALM_A = .
>    }
You need this section on both realm's KDCs.


-- 
/ Alexander Bokovoy



From sipazzo at yahoo.com  Wed Dec  3 14:05:23 2014
From: sipazzo at yahoo.com (sipazzo)
Date: Wed, 3 Dec 2014 06:05:23 -0800
Subject: [Freeipa-users] sudo utilizing sssd rhel6.6
Message-ID: <1417615523.93665.YahooMailBasic@web122506.mail.ne1.yahoo.com>

Good morning, I have a fairly new ipa domain (server version 3.0.0-42 and clients mixed 3.0.0-37 and 3.0.0-42) set up with a mix of rhel6, rhel5 and solaris. It seemed like my sudo config using sssd in rhel6.5 was working and then we patched to 6.6 and it is broken. I had followed these setup instructions previously:

yum install -y libsss_sudo

Added to /etc/nsswitch.conf

sudoers: sss files

Add nisdomainname:

nisdomainname ipadomain.com
echo "NISDOMAIN=ipadomain.com" >> /etc/sysconfig/network

Added the following to /etc/sssd/sssd.conf (is all this really necessary?)

[domain/ipadomain.com]
???.

sudo_provider = ldap
ldap_uri = ldaps://ipasrv2-corp.ipadomain.com, ldaps://ipasrv1-xo.ipadomain.com, ldaps://ipasrv1-io.ipadomain.com, ldaps://ipasrv1-corp.ipadomain.com, ldaps://ipasrv2-xo.ipadomain.com, ldaps://ipasrv2-io.ipadomain.com
ldap_sudo_search_base = ou=sudoers,dc=ipadomain,dc=com
ldap_sasl_mech = GSSAPI    
ldap_sasl_authid = host/ipaclient1.ipadomain.com  
ldap_sasl_realm = ipadomain.COM
krb5_server =ipasrv2-corp.ipadomain.com, ipasrv1-xo.ipadomain.com, ipasrv1-io.ipadomain.com, ipasrv1-corp.ipadomain.com, ipasrv2-xo.ipadomain.com, ipasrv2-io.ipadomain.com

[sssd]
services =  nss, pam, sudo, ssh

[sudo]


Restart sssd service

I know that libsss_sudo is now included as part of another package and read that you need sssd-common which I tried installing to no avail as well. I had been told that despite the man pages on sssd I needed to specify the servers in ldap_uri (and I assume krb5_server) as it would not use SRV records but am not sure that is correct. 

Questions:
1) What are the steps to get sudo working with sssd on an existing, newly patched (to rhel6.6) system
2) Are the steps any different for a new system (i.e. I read it is "seamless" but I guess we still have to manually edit files?)
3) Does sssd in Rhel6.6 support SRV lookup for the ldap_uri and krb5_server and do we have to specify the ldap_sasl_authid with the client hostname

Thank you for any assistance.



From jhrozek at redhat.com  Wed Dec  3 15:06:15 2014
From: jhrozek at redhat.com (Jakub Hrozek)
Date: Wed, 3 Dec 2014 16:06:15 +0100
Subject: [Freeipa-users] sudo utilizing sssd rhel6.6
In-Reply-To: <1417615523.93665.YahooMailBasic@web122506.mail.ne1.yahoo.com>
References: <1417615523.93665.YahooMailBasic@web122506.mail.ne1.yahoo.com>
Message-ID: <20141203150615.GI3916@hendrix.redhat.com>

On Wed, Dec 03, 2014 at 06:05:23AM -0800, sipazzo wrote:
> Good morning, I have a fairly new ipa domain (server version 3.0.0-42 and clients mixed 3.0.0-37 and 3.0.0-42) set up with a mix of rhel6, rhel5 and solaris. It seemed like my sudo config using sssd in rhel6.5 was working and then we patched to 6.6 and it is broken. I had followed these setup instructions previously:
> 
> yum install -y libsss_sudo
> 
> Added to /etc/nsswitch.conf
> 
> sudoers: sss files
> 
> Add nisdomainname:
> 
> nisdomainname ipadomain.com
> echo "NISDOMAIN=ipadomain.com" >> /etc/sysconfig/network
> 
> Added the following to /etc/sssd/sssd.conf (is all this really necessary?)
> 
> [domain/ipadomain.com]
> ???.
> 
> sudo_provider = ldap
> ldap_uri = ldaps://ipasrv2-corp.ipadomain.com, ldaps://ipasrv1-xo.ipadomain.com, ldaps://ipasrv1-io.ipadomain.com, ldaps://ipasrv1-corp.ipadomain.com, ldaps://ipasrv2-xo.ipadomain.com, ldaps://ipasrv2-io.ipadomain.com
> ldap_sudo_search_base = ou=sudoers,dc=ipadomain,dc=com
> ldap_sasl_mech = GSSAPI    
> ldap_sasl_authid = host/ipaclient1.ipadomain.com  
> ldap_sasl_realm = ipadomain.COM
> krb5_server =ipasrv2-corp.ipadomain.com, ipasrv1-xo.ipadomain.com, ipasrv1-io.ipadomain.com, ipasrv1-corp.ipadomain.com, ipasrv2-xo.ipadomain.com, ipasrv2-io.ipadomain.com
> 
> [sssd]
> services =  nss, pam, sudo, ssh
> 
> [sudo]
> 
> 
> Restart sssd service
> 
> I know that libsss_sudo is now included as part of another package and read that you need sssd-common which I tried installing to no avail as well. I had been told that despite the man pages on sssd I needed to specify the servers in ldap_uri (and I assume krb5_server) as it would not use SRV records but am not sure that is correct. 
> 
> Questions:
> 1) What are the steps to get sudo working with sssd on an existing, newly patched (to rhel6.6) system

Starting with 6.6 the procedure was simplified to:
 * add sudo_provider=ipa to sssd.conf's domain section
 * add sss to the sudoers line of nsswitch.conf

> 2) Are the steps any different for a new system (i.e. I read it is "seamless" but I guess we still have to manually edit files?)

I'm not 100% sure if the ipa-client-install patches made it to 6.6 or
not, but with very recent (7.1) ipa-client-install, everything should
just work and be set up by the installer

> 3) Does sssd in Rhel6.6 support SRV lookup for the ldap_uri and krb5_server and do we have to specify the ldap_sasl_authid with the client hostname

SRV records - yes
ldap_sasl_authid - you don't need that starting with 6.6



From lslebodn at redhat.com  Wed Dec  3 15:38:49 2014
From: lslebodn at redhat.com (Lukas Slebodnik)
Date: Wed, 3 Dec 2014 16:38:49 +0100
Subject: [Freeipa-users] sudo utilizing sssd rhel6.6
In-Reply-To: <1417615523.93665.YahooMailBasic@web122506.mail.ne1.yahoo.com>
References: <1417615523.93665.YahooMailBasic@web122506.mail.ne1.yahoo.com>
Message-ID: <20141203153849.GH8388@mail.corp.redhat.com>

On (03/12/14 06:05), sipazzo wrote:
>Good morning, I have a fairly new ipa domain (server version 3.0.0-42 and clients mixed 3.0.0-37 and 3.0.0-42) set up with a mix of rhel6, rhel5 and solaris. It seemed like my sudo config using sssd in rhel6.5 was working and then we patched to 6.6 and it is broken. I had followed these setup instructions previously:
>
>yum install -y libsss_sudo
>
>Added to /etc/nsswitch.conf
>
>sudoers: sss files
>
>Add nisdomainname:
>
>nisdomainname ipadomain.com
>echo "NISDOMAIN=ipadomain.com" >> /etc/sysconfig/network
>
>Added the following to /etc/sssd/sssd.conf (is all this really necessary?)
>
>[domain/ipadomain.com]
>???.
>
>sudo_provider = ldap
>ldap_uri = ldaps://ipasrv2-corp.ipadomain.com, ldaps://ipasrv1-xo.ipadomain.com, ldaps://ipasrv1-io.ipadomain.com, ldaps://ipasrv1-corp.ipadomain.com, ldaps://ipasrv2-xo.ipadomain.com, ldaps://ipasrv2-io.ipadomain.com
>ldap_sudo_search_base = ou=sudoers,dc=ipadomain,dc=com
>ldap_sasl_mech = GSSAPI    
>ldap_sasl_authid = host/ipaclient1.ipadomain.com  
>ldap_sasl_realm = ipadomain.COM
>krb5_server =ipasrv2-corp.ipadomain.com, ipasrv1-xo.ipadomain.com, ipasrv1-io.ipadomain.com, ipasrv1-corp.ipadomain.com, ipasrv2-xo.ipadomain.com, ipasrv2-io.ipadomain.com
>
>[sssd]
>services =  nss, pam, sudo, ssh
>
>[sudo]
>
>
>Restart sssd service
>
>I know that libsss_sudo is now included as part of another package and read that you need sssd-common which I tried installing to no avail as well. I had been told that despite the man pages on sssd I needed to specify the servers in ldap_uri (and I assume krb5_server) as it would not use SRV records but am not sure that is correct. 
>
>Questions:
>1) What are the steps to get sudo working with sssd on an existing, newly patched (to rhel6.6) system
Configuration from rhel 6.5 shoudl work also on rhel 6.6

But rhel 6.6 can work also with sudo_provider = ipa
In this case sssd configuration is easier. You cna find details in manual page
man sssd-sudo.


>2) Are the steps any different for a new system (i.e. I read it is "seamless" but I guess we still have to manually edit files?)
On rhel6.6 ipa-client-install should configure sudo unless you executed
ipa-client-install with --no-sudo

>3) Does sssd in Rhel6.6 support SRV lookup for the ldap_uri and krb5_server and do we have to specify the ldap_sasl_authid with the client hostname
Yes, it does.
man sssd.ldap -> SERVICE DISCOVERY

If you use sudo_provider=ipa then you will not need to configure all ldap_*
krb5_* options on your own.

LS



From janellenicole80 at gmail.com  Wed Dec  3 17:23:13 2014
From: janellenicole80 at gmail.com (Janelle)
Date: Wed, 03 Dec 2014 09:23:13 -0800
Subject: [Freeipa-users] strange error - disconnecting a replica?
Message-ID: <547F4701.5060501@gmail.com>

Hi all..

Was on vacation - now I'm back. Have a new problem I thought I would run 
by you --

I have replica agreements between a server and 3 others. They all show 
up in ipa-replica-manage list, BUT when I try to disconnect one of them :

ipa: INFO: Replication Update in progress: FALSE: status: 1 Can't 
acquire busy replica: start: 0: end: 0

Any idea what this might be telling me? And any ideas on how to reduce 
CPU load on replicas other than to reduce the number of hosts they 
replicate to?

Thanks
~J



From janellenicole80 at gmail.com  Wed Dec  3 21:40:07 2014
From: janellenicole80 at gmail.com (Janelle)
Date: Wed, 03 Dec 2014 13:40:07 -0800
Subject: [Freeipa-users] strange replica install error (another one)
Message-ID: <547F8337.4020301@gmail.com>

Here is a bit of baffling one on 4.0.5:

Replica install p11-kit???

Connection from master to replica is OK.

Connection check OK
p11-kit: ipa.p11-kit: x-public-key-info: invalid or unsupported attribute
Configuring NTP daemon (ntpd)
   [1/4]: stopping ntpd
   [2/4]: writing configuration
...

Your system may be partly configured.
Run /usr/sbin/ipa-server-install --uninstall to clean up.

LDAP error: UNWILLING_TO_PERFORM
database is read-only


Thoughts?
~J



From dpal at redhat.com  Wed Dec  3 22:56:57 2014
From: dpal at redhat.com (Dmitri Pal)
Date: Wed, 03 Dec 2014 17:56:57 -0500
Subject: [Freeipa-users] strange replica install error (another one)
In-Reply-To: <547F8337.4020301@gmail.com>
References: <547F8337.4020301@gmail.com>
Message-ID: <547F9539.50602@redhat.com>

On 12/03/2014 04:40 PM, Janelle wrote:
> Here is a bit of baffling one on 4.0.5:
>
> Replica install p11-kit???

This is a part of the DNSSEC set of packages.

>
> Connection from master to replica is OK.
>
> Connection check OK
> p11-kit: ipa.p11-kit: x-public-key-info: invalid or unsupported attribute
> Configuring NTP daemon (ntpd)
>   [1/4]: stopping ntpd
>   [2/4]: writing configuration
> ...
>
> Your system may be partly configured.
> Run /usr/sbin/ipa-server-install --uninstall to clean up.
>
> LDAP error: UNWILLING_TO_PERFORM
> database is read-only
>
>
> Thoughts?
> ~J
>


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.



From janellenicole80 at gmail.com  Thu Dec  4 04:02:39 2014
From: janellenicole80 at gmail.com (Janelle)
Date: Wed, 03 Dec 2014 20:02:39 -0800
Subject: [Freeipa-users] strange replica install error (another one)
In-Reply-To: <547F9539.50602@redhat.com>
References: <547F8337.4020301@gmail.com> <547F9539.50602@redhat.com>
Message-ID: <547FDCDF.6060200@gmail.com>

Thanks -- still a bit strange that it did not show up on some servers - 
vary random and intermittent.

BTW - a bit of information others might find useful.  If you try to use 
the "LDAP" portion of IPA for authentication - rather than fulling 
installing the IPA client and using Kerberos - the servers running 
ds-389 do not do well in handling the load. In other words - a few 
hundred hosts trying to authenticate via LDAP only will send CPU through 
the roof and crashes the slapd process often.   Since IPA is supposed to 
handle all options, I guess I am disappointed.

regards
~J


On 12/3/14 2:56 PM, Dmitri Pal wrote:
> On 12/03/2014 04:40 PM, Janelle wrote:
>> Here is a bit of baffling one on 4.0.5:
>>
>> Replica install p11-kit???
>
> This is a part of the DNSSEC set of packages.
>
>>
>> Connection from master to replica is OK.
>>
>> Connection check OK
>> p11-kit: ipa.p11-kit: x-public-key-info: invalid or unsupported 
>> attribute
>> Configuring NTP daemon (ntpd)
>>   [1/4]: stopping ntpd
>>   [2/4]: writing configuration
>> ...
>>
>> Your system may be partly configured.
>> Run /usr/sbin/ipa-server-install --uninstall to clean up.
>>
>> LDAP error: UNWILLING_TO_PERFORM
>> database is read-only
>>
>>
>> Thoughts?
>> ~J
>>
>
>



From pspacek at redhat.com  Thu Dec  4 07:45:43 2014
From: pspacek at redhat.com (Petr Spacek)
Date: Thu, 04 Dec 2014 08:45:43 +0100
Subject: [Freeipa-users] strange replica install error (another one)
In-Reply-To: <547FDCDF.6060200@gmail.com>
References: <547F8337.4020301@gmail.com> <547F9539.50602@redhat.com>
	<547FDCDF.6060200@gmail.com>
Message-ID: <54801127.3060404@redhat.com>

On 4.12.2014 05:02, Janelle wrote:
> Thanks -- still a bit strange that it did not show up on some servers - vary
> random and intermittent.
> 
> BTW - a bit of information others might find useful.  If you try to use the
> "LDAP" portion of IPA for authentication - rather than fulling installing the
> IPA client and using Kerberos - the servers running ds-389 do not do well in
> handling the load. In other words - a few hundred hosts trying to authenticate
> via LDAP only will send CPU through the roof and crashes the slapd process
> often.   Since IPA is supposed to handle all options, I guess I am disappointed.
> 
> regards
> ~J
> 
> 
> On 12/3/14 2:56 PM, Dmitri Pal wrote:
>> On 12/03/2014 04:40 PM, Janelle wrote:
>>> Here is a bit of baffling one on 4.0.5:
>>>
>>> Replica install p11-kit???
>>
>> This is a part of the DNSSEC set of packages.
>>
>>>
>>> Connection from master to replica is OK.
>>>
>>> Connection check OK
>>> p11-kit: ipa.p11-kit: x-public-key-info: invalid or unsupported attribute
>>> Configuring NTP daemon (ntpd)
>>>   [1/4]: stopping ntpd
>>>   [2/4]: writing configuration
>>> ...
>>>
>>> Your system may be partly configured.
>>> Run /usr/sbin/ipa-server-install --uninstall to clean up.
>>>
>>> LDAP error: UNWILLING_TO_PERFORM
>>> database is read-only
>>>
>>>
>>> Thoughts?

We need more information about your problem.

As always, please start with information requested on
http://www.freeipa.org/page/Troubleshooting#Reporting_bugs

/var/log/ipa*.log from affected replica will be invaluable (along with exact
package version numbers [including p11-kit] and repo configuration).

-- 
Petr^2 Spacek



From andreas.ladanyi at kit.edu  Thu Dec  4 09:25:15 2014
From: andreas.ladanyi at kit.edu (Andreas Ladanyi)
Date: Thu, 04 Dec 2014 10:25:15 +0100
Subject: [Freeipa-users] Cross-Realm authentification
In-Reply-To: <20141203135351.GG16288@redhat.com>
References: <547F1233.4020709@kit.edu> <20141203135351.GG16288@redhat.com>
Message-ID: <5480287B.4050406@kit.edu>

Am 03.12.2014 um 14:53 schrieb Alexander Bokovoy:
> On Wed, 03 Dec 2014, Andreas Ladanyi wrote:
>> Hi,
>>
>> iam trying to setup a cross-realm relationship.
>>
>> Generated krbtgt cross-realm principals on both KDCs with the same
>> password and kvno:
>>
>> krbtgt/REALM_B (MIT Kerberos)@REALM_A (FreeIPA 3.3.5)
>> krbtgt/REALM_A at REALM_B
>>
>> getprinc on REALM_A KDC for principal krbtgt/REALM_B at REALM_A:
>>
>> Number of keys: 4
>> Key: vno 1, aes256-cts-hmac-sha1-96, Version 5
>> Key: vno 1, aes128-cts-hmac-sha1-96, Version 5
>> Key: vno 1, des3-cbc-sha1, Version 5
>> Key: vno 1, arcfour-hmac, Version 5
>> MKey: vno 1
>>
>> getprinc on REALM_A KDC for principal krbtgt/REALM_A at REALM_B:
>>
>> Number of keys: 4
>> Key: vno 1, aes256-cts-hmac-sha1-96, Version 5
>> Key: vno 1, aes128-cts-hmac-sha1-96, Version 5
>> Key: vno 1, des3-cbc-sha1, Version 5
>> Key: vno 1, arcfour-hmac, Version 5
>> MKey: vno 1
>>
>> getprinc on REALM_B KDC for principal krbtgt/REALM_B at REALM_A:
>>
>> Number of keys: 6
>> Key: vno 1, Triple DES cbc mode with HMAC/sha1, no salt
>> Key: vno 1, DES cbc mode with CRC-32, no salt
>> Key: vno 1, DES cbc mode with RSA-MD5, Version 4
>> Key: vno 1, DES cbc mode with RSA-MD5, Version 5 - No Realm
>> Key: vno 1, DES cbc mode with RSA-MD5, Version 5 - Realm Only
>> Key: vno 1, DES cbc mode with RSA-MD5, AFS version 3
>> MKey: vno 1
>>
>> getprinc on REALM_B KDC for principal krbtgt/REALM_A at REALM_B:
>>
>> Number of keys: 6
>> Key: vno 1, Triple DES cbc mode with HMAC/sha1, no salt
>> Key: vno 1, DES cbc mode with CRC-32, no salt
>> Key: vno 1, DES cbc mode with RSA-MD5, Version 4
>> Key: vno 1, DES cbc mode with RSA-MD5, Version 5 - No Realm
>> Key: vno 1, DES cbc mode with RSA-MD5, Version 5 - Realm Only
>> Key: vno 1, DES cbc mode with RSA-MD5, AFS version 3
>> MKey: vno 1
>>
>>
>> I set up the [capaths] section in the krb5.conf client config:
>>
>> [capaths]
>> REALM_A = {
>>    REALM_B = .
>>    }
>> REALM_B = {
>>    REALM_A = .
>>    }
> You need this section on both realm's KDCs.
>
>

I have done this now on all (2) KDCs without a restart of kerberos
service. The error message is the same like in my first mail.

-- 

Dipl.-Ing. (FH) Andreas Ladanyi

ATIS - Abt. Technische Infrastruktur, Fakult?t f?r Informatik
Karlsruher Institut f?r Technologie (KIT)

Am Fasanengarten 5, Geb?ude 50.34, Raum 013
76131 Karlsruhe
Telefon: +49 721 608-43663

E-Mail: andreas.ladanyi at kit.edu

www.atis.informatik.kit.edu
www.kit.edu

KIT - Universit?t des Landes Baden-W?rttemberg und nationales Forschungszentrum in der Helmholtz-Gemeinschaft


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5306 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141204/1ee46e64/attachment.p7s>

From jhrozek at redhat.com  Thu Dec  4 09:34:05 2014
From: jhrozek at redhat.com (Jakub Hrozek)
Date: Thu, 4 Dec 2014 10:34:05 +0100
Subject: [Freeipa-users] FreeIPA4 OTP vs PAM
In-Reply-To: <CAAFs98XrY8XHxCJfHHD6_MPc9_KVw0hSqmr82ZjUqsjQK0veJw@mail.gmail.com>
References: <CAAFs98WnvDJtuG0msf33UpGsyxOZqaaNJBVa72zEtiU2FaE5zw@mail.gmail.com>
	<20140815080736.GO3684@hendrix.redhat.com>
	<CAAFs98UO8-oz-cBxz6T6qwyougaiy_94DVp+7=svusBAJz=Ejw@mail.gmail.com>
	<CAAFs98UC74g8ZDubkD15ZFREyCGEq9bsV3REntK+kpQG_rWYVw@mail.gmail.com>
	<CAAFs98XrY8XHxCJfHHD6_MPc9_KVw0hSqmr82ZjUqsjQK0veJw@mail.gmail.com>
Message-ID: <20141204093405.GA3916@hendrix.redhat.com>

On Sat, Nov 22, 2014 at 02:05:19PM -0800, Michael Lasevich wrote:
> I got some extra log output: seems that FAST IS being used.  I am running
> SSSD 1.11.6, which is supposed to have above mentioned issues fixed:
> 
> Log:
> =================
> (Sat Nov 22 14:55:43 2014) [[sssd[krb5_child[2451]]]]
> [find_principal_in_keytab] (0x4000): Trying to find principal host/
> ipaclient.my.domain.com at MY.DOMAIN.COM in keytab.
> (Sat Nov 22 14:55:43 2014) [[sssd[krb5_child[2451]]]] [match_principal]
> (0x1000): Principal matched to the sample (host/
> ipaclient.my.domain.com at MY.DOMAIN.COM).
> (Sat Nov 22 14:55:43 2014) [[sssd[krb5_child[2451]]]]
> [sss_child_krb5_trace_cb] (0x4000): [2451] 1416693343.361296: Retrieving
> host/ipaclient.my.domain.com at MY.DOMAIN.COM -> krbtgt/
> MY.DOMAIN.COM at MY.DOMAIN.COM from FILE:/var/lib/sss/db/
> fast_ccache_MY.DOMAIN.COM with result: 0/Success
> (Sat Nov 22 14:55:43 2014) [[sssd[krb5_child[2451]]]] [check_fast_ccache]
> (0x0200): FAST TGT is still valid.
> (Sat Nov 22 14:55:43 2014) [[sssd[krb5_child[2451]]]] [main] (0x0400): Will
> perform online auth
> (Sat Nov 22 14:55:43 2014) [[sssd[krb5_child[2451]]]] [tgt_req_child]
> (0x1000): Attempting to get a TGT
> (Sat Nov 22 14:55:43 2014) [[sssd[krb5_child[2451]]]] [get_and_save_tgt]
> (0x0400): Attempting kinit for realm [MY.DOMAIN.COM]
> (Sat Nov 22 14:55:43 2014) [[sssd[krb5_child[2451]]]]
> [sss_child_krb5_trace_cb] (0x4000): [2451] 1416693343.361440: Getting
> initial credentials for michael at MY.DOMAIN.COM
> (Sat Nov 22 14:55:43 2014) [[sssd[krb5_child[2451]]]]
> [sss_child_krb5_trace_cb] (0x4000): [2451] 1416693343.361508: FAST armor
> ccache: FILE:/var/lib/sss/db/fast_ccache_MY.DOMAIN.COM
> (Sat Nov 22 14:55:43 2014) [[sssd[krb5_child[2451]]]]
> [sss_child_krb5_trace_cb] (0x4000): [2451] 1416693343.361575: Retrieving
> host/ipaclient.my.domain.com at MY.DOMAIN.COM ->
> krb5_ccache_conf_data/fast_avail/krbtgt\/MY.DOMAIN.COM
> \@MY.DOMAIN.COM at X-CACHECONF: from FILE:/var/lib/sss/db/
> fast_ccache_MY.DOMAIN.COM with result: -1765328243/Matching credential not
> found
> (Sat Nov 22 14:55:43 2014) [[sssd[krb5_child[2451]]]]
> [sss_child_krb5_trace_cb] (0x4000): [2451] 1416693343.361648: Sending
> request (188 bytes) to MY.DOMAIN.COM
> (Sat Nov 22 14:55:43 2014) [[sssd[krb5_child[2451]]]]
> [sss_child_krb5_trace_cb] (0x4000): [2451] 1416693343.361842: Sending
> initial UDP request to dgram 1.1.1.2:88
> (Sat Nov 22 14:55:43 2014) [[sssd[krb5_child[2451]]]]
> [sss_child_krb5_trace_cb] (0x4000): [2451] 1416693343.365901: Received
> answer from dgram 1.1.1.2:88
> (Sat Nov 22 14:55:43 2014) [[sssd[krb5_child[2451]]]]
> [sss_child_krb5_trace_cb] (0x4000): [2451] 1416693343.365981: Response was
> from master KDC
> (Sat Nov 22 14:55:43 2014) [[sssd[krb5_child[2451]]]]
> [sss_child_krb5_trace_cb] (0x4000): [2451] 1416693343.366020: Received
> error from KDC: -1765328359/Additional pre-authentication required
> (Sat Nov 22 14:55:43 2014) [[sssd[krb5_child[2451]]]]
> [sss_child_krb5_trace_cb] (0x4000): [2451] 1416693343.366051: Upgrading to
> FAST due to presence of PA_FX_FAST in reply
> (Sat Nov 22 14:55:43 2014) [[sssd[krb5_child[2451]]]]
> [sss_child_krb5_trace_cb] (0x4000): [2451] 1416693343.366075: Restarting to
> upgrade to FAST
> (Sat Nov 22 14:55:43 2014) [[sssd[krb5_child[2451]]]]
> [sss_child_krb5_trace_cb] (0x4000): [2451] 1416693343.366102: FAST armor
> ccache: FILE:/var/lib/sss/db/fast_ccache_MY.DOMAIN.COM
> (Sat Nov 22 14:55:43 2014) [[sssd[krb5_child[2451]]]]
> [sss_child_krb5_trace_cb] (0x4000): [2451] 1416693343.366161: Retrieving
> host/ipaclient.my.domain.com at MY.DOMAIN.COM ->
> krb5_ccache_conf_data/fast_avail/krbtgt\/MY.DOMAIN.COM
> \@MY.DOMAIN.COM at X-CACHECONF: from FILE:/var/lib/sss/db/
> fast_ccache_MY.DOMAIN.COM with result: -1765328243/Matching credential not
> found
> (Sat Nov 22 14:55:43 2014) [[sssd[krb5_child[2451]]]]
> [sss_child_krb5_trace_cb] (0x4000): [2451] 1416693343.366191: Upgrading to
> FAST due to presence of PA_FX_FAST in reply
> (Sat Nov 22 14:55:43 2014) [[sssd[krb5_child[2451]]]]
> [sss_child_krb5_trace_cb] (0x4000): [2451] 1416693343.366215: FAST armor
> ccache: FILE:/var/lib/sss/db/fast_ccache_MY.DOMAIN.COM
> (Sat Nov 22 14:55:43 2014) [[sssd[krb5_child[2451]]]]
> [sss_child_krb5_trace_cb] (0x4000): [2451] 1416693343.366267: Retrieving
> host/ipaclient.my.domain.com at MY.DOMAIN.COM ->
> krb5_ccache_conf_data/fast_avail/krbtgt\/MY.DOMAIN.COM
> \@MY.DOMAIN.COM at X-CACHECONF: from FILE:/var/lib/sss/db/
> fast_ccache_MY.DOMAIN.COM with result: -1765328243/Matching credential not
> found
> (Sat Nov 22 14:55:43 2014) [[sssd[krb5_child[2451]]]]
> [sss_child_krb5_trace_cb] (0x4000): [2451] 1416693343.366322: Getting
> credentials host/ipaclient.my.domain.com at MY.DOMAIN.COM -> krbtgt/
> MY.DOMAIN.COM at MY.DOMAIN.COM using ccache FILE:/var/lib/sss/db/
> fast_ccache_MY.DOMAIN.COM
> (Sat Nov 22 14:55:43 2014) [[sssd[krb5_child[2451]]]]
> [sss_child_krb5_trace_cb] (0x4000): [2451] 1416693343.366380: Retrieving
> host/ipaclient.my.domain.com at MY.DOMAIN.COM -> krbtgt/
> MY.DOMAIN.COM at MY.DOMAIN.COM from FILE:/var/lib/sss/db/
> fast_ccache_MY.DOMAIN.COM with result: 0/Success
> (Sat Nov 22 14:55:43 2014) [[sssd[krb5_child[2451]]]]
> [sss_child_krb5_trace_cb] (0x4000): [2451] 1416693343.366425: Armor ccache
> sesion key: aes256-cts/9082
> (Sat Nov 22 14:55:43 2014) [[sssd[krb5_child[2451]]]]
> [sss_child_krb5_trace_cb] (0x4000): [2451] 1416693343.366476: Creating
> authenticator for host/ipaclient.my.domain.com at MY.DOMAIN.COM -> krbtgt/
> MY.DOMAIN.COM at MY.DOMAIN.COM, seqnum 0, subkey aes256-cts/F5B0, session key
> aes256-cts/9082
> (Sat Nov 22 14:55:43 2014) [[sssd[krb5_child[2451]]]]
> [sss_child_krb5_trace_cb] (0x4000): [2451] 1416693343.366562: FAST armor
> key: aes256-cts/0D88
> (Sat Nov 22 14:55:43 2014) [[sssd[krb5_child[2451]]]]
> [sss_child_krb5_trace_cb] (0x4000): [2451] 1416693343.366605: Encoding
> request body and padata into FAST request
> (Sat Nov 22 14:55:43 2014) [[sssd[krb5_child[2451]]]]
> [sss_child_krb5_trace_cb] (0x4000): [2451] 1416693343.366675: Sending
> request (1089 bytes) to MY.DOMAIN.COM
> (Sat Nov 22 14:55:43 2014) [[sssd[krb5_child[2451]]]]
> [sss_child_krb5_trace_cb] (0x4000): [2451] 1416693343.366752: Sending
> initial UDP request to dgram 1.1.1.2:88
> (Sat Nov 22 14:55:43 2014) [[sssd[krb5_child[2451]]]]
> [sss_child_krb5_trace_cb] (0x4000): [2451] 1416693343.370122: Received
> answer from dgram 1.1.1.2:88
> (Sat Nov 22 14:55:43 2014) [[sssd[krb5_child[2451]]]]
> [sss_child_krb5_trace_cb] (0x4000): [2451] 1416693343.370193: Response was
> from master KDC
> (Sat Nov 22 14:55:43 2014) [[sssd[krb5_child[2451]]]]
> [sss_child_krb5_trace_cb] (0x4000): [2451] 1416693343.370232: Received
> error from KDC: -1765328359/Additional pre-authentication required
> (Sat Nov 22 14:55:43 2014) [[sssd[krb5_child[2451]]]]
> [sss_child_krb5_trace_cb] (0x4000): [2451] 1416693343.370262: Decoding FAST
> response
> (Sat Nov 22 14:55:43 2014) [[sssd[krb5_child[2451]]]]
> [sss_child_krb5_trace_cb] (0x4000): [2451] 1416693343.370333: Processing
> preauth types: 136, 141, 133, 137
> (Sat Nov 22 14:55:43 2014) [[sssd[krb5_child[2451]]]]
> [sss_child_krb5_trace_cb] (0x4000): [2451] 1416693343.370364: Received
> cookie: MIT
> (Sat Nov 22 14:55:43 2014) [[sssd[krb5_child[2451]]]]
> [sss_child_krb5_trace_cb] (0x4000): [2451] 1416693343.370404: Produced
> preauth for next request: 133
> (Sat Nov 22 14:55:43 2014) [[sssd[krb5_child[2451]]]] [get_and_save_tgt]
> (0x0020): 981: [-1765328174][Generic preauthentication failure]
> (Sat Nov 22 14:55:43 2014) [[sssd[krb5_child[2451]]]] [map_krb5_error]
> (0x0020): 1043: [-1765328174][Generic preauthentication failure]

Could you try authenticating with the OTP without SSSD, just using
kinit? You need to create the FAST ccache first:

$ sudo kinit -c FILE:/tmp/armor_ccache -k
$ sudo KRB5_TRACE=/dev/stderr kinit -T /tmp/armor_ccache otptest at IPA.EXAMPLE.COM



From abokovoy at redhat.com  Thu Dec  4 11:07:02 2014
From: abokovoy at redhat.com (Alexander Bokovoy)
Date: Thu, 4 Dec 2014 13:07:02 +0200
Subject: [Freeipa-users] Cross-Realm authentification
In-Reply-To: <5480287B.4050406@kit.edu>
References: <547F1233.4020709@kit.edu> <20141203135351.GG16288@redhat.com>
	<5480287B.4050406@kit.edu>
Message-ID: <20141204110702.GH16288@redhat.com>

On Thu, 04 Dec 2014, Andreas Ladanyi wrote:
>Am 03.12.2014 um 14:53 schrieb Alexander Bokovoy:
>> On Wed, 03 Dec 2014, Andreas Ladanyi wrote:
>>> Hi,
>>>
>>> iam trying to setup a cross-realm relationship.
>>>
>>> Generated krbtgt cross-realm principals on both KDCs with the same
>>> password and kvno:
>>>
>>> krbtgt/REALM_B (MIT Kerberos)@REALM_A (FreeIPA 3.3.5)
>>> krbtgt/REALM_A at REALM_B
>>>
>>> getprinc on REALM_A KDC for principal krbtgt/REALM_B at REALM_A:
>>>
>>> Number of keys: 4
>>> Key: vno 1, aes256-cts-hmac-sha1-96, Version 5
>>> Key: vno 1, aes128-cts-hmac-sha1-96, Version 5
>>> Key: vno 1, des3-cbc-sha1, Version 5
>>> Key: vno 1, arcfour-hmac, Version 5
>>> MKey: vno 1
>>>
>>> getprinc on REALM_A KDC for principal krbtgt/REALM_A at REALM_B:
>>>
>>> Number of keys: 4
>>> Key: vno 1, aes256-cts-hmac-sha1-96, Version 5
>>> Key: vno 1, aes128-cts-hmac-sha1-96, Version 5
>>> Key: vno 1, des3-cbc-sha1, Version 5
>>> Key: vno 1, arcfour-hmac, Version 5
>>> MKey: vno 1
>>>
>>> getprinc on REALM_B KDC for principal krbtgt/REALM_B at REALM_A:
>>>
>>> Number of keys: 6
>>> Key: vno 1, Triple DES cbc mode with HMAC/sha1, no salt
>>> Key: vno 1, DES cbc mode with CRC-32, no salt
>>> Key: vno 1, DES cbc mode with RSA-MD5, Version 4
>>> Key: vno 1, DES cbc mode with RSA-MD5, Version 5 - No Realm
>>> Key: vno 1, DES cbc mode with RSA-MD5, Version 5 - Realm Only
>>> Key: vno 1, DES cbc mode with RSA-MD5, AFS version 3
>>> MKey: vno 1
>>>
>>> getprinc on REALM_B KDC for principal krbtgt/REALM_A at REALM_B:
>>>
>>> Number of keys: 6
>>> Key: vno 1, Triple DES cbc mode with HMAC/sha1, no salt
>>> Key: vno 1, DES cbc mode with CRC-32, no salt
>>> Key: vno 1, DES cbc mode with RSA-MD5, Version 4
>>> Key: vno 1, DES cbc mode with RSA-MD5, Version 5 - No Realm
>>> Key: vno 1, DES cbc mode with RSA-MD5, Version 5 - Realm Only
>>> Key: vno 1, DES cbc mode with RSA-MD5, AFS version 3
>>> MKey: vno 1
>>>
>>>
>>> I set up the [capaths] section in the krb5.conf client config:
>>>
>>> [capaths]
>>> REALM_A = {
>>>    REALM_B = .
>>>    }
>>> REALM_B = {
>>>    REALM_A = .
>>>    }
>> You need this section on both realm's KDCs.
>>
>>
>
>I have done this now on all (2) KDCs without a restart of kerberos
>service. The error message is the same like in my first mail.
I'm also getting errors but they are different to yours. Here is what I
did:

(on master.f21.test, realm F21.TEST):
[root at master ~]# kadmin.local -x ipa-setup-override-restrictions -r F21.TEST
Authenticating as principal root/admin at F21.TEST with password.
kadmin.local:  addprinc -requires_preauth krbtgt/IPA5.TEST
WARNING: no policy specified for krbtgt/IPA5.TEST at F21.TEST; defaulting to no policy
Enter password for principal "krbtgt/IPA5.TEST at F21.TEST": 
Re-enter password for principal "krbtgt/IPA5.TEST at F21.TEST": 
Principal "krbtgt/IPA5.TEST at F21.TEST" created.
kadmin.local:  addprinc -requires_preauth krbtgt/F21.TEST at IPA5.TEST
WARNING: no policy specified for krbtgt/F21.TEST at IPA5.TEST; defaulting to no policy
Enter password for principal "krbtgt/F21.TEST at IPA5.TEST": 
Re-enter password for principal "krbtgt/F21.TEST at IPA5.TEST": 
Principal "krbtgt/F21.TEST at IPA5.TEST" created.
kadmin.local:  q

added following to the /etc/krb5.conf:
[libdefaults]
dns_lookup_realm = true

[domain_realms]
 .ipa5.test = IPA5.TEST
 ipa5.test = IPA5.TEST

[capaths]
 F21.TEST = { 
  IPA5.TEST = . 
}
 IPA5.TEST = { 
  F21.TEST = . 
}



(on ipa-05-m.ipa5.test, realm IPA5.TEST):
[root at ipa-05-m ~]# kadmin.local -x ipa-setup-override-restrictions -r IPA5.TEST
Authenticating as principal admin/admin at IPA5.TEST with password.
kadmin.local:  addprinc -requires_preauth krbtgt/F21.TEST
WARNING: no policy specified for krbtgt/F21.TEST at IPA5.TEST; defaulting to no policy
Enter password for principal "krbtgt/F21.TEST at IPA5.TEST": 
Re-enter password for principal "krbtgt/F21.TEST at IPA5.TEST": 
Principal "krbtgt/F21.TEST at IPA5.TEST" created.
kadmin.local:  addprinc -requires_preauth krbtgt/IPA5.TEST at F21.TEST
WARNING: no policy specified for krbtgt/IPA5.TEST at F21.TEST; defaulting to no policy
Enter password for principal "krbtgt/IPA5.TEST at F21.TEST": 
Re-enter password for principal "krbtgt/IPA5.TEST at F21.TEST": 
Principal "krbtgt/IPA5.TEST at F21.TEST" created.
kadmin.local:  q

and similar changes to /etc/krb5.conf.

Then I tried to get a ticket to host/master.f21.test at F21.TEST while
being an admin at IPA5.TEST:

[root at ipa-05-m ~]# kinit admin
Password for admin at IPA5.TEST: 
[root at ipa-05-m ~]# KRB5_TRACE=/dev/stderr kvno -S host master.f21.test
[22351] 1417689782.154516: Convert service host (service with host as instance) on host master.f21.test to principal
[22351] 1417689782.158724: Remote host after forward canonicalization: master.f21.test
[22351] 1417689782.158814: Remote host after reverse DNS processing: master.f21.test
[22351] 1417689782.158849: Get host realm for master.f21.test
[22351] 1417689782.158899: Use local host master.f21.test to get host realm
[22351] 1417689782.158946: Look up master.f21.test in the domain_realm map
[22351] 1417689782.158999: Look up .f21.test in the domain_realm map
[22351] 1417689782.159023: Temporary realm is F21.TEST
[22351] 1417689782.159044: Got realm F21.TEST for host master.f21.test
[22351] 1417689782.159071: Got service principal host/master.f21.test at F21.TEST
[22351] 1417689782.159098: Getting credentials admin at IPA5.TEST -> host/master.f21.test at F21.TEST using ccache KEYRING:persistent:0:0
[22351] 1417689782.159237: Retrieving admin at IPA5.TEST -> host/master.f21.test at F21.TEST from KEYRING:persistent:0:0 with result: -1765328243/Matching credential not found
[22351] 1417689782.159297: Retrieving admin at IPA5.TEST -> krbtgt/F21.TEST at IPA5.TEST from KEYRING:persistent:0:0 with result: -1765328243/Matching credential not found
[22351] 1417689782.159411: Retrieving admin at IPA5.TEST -> krbtgt/IPA5.TEST at IPA5.TEST from KEYRING:persistent:0:0 with result: 0/Success
[22351] 1417689782.159453: Starting with TGT for client realm: admin at IPA5.TEST -> krbtgt/IPA5.TEST at IPA5.TEST
[22351] 1417689782.159502: Retrieving admin at IPA5.TEST -> krbtgt/F21.TEST at IPA5.TEST from KEYRING:persistent:0:0 with result: -1765328243/Matching credential not found
[22351] 1417689782.159530: Requesting TGT krbtgt/F21.TEST at IPA5.TEST using TGT krbtgt/IPA5.TEST at IPA5.TEST
[22351] 1417689782.159576: Generated subkey for TGS request: aes256-cts/54E6
[22351] 1417689782.159628: etypes requested in TGS request: aes256-cts, aes128-cts, des3-cbc-sha1, rc4-hmac, camellia128-cts, camellia256-cts
[22351] 1417689782.159726: Encoding request body and padata into FAST request
[22351] 1417689782.159784: Sending request (890 bytes) to IPA5.TEST
[22351] 1417689782.159909: Sending initial UDP request to dgram 192.168.5.109:88
[22351] 1417689782.161823: Received answer from dgram 192.168.5.109:88
[22351] 1417689782.161925: Response was from master KDC
[22351] 1417689782.162011: Decoding FAST response
[22351] 1417689782.162084: FAST reply key: aes256-cts/EBCE
[22351] 1417689782.162127: TGS reply is for admin at IPA5.TEST -> krbtgt/F21.TEST at IPA5.TEST with session key aes256-cts/822B
[22351] 1417689782.162159: TGS request result: 0/Success
[22351] 1417689782.162185: Removing admin at IPA5.TEST -> krbtgt/F21.TEST at IPA5.TEST from KEYRING:persistent:0:0
[22351] 1417689782.162207: Storing admin at IPA5.TEST -> krbtgt/F21.TEST at IPA5.TEST in KEYRING:persistent:0:0
[22351] 1417689782.162268: Received TGT for service realm: krbtgt/F21.TEST at IPA5.TEST
[22351] 1417689782.162296: Requesting tickets for host/master.f21.test at F21.TEST, referrals on
[22351] 1417689782.162322: Generated subkey for TGS request: aes256-cts/61A2
[22351] 1417689782.162359: etypes requested in TGS request: aes256-cts, aes128-cts, des3-cbc-sha1, rc4-hmac, camellia128-cts, camellia256-cts
[22351] 1417689782.162413: Encoding request body and padata into FAST request
[22351] 1417689782.162460: Sending request (855 bytes) to F21.TEST
[22351] 1417689782.162493: Resolving hostname master.f21.test
[22351] 1417689782.163213: Sending initial UDP request to dgram 192.168.5.169:88
[22351] 1417689782.165439: Received answer from dgram 192.168.5.169:88
[22351] 1417689782.165516: Response was from master KDC
[22351] 1417689782.165572: Decoding FAST response
[22351] 1417689782.165643: TGS request result: -1765328372/KDC policy rejects request
[22351] 1417689782.165680: Requesting tickets for host/master.f21.test at F21.TEST, referrals off
[22351] 1417689782.165714: Generated subkey for TGS request: aes256-cts/FEA9
[22351] 1417689782.165751: etypes requested in TGS request: aes256-cts, aes128-cts, des3-cbc-sha1, rc4-hmac, camellia128-cts, camellia256-cts
[22351] 1417689782.165799: Encoding request body and padata into FAST request
[22351] 1417689782.165847: Sending request (855 bytes) to F21.TEST
[22351] 1417689782.165875: Resolving hostname master.f21.test
[22351] 1417689782.166084: Sending initial UDP request to dgram 192.168.5.169:88
[22351] 1417689782.167602: Received answer from dgram 192.168.5.169:88
[22351] 1417689782.167642: Response was from master KDC
[22351] 1417689782.167669: Decoding FAST response
[22351] 1417689782.167709: TGS request result: -1765328372/KDC policy rejects request
kvno: KDC policy rejects request while getting credentials for host/master.f21.test at F21.TEST
[root at ipa-05-m ~]# 

And /var/log/krb5kdc.log on master.f21.test (KDC for F21.TEST) I can
see:
Dec 04 12:41:52 master.f21.test krb5kdc[1131](info): bad realm transit path from 'admin at IPA5.TEST' to 'host/master.f21.test at F21.TEST' via ''
Dec 04 12:41:52 master.f21.test krb5kdc[1131](info): TGS_REQ (6 etypes {18 17 16 23 25 26}) 192.168.5.109: BAD_TRANSIT: authtime 1417689777, admin at IPA5.TEST for host/master.f21.test at F21.TEST, KDC policy rejects request
Dec 04 12:41:52 master.f21.test krb5kdc[1131](info): bad realm transit path from 'admin at IPA5.TEST' to 'host/master.f21.test at F21.TEST' via ''
Dec 04 12:41:52 master.f21.test krb5kdc[1131](info): TGS_REQ (6 etypes {18 17 16 23 25 26}) 192.168.5.109: BAD_TRANSIT: authtime 1417689777, admin at IPA5.TEST for host/master.f21.test at F21.TEST, KDC policy rejects request

And this is correct for FreeIPA 3.3 or later because we limit trust to
those domains we defined in cn=ad,cn=trusts,$SUFFIX with filter
(objectclass=ipaNTTrustedDomain). For the rest we return
KRB5KRB_AP_ERR_ILL_CR_TKT error code which is visible as 'KDC policy
rejects request'.


We may reconsider this check and instead of KRB5KRB_AP_ERR_ILL_CR_TKT
return KRB5_PLUGIN_NO_HANDLE to allow fallback to krb5.conf-defined
capaths but I remember we had some issues with krb5 versions prior to
1.12 where capaths from krb5.conf were blocking work of the DAL driver.



-- 
/ Alexander Bokovoy



From pspacek at redhat.com  Thu Dec  4 11:12:33 2014
From: pspacek at redhat.com (Petr Spacek)
Date: Thu, 04 Dec 2014 12:12:33 +0100
Subject: [Freeipa-users] Cross-Realm authentification
In-Reply-To: <20141204110702.GH16288@redhat.com>
References: <547F1233.4020709@kit.edu>
	<20141203135351.GG16288@redhat.com>	<5480287B.4050406@kit.edu>
	<20141204110702.GH16288@redhat.com>
Message-ID: <548041A1.7080305@redhat.com>

On 4.12.2014 12:07, Alexander Bokovoy wrote:
> On Thu, 04 Dec 2014, Andreas Ladanyi wrote:
>> Am 03.12.2014 um 14:53 schrieb Alexander Bokovoy:
>>> On Wed, 03 Dec 2014, Andreas Ladanyi wrote:
>>>> Hi,
>>>>
>>>> iam trying to setup a cross-realm relationship.
>>>>
>>>> Generated krbtgt cross-realm principals on both KDCs with the same
>>>> password and kvno:
>>>>
>>>> krbtgt/REALM_B (MIT Kerberos)@REALM_A (FreeIPA 3.3.5)
>>>> krbtgt/REALM_A at REALM_B
>>>>
>>>> getprinc on REALM_A KDC for principal krbtgt/REALM_B at REALM_A:
>>>>
>>>> Number of keys: 4
>>>> Key: vno 1, aes256-cts-hmac-sha1-96, Version 5
>>>> Key: vno 1, aes128-cts-hmac-sha1-96, Version 5
>>>> Key: vno 1, des3-cbc-sha1, Version 5
>>>> Key: vno 1, arcfour-hmac, Version 5
>>>> MKey: vno 1
>>>>
>>>> getprinc on REALM_A KDC for principal krbtgt/REALM_A at REALM_B:
>>>>
>>>> Number of keys: 4
>>>> Key: vno 1, aes256-cts-hmac-sha1-96, Version 5
>>>> Key: vno 1, aes128-cts-hmac-sha1-96, Version 5
>>>> Key: vno 1, des3-cbc-sha1, Version 5
>>>> Key: vno 1, arcfour-hmac, Version 5
>>>> MKey: vno 1
>>>>
>>>> getprinc on REALM_B KDC for principal krbtgt/REALM_B at REALM_A:
>>>>
>>>> Number of keys: 6
>>>> Key: vno 1, Triple DES cbc mode with HMAC/sha1, no salt
>>>> Key: vno 1, DES cbc mode with CRC-32, no salt
>>>> Key: vno 1, DES cbc mode with RSA-MD5, Version 4
>>>> Key: vno 1, DES cbc mode with RSA-MD5, Version 5 - No Realm
>>>> Key: vno 1, DES cbc mode with RSA-MD5, Version 5 - Realm Only
>>>> Key: vno 1, DES cbc mode with RSA-MD5, AFS version 3
>>>> MKey: vno 1
>>>>
>>>> getprinc on REALM_B KDC for principal krbtgt/REALM_A at REALM_B:
>>>>
>>>> Number of keys: 6
>>>> Key: vno 1, Triple DES cbc mode with HMAC/sha1, no salt
>>>> Key: vno 1, DES cbc mode with CRC-32, no salt
>>>> Key: vno 1, DES cbc mode with RSA-MD5, Version 4
>>>> Key: vno 1, DES cbc mode with RSA-MD5, Version 5 - No Realm
>>>> Key: vno 1, DES cbc mode with RSA-MD5, Version 5 - Realm Only
>>>> Key: vno 1, DES cbc mode with RSA-MD5, AFS version 3
>>>> MKey: vno 1
>>>>
>>>>
>>>> I set up the [capaths] section in the krb5.conf client config:
>>>>
>>>> [capaths]
>>>> REALM_A = {
>>>>    REALM_B = .
>>>>    }
>>>> REALM_B = {
>>>>    REALM_A = .
>>>>    }
>>> You need this section on both realm's KDCs.
>>>
>>>
>>
>> I have done this now on all (2) KDCs without a restart of kerberos
>> service. The error message is the same like in my first mail.
> I'm also getting errors but they are different to yours. Here is what I
> did:
> 
> (on master.f21.test, realm F21.TEST):
> [root at master ~]# kadmin.local -x ipa-setup-override-restrictions -r F21.TEST
> Authenticating as principal root/admin at F21.TEST with password.
> kadmin.local:  addprinc -requires_preauth krbtgt/IPA5.TEST
> WARNING: no policy specified for krbtgt/IPA5.TEST at F21.TEST; defaulting to no
> policy
> Enter password for principal "krbtgt/IPA5.TEST at F21.TEST": Re-enter password
> for principal "krbtgt/IPA5.TEST at F21.TEST": Principal
> "krbtgt/IPA5.TEST at F21.TEST" created.
> kadmin.local:  addprinc -requires_preauth krbtgt/F21.TEST at IPA5.TEST
> WARNING: no policy specified for krbtgt/F21.TEST at IPA5.TEST; defaulting to no
> policy
> Enter password for principal "krbtgt/F21.TEST at IPA5.TEST": Re-enter password
> for principal "krbtgt/F21.TEST at IPA5.TEST": Principal
> "krbtgt/F21.TEST at IPA5.TEST" created.
> kadmin.local:  q
> 
> added following to the /etc/krb5.conf:
> [libdefaults]
> dns_lookup_realm = true
> 
> [domain_realms]
> .ipa5.test = IPA5.TEST
> ipa5.test = IPA5.TEST
> 
> [capaths]
> F21.TEST = {  IPA5.TEST = . }
> IPA5.TEST = {  F21.TEST = . }
> 
> 
> 
> (on ipa-05-m.ipa5.test, realm IPA5.TEST):
> [root at ipa-05-m ~]# kadmin.local -x ipa-setup-override-restrictions -r IPA5.TEST
> Authenticating as principal admin/admin at IPA5.TEST with password.
> kadmin.local:  addprinc -requires_preauth krbtgt/F21.TEST
> WARNING: no policy specified for krbtgt/F21.TEST at IPA5.TEST; defaulting to no
> policy
> Enter password for principal "krbtgt/F21.TEST at IPA5.TEST": Re-enter password
> for principal "krbtgt/F21.TEST at IPA5.TEST": Principal
> "krbtgt/F21.TEST at IPA5.TEST" created.
> kadmin.local:  addprinc -requires_preauth krbtgt/IPA5.TEST at F21.TEST
> WARNING: no policy specified for krbtgt/IPA5.TEST at F21.TEST; defaulting to no
> policy
> Enter password for principal "krbtgt/IPA5.TEST at F21.TEST": Re-enter password
> for principal "krbtgt/IPA5.TEST at F21.TEST": Principal
> "krbtgt/IPA5.TEST at F21.TEST" created.
> kadmin.local:  q
> 
> and similar changes to /etc/krb5.conf.
> 
> Then I tried to get a ticket to host/master.f21.test at F21.TEST while
> being an admin at IPA5.TEST:
> 
> [root at ipa-05-m ~]# kinit admin
> Password for admin at IPA5.TEST: [root at ipa-05-m ~]# KRB5_TRACE=/dev/stderr kvno
> -S host master.f21.test
> [22351] 1417689782.154516: Convert service host (service with host as
> instance) on host master.f21.test to principal
> [22351] 1417689782.158724: Remote host after forward canonicalization:
> master.f21.test
> [22351] 1417689782.158814: Remote host after reverse DNS processing:
> master.f21.test
> [22351] 1417689782.158849: Get host realm for master.f21.test
> [22351] 1417689782.158899: Use local host master.f21.test to get host realm
> [22351] 1417689782.158946: Look up master.f21.test in the domain_realm map
> [22351] 1417689782.158999: Look up .f21.test in the domain_realm map
> [22351] 1417689782.159023: Temporary realm is F21.TEST
> [22351] 1417689782.159044: Got realm F21.TEST for host master.f21.test
> [22351] 1417689782.159071: Got service principal host/master.f21.test at F21.TEST
> [22351] 1417689782.159098: Getting credentials admin at IPA5.TEST ->
> host/master.f21.test at F21.TEST using ccache KEYRING:persistent:0:0
> [22351] 1417689782.159237: Retrieving admin at IPA5.TEST ->
> host/master.f21.test at F21.TEST from KEYRING:persistent:0:0 with result:
> -1765328243/Matching credential not found
> [22351] 1417689782.159297: Retrieving admin at IPA5.TEST ->
> krbtgt/F21.TEST at IPA5.TEST from KEYRING:persistent:0:0 with result:
> -1765328243/Matching credential not found
> [22351] 1417689782.159411: Retrieving admin at IPA5.TEST ->
> krbtgt/IPA5.TEST at IPA5.TEST from KEYRING:persistent:0:0 with result: 0/Success
> [22351] 1417689782.159453: Starting with TGT for client realm: admin at IPA5.TEST
> -> krbtgt/IPA5.TEST at IPA5.TEST
> [22351] 1417689782.159502: Retrieving admin at IPA5.TEST ->
> krbtgt/F21.TEST at IPA5.TEST from KEYRING:persistent:0:0 with result:
> -1765328243/Matching credential not found
> [22351] 1417689782.159530: Requesting TGT krbtgt/F21.TEST at IPA5.TEST using TGT
> krbtgt/IPA5.TEST at IPA5.TEST
> [22351] 1417689782.159576: Generated subkey for TGS request: aes256-cts/54E6
> [22351] 1417689782.159628: etypes requested in TGS request: aes256-cts,
> aes128-cts, des3-cbc-sha1, rc4-hmac, camellia128-cts, camellia256-cts
> [22351] 1417689782.159726: Encoding request body and padata into FAST request
> [22351] 1417689782.159784: Sending request (890 bytes) to IPA5.TEST
> [22351] 1417689782.159909: Sending initial UDP request to dgram 192.168.5.109:88
> [22351] 1417689782.161823: Received answer from dgram 192.168.5.109:88
> [22351] 1417689782.161925: Response was from master KDC
> [22351] 1417689782.162011: Decoding FAST response
> [22351] 1417689782.162084: FAST reply key: aes256-cts/EBCE
> [22351] 1417689782.162127: TGS reply is for admin at IPA5.TEST ->
> krbtgt/F21.TEST at IPA5.TEST with session key aes256-cts/822B
> [22351] 1417689782.162159: TGS request result: 0/Success
> [22351] 1417689782.162185: Removing admin at IPA5.TEST ->
> krbtgt/F21.TEST at IPA5.TEST from KEYRING:persistent:0:0
> [22351] 1417689782.162207: Storing admin at IPA5.TEST ->
> krbtgt/F21.TEST at IPA5.TEST in KEYRING:persistent:0:0
> [22351] 1417689782.162268: Received TGT for service realm:
> krbtgt/F21.TEST at IPA5.TEST
> [22351] 1417689782.162296: Requesting tickets for
> host/master.f21.test at F21.TEST, referrals on
> [22351] 1417689782.162322: Generated subkey for TGS request: aes256-cts/61A2
> [22351] 1417689782.162359: etypes requested in TGS request: aes256-cts,
> aes128-cts, des3-cbc-sha1, rc4-hmac, camellia128-cts, camellia256-cts
> [22351] 1417689782.162413: Encoding request body and padata into FAST request
> [22351] 1417689782.162460: Sending request (855 bytes) to F21.TEST
> [22351] 1417689782.162493: Resolving hostname master.f21.test
> [22351] 1417689782.163213: Sending initial UDP request to dgram 192.168.5.169:88
> [22351] 1417689782.165439: Received answer from dgram 192.168.5.169:88
> [22351] 1417689782.165516: Response was from master KDC
> [22351] 1417689782.165572: Decoding FAST response
> [22351] 1417689782.165643: TGS request result: -1765328372/KDC policy rejects
> request
> [22351] 1417689782.165680: Requesting tickets for
> host/master.f21.test at F21.TEST, referrals off
> [22351] 1417689782.165714: Generated subkey for TGS request: aes256-cts/FEA9
> [22351] 1417689782.165751: etypes requested in TGS request: aes256-cts,
> aes128-cts, des3-cbc-sha1, rc4-hmac, camellia128-cts, camellia256-cts
> [22351] 1417689782.165799: Encoding request body and padata into FAST request
> [22351] 1417689782.165847: Sending request (855 bytes) to F21.TEST
> [22351] 1417689782.165875: Resolving hostname master.f21.test
> [22351] 1417689782.166084: Sending initial UDP request to dgram 192.168.5.169:88
> [22351] 1417689782.167602: Received answer from dgram 192.168.5.169:88
> [22351] 1417689782.167642: Response was from master KDC
> [22351] 1417689782.167669: Decoding FAST response
> [22351] 1417689782.167709: TGS request result: -1765328372/KDC policy rejects
> request
> kvno: KDC policy rejects request while getting credentials for
> host/master.f21.test at F21.TEST
> [root at ipa-05-m ~]#
> And /var/log/krb5kdc.log on master.f21.test (KDC for F21.TEST) I can
> see:
> Dec 04 12:41:52 master.f21.test krb5kdc[1131](info): bad realm transit path
> from 'admin at IPA5.TEST' to 'host/master.f21.test at F21.TEST' via ''
> Dec 04 12:41:52 master.f21.test krb5kdc[1131](info): TGS_REQ (6 etypes {18 17
> 16 23 25 26}) 192.168.5.109: BAD_TRANSIT: authtime 1417689777, admin at IPA5.TEST
> for host/master.f21.test at F21.TEST, KDC policy rejects request
> Dec 04 12:41:52 master.f21.test krb5kdc[1131](info): bad realm transit path
> from 'admin at IPA5.TEST' to 'host/master.f21.test at F21.TEST' via ''
> Dec 04 12:41:52 master.f21.test krb5kdc[1131](info): TGS_REQ (6 etypes {18 17
> 16 23 25 26}) 192.168.5.109: BAD_TRANSIT: authtime 1417689777, admin at IPA5.TEST
> for host/master.f21.test at F21.TEST, KDC policy rejects request
> 
> And this is correct for FreeIPA 3.3 or later because we limit trust to
> those domains we defined in cn=ad,cn=trusts,$SUFFIX with filter
> (objectclass=ipaNTTrustedDomain). For the rest we return
> KRB5KRB_AP_ERR_ILL_CR_TKT error code which is visible as 'KDC policy
> rejects request'.
> 
> 
> We may reconsider this check and instead of KRB5KRB_AP_ERR_ILL_CR_TKT
> return KRB5_PLUGIN_NO_HANDLE to allow fallback to krb5.conf-defined
> capaths but I remember we had some issues with krb5 versions prior to
> 1.12 where capaths from krb5.conf were blocking work of the DAL driver.

Alexander, could you open a ticket to prevent us from forgetting about it?

-- 
Petr^2 Spacek



From abokovoy at redhat.com  Thu Dec  4 11:22:01 2014
From: abokovoy at redhat.com (Alexander Bokovoy)
Date: Thu, 4 Dec 2014 13:22:01 +0200
Subject: [Freeipa-users] Cross-Realm authentification
In-Reply-To: <548041A1.7080305@redhat.com>
References: <547F1233.4020709@kit.edu> <20141203135351.GG16288@redhat.com>
	<5480287B.4050406@kit.edu> <20141204110702.GH16288@redhat.com>
	<548041A1.7080305@redhat.com>
Message-ID: <20141204112201.GI16288@redhat.com>

On Thu, 04 Dec 2014, Petr Spacek wrote:
>> And /var/log/krb5kdc.log on master.f21.test (KDC for F21.TEST) I can
>> see:
>> Dec 04 12:41:52 master.f21.test krb5kdc[1131](info): bad realm transit path
>> from 'admin at IPA5.TEST' to 'host/master.f21.test at F21.TEST' via ''
>> Dec 04 12:41:52 master.f21.test krb5kdc[1131](info): TGS_REQ (6 etypes {18 17
>> 16 23 25 26}) 192.168.5.109: BAD_TRANSIT: authtime 1417689777, admin at IPA5.TEST
>> for host/master.f21.test at F21.TEST, KDC policy rejects request
>> Dec 04 12:41:52 master.f21.test krb5kdc[1131](info): bad realm transit path
>> from 'admin at IPA5.TEST' to 'host/master.f21.test at F21.TEST' via ''
>> Dec 04 12:41:52 master.f21.test krb5kdc[1131](info): TGS_REQ (6 etypes {18 17
>> 16 23 25 26}) 192.168.5.109: BAD_TRANSIT: authtime 1417689777, admin at IPA5.TEST
>> for host/master.f21.test at F21.TEST, KDC policy rejects request
>>
>> And this is correct for FreeIPA 3.3 or later because we limit trust to
>> those domains we defined in cn=ad,cn=trusts,$SUFFIX with filter
>> (objectclass=ipaNTTrustedDomain). For the rest we return
>> KRB5KRB_AP_ERR_ILL_CR_TKT error code which is visible as 'KDC policy
>> rejects request'.
>>
>>
>> We may reconsider this check and instead of KRB5KRB_AP_ERR_ILL_CR_TKT
>> return KRB5_PLUGIN_NO_HANDLE to allow fallback to krb5.conf-defined
>> capaths but I remember we had some issues with krb5 versions prior to
>> 1.12 where capaths from krb5.conf were blocking work of the DAL driver.
>
>Alexander, could you open a ticket to prevent us from forgetting about it?
I'm not sure yet this is valid. For FreeIPA-FreeIPA trust we'll have a
separate solution and it will be along the lines of existing 'ipa trust-add'
workflow where existing DAL driver code will work as it is.

-- 
/ Alexander Bokovoy



From rmeggins at redhat.com  Thu Dec  4 14:39:20 2014
From: rmeggins at redhat.com (Rich Megginson)
Date: Thu, 04 Dec 2014 08:39:20 -0600
Subject: [Freeipa-users] strange replica install error (another one)
In-Reply-To: <54801127.3060404@redhat.com>
References: <547F8337.4020301@gmail.com>
	<547F9539.50602@redhat.com>	<547FDCDF.6060200@gmail.com>
	<54801127.3060404@redhat.com>
Message-ID: <54807218.7080208@redhat.com>

On 12/04/2014 01:45 AM, Petr Spacek wrote:
> On 4.12.2014 05:02, Janelle wrote:
>> Thanks -- still a bit strange that it did not show up on some servers - vary
>> random and intermittent.
>>
>> BTW - a bit of information others might find useful.  If you try to use the
>> "LDAP" portion of IPA for authentication - rather than fulling installing the
>> IPA client and using Kerberos - the servers running ds-389 do not do well in
>> handling the load. In other words - a few hundred hosts trying to authenticate
>> via LDAP only will send CPU through the roof and crashes the slapd process
>> often.

That should not happen.
For crashes, we would need to look at some stack traces: 
http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-crashes
For situations when the CPU is through the roof, that is very similar to 
debugging hangs: 
http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-hangs

>> Since IPA is supposed to handle all options, I guess I am disappointed.
>>
>> regards
>> ~J
>>
>>
>> On 12/3/14 2:56 PM, Dmitri Pal wrote:
>>> On 12/03/2014 04:40 PM, Janelle wrote:
>>>> Here is a bit of baffling one on 4.0.5:
>>>>
>>>> Replica install p11-kit???
>>> This is a part of the DNSSEC set of packages.
>>>
>>>> Connection from master to replica is OK.
>>>>
>>>> Connection check OK
>>>> p11-kit: ipa.p11-kit: x-public-key-info: invalid or unsupported attribute
>>>> Configuring NTP daemon (ntpd)
>>>>    [1/4]: stopping ntpd
>>>>    [2/4]: writing configuration
>>>> ...
>>>>
>>>> Your system may be partly configured.
>>>> Run /usr/sbin/ipa-server-install --uninstall to clean up.
>>>>
>>>> LDAP error: UNWILLING_TO_PERFORM
>>>> database is read-only
>>>>
>>>>
>>>> Thoughts?
> We need more information about your problem.
>
> As always, please start with information requested on
> http://www.freeipa.org/page/Troubleshooting#Reporting_bugs
>
> /var/log/ipa*.log from affected replica will be invaluable (along with exact
> package version numbers [including p11-kit] and repo configuration).
>



From rmeggins at redhat.com  Thu Dec  4 14:41:02 2014
From: rmeggins at redhat.com (Rich Megginson)
Date: Thu, 04 Dec 2014 08:41:02 -0600
Subject: [Freeipa-users] strange replica install error (another one)
In-Reply-To: <54807218.7080208@redhat.com>
References: <547F8337.4020301@gmail.com>	<547F9539.50602@redhat.com>	<547FDCDF.6060200@gmail.com>	<54801127.3060404@redhat.com>
	<54807218.7080208@redhat.com>
Message-ID: <5480727E.9070302@redhat.com>

On 12/04/2014 08:39 AM, Rich Megginson wrote:
> On 12/04/2014 01:45 AM, Petr Spacek wrote:
>> On 4.12.2014 05:02, Janelle wrote:
>>> Thanks -- still a bit strange that it did not show up on some 
>>> servers - vary
>>> random and intermittent.
>>>
>>> BTW - a bit of information others might find useful.  If you try to 
>>> use the
>>> "LDAP" portion of IPA for authentication - rather than fulling 
>>> installing the
>>> IPA client and using Kerberos - the servers running ds-389 do not do 
>>> well in
>>> handling the load. In other words - a few hundred hosts trying to 
>>> authenticate
>>> via LDAP only will send CPU through the roof and crashes the slapd 
>>> process
>>> often.
>
> That should not happen.
> For crashes, we would need to look at some stack traces: 
> http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-crashes
> For situations when the CPU is through the roof, that is very similar 
> to debugging hangs: 
> http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-hangs

Sorry, forgot to mention that since this is IPA you'll also need to 
install the ipa-debuginfo and slapi-nis-debuginfo packages.

>
>>> Since IPA is supposed to handle all options, I guess I am disappointed.
>>>
>>> regards
>>> ~J
>>>
>>>
>>> On 12/3/14 2:56 PM, Dmitri Pal wrote:
>>>> On 12/03/2014 04:40 PM, Janelle wrote:
>>>>> Here is a bit of baffling one on 4.0.5:
>>>>>
>>>>> Replica install p11-kit???
>>>> This is a part of the DNSSEC set of packages.
>>>>
>>>>> Connection from master to replica is OK.
>>>>>
>>>>> Connection check OK
>>>>> p11-kit: ipa.p11-kit: x-public-key-info: invalid or unsupported 
>>>>> attribute
>>>>> Configuring NTP daemon (ntpd)
>>>>>    [1/4]: stopping ntpd
>>>>>    [2/4]: writing configuration
>>>>> ...
>>>>>
>>>>> Your system may be partly configured.
>>>>> Run /usr/sbin/ipa-server-install --uninstall to clean up.
>>>>>
>>>>> LDAP error: UNWILLING_TO_PERFORM
>>>>> database is read-only
>>>>>
>>>>>
>>>>> Thoughts?
>> We need more information about your problem.
>>
>> As always, please start with information requested on
>> http://www.freeipa.org/page/Troubleshooting#Reporting_bugs
>>
>> /var/log/ipa*.log from affected replica will be invaluable (along 
>> with exact
>> package version numbers [including p11-kit] and repo configuration).
>>
>



From dpal at redhat.com  Thu Dec  4 15:38:13 2014
From: dpal at redhat.com (Dmitri Pal)
Date: Thu, 04 Dec 2014 10:38:13 -0500
Subject: [Freeipa-users] strange replica install error (another one)
In-Reply-To: <5480727E.9070302@redhat.com>
References: <547F8337.4020301@gmail.com>	<547F9539.50602@redhat.com>	<547FDCDF.6060200@gmail.com>	<54801127.3060404@redhat.com>	<54807218.7080208@redhat.com>
	<5480727E.9070302@redhat.com>
Message-ID: <54807FE5.9060606@redhat.com>

On 12/04/2014 09:41 AM, Rich Megginson wrote:
> On 12/04/2014 08:39 AM, Rich Megginson wrote:
>> On 12/04/2014 01:45 AM, Petr Spacek wrote:
>>> On 4.12.2014 05:02, Janelle wrote:
>>>> Thanks -- still a bit strange that it did not show up on some 
>>>> servers - vary
>>>> random and intermittent.
>>>>
>>>> BTW - a bit of information others might find useful.  If you try to 
>>>> use the
>>>> "LDAP" portion of IPA for authentication - rather than fulling 
>>>> installing the
>>>> IPA client and using Kerberos - the servers running ds-389 do not 
>>>> do well in
>>>> handling the load. In other words - a few hundred hosts trying to 
>>>> authenticate
>>>> via LDAP only will send CPU through the roof and crashes the slapd 
>>>> process
>>>> often.
>>
>> That should not happen.
>> For crashes, we would need to look at some stack traces: 
>> http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-crashes
>> For situations when the CPU is through the roof, that is very similar 
>> to debugging hangs: 
>> http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-hangs
>
> Sorry, forgot to mention that since this is IPA you'll also need to 
> install the ipa-debuginfo and slapi-nis-debuginfo packages.
>

I would also add a question about your client configuration.
For example if you use SSSD with enumerate=true for your clients then 
yes you will get your environment to the knees pretty quickly.

>>
>>>> Since IPA is supposed to handle all options, I guess I am 
>>>> disappointed.
>>>>
>>>> regards
>>>> ~J
>>>>
>>>>
>>>> On 12/3/14 2:56 PM, Dmitri Pal wrote:
>>>>> On 12/03/2014 04:40 PM, Janelle wrote:
>>>>>> Here is a bit of baffling one on 4.0.5:
>>>>>>
>>>>>> Replica install p11-kit???
>>>>> This is a part of the DNSSEC set of packages.
>>>>>
>>>>>> Connection from master to replica is OK.
>>>>>>
>>>>>> Connection check OK
>>>>>> p11-kit: ipa.p11-kit: x-public-key-info: invalid or unsupported 
>>>>>> attribute
>>>>>> Configuring NTP daemon (ntpd)
>>>>>>    [1/4]: stopping ntpd
>>>>>>    [2/4]: writing configuration
>>>>>> ...
>>>>>>
>>>>>> Your system may be partly configured.
>>>>>> Run /usr/sbin/ipa-server-install --uninstall to clean up.
>>>>>>
>>>>>> LDAP error: UNWILLING_TO_PERFORM
>>>>>> database is read-only
>>>>>>
>>>>>>
>>>>>> Thoughts?
>>> We need more information about your problem.
>>>
>>> As always, please start with information requested on
>>> http://www.freeipa.org/page/Troubleshooting#Reporting_bugs
>>>
>>> /var/log/ipa*.log from affected replica will be invaluable (along 
>>> with exact
>>> package version numbers [including p11-kit] and repo configuration).
>>>
>>
>


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.



From rcritten at redhat.com  Thu Dec  4 15:40:43 2014
From: rcritten at redhat.com (Rob Crittenden)
Date: Thu, 04 Dec 2014 10:40:43 -0500
Subject: [Freeipa-users] strange replica install error (another one)
In-Reply-To: <54807FE5.9060606@redhat.com>
References: <547F8337.4020301@gmail.com>	<547F9539.50602@redhat.com>	<547FDCDF.6060200@gmail.com>	<54801127.3060404@redhat.com>	<54807218.7080208@redhat.com>	<5480727E.9070302@redhat.com>
	<54807FE5.9060606@redhat.com>
Message-ID: <5480807B.8040805@redhat.com>

Dmitri Pal wrote:
> On 12/04/2014 09:41 AM, Rich Megginson wrote:
>> On 12/04/2014 08:39 AM, Rich Megginson wrote:
>>> On 12/04/2014 01:45 AM, Petr Spacek wrote:
>>>> On 4.12.2014 05:02, Janelle wrote:
>>>>> Thanks -- still a bit strange that it did not show up on some
>>>>> servers - vary
>>>>> random and intermittent.
>>>>>
>>>>> BTW - a bit of information others might find useful.  If you try to
>>>>> use the
>>>>> "LDAP" portion of IPA for authentication - rather than fulling
>>>>> installing the
>>>>> IPA client and using Kerberos - the servers running ds-389 do not
>>>>> do well in
>>>>> handling the load. In other words - a few hundred hosts trying to
>>>>> authenticate
>>>>> via LDAP only will send CPU through the roof and crashes the slapd
>>>>> process
>>>>> often.
>>>
>>> That should not happen.
>>> For crashes, we would need to look at some stack traces:
>>> http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-crashes
>>> For situations when the CPU is through the roof, that is very similar
>>> to debugging hangs:
>>> http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-hangs
>>
>> Sorry, forgot to mention that since this is IPA you'll also need to
>> install the ipa-debuginfo and slapi-nis-debuginfo packages.
>>
> 
> I would also add a question about your client configuration.
> For example if you use SSSD with enumerate=true for your clients then
> yes you will get your environment to the knees pretty quickly.

I assumed SSSD wasn't being used at all which begs the question: what
is? nss_ldap? Is nslcd being used?

What is hitting LDAP, only auth or something else (e.g. sudo, automount).

rob

> 
>>>
>>>>> Since IPA is supposed to handle all options, I guess I am
>>>>> disappointed.
>>>>>
>>>>> regards
>>>>> ~J
>>>>>
>>>>>
>>>>> On 12/3/14 2:56 PM, Dmitri Pal wrote:
>>>>>> On 12/03/2014 04:40 PM, Janelle wrote:
>>>>>>> Here is a bit of baffling one on 4.0.5:
>>>>>>>
>>>>>>> Replica install p11-kit???
>>>>>> This is a part of the DNSSEC set of packages.
>>>>>>
>>>>>>> Connection from master to replica is OK.
>>>>>>>
>>>>>>> Connection check OK
>>>>>>> p11-kit: ipa.p11-kit: x-public-key-info: invalid or unsupported
>>>>>>> attribute
>>>>>>> Configuring NTP daemon (ntpd)
>>>>>>>    [1/4]: stopping ntpd
>>>>>>>    [2/4]: writing configuration
>>>>>>> ...
>>>>>>>
>>>>>>> Your system may be partly configured.
>>>>>>> Run /usr/sbin/ipa-server-install --uninstall to clean up.
>>>>>>>
>>>>>>> LDAP error: UNWILLING_TO_PERFORM
>>>>>>> database is read-only
>>>>>>>
>>>>>>>
>>>>>>> Thoughts?
>>>> We need more information about your problem.
>>>>
>>>> As always, please start with information requested on
>>>> http://www.freeipa.org/page/Troubleshooting#Reporting_bugs
>>>>
>>>> /var/log/ipa*.log from affected replica will be invaluable (along
>>>> with exact
>>>> package version numbers [including p11-kit] and repo configuration).
>>>>
>>>
>>
> 
> 



From janellenicole80 at gmail.com  Thu Dec  4 15:56:58 2014
From: janellenicole80 at gmail.com (Janelle)
Date: Thu, 04 Dec 2014 07:56:58 -0800
Subject: [Freeipa-users] strange replica install error (another one)
In-Reply-To: <5480807B.8040805@redhat.com>
References: <547F8337.4020301@gmail.com>	<547F9539.50602@redhat.com>	<547FDCDF.6060200@gmail.com>	<54801127.3060404@redhat.com>	<54807218.7080208@redhat.com>	<5480727E.9070302@redhat.com>	<54807FE5.9060606@redhat.com>
	<5480807B.8040805@redhat.com>
Message-ID: <5480844A.6040405@gmail.com>

Hi all,

just (pam)auth and nslcd

It was ported from a running OpenLDAP environment to IPA.  Just trying 
to do conversions in stages so as not to change too much all at once. 
Thought I could go from OpenLDAP to IPA and just use the backend of 
389ds. Functionally it does work, but the load kills it. Seems like FDs 
are a huge problem.  But all the settings documented don't see to 
resolve the magic:

/ Netscape Portable Runtime error -5971 (Process open FD table is full.)/

error.

Shouldn't this increase file descriptors in conjunction with 
/etc/sysconfig/dirsrv.systemd change? FS-limits across the OS are set to 
65535 - /etc/security/limits.conf, /proc, sysctl.conf -- everything but 
389-ds itself. But I still can't get this to work, although it does not 
give an error.

ldapmodify -x -D "cn=directory manager" -W <<EOF
dn: cn=config,cn=ldbm database,cn=plugins,cn=config
changetype: modify
replace: nsslapd-maxdescriptors
nsslapd-maxdescriptors: 65535
-
replace: nsslapd-dtablesize
nsslapd-dtablesize: 65535
-
replace: nsslapd-reservedescriptors
nsslapd-reservedescriptors: 100
EOF

Thanks
~J

On 12/4/14 7:40 AM, Rob Crittenden wrote:
> Dmitri Pal wrote:
>> On 12/04/2014 09:41 AM, Rich Megginson wrote:
>>> On 12/04/2014 08:39 AM, Rich Megginson wrote:
>>>> On 12/04/2014 01:45 AM, Petr Spacek wrote:
>>>>> On 4.12.2014 05:02, Janelle wrote:
>>>>>> Thanks -- still a bit strange that it did not show up on some
>>>>>> servers - vary
>>>>>> random and intermittent.
>>>>>>
>>>>>> BTW - a bit of information others might find useful.  If you try to
>>>>>> use the
>>>>>> "LDAP" portion of IPA for authentication - rather than fulling
>>>>>> installing the
>>>>>> IPA client and using Kerberos - the servers running ds-389 do not
>>>>>> do well in
>>>>>> handling the load. In other words - a few hundred hosts trying to
>>>>>> authenticate
>>>>>> via LDAP only will send CPU through the roof and crashes the slapd
>>>>>> process
>>>>>> often.
>>>> That should not happen.
>>>> For crashes, we would need to look at some stack traces:
>>>> http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-crashes
>>>> For situations when the CPU is through the roof, that is very similar
>>>> to debugging hangs:
>>>> http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-hangs
>>> Sorry, forgot to mention that since this is IPA you'll also need to
>>> install the ipa-debuginfo and slapi-nis-debuginfo packages.
>>>
>> I would also add a question about your client configuration.
>> For example if you use SSSD with enumerate=true for your clients then
>> yes you will get your environment to the knees pretty quickly.
> I assumed SSSD wasn't being used at all which begs the question: what
> is? nss_ldap? Is nslcd being used?
>
> What is hitting LDAP, only auth or something else (e.g. sudo, automount).
>
> rob
>
>>>>>> Since IPA is supposed to handle all options, I guess I am
>>>>>> disappointed.
>>>>>>
>>>>>> regards
>>>>>> ~J
>>>>>>
>>>>>>
>>>>>> On 12/3/14 2:56 PM, Dmitri Pal wrote:
>>>>>>> On 12/03/2014 04:40 PM, Janelle wrote:
>>>>>>>> Here is a bit of baffling one on 4.0.5:
>>>>>>>>
>>>>>>>> Replica install p11-kit???
>>>>>>> This is a part of the DNSSEC set of packages.
>>>>>>>
>>>>>>>> Connection from master to replica is OK.
>>>>>>>>
>>>>>>>> Connection check OK
>>>>>>>> p11-kit: ipa.p11-kit: x-public-key-info: invalid or unsupported
>>>>>>>> attribute
>>>>>>>> Configuring NTP daemon (ntpd)
>>>>>>>>     [1/4]: stopping ntpd
>>>>>>>>     [2/4]: writing configuration
>>>>>>>> ...
>>>>>>>>
>>>>>>>> Your system may be partly configured.
>>>>>>>> Run /usr/sbin/ipa-server-install --uninstall to clean up.
>>>>>>>>
>>>>>>>> LDAP error: UNWILLING_TO_PERFORM
>>>>>>>> database is read-only
>>>>>>>>
>>>>>>>>
>>>>>>>> Thoughts?
>>>>> We need more information about your problem.
>>>>>
>>>>> As always, please start with information requested on
>>>>> http://www.freeipa.org/page/Troubleshooting#Reporting_bugs
>>>>>
>>>>> /var/log/ipa*.log from affected replica will be invaluable (along
>>>>> with exact
>>>>> package version numbers [including p11-kit] and repo configuration).
>>>>>
>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141204/cde88240/attachment.htm>

From simo at redhat.com  Thu Dec  4 15:58:12 2014
From: simo at redhat.com (Simo Sorce)
Date: Thu, 4 Dec 2014 10:58:12 -0500
Subject: [Freeipa-users] Cross-Realm authentification
In-Reply-To: <20141204112201.GI16288@redhat.com>
References: <547F1233.4020709@kit.edu> <20141203135351.GG16288@redhat.com>
	<5480287B.4050406@kit.edu> <20141204110702.GH16288@redhat.com>
	<548041A1.7080305@redhat.com> <20141204112201.GI16288@redhat.com>
Message-ID: <20141204105812.21a64688@willson.usersys.redhat.com>

On Thu, 4 Dec 2014 13:22:01 +0200
Alexander Bokovoy <abokovoy at redhat.com> wrote:

> On Thu, 04 Dec 2014, Petr Spacek wrote:
> >> And /var/log/krb5kdc.log on master.f21.test (KDC for F21.TEST) I
> >> can see:
> >> Dec 04 12:41:52 master.f21.test krb5kdc[1131](info): bad realm
> >> transit path from 'admin at IPA5.TEST' to
> >> 'host/master.f21.test at F21.TEST' via '' Dec 04 12:41:52
> >> master.f21.test krb5kdc[1131](info): TGS_REQ (6 etypes {18 17 16
> >> 23 25 26}) 192.168.5.109: BAD_TRANSIT: authtime 1417689777,
> >> admin at IPA5.TEST for host/master.f21.test at F21.TEST, KDC policy
> >> rejects request Dec 04 12:41:52 master.f21.test
> >> krb5kdc[1131](info): bad realm transit path from 'admin at IPA5.TEST'
> >> to 'host/master.f21.test at F21.TEST' via '' Dec 04 12:41:52
> >> master.f21.test krb5kdc[1131](info): TGS_REQ (6 etypes {18 17 16
> >> 23 25 26}) 192.168.5.109: BAD_TRANSIT: authtime 1417689777,
> >> admin at IPA5.TEST for host/master.f21.test at F21.TEST, KDC policy
> >> rejects request
> >>
> >> And this is correct for FreeIPA 3.3 or later because we limit
> >> trust to those domains we defined in cn=ad,cn=trusts,$SUFFIX with
> >> filter (objectclass=ipaNTTrustedDomain). For the rest we return
> >> KRB5KRB_AP_ERR_ILL_CR_TKT error code which is visible as 'KDC
> >> policy rejects request'.
> >>
> >>
> >> We may reconsider this check and instead of
> >> KRB5KRB_AP_ERR_ILL_CR_TKT return KRB5_PLUGIN_NO_HANDLE to allow
> >> fallback to krb5.conf-defined capaths but I remember we had some
> >> issues with krb5 versions prior to 1.12 where capaths from
> >> krb5.conf were blocking work of the DAL driver.
> >
> >Alexander, could you open a ticket to prevent us from forgetting
> >about it?
> I'm not sure yet this is valid. For FreeIPA-FreeIPA trust we'll have a
> separate solution and it will be along the lines of existing 'ipa
> trust-add' workflow where existing DAL driver code will work as it is.

I think we should have a way to relax this requirement, so that people
like Andreas can play with kerberos level trusts.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York



From pspacek at redhat.com  Thu Dec  4 16:14:15 2014
From: pspacek at redhat.com (Petr Spacek)
Date: Thu, 04 Dec 2014 17:14:15 +0100
Subject: [Freeipa-users] Cross-Realm authentification
In-Reply-To: <20141204105812.21a64688@willson.usersys.redhat.com>
References: <547F1233.4020709@kit.edu>	<20141203135351.GG16288@redhat.com>	<5480287B.4050406@kit.edu>	<20141204110702.GH16288@redhat.com>	<548041A1.7080305@redhat.com>	<20141204112201.GI16288@redhat.com>
	<20141204105812.21a64688@willson.usersys.redhat.com>
Message-ID: <54808857.6070707@redhat.com>

On 4.12.2014 16:58, Simo Sorce wrote:
> On Thu, 4 Dec 2014 13:22:01 +0200
> Alexander Bokovoy <abokovoy at redhat.com> wrote:
> 
>> On Thu, 04 Dec 2014, Petr Spacek wrote:
>>>> And /var/log/krb5kdc.log on master.f21.test (KDC for F21.TEST) I
>>>> can see:
>>>> Dec 04 12:41:52 master.f21.test krb5kdc[1131](info): bad realm
>>>> transit path from 'admin at IPA5.TEST' to
>>>> 'host/master.f21.test at F21.TEST' via '' Dec 04 12:41:52
>>>> master.f21.test krb5kdc[1131](info): TGS_REQ (6 etypes {18 17 16
>>>> 23 25 26}) 192.168.5.109: BAD_TRANSIT: authtime 1417689777,
>>>> admin at IPA5.TEST for host/master.f21.test at F21.TEST, KDC policy
>>>> rejects request Dec 04 12:41:52 master.f21.test
>>>> krb5kdc[1131](info): bad realm transit path from 'admin at IPA5.TEST'
>>>> to 'host/master.f21.test at F21.TEST' via '' Dec 04 12:41:52
>>>> master.f21.test krb5kdc[1131](info): TGS_REQ (6 etypes {18 17 16
>>>> 23 25 26}) 192.168.5.109: BAD_TRANSIT: authtime 1417689777,
>>>> admin at IPA5.TEST for host/master.f21.test at F21.TEST, KDC policy
>>>> rejects request
>>>>
>>>> And this is correct for FreeIPA 3.3 or later because we limit
>>>> trust to those domains we defined in cn=ad,cn=trusts,$SUFFIX with
>>>> filter (objectclass=ipaNTTrustedDomain). For the rest we return
>>>> KRB5KRB_AP_ERR_ILL_CR_TKT error code which is visible as 'KDC
>>>> policy rejects request'.
>>>>
>>>>
>>>> We may reconsider this check and instead of
>>>> KRB5KRB_AP_ERR_ILL_CR_TKT return KRB5_PLUGIN_NO_HANDLE to allow
>>>> fallback to krb5.conf-defined capaths but I remember we had some
>>>> issues with krb5 versions prior to 1.12 where capaths from
>>>> krb5.conf were blocking work of the DAL driver.
>>>
>>> Alexander, could you open a ticket to prevent us from forgetting
>>> about it?
>> I'm not sure yet this is valid. For FreeIPA-FreeIPA trust we'll have a
>> separate solution and it will be along the lines of existing 'ipa
>> trust-add' workflow where existing DAL driver code will work as it is.
> 
> I think we should have a way to relax this requirement, so that people
> like Andreas can play with kerberos level trusts.

I agree.

-- 
Petr^2 Spacek



From rmeggins at redhat.com  Thu Dec  4 16:27:14 2014
From: rmeggins at redhat.com (Rich Megginson)
Date: Thu, 04 Dec 2014 10:27:14 -0600
Subject: [Freeipa-users] strange replica install error (another one)
In-Reply-To: <5480844A.6040405@gmail.com>
References: <547F8337.4020301@gmail.com>	<547F9539.50602@redhat.com>	<547FDCDF.6060200@gmail.com>	<54801127.3060404@redhat.com>	<54807218.7080208@redhat.com>	<5480727E.9070302@redhat.com>	<54807FE5.9060606@redhat.com>	<5480807B.8040805@redhat.com>
	<5480844A.6040405@gmail.com>
Message-ID: <54808B62.9040301@redhat.com>

On 12/04/2014 09:56 AM, Janelle wrote:
> Hi all,
>
> just (pam)auth and nslcd
>
> It was ported from a running OpenLDAP environment to IPA.  Just trying 
> to do conversions in stages so as not to change too much all at once. 
> Thought I could go from OpenLDAP to IPA and just use the backend of 
> 389ds. Functionally it does work, but the load kills it. Seems like 
> FDs are a huge problem.  But all the settings documented don't see to 
> resolve the magic:

Ok.  This is yet a third issue - 1) crashes 2) high cpu 3) running out 
of FDs

>
> / Netscape Portable Runtime error -5971 (Process open FD table is full.)/
>
> error.
>
> Shouldn't this increase file descriptors in conjunction with 
> /etc/sysconfig/dirsrv.systemd change? FS-limits across the OS are set 
> to 65535 - /etc/security/limits.conf, /proc, sysctl.conf -- everything 
> but 389-ds itself. But I still can't get this to work, although it 
> does not give an error.
>
> ldapmodify -x -D "cn=directory manager" -W <<EOF
> dn: cn=config,cn=ldbm database,cn=plugins,cn=config
> changetype: modify
> replace: nsslapd-maxdescriptors
> nsslapd-maxdescriptors: 65535
> -
> replace: nsslapd-dtablesize
> nsslapd-dtablesize: 65535
> -
> replace: nsslapd-reservedescriptors
> nsslapd-reservedescriptors: 100
> EOF

Please see 
http://www.port389.org/docs/389ds/FAQ/performance-tuning.html#linux and 
http://www.port389.org/docs/389ds/howto/howto-systemd.html#increase-fd

Note that nsslapd-maxdescriptors: 65535 is extremely high.  I would not 
suggest going over 8192.

>
> Thanks
> ~J
>
> On 12/4/14 7:40 AM, Rob Crittenden wrote:
>> Dmitri Pal wrote:
>>> On 12/04/2014 09:41 AM, Rich Megginson wrote:
>>>> On 12/04/2014 08:39 AM, Rich Megginson wrote:
>>>>> On 12/04/2014 01:45 AM, Petr Spacek wrote:
>>>>>> On 4.12.2014 05:02, Janelle wrote:
>>>>>>> Thanks -- still a bit strange that it did not show up on some
>>>>>>> servers - vary
>>>>>>> random and intermittent.
>>>>>>>
>>>>>>> BTW - a bit of information others might find useful.  If you try to
>>>>>>> use the
>>>>>>> "LDAP" portion of IPA for authentication - rather than fulling
>>>>>>> installing the
>>>>>>> IPA client and using Kerberos - the servers running ds-389 do not
>>>>>>> do well in
>>>>>>> handling the load. In other words - a few hundred hosts trying to
>>>>>>> authenticate
>>>>>>> via LDAP only will send CPU through the roof and crashes the slapd
>>>>>>> process
>>>>>>> often.
>>>>> That should not happen.
>>>>> For crashes, we would need to look at some stack traces:
>>>>> http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-crashes
>>>>> For situations when the CPU is through the roof, that is very similar
>>>>> to debugging hangs:
>>>>> http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-hangs
>>>> Sorry, forgot to mention that since this is IPA you'll also need to
>>>> install the ipa-debuginfo and slapi-nis-debuginfo packages.
>>>>
>>> I would also add a question about your client configuration.
>>> For example if you use SSSD with enumerate=true for your clients then
>>> yes you will get your environment to the knees pretty quickly.
>> I assumed SSSD wasn't being used at all which begs the question: what
>> is? nss_ldap? Is nslcd being used?
>>
>> What is hitting LDAP, only auth or something else (e.g. sudo, automount).
>>
>> rob
>>
>>>>>>> Since IPA is supposed to handle all options, I guess I am
>>>>>>> disappointed.
>>>>>>>
>>>>>>> regards
>>>>>>> ~J
>>>>>>>
>>>>>>>
>>>>>>> On 12/3/14 2:56 PM, Dmitri Pal wrote:
>>>>>>>> On 12/03/2014 04:40 PM, Janelle wrote:
>>>>>>>>> Here is a bit of baffling one on 4.0.5:
>>>>>>>>>
>>>>>>>>> Replica install p11-kit???
>>>>>>>> This is a part of the DNSSEC set of packages.
>>>>>>>>
>>>>>>>>> Connection from master to replica is OK.
>>>>>>>>>
>>>>>>>>> Connection check OK
>>>>>>>>> p11-kit: ipa.p11-kit: x-public-key-info: invalid or unsupported
>>>>>>>>> attribute
>>>>>>>>> Configuring NTP daemon (ntpd)
>>>>>>>>>     [1/4]: stopping ntpd
>>>>>>>>>     [2/4]: writing configuration
>>>>>>>>> ...
>>>>>>>>>
>>>>>>>>> Your system may be partly configured.
>>>>>>>>> Run /usr/sbin/ipa-server-install --uninstall to clean up.
>>>>>>>>>
>>>>>>>>> LDAP error: UNWILLING_TO_PERFORM
>>>>>>>>> database is read-only
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Thoughts?
>>>>>> We need more information about your problem.
>>>>>>
>>>>>> As always, please start with information requested on
>>>>>> http://www.freeipa.org/page/Troubleshooting#Reporting_bugs
>>>>>>
>>>>>> /var/log/ipa*.log from affected replica will be invaluable (along
>>>>>> with exact
>>>>>> package version numbers [including p11-kit] and repo configuration).
>>>>>>
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141204/e619bbb6/attachment.htm>

From abokovoy at redhat.com  Thu Dec  4 16:27:22 2014
From: abokovoy at redhat.com (Alexander Bokovoy)
Date: Thu, 4 Dec 2014 18:27:22 +0200
Subject: [Freeipa-users] Cross-Realm authentification
In-Reply-To: <54808857.6070707@redhat.com>
References: <547F1233.4020709@kit.edu> <20141203135351.GG16288@redhat.com>
	<5480287B.4050406@kit.edu> <20141204110702.GH16288@redhat.com>
	<548041A1.7080305@redhat.com> <20141204112201.GI16288@redhat.com>
	<20141204105812.21a64688@willson.usersys.redhat.com>
	<54808857.6070707@redhat.com>
Message-ID: <20141204162722.GK16288@redhat.com>

On Thu, 04 Dec 2014, Petr Spacek wrote:
>On 4.12.2014 16:58, Simo Sorce wrote:
>> On Thu, 4 Dec 2014 13:22:01 +0200
>> Alexander Bokovoy <abokovoy at redhat.com> wrote:
>>
>>> On Thu, 04 Dec 2014, Petr Spacek wrote:
>>>>> And /var/log/krb5kdc.log on master.f21.test (KDC for F21.TEST) I
>>>>> can see:
>>>>> Dec 04 12:41:52 master.f21.test krb5kdc[1131](info): bad realm
>>>>> transit path from 'admin at IPA5.TEST' to
>>>>> 'host/master.f21.test at F21.TEST' via '' Dec 04 12:41:52
>>>>> master.f21.test krb5kdc[1131](info): TGS_REQ (6 etypes {18 17 16
>>>>> 23 25 26}) 192.168.5.109: BAD_TRANSIT: authtime 1417689777,
>>>>> admin at IPA5.TEST for host/master.f21.test at F21.TEST, KDC policy
>>>>> rejects request Dec 04 12:41:52 master.f21.test
>>>>> krb5kdc[1131](info): bad realm transit path from 'admin at IPA5.TEST'
>>>>> to 'host/master.f21.test at F21.TEST' via '' Dec 04 12:41:52
>>>>> master.f21.test krb5kdc[1131](info): TGS_REQ (6 etypes {18 17 16
>>>>> 23 25 26}) 192.168.5.109: BAD_TRANSIT: authtime 1417689777,
>>>>> admin at IPA5.TEST for host/master.f21.test at F21.TEST, KDC policy
>>>>> rejects request
>>>>>
>>>>> And this is correct for FreeIPA 3.3 or later because we limit
>>>>> trust to those domains we defined in cn=ad,cn=trusts,$SUFFIX with
>>>>> filter (objectclass=ipaNTTrustedDomain). For the rest we return
>>>>> KRB5KRB_AP_ERR_ILL_CR_TKT error code which is visible as 'KDC
>>>>> policy rejects request'.
>>>>>
>>>>>
>>>>> We may reconsider this check and instead of
>>>>> KRB5KRB_AP_ERR_ILL_CR_TKT return KRB5_PLUGIN_NO_HANDLE to allow
>>>>> fallback to krb5.conf-defined capaths but I remember we had some
>>>>> issues with krb5 versions prior to 1.12 where capaths from
>>>>> krb5.conf were blocking work of the DAL driver.
>>>>
>>>> Alexander, could you open a ticket to prevent us from forgetting
>>>> about it?
>>> I'm not sure yet this is valid. For FreeIPA-FreeIPA trust we'll have a
>>> separate solution and it will be along the lines of existing 'ipa
>>> trust-add' workflow where existing DAL driver code will work as it is.
>>
>> I think we should have a way to relax this requirement, so that people
>> like Andreas can play with kerberos level trusts.
>
>I agree.
Ok, then please file a ticket for this.
The change in the DAL driver will be a single line.
-- 
/ Alexander Bokovoy



From abokovoy at redhat.com  Thu Dec  4 16:30:51 2014
From: abokovoy at redhat.com (Alexander Bokovoy)
Date: Thu, 4 Dec 2014 18:30:51 +0200
Subject: [Freeipa-users] strange replica install error (another one)
In-Reply-To: <5480844A.6040405@gmail.com>
References: <547F8337.4020301@gmail.com> <547F9539.50602@redhat.com>
	<547FDCDF.6060200@gmail.com> <54801127.3060404@redhat.com>
	<54807218.7080208@redhat.com> <5480727E.9070302@redhat.com>
	<54807FE5.9060606@redhat.com> <5480807B.8040805@redhat.com>
	<5480844A.6040405@gmail.com>
Message-ID: <20141204163051.GL16288@redhat.com>

On Thu, 04 Dec 2014, Janelle wrote:
>Hi all,
>
>just (pam)auth and nslcd
>
>It was ported from a running OpenLDAP environment to IPA.  Just trying 
>to do conversions in stages so as not to change too much all at once. 
>Thought I could go from OpenLDAP to IPA and just use the backend of 
>389ds. Functionally it does work, but the load kills it. Seems like 
>FDs are a huge problem.  But all the settings documented don't see to 
>resolve the magic:
>
>/ Netscape Portable Runtime error -5971 (Process open FD table is full.)/
>
>error.
>
>Shouldn't this increase file descriptors in conjunction with 
>/etc/sysconfig/dirsrv.systemd change? FS-limits across the OS are set 
>to 65535 - /etc/security/limits.conf, /proc, sysctl.conf -- everything 
>but 389-ds itself. But I still can't get this to work, although it 
>does not give an error.
>
>ldapmodify -x -D "cn=directory manager" -W <<EOF
>dn: cn=config,cn=ldbm database,cn=plugins,cn=config
>changetype: modify
>replace: nsslapd-maxdescriptors
>nsslapd-maxdescriptors: 65535
>-
>replace: nsslapd-dtablesize
>nsslapd-dtablesize: 65535
>-
>replace: nsslapd-reservedescriptors
>nsslapd-reservedescriptors: 100
>EOF
As you said in the original messages that you are dealing with FreeIPA
4.0.5, it means you are on a system with systemd. For it to change
limits you have to do it differently. See
/lib/systemd/system/dirsrv at .service for detailed instructions.


-- 
/ Alexander Bokovoy



From janellenicole80 at gmail.com  Thu Dec  4 16:38:30 2014
From: janellenicole80 at gmail.com (Janelle)
Date: Thu, 04 Dec 2014 08:38:30 -0800
Subject: [Freeipa-users] strange replica install error (another one)
In-Reply-To: <20141204163051.GL16288@redhat.com>
References: <547F8337.4020301@gmail.com> <547F9539.50602@redhat.com>
	<547FDCDF.6060200@gmail.com> <54801127.3060404@redhat.com>
	<54807218.7080208@redhat.com> <5480727E.9070302@redhat.com>
	<54807FE5.9060606@redhat.com> <5480807B.8040805@redhat.com>
	<5480844A.6040405@gmail.com> <20141204163051.GL16288@redhat.com>
Message-ID: <54808E06.1030205@gmail.com>

On 12/4/14 8:30 AM, Alexander Bokovoy wrote:
> On Thu, 04 Dec 2014, Janelle wrote:
>> Hi all,
>>
>> just (pam)auth and nslcd
>>
>> It was ported from a running OpenLDAP environment to IPA.  Just 
>> trying to do conversions in stages so as not to change too much all 
>> at once. Thought I could go from OpenLDAP to IPA and just use the 
>> backend of 389ds. Functionally it does work, but the load kills it. 
>> Seems like FDs are a huge problem.  But all the settings documented 
>> don't see to resolve the magic:
>>
>> / Netscape Portable Runtime error -5971 (Process open FD table is 
>> full.)/
>>
>> error.
>>
>> Shouldn't this increase file descriptors in conjunction with 
>> /etc/sysconfig/dirsrv.systemd change? FS-limits across the OS are set 
>> to 65535 - /etc/security/limits.conf, /proc, sysctl.conf -- 
>> everything but 389-ds itself. But I still can't get this to work, 
>> although it does not give an error.
>>
>> ldapmodify -x -D "cn=directory manager" -W <<EOF
>> dn: cn=config,cn=ldbm database,cn=plugins,cn=config
>> changetype: modify
>> replace: nsslapd-maxdescriptors
>> nsslapd-maxdescriptors: 65535
>> -
>> replace: nsslapd-dtablesize
>> nsslapd-dtablesize: 65535
>> -
>> replace: nsslapd-reservedescriptors
>> nsslapd-reservedescriptors: 100
>> EOF
> As you said in the original messages that you are dealing with FreeIPA
> 4.0.5, it means you are on a system with systemd. For it to change
> limits you have to do it differently. See
> /lib/systemd/system/dirsrv at .service for detailed instructions.
>
>
from /lib/systemd/system/dirsrv at .service --

# if you need to set other directives e.g. LimitNOFILE=8192
# set them in this file
.include /etc/sysconfig/dirsrv.systemd

And that is the file that contains the LimitNOFILE=32768

So that was done. But it still seems to not make any difference since 
ns-slapd itself is still code to  8192. That is the issue I am facing - 
I can get beyond 8192.  (even if 65535 is not used - although that was 
the limit used with OpenLDAP and no issues)

~J



From lkrispen at redhat.com  Thu Dec  4 16:41:48 2014
From: lkrispen at redhat.com (Ludwig Krispenz)
Date: Thu, 04 Dec 2014 17:41:48 +0100
Subject: [Freeipa-users] strange replica install error (another one)
In-Reply-To: <5480844A.6040405@gmail.com>
References: <547F8337.4020301@gmail.com>	<547F9539.50602@redhat.com>	<547FDCDF.6060200@gmail.com>	<54801127.3060404@redhat.com>	<54807218.7080208@redhat.com>	<5480727E.9070302@redhat.com>	<54807FE5.9060606@redhat.com>
	<5480807B.8040805@redhat.com> <5480844A.6040405@gmail.com>
Message-ID: <54808ECC.5010406@redhat.com>


On 12/04/2014 04:56 PM, Janelle wrote:
> Hi all,
>
> just (pam)auth and nslcd
>
> It was ported from a running OpenLDAP environment to IPA.  Just trying 
> to do conversions in stages so as not to change too much all at once. 
> Thought I could go from OpenLDAP to IPA and just use the backend of 
> 389ds. Functionally it does work, but the load kills it. Seems like 
> FDs are a huge problem.  But all the settings documented don't see to 
> resolve the magic:
>
> / Netscape Portable Runtime error -5971 (Process open FD table is full.)/
>
> error.
>
> Shouldn't this increase file descriptors in conjunction with 
> /etc/sysconfig/dirsrv.systemd change? FS-limits across the OS are set 
> to 65535 - /etc/security/limits.conf, /proc, sysctl.conf -- everything 
> but 389-ds itself. But I still can't get this to work, although it 
> does not give an error.
>
> ldapmodify -x -D "cn=directory manager" -W <<EOF
> dn: cn=config,cn=ldbm database,cn=plugins,cn=config
> changetype: modify
> replace: nsslapd-maxdescriptors
> nsslapd-maxdescriptors: 65535
> -
> replace: nsslapd-dtablesize
> nsslapd-dtablesize: 65535
> -
> replace: nsslapd-reservedescriptors
> nsslapd-reservedescriptors: 100
> EOF
there are two problems
- how to increase the connetction table size in DS
I would suggest to replace nsslapd-conntablesize and restart the server, 
the change is not dynamic
- why you are running out of file descriptors
you should query "cn=monitor" to check the effective tablesize and the 
number of established connections
it could be a problem of clients not well behaving and not closing 
connections. you could set a low value of nsslapd-idletimeout to get rid 
of these connections

>
> Thanks
> ~J
>
> On 12/4/14 7:40 AM, Rob Crittenden wrote:
>> Dmitri Pal wrote:
>>> On 12/04/2014 09:41 AM, Rich Megginson wrote:
>>>> On 12/04/2014 08:39 AM, Rich Megginson wrote:
>>>>> On 12/04/2014 01:45 AM, Petr Spacek wrote:
>>>>>> On 4.12.2014 05:02, Janelle wrote:
>>>>>>> Thanks -- still a bit strange that it did not show up on some
>>>>>>> servers - vary
>>>>>>> random and intermittent.
>>>>>>>
>>>>>>> BTW - a bit of information others might find useful.  If you try to
>>>>>>> use the
>>>>>>> "LDAP" portion of IPA for authentication - rather than fulling
>>>>>>> installing the
>>>>>>> IPA client and using Kerberos - the servers running ds-389 do not
>>>>>>> do well in
>>>>>>> handling the load. In other words - a few hundred hosts trying to
>>>>>>> authenticate
>>>>>>> via LDAP only will send CPU through the roof and crashes the slapd
>>>>>>> process
>>>>>>> often.
>>>>> That should not happen.
>>>>> For crashes, we would need to look at some stack traces:
>>>>> http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-crashes
>>>>> For situations when the CPU is through the roof, that is very similar
>>>>> to debugging hangs:
>>>>> http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-hangs
>>>> Sorry, forgot to mention that since this is IPA you'll also need to
>>>> install the ipa-debuginfo and slapi-nis-debuginfo packages.
>>>>
>>> I would also add a question about your client configuration.
>>> For example if you use SSSD with enumerate=true for your clients then
>>> yes you will get your environment to the knees pretty quickly.
>> I assumed SSSD wasn't being used at all which begs the question: what
>> is? nss_ldap? Is nslcd being used?
>>
>> What is hitting LDAP, only auth or something else (e.g. sudo, automount).
>>
>> rob
>>
>>>>>>> Since IPA is supposed to handle all options, I guess I am
>>>>>>> disappointed.
>>>>>>>
>>>>>>> regards
>>>>>>> ~J
>>>>>>>
>>>>>>>
>>>>>>> On 12/3/14 2:56 PM, Dmitri Pal wrote:
>>>>>>>> On 12/03/2014 04:40 PM, Janelle wrote:
>>>>>>>>> Here is a bit of baffling one on 4.0.5:
>>>>>>>>>
>>>>>>>>> Replica install p11-kit???
>>>>>>>> This is a part of the DNSSEC set of packages.
>>>>>>>>
>>>>>>>>> Connection from master to replica is OK.
>>>>>>>>>
>>>>>>>>> Connection check OK
>>>>>>>>> p11-kit: ipa.p11-kit: x-public-key-info: invalid or unsupported
>>>>>>>>> attribute
>>>>>>>>> Configuring NTP daemon (ntpd)
>>>>>>>>>     [1/4]: stopping ntpd
>>>>>>>>>     [2/4]: writing configuration
>>>>>>>>> ...
>>>>>>>>>
>>>>>>>>> Your system may be partly configured.
>>>>>>>>> Run /usr/sbin/ipa-server-install --uninstall to clean up.
>>>>>>>>>
>>>>>>>>> LDAP error: UNWILLING_TO_PERFORM
>>>>>>>>> database is read-only
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Thoughts?
>>>>>> We need more information about your problem.
>>>>>>
>>>>>> As always, please start with information requested on
>>>>>> http://www.freeipa.org/page/Troubleshooting#Reporting_bugs
>>>>>>
>>>>>> /var/log/ipa*.log from affected replica will be invaluable (along
>>>>>> with exact
>>>>>> package version numbers [including p11-kit] and repo configuration).
>>>>>>
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141204/b55aa0f5/attachment.htm>

From pspacek at redhat.com  Thu Dec  4 16:46:02 2014
From: pspacek at redhat.com (Petr Spacek)
Date: Thu, 04 Dec 2014 17:46:02 +0100
Subject: [Freeipa-users] Cross-Realm authentification
In-Reply-To: <20141204162722.GK16288@redhat.com>
References: <547F1233.4020709@kit.edu> <20141203135351.GG16288@redhat.com>
	<5480287B.4050406@kit.edu> <20141204110702.GH16288@redhat.com>
	<548041A1.7080305@redhat.com> <20141204112201.GI16288@redhat.com>
	<20141204105812.21a64688@willson.usersys.redhat.com>
	<54808857.6070707@redhat.com> <20141204162722.GK16288@redhat.com>
Message-ID: <54808FCA.5060001@redhat.com>

On 4.12.2014 17:27, Alexander Bokovoy wrote:
> On Thu, 04 Dec 2014, Petr Spacek wrote:
>> On 4.12.2014 16:58, Simo Sorce wrote:
>>> On Thu, 4 Dec 2014 13:22:01 +0200
>>> Alexander Bokovoy <abokovoy at redhat.com> wrote:
>>>
>>>> On Thu, 04 Dec 2014, Petr Spacek wrote:
>>>>>> And /var/log/krb5kdc.log on master.f21.test (KDC for F21.TEST) I
>>>>>> can see:
>>>>>> Dec 04 12:41:52 master.f21.test krb5kdc[1131](info): bad realm
>>>>>> transit path from 'admin at IPA5.TEST' to
>>>>>> 'host/master.f21.test at F21.TEST' via '' Dec 04 12:41:52
>>>>>> master.f21.test krb5kdc[1131](info): TGS_REQ (6 etypes {18 17 16
>>>>>> 23 25 26}) 192.168.5.109: BAD_TRANSIT: authtime 1417689777,
>>>>>> admin at IPA5.TEST for host/master.f21.test at F21.TEST, KDC policy
>>>>>> rejects request Dec 04 12:41:52 master.f21.test
>>>>>> krb5kdc[1131](info): bad realm transit path from 'admin at IPA5.TEST'
>>>>>> to 'host/master.f21.test at F21.TEST' via '' Dec 04 12:41:52
>>>>>> master.f21.test krb5kdc[1131](info): TGS_REQ (6 etypes {18 17 16
>>>>>> 23 25 26}) 192.168.5.109: BAD_TRANSIT: authtime 1417689777,
>>>>>> admin at IPA5.TEST for host/master.f21.test at F21.TEST, KDC policy
>>>>>> rejects request
>>>>>>
>>>>>> And this is correct for FreeIPA 3.3 or later because we limit
>>>>>> trust to those domains we defined in cn=ad,cn=trusts,$SUFFIX with
>>>>>> filter (objectclass=ipaNTTrustedDomain). For the rest we return
>>>>>> KRB5KRB_AP_ERR_ILL_CR_TKT error code which is visible as 'KDC
>>>>>> policy rejects request'.
>>>>>>
>>>>>>
>>>>>> We may reconsider this check and instead of
>>>>>> KRB5KRB_AP_ERR_ILL_CR_TKT return KRB5_PLUGIN_NO_HANDLE to allow
>>>>>> fallback to krb5.conf-defined capaths but I remember we had some
>>>>>> issues with krb5 versions prior to 1.12 where capaths from
>>>>>> krb5.conf were blocking work of the DAL driver.
>>>>>
>>>>> Alexander, could you open a ticket to prevent us from forgetting
>>>>> about it?
>>>> I'm not sure yet this is valid. For FreeIPA-FreeIPA trust we'll have a
>>>> separate solution and it will be along the lines of existing 'ipa
>>>> trust-add' workflow where existing DAL driver code will work as it is.
>>>
>>> I think we should have a way to relax this requirement, so that people
>>> like Andreas can play with kerberos level trusts.
>>
>> I agree.
> Ok, then please file a ticket for this.
> The change in the DAL driver will be a single line.

It would be better if you described the details in the ticket, but here it is:
https://fedorahosted.org/freeipa/ticket/4791

Please add missing information.

Have a nice weekend!

-- 
Petr^2 Spacek



From janellenicole80 at gmail.com  Thu Dec  4 17:01:35 2014
From: janellenicole80 at gmail.com (Janelle)
Date: Thu, 04 Dec 2014 09:01:35 -0800
Subject: [Freeipa-users] strange replica install error (another one)
In-Reply-To: <54808ECC.5010406@redhat.com>
References: <547F8337.4020301@gmail.com>	<547F9539.50602@redhat.com>	<547FDCDF.6060200@gmail.com>	<54801127.3060404@redhat.com>	<54807218.7080208@redhat.com>	<5480727E.9070302@redhat.com>	<54807FE5.9060606@redhat.com>	<5480807B.8040805@redhat.com>
	<5480844A.6040405@gmail.com> <54808ECC.5010406@redhat.com>
Message-ID: <5480936F.1040500@gmail.com>

To help understand the environment a bit - perhaps this will help.

 1. Approx 7500 clients across 3 datacenters- all manor of *nix, ranging
    from AIX, Linux, HP-UX and Solaris - hence the reason why they all
    can't use ipa-client configs. Although that is in the plan at least
    for Linux systems.
 2. Servers/masters/replicas = 12 (4 each in 3 datacenters). Each DC has
    a primary CA so the replication agreements are between the 3 servers
    in each DC plus 1 server is a hot-spare and used strictly for
    replication to the other datacenters.
 3. running out of FDs because there are 100s of jobs running across all
    the servers that do a lot of sudo and group lookups and more have to
    happen. Also, approx 1100 users accessing servers in vary random
    ways - but just using ssh/pssh/other-tools.

Not sure if this helps - but perhaps?

~Janelle

On 12/4/14 8:41 AM, Ludwig Krispenz wrote:
>
> On 12/04/2014 04:56 PM, Janelle wrote:
>> Hi all,
>>
>> just (pam)auth and nslcd
>>
>> It was ported from a running OpenLDAP environment to IPA.  Just 
>> trying to do conversions in stages so as not to change too much all 
>> at once. Thought I could go from OpenLDAP to IPA and just use the 
>> backend of 389ds. Functionally it does work, but the load kills it. 
>> Seems like FDs are a huge problem.  But all the settings documented 
>> don't see to resolve the magic:
>>
>> / Netscape Portable Runtime error -5971 (Process open FD table is full.)/
>>
>> error.
>>
>> Shouldn't this increase file descriptors in conjunction with 
>> /etc/sysconfig/dirsrv.systemd change? FS-limits across the OS are set 
>> to 65535 - /etc/security/limits.conf, /proc, sysctl.conf -- 
>> everything but 389-ds itself. But I still can't get this to work, 
>> although it does not give an error.
>>
>> ldapmodify -x -D "cn=directory manager" -W <<EOF
>> dn: cn=config,cn=ldbm database,cn=plugins,cn=config
>> changetype: modify
>> replace: nsslapd-maxdescriptors
>> nsslapd-maxdescriptors: 65535
>> -
>> replace: nsslapd-dtablesize
>> nsslapd-dtablesize: 65535
>> -
>> replace: nsslapd-reservedescriptors
>> nsslapd-reservedescriptors: 100
>> EOF
> there are two problems
> - how to increase the connetction table size in DS
> I would suggest to replace nsslapd-conntablesize and restart the 
> server, the change is not dynamic
> - why you are running out of file descriptors
> you should query "cn=monitor" to check the effective tablesize and the 
> number of established connections
> it could be a problem of clients not well behaving and not closing 
> connections. you could set a low value of nsslapd-idletimeout to get 
> rid of these connections
>
>>
>> Thanks
>> ~J
>>
>> On 12/4/14 7:40 AM, Rob Crittenden wrote:
>>> Dmitri Pal wrote:
>>>> On 12/04/2014 09:41 AM, Rich Megginson wrote:
>>>>> On 12/04/2014 08:39 AM, Rich Megginson wrote:
>>>>>> On 12/04/2014 01:45 AM, Petr Spacek wrote:
>>>>>>> On 4.12.2014 05:02, Janelle wrote:
>>>>>>>> Thanks -- still a bit strange that it did not show up on some
>>>>>>>> servers - vary
>>>>>>>> random and intermittent.
>>>>>>>>
>>>>>>>> BTW - a bit of information others might find useful.  If you try to
>>>>>>>> use the
>>>>>>>> "LDAP" portion of IPA for authentication - rather than fulling
>>>>>>>> installing the
>>>>>>>> IPA client and using Kerberos - the servers running ds-389 do not
>>>>>>>> do well in
>>>>>>>> handling the load. In other words - a few hundred hosts trying to
>>>>>>>> authenticate
>>>>>>>> via LDAP only will send CPU through the roof and crashes the slapd
>>>>>>>> process
>>>>>>>> often.
>>>>>> That should not happen.
>>>>>> For crashes, we would need to look at some stack traces:
>>>>>> http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-crashes
>>>>>> For situations when the CPU is through the roof, that is very similar
>>>>>> to debugging hangs:
>>>>>> http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-hangs
>>>>> Sorry, forgot to mention that since this is IPA you'll also need to
>>>>> install the ipa-debuginfo and slapi-nis-debuginfo packages.
>>>>>
>>>> I would also add a question about your client configuration.
>>>> For example if you use SSSD with enumerate=true for your clients then
>>>> yes you will get your environment to the knees pretty quickly.
>>> I assumed SSSD wasn't being used at all which begs the question: what
>>> is? nss_ldap? Is nslcd being used?
>>>
>>> What is hitting LDAP, only auth or something else (e.g. sudo, automount).
>>>
>>> rob
>>>
>>>>>>>> Since IPA is supposed to handle all options, I guess I am
>>>>>>>> disappointed.
>>>>>>>>
>>>>>>>> regards
>>>>>>>> ~J
>>>>>>>>
>>>>>>>>
>>>>>>>> On 12/3/14 2:56 PM, Dmitri Pal wrote:
>>>>>>>>> On 12/03/2014 04:40 PM, Janelle wrote:
>>>>>>>>>> Here is a bit of baffling one on 4.0.5:
>>>>>>>>>>
>>>>>>>>>> Replica install p11-kit???
>>>>>>>>> This is a part of the DNSSEC set of packages.
>>>>>>>>>
>>>>>>>>>> Connection from master to replica is OK.
>>>>>>>>>>
>>>>>>>>>> Connection check OK
>>>>>>>>>> p11-kit: ipa.p11-kit: x-public-key-info: invalid or unsupported
>>>>>>>>>> attribute
>>>>>>>>>> Configuring NTP daemon (ntpd)
>>>>>>>>>>     [1/4]: stopping ntpd
>>>>>>>>>>     [2/4]: writing configuration
>>>>>>>>>> ...
>>>>>>>>>>
>>>>>>>>>> Your system may be partly configured.
>>>>>>>>>> Run /usr/sbin/ipa-server-install --uninstall to clean up.
>>>>>>>>>>
>>>>>>>>>> LDAP error: UNWILLING_TO_PERFORM
>>>>>>>>>> database is read-only
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Thoughts?
>>>>>>> We need more information about your problem.
>>>>>>>
>>>>>>> As always, please start with information requested on
>>>>>>> http://www.freeipa.org/page/Troubleshooting#Reporting_bugs
>>>>>>>
>>>>>>> /var/log/ipa*.log from affected replica will be invaluable (along
>>>>>>> with exact
>>>>>>> package version numbers [including p11-kit] and repo configuration).
>>>>>>>
>>
>>
>>
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141204/5ba9f328/attachment.htm>

From rmeggins at redhat.com  Thu Dec  4 17:30:48 2014
From: rmeggins at redhat.com (Rich Megginson)
Date: Thu, 04 Dec 2014 11:30:48 -0600
Subject: [Freeipa-users] strange replica install error (another one)
In-Reply-To: <5480936F.1040500@gmail.com>
References: <547F8337.4020301@gmail.com>	<547F9539.50602@redhat.com>	<547FDCDF.6060200@gmail.com>	<54801127.3060404@redhat.com>	<54807218.7080208@redhat.com>	<5480727E.9070302@redhat.com>	<54807FE5.9060606@redhat.com>	<5480807B.8040805@redhat.com>	<5480844A.6040405@gmail.com>
	<54808ECC.5010406@redhat.com> <5480936F.1040500@gmail.com>
Message-ID: <54809A48.5090705@redhat.com>

On 12/04/2014 11:01 AM, Janelle wrote:
> To help understand the environment a bit - perhaps this will help.
>
>  1. Approx 7500 clients across 3 datacenters- all manor of *nix,
>     ranging from AIX, Linux, HP-UX and Solaris - hence the reason why
>     they all can't use ipa-client configs. Although that is in the
>     plan at least for Linux systems.
>  2. Servers/masters/replicas = 12 (4 each in 3 datacenters). Each DC
>     has a primary CA so the replication agreements are between the 3
>     servers in each DC plus 1 server is a hot-spare and used strictly
>     for replication to the other datacenters.
>  3. running out of FDs because there are 100s of jobs running across
>     all the servers that do a lot of sudo and group lookups and more
>     have to happen. Also, approx 1100 users accessing servers in vary
>     random ways - but just using ssh/pssh/other-tools.
>

This is what nscd/sssd/others are used for - to cache those client 
connections/loads to keep the load off of the server.

Note that openldap uses epoll instead of poll() which is why it is 
better able to scale to 65k connections.  389 works well in environments 
where client caching is used.  The use of 65k connections in 389 could 
explain the high CPU load, but we would need stacktraces to determine 
that (as in the aforementioned Debugging_Hangs).

This still doesn't explain the crashing.


> Not sure if this helps - but perhaps?
>
> ~Janelle
>
> On 12/4/14 8:41 AM, Ludwig Krispenz wrote:
>>
>> On 12/04/2014 04:56 PM, Janelle wrote:
>>> Hi all,
>>>
>>> just (pam)auth and nslcd
>>>
>>> It was ported from a running OpenLDAP environment to IPA. Just 
>>> trying to do conversions in stages so as not to change too much all 
>>> at once. Thought I could go from OpenLDAP to IPA and just use the 
>>> backend of 389ds. Functionally it does work, but the load kills it. 
>>> Seems like FDs are a huge problem.  But all the settings documented 
>>> don't see to resolve the magic:
>>>
>>> / Netscape Portable Runtime error -5971 (Process open FD table is 
>>> full.)/
>>>
>>> error.
>>>
>>> Shouldn't this increase file descriptors in conjunction with 
>>> /etc/sysconfig/dirsrv.systemd change? FS-limits across the OS are 
>>> set to 65535 - /etc/security/limits.conf, /proc, sysctl.conf -- 
>>> everything but 389-ds itself. But I still can't get this to work, 
>>> although it does not give an error.
>>>
>>> ldapmodify -x -D "cn=directory manager" -W <<EOF
>>> dn: cn=config,cn=ldbm database,cn=plugins,cn=config
>>> changetype: modify
>>> replace: nsslapd-maxdescriptors
>>> nsslapd-maxdescriptors: 65535
>>> -
>>> replace: nsslapd-dtablesize
>>> nsslapd-dtablesize: 65535
>>> -
>>> replace: nsslapd-reservedescriptors
>>> nsslapd-reservedescriptors: 100
>>> EOF
>> there are two problems
>> - how to increase the connetction table size in DS
>> I would suggest to replace nsslapd-conntablesize and restart the 
>> server, the change is not dynamic
>> - why you are running out of file descriptors
>> you should query "cn=monitor" to check the effective tablesize and 
>> the number of established connections
>> it could be a problem of clients not well behaving and not closing 
>> connections. you could set a low value of nsslapd-idletimeout to get 
>> rid of these connections
>>
>>>
>>> Thanks
>>> ~J
>>>
>>> On 12/4/14 7:40 AM, Rob Crittenden wrote:
>>>> Dmitri Pal wrote:
>>>>> On 12/04/2014 09:41 AM, Rich Megginson wrote:
>>>>>> On 12/04/2014 08:39 AM, Rich Megginson wrote:
>>>>>>> On 12/04/2014 01:45 AM, Petr Spacek wrote:
>>>>>>>> On 4.12.2014 05:02, Janelle wrote:
>>>>>>>>> Thanks -- still a bit strange that it did not show up on some
>>>>>>>>> servers - vary
>>>>>>>>> random and intermittent.
>>>>>>>>>
>>>>>>>>> BTW - a bit of information others might find useful.  If you try to
>>>>>>>>> use the
>>>>>>>>> "LDAP" portion of IPA for authentication - rather than fulling
>>>>>>>>> installing the
>>>>>>>>> IPA client and using Kerberos - the servers running ds-389 do not
>>>>>>>>> do well in
>>>>>>>>> handling the load. In other words - a few hundred hosts trying to
>>>>>>>>> authenticate
>>>>>>>>> via LDAP only will send CPU through the roof and crashes the slapd
>>>>>>>>> process
>>>>>>>>> often.
>>>>>>> That should not happen.
>>>>>>> For crashes, we would need to look at some stack traces:
>>>>>>> http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-crashes
>>>>>>> For situations when the CPU is through the roof, that is very similar
>>>>>>> to debugging hangs:
>>>>>>> http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-hangs
>>>>>> Sorry, forgot to mention that since this is IPA you'll also need to
>>>>>> install the ipa-debuginfo and slapi-nis-debuginfo packages.
>>>>>>
>>>>> I would also add a question about your client configuration.
>>>>> For example if you use SSSD with enumerate=true for your clients then
>>>>> yes you will get your environment to the knees pretty quickly.
>>>> I assumed SSSD wasn't being used at all which begs the question: what
>>>> is? nss_ldap? Is nslcd being used?
>>>>
>>>> What is hitting LDAP, only auth or something else (e.g. sudo, automount).
>>>>
>>>> rob
>>>>
>>>>>>>>> Since IPA is supposed to handle all options, I guess I am
>>>>>>>>> disappointed.
>>>>>>>>>
>>>>>>>>> regards
>>>>>>>>> ~J
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 12/3/14 2:56 PM, Dmitri Pal wrote:
>>>>>>>>>> On 12/03/2014 04:40 PM, Janelle wrote:
>>>>>>>>>>> Here is a bit of baffling one on 4.0.5:
>>>>>>>>>>>
>>>>>>>>>>> Replica install p11-kit???
>>>>>>>>>> This is a part of the DNSSEC set of packages.
>>>>>>>>>>
>>>>>>>>>>> Connection from master to replica is OK.
>>>>>>>>>>>
>>>>>>>>>>> Connection check OK
>>>>>>>>>>> p11-kit: ipa.p11-kit: x-public-key-info: invalid or unsupported
>>>>>>>>>>> attribute
>>>>>>>>>>> Configuring NTP daemon (ntpd)
>>>>>>>>>>>     [1/4]: stopping ntpd
>>>>>>>>>>>     [2/4]: writing configuration
>>>>>>>>>>> ...
>>>>>>>>>>>
>>>>>>>>>>> Your system may be partly configured.
>>>>>>>>>>> Run /usr/sbin/ipa-server-install --uninstall to clean up.
>>>>>>>>>>>
>>>>>>>>>>> LDAP error: UNWILLING_TO_PERFORM
>>>>>>>>>>> database is read-only
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Thoughts?
>>>>>>>> We need more information about your problem.
>>>>>>>>
>>>>>>>> As always, please start with information requested on
>>>>>>>> http://www.freeipa.org/page/Troubleshooting#Reporting_bugs
>>>>>>>>
>>>>>>>> /var/log/ipa*.log from affected replica will be invaluable (along
>>>>>>>> with exact
>>>>>>>> package version numbers [including p11-kit] and repo configuration).
>>>>>>>>
>>>
>>>
>>>
>>
>>
>>
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141204/bc62e3ca/attachment.htm>

From nicolas.zin at savoirfairelinux.com  Thu Dec  4 17:49:36 2014
From: nicolas.zin at savoirfairelinux.com (Nicolas Zin)
Date: Thu, 4 Dec 2014 12:49:36 -0500 (EST)
Subject: [Freeipa-users] ad trust and default_domain_suffix
In-Reply-To: <1721728889.171428.1417542023984.JavaMail.root@mail>
Message-ID: <227542639.160677.1417715376443.JavaMail.root@mail>

Hi,

I have a IDM (v3.3) installed on a Redhat7.
I have a IDM realm connected to an AD via trust relationship.
In the IDM realm there are Redhat6 and Redhat5 clients.


My client ask to be able to connect to the Linux machine with their AD without entering their domain (just username). On Redhat 6 there is an option for sssd (default_domain_suffix=)
Seems to be exactly what I need, but I have a problem. If I use this option, I can indeed login with my AD username with domain name, but I cannot login with my Linux IDM username anymore, even if I use my fully qualified username at realm. i.e. In the middle of the PAM authentication it seems to fails (when ssh to the machine with ssh <server> -l admin@<realm>, I get Write failed: Broken pipe). If needed I can send more logs.

I reproduce the problem in a more simple environment: just a Linux realm, and default_domain_suffix set to a inexistant domain, and again I cannot ssh to my server with my fully qualified username at realm

Here is my sssd.conf:
[domain/idm1]
cache_credentials = True
krb5_store_password_if_offline = True
ipa_domain = idm1
id_provider = ipa
auth_provider = ipa
access_provider = ipa
ipa_hostname = dc.idm1
chpass_provider = ipa
ipa_server = dc.idm1
ipa_server_mode = True
ldap_tls_cacert = /etc/ipa/ca.crt
[sssd]
services = nss, pam, ssh
config_file_version = 2

domains = idm1

default_domain_suffix=toto.com
[nss]

[pam]

[sudo]

[autofs]

[ssh]

[pac]



Here is my krb5.conf:
includedir /var/lib/sss/pubconf/krb5.include.d/

[logging]
 default = FILE:/var/log/krb5libs.log
 kdc = FILE:/var/log/krb5kdc.log
 admin_server = FILE:/var/log/kadmind.log

[libdefaults]
 default_realm = IDM1
 dns_lookup_realm = false
 dns_lookup_kdc = true
 rdns = false
 ticket_lifetime = 24h
 forwardable = yes
 default_ccache_name = KEYRING:persistent:%{uid}
 ignore_acceptor_hostname = true

[realms]
 IDM1 = {
  kdc = dc.idm1:88
  master_kdc = dc.idm1:88
  admin_server = dc.idm1:749
  default_domain = idm1
  pkinit_anchors = FILE:/etc/ipa/ca.crt
}

[domain_realm]
 .idm1 = IDM1
 idm1 = IDM1

[dbmodules]
  IDM1 = {
    db_library = ipadb.so
  }



is there something to add to make it working?




Site note: also with Redhat5 which is configured following ipa-advise sssd-before-1.9, the default_domain_suffix is not understood with sssd<1.9. Is there a way to connect to force RHEL5 to let my windows user connect without entering their domain. I don?t know if there is a way to tune the compatibility tree return by the ldap server for example.

Or should I try to compile sssd 1.9 for RHEL5? (but I guess this is easier said than done) or it doesn?t worth it? (incompatibility with kerberos, or with the RHEL5 kernel?)


Regards,


Nicolas Zin



From nicolas.zin at savoirfairelinux.com  Thu Dec  4 21:53:00 2014
From: nicolas.zin at savoirfairelinux.com (Nicolas Zin)
Date: Thu, 4 Dec 2014 16:53:00 -0500 (EST)
Subject: [Freeipa-users] ad trust and default_domain_suffix
In-Reply-To: <227542639.160677.1417715376443.JavaMail.root@mail>
Message-ID: <992955671.305465.1417729980028.JavaMail.root@mail>

I answer to myself. (but my problem is not resolved)

> ----- Mail original -----
> De: "Nicolas Zin" <nicolas.zin at savoirfairelinux.com>
> ?: freeipa-users at redhat.com
> Envoy?: Jeudi 4 D?cembre 2014 18:49:36
> Objet: [Freeipa-users] ad trust and default_domain_suffix
> 
> Hi,
> 
> I have a IDM (v3.3) installed on a Redhat7.
> I have a IDM realm connected to an AD via trust relationship.
> In the IDM realm there are Redhat6 and Redhat5 clients.
> 
> 
> My client ask to be able to connect to the Linux machine with their AD without entering their domain (just username). On Redhat 6 there is an option for sssd (default_domain_suffix=)
> Seems to be exactly what I need, but I have a problem. If I use this option, I can indeed login with my AD username with domain name, but I cannot login with my Linux IDM username anymore, even if I use my fully qualified username at realm. i.e. In the middle of the PAM authentication it seems to fails (when ssh to the machine with ssh <server> -l admin@<realm>, I get Write failed: Broken pipe). If needed I can send more logs.
> 
> I reproduce the problem in a more simple environment: just a Linux realm, and default_domain_suffix set to a inexistant domain, and again I cannot ssh to my server with my fully qualified username at realm

so when I try to do "ssh localhost -l admin at idm1" (idm is my domain name),
in the /var/log/sssd/sssd_nss.log I find:
...
(Wed Dec  3 22:44:43 2014) [sssd[nss]] [nss_cmd_getpwnam_search] (0x0100): Requesting info for [admin at idm1]
(Wed Dec  3 22:44:43 2014) [sssd[nss]] [nss_cmd_getbynam] (0x0100): Requesting info for [admin] from [idm1]
(Wed Dec  3 22:44:43 2014) [sssd[nss]] [nss_cmd_getpwnam_search] (0x0100): Requesting info for [admin at idm1]
(Wed Dec  3 22:44:43 2014) [sssd[nss]] [nss_cmd_getbynam] (0x0100): Requesting info for [admin] from [idm1]
(Wed Dec  3 22:44:43 2014) [sssd[nss]] [nss_cmd_getpwnam_search] (0x0100): Requesting info for [admin at idm1]
(Wed Dec  3 22:44:43 2014) [sssd[nss]] [nss_cmd_getbynam] (0x0100): Requesting info for [admin] from [idm1]
(Wed Dec  3 22:44:43 2014) [sssd[nss]] [nss_cmd_getpwnam_search] (0x0100): Requesting info for [admin at idm1]
(Wed Dec  3 22:44:43 2014) [sssd[nss]] [nss_cmd_getbynam] (0x0100): Requesting info for [admin] from [idm1]
(Wed Dec  3 22:44:43 2014) [sssd[nss]] [nss_cmd_getpwnam_search] (0x0100): Requesting info for [admin at idm1]
(Wed Dec  3 22:44:43 2014) [sssd[nss]] [nss_cmd_getbynam_done] (0x0040): Invalid name received [admin]


So it seems to be a problem with nss not able to find my user.
Indeed, if I do a "getent passwd admin" it doesn't show anything, but if I do a "getent passwd admin at idm1" it works.

I found a "workardound":
getent passwd admin at idm1 >> /etc/passwd


Now I can ssh to my server:
ssh localhost -l admin at idm1



Is it a bug? is there a better "workaround"?


Regards,



From mkosek at redhat.com  Fri Dec  5 09:00:02 2014
From: mkosek at redhat.com (Martin Kosek)
Date: Fri, 05 Dec 2014 10:00:02 +0100
Subject: [Freeipa-users] strange error - disconnecting a replica?
In-Reply-To: <547F4701.5060501@gmail.com>
References: <547F4701.5060501@gmail.com>
Message-ID: <54817412.7000208@redhat.com>

On 12/03/2014 06:23 PM, Janelle wrote:
> Hi all..
>
> Was on vacation - now I'm back. Have a new problem I thought I would run by you --
>
> I have replica agreements between a server and 3 others. They all show up in
> ipa-replica-manage list, BUT when I try to disconnect one of them :
>
> ipa: INFO: Replication Update in progress: FALSE: status: 1 Can't acquire busy
> replica: start: 0: end: 0
>
> Any idea what this might be telling me? And any ideas on how to reduce CPU load
> on replicas other than to reduce the number of hosts they replicate to?
>
> Thanks
> ~J
>

Ludwig or Thierry, do you now? I am not sure what "Can't acquire busy replica" 
means in DS speak...

Thanks,
Martin



From tbordaz at redhat.com  Fri Dec  5 09:03:24 2014
From: tbordaz at redhat.com (thierry bordaz)
Date: Fri, 05 Dec 2014 10:03:24 +0100
Subject: [Freeipa-users] strange error - disconnecting a replica?
In-Reply-To: <54817412.7000208@redhat.com>
References: <547F4701.5060501@gmail.com> <54817412.7000208@redhat.com>
Message-ID: <548174DC.1040703@redhat.com>

On 12/05/2014 10:00 AM, Martin Kosek wrote:
> On 12/03/2014 06:23 PM, Janelle wrote:
>> Hi all..
>>
>> Was on vacation - now I'm back. Have a new problem I thought I would 
>> run by you --
>>
>> I have replica agreements between a server and 3 others. They all 
>> show up in
>> ipa-replica-manage list, BUT when I try to disconnect one of them :
>>
>> ipa: INFO: Replication Update in progress: FALSE: status: 1 Can't 
>> acquire busy
>> replica: start: 0: end: 0
>>
>> Any idea what this might be telling me? And any ideas on how to 
>> reduce CPU load
>> on replicas other than to reduce the number of hosts they replicate to?
>>
>> Thanks
>> ~J
>>
>
> Ludwig or Thierry, do you now? I am not sure what "Can't acquire busy 
> replica" means in DS speak...
>
> Thanks,
> Martin
Hello,

    The replica agreement reporting this status is trying to update a
    replica. Before doing that it needs to "acquire" the replica.
    The replica (consumer) is said to be busy when an other replica
    (acting as supplier) is currently updating it.
    This should be a transient issue or there are many updates currently
    sent.

    May I have a look at the machine ?

    thanks
    theirry

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141205/991b5427/attachment.htm>

From tbordaz at redhat.com  Fri Dec  5 09:11:50 2014
From: tbordaz at redhat.com (thierry bordaz)
Date: Fri, 05 Dec 2014 10:11:50 +0100
Subject: [Freeipa-users] strange error - disconnecting a replica?
In-Reply-To: <548174DC.1040703@redhat.com>
References: <547F4701.5060501@gmail.com> <54817412.7000208@redhat.com>
	<548174DC.1040703@redhat.com>
Message-ID: <548176D6.9090201@redhat.com>

On 12/05/2014 10:03 AM, thierry bordaz wrote:
> On 12/05/2014 10:00 AM, Martin Kosek wrote:
>> On 12/03/2014 06:23 PM, Janelle wrote:
>>> Hi all..
>>>
>>> Was on vacation - now I'm back. Have a new problem I thought I would 
>>> run by you --
>>>
>>> I have replica agreements between a server and 3 others. They all 
>>> show up in
>>> ipa-replica-manage list, BUT when I try to disconnect one of them :
>>>
>>> ipa: INFO: Replication Update in progress: FALSE: status: 1 Can't 
>>> acquire busy
>>> replica: start: 0: end: 0
>>>
>>> Any idea what this might be telling me? And any ideas on how to 
>>> reduce CPU load
>>> on replicas other than to reduce the number of hosts they replicate to?
>>>
>>> Thanks
>>> ~J
>>>
>>
>> Ludwig or Thierry, do you now? I am not sure what "Can't acquire busy 
>> replica" means in DS speak...
>>
>> Thanks,
>> Martin
> Hello,
>
>     The replica agreement reporting this status is trying to update a
>     replica. Before doing that it needs to "acquire" the replica.
>     The replica (consumer) is said to be busy when an other replica
>     (acting as supplier) is currently updating it.
>     This should be a transient issue or there are many updates
>     currently sent.
>
>     May I have a look at the machine ?
>
>     thanks
>     theirry
>

Humm sorry, not the right approach.

I think you need to turn on the replication logging on the replicas and 
provide the logs (access/errors) + config.
One thing to look at is to monitor the access logs of the replica (that 
is busy) to check if it receives updates from a replication session.

thanks
theirry
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141205/85a5ab8b/attachment.htm>

From mkosek at redhat.com  Fri Dec  5 09:16:16 2014
From: mkosek at redhat.com (Martin Kosek)
Date: Fri, 05 Dec 2014 10:16:16 +0100
Subject: [Freeipa-users] strange error - disconnecting a replica?
In-Reply-To: <54817412.7000208@redhat.com>
References: <547F4701.5060501@gmail.com> <54817412.7000208@redhat.com>
Message-ID: <548177E0.6030201@redhat.com>

On 12/05/2014 10:00 AM, Martin Kosek wrote:
> On 12/03/2014 06:23 PM, Janelle wrote:
>> Hi all..
>>
>> Was on vacation - now I'm back. Have a new problem I thought I would run by
>> you --
>>
>> I have replica agreements between a server and 3 others. They all show up in
>> ipa-replica-manage list, BUT when I try to disconnect one of them :
>>
>> ipa: INFO: Replication Update in progress: FALSE: status: 1 Can't acquire busy
>> replica: start: 0: end: 0
>>
>> Any idea what this might be telling me? And any ideas on how to reduce CPU load
>> on replicas other than to reduce the number of hosts they replicate to?
>>
>> Thanks
>> ~J
>>
>
> Ludwig or Thierry, do you now? I am not sure what "Can't acquire busy replica"
> means in DS speak...

Maybe I jumped the gun. Now I see the issues that Janelle hit are being 
discussed in the next thread "[Freeipa-users] strange replica install error 
(another one)". So we can just continue there.

Martin



From andreas.ladanyi at kit.edu  Fri Dec  5 12:26:35 2014
From: andreas.ladanyi at kit.edu (Andreas Ladanyi)
Date: Fri, 05 Dec 2014 13:26:35 +0100
Subject: [Freeipa-users] Cross-Realm authentification
In-Reply-To: <20141204110702.GH16288@redhat.com>
References: <547F1233.4020709@kit.edu> <20141203135351.GG16288@redhat.com>
	<5480287B.4050406@kit.edu> <20141204110702.GH16288@redhat.com>
Message-ID: <5481A47B.2000005@kit.edu>


> I'm also getting errors but they are different to yours. Here is what I
> did:
>
> (on master.f21.test, realm F21.TEST):
> [root at master ~]# kadmin.local -x ipa-setup-override-restrictions -r
> F21.TEST
> Authenticating as principal root/admin at F21.TEST with password.
> kadmin.local:  addprinc -requires_preauth krbtgt/IPA5.TEST
> WARNING: no policy specified for krbtgt/IPA5.TEST at F21.TEST; defaulting
> to no policy
> Enter password for principal "krbtgt/IPA5.TEST at F21.TEST": Re-enter
> password for principal "krbtgt/IPA5.TEST at F21.TEST": Principal
> "krbtgt/IPA5.TEST at F21.TEST" created.
> kadmin.local:  addprinc -requires_preauth krbtgt/F21.TEST at IPA5.TEST
> WARNING: no policy specified for krbtgt/F21.TEST at IPA5.TEST; defaulting
> to no policy
> Enter password for principal "krbtgt/F21.TEST at IPA5.TEST": Re-enter
> password for principal "krbtgt/F21.TEST at IPA5.TEST": Principal
> "krbtgt/F21.TEST at IPA5.TEST" created.
> kadmin.local:  q
>
> added following to the /etc/krb5.conf:
> [libdefaults]
> dns_lookup_realm = true
>
> [domain_realms]
> .ipa5.test = IPA5.TEST
> ipa5.test = IPA5.TEST
Why only one domain and one realm if you have two REALMs ?

On this position i have another question:

I have 2 REALMs and one DNS domain.

.domainname_X = REALM A
domainname_X = REALM A
.domainname_X = REALM B
domainname_X = REALM B

Could this work clear ?



On my first "kvno -S host hostname_in_foreign_domain" i saw that the
temporary realm wasnt choosen correct. So i had to delete one REALM
entry in the domain_realm section to get kvno -S chooses the correct (
foreign ) temporary realm.



>
> [capaths]
> F21.TEST = {  IPA5.TEST = . }
> IPA5.TEST = {  F21.TEST = . }
>
>
>
> (on ipa-05-m.ipa5.test, realm IPA5.TEST):
> [root at ipa-05-m ~]# kadmin.local -x ipa-setup-override-restrictions -r
> IPA5.TEST
> Authenticating as principal admin/admin at IPA5.TEST with password.
> kadmin.local:  addprinc -requires_preauth krbtgt/F21.TEST
> WARNING: no policy specified for krbtgt/F21.TEST at IPA5.TEST; defaulting
> to no policy
> Enter password for principal "krbtgt/F21.TEST at IPA5.TEST": Re-enter
> password for principal "krbtgt/F21.TEST at IPA5.TEST": Principal
> "krbtgt/F21.TEST at IPA5.TEST" created.
> kadmin.local:  addprinc -requires_preauth krbtgt/IPA5.TEST at F21.TEST
> WARNING: no policy specified for krbtgt/IPA5.TEST at F21.TEST; defaulting
> to no policy
> Enter password for principal "krbtgt/IPA5.TEST at F21.TEST": Re-enter
> password for principal "krbtgt/IPA5.TEST at F21.TEST": Principal
> "krbtgt/IPA5.TEST at F21.TEST" created.
> kadmin.local:  q
>
Ok, i see one difference: i didnt use the "-requires_preauth" flag. Why
did you use them ?
> and similar changes to /etc/krb5.conf.
>
> Then I tried to get a ticket to host/master.f21.test at F21.TEST while
> being an admin at IPA5.TEST:
I tried out this on the IPA box to connect to the non IPA box (foreign
realm).
>
> [root at ipa-05-m ~]# kinit admin
> Password for admin at IPA5.TEST: [root at ipa-05-m ~]#
> KRB5_TRACE=/dev/stderr kvno -S host master.f21.test
> [22351] 1417689782.154516: Convert service host (service with host as
> instance) on host master.f21.test to principal
> [22351] 1417689782.158724: Remote host after forward canonicalization:
> master.f21.test
> [22351] 1417689782.158814: Remote host after reverse DNS processing:
> master.f21.test
> [22351] 1417689782.158849: Get host realm for master.f21.test
> [22351] 1417689782.158899: Use local host master.f21.test to get host
> realm
> [22351] 1417689782.158946: Look up master.f21.test in the domain_realm
> map
> [22351] 1417689782.158999: Look up .f21.test in the domain_realm map
> [22351] 1417689782.159023: Temporary realm is F21.TEST
> [22351] 1417689782.159044: Got realm F21.TEST for host master.f21.test
> [22351] 1417689782.159071: Got service principal
> host/master.f21.test at F21.TEST
> [22351] 1417689782.159098: Getting credentials admin at IPA5.TEST ->
> host/master.f21.test at F21.TEST using ccache KEYRING:persistent:0:0
> [22351] 1417689782.159237: Retrieving admin at IPA5.TEST ->
> host/master.f21.test at F21.TEST from KEYRING:persistent:0:0 with result:
> -1765328243/Matching credential not found
> [22351] 1417689782.159297: Retrieving admin at IPA5.TEST ->
> krbtgt/F21.TEST at IPA5.TEST from KEYRING:persistent:0:0 with result:
> -1765328243/Matching credential not found
> [22351] 1417689782.159411: Retrieving admin at IPA5.TEST ->
> krbtgt/IPA5.TEST at IPA5.TEST from KEYRING:persistent:0:0 with result:
> 0/Success
> [22351] 1417689782.159453: Starting with TGT for client realm:
> admin at IPA5.TEST -> krbtgt/IPA5.TEST at IPA5.TEST
> [22351] 1417689782.159502: Retrieving admin at IPA5.TEST ->
> krbtgt/F21.TEST at IPA5.TEST from KEYRING:persistent:0:0 with result:
> -1765328243/Matching credential not found
> [22351] 1417689782.159530: Requesting TGT krbtgt/F21.TEST at IPA5.TEST
> using TGT krbtgt/IPA5.TEST at IPA5.TEST
> [22351] 1417689782.159576: Generated subkey for TGS request:
> aes256-cts/54E6
> [22351] 1417689782.159628: etypes requested in TGS request:
> aes256-cts, aes128-cts, des3-cbc-sha1, rc4-hmac, camellia128-cts,
> camellia256-cts
> [22351] 1417689782.159726: Encoding request body and padata into FAST
> request
> [22351] 1417689782.159784: Sending request (890 bytes) to IPA5.TEST
> [22351] 1417689782.159909: Sending initial UDP request to dgram
> 192.168.5.109:88
> [22351] 1417689782.161823: Received answer from dgram 192.168.5.109:88
> [22351] 1417689782.161925: Response was from master KDC
> [22351] 1417689782.162011: Decoding FAST response
> [22351] 1417689782.162084: FAST reply key: aes256-cts/EBCE
> [22351] 1417689782.162127: TGS reply is for admin at IPA5.TEST ->
> krbtgt/F21.TEST at IPA5.TEST with session key aes256-cts/822B
> [22351] 1417689782.162159: TGS request result: 0/Success
> [22351] 1417689782.162185: Removing admin at IPA5.TEST ->
> krbtgt/F21.TEST at IPA5.TEST from KEYRING:persistent:0:0
> [22351] 1417689782.162207: Storing admin at IPA5.TEST ->
> krbtgt/F21.TEST at IPA5.TEST in KEYRING:persistent:0:0
> [22351] 1417689782.162268: Received TGT for service realm:
> krbtgt/F21.TEST at IPA5.TEST
> [22351] 1417689782.162296: Requesting tickets for
> host/master.f21.test at F21.TEST, referrals on
> [22351] 1417689782.162322: Generated subkey for TGS request:
> aes256-cts/61A2
> [22351] 1417689782.162359: etypes requested in TGS request:
> aes256-cts, aes128-cts, des3-cbc-sha1, rc4-hmac, camellia128-cts,
> camellia256-cts
> [22351] 1417689782.162413: Encoding request body and padata into FAST
> request
> [22351] 1417689782.162460: Sending request (855 bytes) to F21.TEST
> [22351] 1417689782.162493: Resolving hostname master.f21.test
> [22351] 1417689782.163213: Sending initial UDP request to dgram
> 192.168.5.169:88
> [22351] 1417689782.165439: Received answer from dgram 192.168.5.169:88
> [22351] 1417689782.165516: Response was from master KDC
In my case:

[31580] 1417773156.446922: TGS request result: -1765328324/KDC returned
error string: PROCESS_TGS

There is no Decoding FAST response.

> [22351] 1417689782.165572: Decoding FAST response
> [22351] 1417689782.165643: TGS request result: -1765328372/KDC policy
> rejects request
> [22351] 1417689782.165680: Requesting tickets for
> host/master.f21.test at F21.TEST, referrals off
> [22351] 1417689782.165714: Generated subkey for TGS request:
> aes256-cts/FEA9
> [22351] 1417689782.165751: etypes requested in TGS request:
> aes256-cts, aes128-cts, des3-cbc-sha1, rc4-hmac, camellia128-cts,
> camellia256-cts
> [22351] 1417689782.165799: Encoding request body and padata into FAST
> request
> [22351] 1417689782.165847: Sending request (855 bytes) to F21.TEST
> [22351] 1417689782.165875: Resolving hostname master.f21.test
> [22351] 1417689782.166084: Sending initial UDP request to dgram
> 192.168.5.169:88
> [22351] 1417689782.167602: Received answer from dgram 192.168.5.169:88
> [22351] 1417689782.167642: Response was from master KDC
In my case at this position:

[31580] 1417773156.449640: TGS request result: -1765328324/KDC returned
error string: PROCESS_TGS
kvno: KDC returned error string: PROCESS_TGS while getting credentials for

I found out that at the non IPA KDC (the foreign KDC) isnt a Port 88
available (closed). The ports 464+749 are available.

On the IPA KDC there are ports 88+464+749

There is no Decoding FAST response.

> [22351] 1417689782.167669: Decoding FAST response
> [22351] 1417689782.167709: TGS request result: -1765328372/KDC policy
> rejects request
> kvno: KDC policy rejects request while getting credentials for
> host/master.f21.test at F21.TEST
> [root at ipa-05-m ~]#
> And /var/log/krb5kdc.log on master.f21.test (KDC for F21.TEST) I can
> see:
> Dec 04 12:41:52 master.f21.test krb5kdc[1131](info): bad realm transit
> path from 'admin at IPA5.TEST' to 'host/master.f21.test at F21.TEST' via ''
> Dec 04 12:41:52 master.f21.test krb5kdc[1131](info): TGS_REQ (6 etypes
> {18 17 16 23 25 26}) 192.168.5.109: BAD_TRANSIT: authtime 1417689777,
> admin at IPA5.TEST for host/master.f21.test at F21.TEST, KDC policy rejects
> request
> Dec 04 12:41:52 master.f21.test krb5kdc[1131](info): bad realm transit
> path from 'admin at IPA5.TEST' to 'host/master.f21.test at F21.TEST' via ''
> Dec 04 12:41:52 master.f21.test krb5kdc[1131](info): TGS_REQ (6 etypes
> {18 17 16 23 25 26}) 192.168.5.109: BAD_TRANSIT: authtime 1417689777,
> admin at IPA5.TEST for host/master.f21.test at F21.TEST, KDC policy rejects
> request
>
> And this is correct for FreeIPA 3.3 or later because we limit trust to
> those domains we defined in cn=ad,cn=trusts,$SUFFIX with filter
> (objectclass=ipaNTTrustedDomain). For the rest we return
> KRB5KRB_AP_ERR_ILL_CR_TKT error code which is visible as 'KDC policy
> rejects request'.
Is it possible or a good idea to add my trust domain, which isnt a AD
domain, manualy to IPA 3.3 ?
>
>
> We may reconsider this check and instead of KRB5KRB_AP_ERR_ILL_CR_TKT
> return KRB5_PLUGIN_NO_HANDLE to allow fallback to krb5.conf-defined
> capaths but I remember we had some issues with krb5 versions prior to
> 1.12 where capaths from krb5.conf were blocking work of the DAL driver.
I use MIT Kerberos 1.6 from OpenCSW on Solaris and FreeIPA 3.3.5. So
this shouldnt be a problem ?!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5306 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141205/73e41b6f/attachment.p7s>

From abokovoy at redhat.com  Fri Dec  5 12:56:37 2014
From: abokovoy at redhat.com (Alexander Bokovoy)
Date: Fri, 5 Dec 2014 14:56:37 +0200
Subject: [Freeipa-users] Cross-Realm authentification
In-Reply-To: <5481A47B.2000005@kit.edu>
References: <547F1233.4020709@kit.edu> <20141203135351.GG16288@redhat.com>
	<5480287B.4050406@kit.edu> <20141204110702.GH16288@redhat.com>
	<5481A47B.2000005@kit.edu>
Message-ID: <20141205125637.GM16288@redhat.com>

On Fri, 05 Dec 2014, Andreas Ladanyi wrote:
>
>> I'm also getting errors but they are different to yours. Here is what I
>> did:
>>
>> (on master.f21.test, realm F21.TEST):
>> [root at master ~]# kadmin.local -x ipa-setup-override-restrictions -r
>> F21.TEST
>> Authenticating as principal root/admin at F21.TEST with password.
>> kadmin.local:  addprinc -requires_preauth krbtgt/IPA5.TEST
>> WARNING: no policy specified for krbtgt/IPA5.TEST at F21.TEST; defaulting
>> to no policy
>> Enter password for principal "krbtgt/IPA5.TEST at F21.TEST": Re-enter
>> password for principal "krbtgt/IPA5.TEST at F21.TEST": Principal
>> "krbtgt/IPA5.TEST at F21.TEST" created.
>> kadmin.local:  addprinc -requires_preauth krbtgt/F21.TEST at IPA5.TEST
>> WARNING: no policy specified for krbtgt/F21.TEST at IPA5.TEST; defaulting
>> to no policy
>> Enter password for principal "krbtgt/F21.TEST at IPA5.TEST": Re-enter
>> password for principal "krbtgt/F21.TEST at IPA5.TEST": Principal
>> "krbtgt/F21.TEST at IPA5.TEST" created.
>> kadmin.local:  q
>>
>> added following to the /etc/krb5.conf:
>> [libdefaults]
>> dns_lookup_realm = true
>>
>> [domain_realms]
>> .ipa5.test = IPA5.TEST
>> ipa5.test = IPA5.TEST
>Why only one domain and one realm if you have two REALMs ?
Because this is what I _added_. The F21.TEST entries were already in
place.

>On this position i have another question:
>
>I have 2 REALMs and one DNS domain.
>
>.domainname_X = REALM A
>domainname_X = REALM A
>.domainname_X = REALM B
>domainname_X = REALM B
>
>Could this work clear ?
No. What realm would it select if the domain name is the same? Either
you define explicitly per each host which realm the host belongs to or
you'd have different DNS domains for the realms.

>> "krbtgt/IPA5.TEST at F21.TEST" created.
>> kadmin.local:  q
>>
>Ok, i see one difference: i didnt use the "-requires_preauth" flag. Why
>did you use them ?
Because this is recommended by MIT documentation. The link between
realms has to be protected well, including preauth and good passwords
for the cross-realm principals.

>> and similar changes to /etc/krb5.conf.
>>
>> Then I tried to get a ticket to host/master.f21.test at F21.TEST while
>> being an admin at IPA5.TEST:
>I tried out this on the IPA box to connect to the non IPA box (foreign
>realm).
>>
>> [root at ipa-05-m ~]# kinit admin
>> Password for admin at IPA5.TEST: [root at ipa-05-m ~]#
>> KRB5_TRACE=/dev/stderr kvno -S host master.f21.test
>> [22351] 1417689782.154516: Convert service host (service with host as
>> instance) on host master.f21.test to principal
>> [22351] 1417689782.158724: Remote host after forward canonicalization:
>> master.f21.test
>> [22351] 1417689782.158814: Remote host after reverse DNS processing:
>> master.f21.test
>> [22351] 1417689782.158849: Get host realm for master.f21.test
>> [22351] 1417689782.158899: Use local host master.f21.test to get host
>> realm
>> [22351] 1417689782.158946: Look up master.f21.test in the domain_realm
>> map
>> [22351] 1417689782.158999: Look up .f21.test in the domain_realm map
>> [22351] 1417689782.159023: Temporary realm is F21.TEST
>> [22351] 1417689782.159044: Got realm F21.TEST for host master.f21.test
>> [22351] 1417689782.159071: Got service principal
>> host/master.f21.test at F21.TEST
>> [22351] 1417689782.159098: Getting credentials admin at IPA5.TEST ->
>> host/master.f21.test at F21.TEST using ccache KEYRING:persistent:0:0
>> [22351] 1417689782.159237: Retrieving admin at IPA5.TEST ->
>> host/master.f21.test at F21.TEST from KEYRING:persistent:0:0 with result:
>> -1765328243/Matching credential not found
>> [22351] 1417689782.159297: Retrieving admin at IPA5.TEST ->
>> krbtgt/F21.TEST at IPA5.TEST from KEYRING:persistent:0:0 with result:
>> -1765328243/Matching credential not found
>> [22351] 1417689782.159411: Retrieving admin at IPA5.TEST ->
>> krbtgt/IPA5.TEST at IPA5.TEST from KEYRING:persistent:0:0 with result:
>> 0/Success
>> [22351] 1417689782.159453: Starting with TGT for client realm:
>> admin at IPA5.TEST -> krbtgt/IPA5.TEST at IPA5.TEST
>> [22351] 1417689782.159502: Retrieving admin at IPA5.TEST ->
>> krbtgt/F21.TEST at IPA5.TEST from KEYRING:persistent:0:0 with result:
>> -1765328243/Matching credential not found
>> [22351] 1417689782.159530: Requesting TGT krbtgt/F21.TEST at IPA5.TEST
>> using TGT krbtgt/IPA5.TEST at IPA5.TEST
>> [22351] 1417689782.159576: Generated subkey for TGS request:
>> aes256-cts/54E6
>> [22351] 1417689782.159628: etypes requested in TGS request:
>> aes256-cts, aes128-cts, des3-cbc-sha1, rc4-hmac, camellia128-cts,
>> camellia256-cts
>> [22351] 1417689782.159726: Encoding request body and padata into FAST
>> request
>> [22351] 1417689782.159784: Sending request (890 bytes) to IPA5.TEST
>> [22351] 1417689782.159909: Sending initial UDP request to dgram
>> 192.168.5.109:88
>> [22351] 1417689782.161823: Received answer from dgram 192.168.5.109:88
>> [22351] 1417689782.161925: Response was from master KDC
>> [22351] 1417689782.162011: Decoding FAST response
>> [22351] 1417689782.162084: FAST reply key: aes256-cts/EBCE
>> [22351] 1417689782.162127: TGS reply is for admin at IPA5.TEST ->
>> krbtgt/F21.TEST at IPA5.TEST with session key aes256-cts/822B
>> [22351] 1417689782.162159: TGS request result: 0/Success
>> [22351] 1417689782.162185: Removing admin at IPA5.TEST ->
>> krbtgt/F21.TEST at IPA5.TEST from KEYRING:persistent:0:0
>> [22351] 1417689782.162207: Storing admin at IPA5.TEST ->
>> krbtgt/F21.TEST at IPA5.TEST in KEYRING:persistent:0:0
>> [22351] 1417689782.162268: Received TGT for service realm:
>> krbtgt/F21.TEST at IPA5.TEST
>> [22351] 1417689782.162296: Requesting tickets for
>> host/master.f21.test at F21.TEST, referrals on
>> [22351] 1417689782.162322: Generated subkey for TGS request:
>> aes256-cts/61A2
>> [22351] 1417689782.162359: etypes requested in TGS request:
>> aes256-cts, aes128-cts, des3-cbc-sha1, rc4-hmac, camellia128-cts,
>> camellia256-cts
>> [22351] 1417689782.162413: Encoding request body and padata into FAST
>> request
>> [22351] 1417689782.162460: Sending request (855 bytes) to F21.TEST
>> [22351] 1417689782.162493: Resolving hostname master.f21.test
>> [22351] 1417689782.163213: Sending initial UDP request to dgram
>> 192.168.5.169:88
>> [22351] 1417689782.165439: Received answer from dgram 192.168.5.169:88
>> [22351] 1417689782.165516: Response was from master KDC
>In my case:
>
>[31580] 1417773156.446922: TGS request result: -1765328324/KDC returned
>error string: PROCESS_TGS
>
>There is no Decoding FAST response.
This is a detail of your foreign KDC configuration, what features it
exposes and requires.

>
>> [22351] 1417689782.165572: Decoding FAST response
>> [22351] 1417689782.165643: TGS request result: -1765328372/KDC policy
>> rejects request
>> [22351] 1417689782.165680: Requesting tickets for
>> host/master.f21.test at F21.TEST, referrals off
>> [22351] 1417689782.165714: Generated subkey for TGS request:
>> aes256-cts/FEA9
>> [22351] 1417689782.165751: etypes requested in TGS request:
>> aes256-cts, aes128-cts, des3-cbc-sha1, rc4-hmac, camellia128-cts,
>> camellia256-cts
>> [22351] 1417689782.165799: Encoding request body and padata into FAST
>> request
>> [22351] 1417689782.165847: Sending request (855 bytes) to F21.TEST
>> [22351] 1417689782.165875: Resolving hostname master.f21.test
>> [22351] 1417689782.166084: Sending initial UDP request to dgram
>> 192.168.5.169:88
>> [22351] 1417689782.167602: Received answer from dgram 192.168.5.169:88
>> [22351] 1417689782.167642: Response was from master KDC
>In my case at this position:
>
>[31580] 1417773156.449640: TGS request result: -1765328324/KDC returned
>error string: PROCESS_TGS
>kvno: KDC returned error string: PROCESS_TGS while getting credentials for
>
>I found out that at the non IPA KDC (the foreign KDC) isnt a Port 88
>available (closed). The ports 464+749 are available.
>
>On the IPA KDC there are ports 88+464+749
Port 88 is the standard KDC port. One can choose to use another ports
but all machines in the realm then should have the required ports
configured properly. 88 is the port for the normal Kerberos
communication, 464 is the port for kpasswd, 749 is kadmin.

See more on
http://web.mit.edu/kerberos/krb5-latest/doc/admin/appl_servers.html#conf-firewall


>There is no Decoding FAST response.
>
>> [22351] 1417689782.167669: Decoding FAST response
>> [22351] 1417689782.167709: TGS request result: -1765328372/KDC policy
>> rejects request
>> kvno: KDC policy rejects request while getting credentials for
>> host/master.f21.test at F21.TEST
>> [root at ipa-05-m ~]#
>> And /var/log/krb5kdc.log on master.f21.test (KDC for F21.TEST) I can
>> see:
>> Dec 04 12:41:52 master.f21.test krb5kdc[1131](info): bad realm transit
>> path from 'admin at IPA5.TEST' to 'host/master.f21.test at F21.TEST' via ''
>> Dec 04 12:41:52 master.f21.test krb5kdc[1131](info): TGS_REQ (6 etypes
>> {18 17 16 23 25 26}) 192.168.5.109: BAD_TRANSIT: authtime 1417689777,
>> admin at IPA5.TEST for host/master.f21.test at F21.TEST, KDC policy rejects
>> request
>> Dec 04 12:41:52 master.f21.test krb5kdc[1131](info): bad realm transit
>> path from 'admin at IPA5.TEST' to 'host/master.f21.test at F21.TEST' via ''
>> Dec 04 12:41:52 master.f21.test krb5kdc[1131](info): TGS_REQ (6 etypes
>> {18 17 16 23 25 26}) 192.168.5.109: BAD_TRANSIT: authtime 1417689777,
>> admin at IPA5.TEST for host/master.f21.test at F21.TEST, KDC policy rejects
>> request
>>
>> And this is correct for FreeIPA 3.3 or later because we limit trust to
>> those domains we defined in cn=ad,cn=trusts,$SUFFIX with filter
>> (objectclass=ipaNTTrustedDomain). For the rest we return
>> KRB5KRB_AP_ERR_ILL_CR_TKT error code which is visible as 'KDC policy
>> rejects request'.
>Is it possible or a good idea to add my trust domain, which isnt a AD
>domain, manualy to IPA 3.3 ?
Well, you can hack of course, that's up to you. I haven't checked that
myself and cannot give you definitive answer on this path, though.

>>
>>
>> We may reconsider this check and instead of KRB5KRB_AP_ERR_ILL_CR_TKT
>> return KRB5_PLUGIN_NO_HANDLE to allow fallback to krb5.conf-defined
>> capaths but I remember we had some issues with krb5 versions prior to
>> 1.12 where capaths from krb5.conf were blocking work of the DAL driver.
>I use MIT Kerberos 1.6 from OpenCSW on Solaris and FreeIPA 3.3.5. So
>this shouldnt be a problem ?!
1.6 does not support cross-realm communication as support for RFC6806
was added only in 1.7. So I don't think your setup would have any chance
to work at all.


-- 
/ Alexander Bokovoy



From abokovoy at redhat.com  Fri Dec  5 13:04:26 2014
From: abokovoy at redhat.com (Alexander Bokovoy)
Date: Fri, 5 Dec 2014 15:04:26 +0200
Subject: [Freeipa-users] Cross-Realm authentification
In-Reply-To: <20141205125637.GM16288@redhat.com>
References: <547F1233.4020709@kit.edu> <20141203135351.GG16288@redhat.com>
	<5480287B.4050406@kit.edu> <20141204110702.GH16288@redhat.com>
	<5481A47B.2000005@kit.edu> <20141205125637.GM16288@redhat.com>
Message-ID: <20141205130426.GN16288@redhat.com>

On Fri, 05 Dec 2014, Alexander Bokovoy wrote:
>On Fri, 05 Dec 2014, Andreas Ladanyi wrote:
>>
>>>I'm also getting errors but they are different to yours. Here is what I
>>>did:
>>>
>>>(on master.f21.test, realm F21.TEST):
>>>[root at master ~]# kadmin.local -x ipa-setup-override-restrictions -r
>>>F21.TEST
>>>Authenticating as principal root/admin at F21.TEST with password.
>>>kadmin.local:  addprinc -requires_preauth krbtgt/IPA5.TEST
>>>WARNING: no policy specified for krbtgt/IPA5.TEST at F21.TEST; defaulting
>>>to no policy
>>>Enter password for principal "krbtgt/IPA5.TEST at F21.TEST": Re-enter
>>>password for principal "krbtgt/IPA5.TEST at F21.TEST": Principal
>>>"krbtgt/IPA5.TEST at F21.TEST" created.
>>>kadmin.local:  addprinc -requires_preauth krbtgt/F21.TEST at IPA5.TEST
>>>WARNING: no policy specified for krbtgt/F21.TEST at IPA5.TEST; defaulting
>>>to no policy
>>>Enter password for principal "krbtgt/F21.TEST at IPA5.TEST": Re-enter
>>>password for principal "krbtgt/F21.TEST at IPA5.TEST": Principal
>>>"krbtgt/F21.TEST at IPA5.TEST" created.
>>>kadmin.local:  q
>>>
>>>added following to the /etc/krb5.conf:
>>>[libdefaults]
>>>dns_lookup_realm = true
>>>
>>>[domain_realms]
>>>.ipa5.test = IPA5.TEST
>>>ipa5.test = IPA5.TEST
>>Why only one domain and one realm if you have two REALMs ?
>Because this is what I _added_. The F21.TEST entries were already in
>place.
>
>>On this position i have another question:
>>
>>I have 2 REALMs and one DNS domain.
>>
>>.domainname_X = REALM A
>>domainname_X = REALM A
>>.domainname_X = REALM B
>>domainname_X = REALM B
>>
>>Could this work clear ?
>No. What realm would it select if the domain name is the same? Either
>you define explicitly per each host which realm the host belongs to or
>you'd have different DNS domains for the realms.
>
>>>"krbtgt/IPA5.TEST at F21.TEST" created.
>>>kadmin.local:  q
>>>
>>Ok, i see one difference: i didnt use the "-requires_preauth" flag. Why
>>did you use them ?
>Because this is recommended by MIT documentation. The link between
>realms has to be protected well, including preauth and good passwords
>for the cross-realm principals.
>
>>>and similar changes to /etc/krb5.conf.
>>>
>>>Then I tried to get a ticket to host/master.f21.test at F21.TEST while
>>>being an admin at IPA5.TEST:
>>I tried out this on the IPA box to connect to the non IPA box (foreign
>>realm).
>>>
>>>[root at ipa-05-m ~]# kinit admin
>>>Password for admin at IPA5.TEST: [root at ipa-05-m ~]#
>>>KRB5_TRACE=/dev/stderr kvno -S host master.f21.test
>>>[22351] 1417689782.154516: Convert service host (service with host as
>>>instance) on host master.f21.test to principal
>>>[22351] 1417689782.158724: Remote host after forward canonicalization:
>>>master.f21.test
>>>[22351] 1417689782.158814: Remote host after reverse DNS processing:
>>>master.f21.test
>>>[22351] 1417689782.158849: Get host realm for master.f21.test
>>>[22351] 1417689782.158899: Use local host master.f21.test to get host
>>>realm
>>>[22351] 1417689782.158946: Look up master.f21.test in the domain_realm
>>>map
>>>[22351] 1417689782.158999: Look up .f21.test in the domain_realm map
>>>[22351] 1417689782.159023: Temporary realm is F21.TEST
>>>[22351] 1417689782.159044: Got realm F21.TEST for host master.f21.test
>>>[22351] 1417689782.159071: Got service principal
>>>host/master.f21.test at F21.TEST
>>>[22351] 1417689782.159098: Getting credentials admin at IPA5.TEST ->
>>>host/master.f21.test at F21.TEST using ccache KEYRING:persistent:0:0
>>>[22351] 1417689782.159237: Retrieving admin at IPA5.TEST ->
>>>host/master.f21.test at F21.TEST from KEYRING:persistent:0:0 with result:
>>>-1765328243/Matching credential not found
>>>[22351] 1417689782.159297: Retrieving admin at IPA5.TEST ->
>>>krbtgt/F21.TEST at IPA5.TEST from KEYRING:persistent:0:0 with result:
>>>-1765328243/Matching credential not found
>>>[22351] 1417689782.159411: Retrieving admin at IPA5.TEST ->
>>>krbtgt/IPA5.TEST at IPA5.TEST from KEYRING:persistent:0:0 with result:
>>>0/Success
>>>[22351] 1417689782.159453: Starting with TGT for client realm:
>>>admin at IPA5.TEST -> krbtgt/IPA5.TEST at IPA5.TEST
>>>[22351] 1417689782.159502: Retrieving admin at IPA5.TEST ->
>>>krbtgt/F21.TEST at IPA5.TEST from KEYRING:persistent:0:0 with result:
>>>-1765328243/Matching credential not found
>>>[22351] 1417689782.159530: Requesting TGT krbtgt/F21.TEST at IPA5.TEST
>>>using TGT krbtgt/IPA5.TEST at IPA5.TEST
>>>[22351] 1417689782.159576: Generated subkey for TGS request:
>>>aes256-cts/54E6
>>>[22351] 1417689782.159628: etypes requested in TGS request:
>>>aes256-cts, aes128-cts, des3-cbc-sha1, rc4-hmac, camellia128-cts,
>>>camellia256-cts
>>>[22351] 1417689782.159726: Encoding request body and padata into FAST
>>>request
>>>[22351] 1417689782.159784: Sending request (890 bytes) to IPA5.TEST
>>>[22351] 1417689782.159909: Sending initial UDP request to dgram
>>>192.168.5.109:88
>>>[22351] 1417689782.161823: Received answer from dgram 192.168.5.109:88
>>>[22351] 1417689782.161925: Response was from master KDC
>>>[22351] 1417689782.162011: Decoding FAST response
>>>[22351] 1417689782.162084: FAST reply key: aes256-cts/EBCE
>>>[22351] 1417689782.162127: TGS reply is for admin at IPA5.TEST ->
>>>krbtgt/F21.TEST at IPA5.TEST with session key aes256-cts/822B
>>>[22351] 1417689782.162159: TGS request result: 0/Success
>>>[22351] 1417689782.162185: Removing admin at IPA5.TEST ->
>>>krbtgt/F21.TEST at IPA5.TEST from KEYRING:persistent:0:0
>>>[22351] 1417689782.162207: Storing admin at IPA5.TEST ->
>>>krbtgt/F21.TEST at IPA5.TEST in KEYRING:persistent:0:0
>>>[22351] 1417689782.162268: Received TGT for service realm:
>>>krbtgt/F21.TEST at IPA5.TEST
>>>[22351] 1417689782.162296: Requesting tickets for
>>>host/master.f21.test at F21.TEST, referrals on
>>>[22351] 1417689782.162322: Generated subkey for TGS request:
>>>aes256-cts/61A2
>>>[22351] 1417689782.162359: etypes requested in TGS request:
>>>aes256-cts, aes128-cts, des3-cbc-sha1, rc4-hmac, camellia128-cts,
>>>camellia256-cts
>>>[22351] 1417689782.162413: Encoding request body and padata into FAST
>>>request
>>>[22351] 1417689782.162460: Sending request (855 bytes) to F21.TEST
>>>[22351] 1417689782.162493: Resolving hostname master.f21.test
>>>[22351] 1417689782.163213: Sending initial UDP request to dgram
>>>192.168.5.169:88
>>>[22351] 1417689782.165439: Received answer from dgram 192.168.5.169:88
>>>[22351] 1417689782.165516: Response was from master KDC
>>In my case:
>>
>>[31580] 1417773156.446922: TGS request result: -1765328324/KDC returned
>>error string: PROCESS_TGS
>>
>>There is no Decoding FAST response.
>This is a detail of your foreign KDC configuration, what features it
>exposes and requires.
>
>>
>>>[22351] 1417689782.165572: Decoding FAST response
>>>[22351] 1417689782.165643: TGS request result: -1765328372/KDC policy
>>>rejects request
>>>[22351] 1417689782.165680: Requesting tickets for
>>>host/master.f21.test at F21.TEST, referrals off
>>>[22351] 1417689782.165714: Generated subkey for TGS request:
>>>aes256-cts/FEA9
>>>[22351] 1417689782.165751: etypes requested in TGS request:
>>>aes256-cts, aes128-cts, des3-cbc-sha1, rc4-hmac, camellia128-cts,
>>>camellia256-cts
>>>[22351] 1417689782.165799: Encoding request body and padata into FAST
>>>request
>>>[22351] 1417689782.165847: Sending request (855 bytes) to F21.TEST
>>>[22351] 1417689782.165875: Resolving hostname master.f21.test
>>>[22351] 1417689782.166084: Sending initial UDP request to dgram
>>>192.168.5.169:88
>>>[22351] 1417689782.167602: Received answer from dgram 192.168.5.169:88
>>>[22351] 1417689782.167642: Response was from master KDC
>>In my case at this position:
>>
>>[31580] 1417773156.449640: TGS request result: -1765328324/KDC returned
>>error string: PROCESS_TGS
>>kvno: KDC returned error string: PROCESS_TGS while getting credentials for
>>
>>I found out that at the non IPA KDC (the foreign KDC) isnt a Port 88
>>available (closed). The ports 464+749 are available.
>>
>>On the IPA KDC there are ports 88+464+749
>Port 88 is the standard KDC port. One can choose to use another ports
>but all machines in the realm then should have the required ports
>configured properly. 88 is the port for the normal Kerberos
>communication, 464 is the port for kpasswd, 749 is kadmin.
>
>See more on
>http://web.mit.edu/kerberos/krb5-latest/doc/admin/appl_servers.html#conf-firewall
>
>
>>There is no Decoding FAST response.
>>
>>>[22351] 1417689782.167669: Decoding FAST response
>>>[22351] 1417689782.167709: TGS request result: -1765328372/KDC policy
>>>rejects request
>>>kvno: KDC policy rejects request while getting credentials for
>>>host/master.f21.test at F21.TEST
>>>[root at ipa-05-m ~]#
>>>And /var/log/krb5kdc.log on master.f21.test (KDC for F21.TEST) I can
>>>see:
>>>Dec 04 12:41:52 master.f21.test krb5kdc[1131](info): bad realm transit
>>>path from 'admin at IPA5.TEST' to 'host/master.f21.test at F21.TEST' via ''
>>>Dec 04 12:41:52 master.f21.test krb5kdc[1131](info): TGS_REQ (6 etypes
>>>{18 17 16 23 25 26}) 192.168.5.109: BAD_TRANSIT: authtime 1417689777,
>>>admin at IPA5.TEST for host/master.f21.test at F21.TEST, KDC policy rejects
>>>request
>>>Dec 04 12:41:52 master.f21.test krb5kdc[1131](info): bad realm transit
>>>path from 'admin at IPA5.TEST' to 'host/master.f21.test at F21.TEST' via ''
>>>Dec 04 12:41:52 master.f21.test krb5kdc[1131](info): TGS_REQ (6 etypes
>>>{18 17 16 23 25 26}) 192.168.5.109: BAD_TRANSIT: authtime 1417689777,
>>>admin at IPA5.TEST for host/master.f21.test at F21.TEST, KDC policy rejects
>>>request
>>>
>>>And this is correct for FreeIPA 3.3 or later because we limit trust to
>>>those domains we defined in cn=ad,cn=trusts,$SUFFIX with filter
>>>(objectclass=ipaNTTrustedDomain). For the rest we return
>>>KRB5KRB_AP_ERR_ILL_CR_TKT error code which is visible as 'KDC policy
>>>rejects request'.
>>Is it possible or a good idea to add my trust domain, which isnt a AD
>>domain, manualy to IPA 3.3 ?
>Well, you can hack of course, that's up to you. I haven't checked that
>myself and cannot give you definitive answer on this path, though.
>
>>>
>>>
>>>We may reconsider this check and instead of KRB5KRB_AP_ERR_ILL_CR_TKT
>>>return KRB5_PLUGIN_NO_HANDLE to allow fallback to krb5.conf-defined
>>>capaths but I remember we had some issues with krb5 versions prior to
>>>1.12 where capaths from krb5.conf were blocking work of the DAL driver.
>>I use MIT Kerberos 1.6 from OpenCSW on Solaris and FreeIPA 3.3.5. So
>>this shouldnt be a problem ?!
>1.6 does not support cross-realm communication as support for RFC6806
>was added only in 1.7. So I don't think your setup would have any chance
>to work at all.
Hm.. on the other hand, 1.6 documentation talks about it:
http://web.mit.edu/kerberos/krb5-1.6/krb5-1.6.3/doc/krb5-admin.html#Cross_002drealm-Authentication
So may be their changelogs aren't as complete as they should be. :)

With the link above you can also see with disabling preauth on the
cross-realm krbtgt records is recommended.

But I think most of your issues were because of the 88 port not being
available and no other means to traverse firewall were configured. That
is, aside from the fact that IPA will reject cross-realm tickets because
of how we programmed DAL driver as I explained above.
-- 
/ Alexander Bokovoy



From andreas.ladanyi at kit.edu  Fri Dec  5 14:21:01 2014
From: andreas.ladanyi at kit.edu (Andreas Ladanyi)
Date: Fri, 05 Dec 2014 15:21:01 +0100
Subject: [Freeipa-users] Cross-Realm authentification
In-Reply-To: <20141205130426.GN16288@redhat.com>
References: <547F1233.4020709@kit.edu> <20141203135351.GG16288@redhat.com>
	<5480287B.4050406@kit.edu> <20141204110702.GH16288@redhat.com>
	<5481A47B.2000005@kit.edu> <20141205125637.GM16288@redhat.com>
	<20141205130426.GN16288@redhat.com>
Message-ID: <5481BF4D.5060006@kit.edu>

Am 05.12.2014 um 14:04 schrieb Alexander Bokovoy:
>
>>>>
>>> Ok, i see one difference: i didnt use the "-requires_preauth" flag. Why
>>> did you use them ?
>> Because this is recommended by MIT documentation. The link between
>> realms has to be protected well, including preauth and good passwords
>> for the cross-realm principals.
>>
>>
>>> Is it possible or a good idea to add my trust domain, which isnt a AD
>>> domain, manualy to IPA 3.3 ?
>> Well, you can hack of course, that's up to you. I haven't checked that
>> myself and cannot give you definitive answer on this path, though.
At this time i havent an idea off the steps in detail how to do that.
>>
>>>>
>>>>
>>>> We may reconsider this check and instead of KRB5KRB_AP_ERR_ILL_CR_TKT
>>>> return KRB5_PLUGIN_NO_HANDLE to allow fallback to krb5.conf-defined
>>>> capaths but I remember we had some issues with krb5 versions prior to
>>>> 1.12 where capaths from krb5.conf were blocking work of the DAL
>>>> driver.
>>> I use MIT Kerberos 1.6 from OpenCSW on Solaris and FreeIPA 3.3.5. So
>>> this shouldnt be a problem ?!
Sorry i made a little typing mistake. The foreign realm ist MIT Kerberos
1.9.2 and not 1.6
>> 1.6 does not support cross-realm communication as support for RFC6806
>> was added only in 1.7. So I don't think your setup would have any chance
>> to work at all.
> Hm.. on the other hand, 1.6 documentation talks about it:
> http://web.mit.edu/kerberos/krb5-1.6/krb5-1.6.3/doc/krb5-admin.html#Cross_002drealm-Authentication
>
> So may be their changelogs aren't as complete as they should be. :)
>
> With the link above you can also see with disabling preauth on the
> cross-realm krbtgt records is recommended.
>
> But I think most of your issues were because of the 88 port not being
> available and no other means to traverse firewall were configured. 
I will look particular for that.

There is no firewall between the two KDCs.

> That
> is, aside from the fact that IPA will reject cross-realm tickets because
> of how we programmed DAL driver as I explained above.


I dont know in detail what DAL is doing.

OK, it sounds like with IPA my setup wont be very easy :-)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5306 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141205/574576df/attachment.p7s>

From pspacek at redhat.com  Fri Dec  5 14:24:45 2014
From: pspacek at redhat.com (Petr Spacek)
Date: Fri, 05 Dec 2014 15:24:45 +0100
Subject: [Freeipa-users] Cross-Realm authentification
In-Reply-To: <5481BF4D.5060006@kit.edu>
References: <547F1233.4020709@kit.edu>
	<20141203135351.GG16288@redhat.com>	<5480287B.4050406@kit.edu>
	<20141204110702.GH16288@redhat.com>	<5481A47B.2000005@kit.edu>
	<20141205125637.GM16288@redhat.com>	<20141205130426.GN16288@redhat.com>
	<5481BF4D.5060006@kit.edu>
Message-ID: <5481C02D.6000805@redhat.com>

On 5.12.2014 15:21, Andreas Ladanyi wrote:
> Am 05.12.2014 um 14:04 schrieb Alexander Bokovoy:
>>
>>>>>
>>>> Ok, i see one difference: i didnt use the "-requires_preauth" flag. Why
>>>> did you use them ?
>>> Because this is recommended by MIT documentation. The link between
>>> realms has to be protected well, including preauth and good passwords
>>> for the cross-realm principals.
>>>
>>>
>>>> Is it possible or a good idea to add my trust domain, which isnt a AD
>>>> domain, manualy to IPA 3.3 ?
>>> Well, you can hack of course, that's up to you. I haven't checked that
>>> myself and cannot give you definitive answer on this path, though.
> At this time i havent an idea off the steps in detail how to do that.
>>>
>>>>>
>>>>>
>>>>> We may reconsider this check and instead of KRB5KRB_AP_ERR_ILL_CR_TKT
>>>>> return KRB5_PLUGIN_NO_HANDLE to allow fallback to krb5.conf-defined
>>>>> capaths but I remember we had some issues with krb5 versions prior to
>>>>> 1.12 where capaths from krb5.conf were blocking work of the DAL
>>>>> driver.
>>>> I use MIT Kerberos 1.6 from OpenCSW on Solaris and FreeIPA 3.3.5. So
>>>> this shouldnt be a problem ?!
> Sorry i made a little typing mistake. The foreign realm ist MIT Kerberos
> 1.9.2 and not 1.6
>>> 1.6 does not support cross-realm communication as support for RFC6806
>>> was added only in 1.7. So I don't think your setup would have any chance
>>> to work at all.
>> Hm.. on the other hand, 1.6 documentation talks about it:
>> http://web.mit.edu/kerberos/krb5-1.6/krb5-1.6.3/doc/krb5-admin.html#Cross_002drealm-Authentication
>>
>> So may be their changelogs aren't as complete as they should be. :)
>>
>> With the link above you can also see with disabling preauth on the
>> cross-realm krbtgt records is recommended.
>>
>> But I think most of your issues were because of the 88 port not being
>> available and no other means to traverse firewall were configured. 
> I will look particular for that.
> 
> There is no firewall between the two KDCs.
> 
>> That
>> is, aside from the fact that IPA will reject cross-realm tickets because
>> of how we programmed DAL driver as I explained above.
> 
> 
> I dont know in detail what DAL is doing.
> 
> OK, it sounds like with IPA my setup wont be very easy :-)

I guess that Alexander or Simo could point you to the line in the source code
you have to change (or send you one-line patch?) but you will have to
recompile the driver from source.

Do you want to try this way?

-- 
Petr^2 Spacek



From sipazzo at yahoo.com  Fri Dec  5 14:43:25 2014
From: sipazzo at yahoo.com (sipazzo)
Date: Fri, 5 Dec 2014 06:43:25 -0800
Subject: [Freeipa-users] sudo utilizing sssd rhel6.6
In-Reply-To: <20141203153849.GH8388@mail.corp.redhat.com>
Message-ID: <1417790605.71041.YahooMailBasic@web122501.mail.ne1.yahoo.com>

Thank you both. I was able to get this working by just adding the sudo_provider = ipa to sssd.conf. I removed all the ldap_uri and krb5_server lines to keep the file tidier. I had read service discovery works with sssd but was told by Redhat support it does not. I am happy to hear it does as it is much easier to maintain.

Thanks again. 
--------------------------------------------_
On Wed, 12/3/14, Lukas Slebodnik <lslebodn at redhat.com> wrote:

 Subject: Re: [Freeipa-users] sudo utilizing sssd rhel6.6
 To: "sipazzo" <sipazzo at yahoo.com>
 Cc: freeipa-users at redhat.com
 Date: Wednesday, December 3, 2014, 7:38 AM
 
 On (03/12/14 06:05),
 sipazzo wrote:
 >Good morning, I have a
 fairly new ipa domain (server version 3.0.0-42 and clients
 mixed 3.0.0-37 and 3.0.0-42) set up with a mix of rhel6,
 rhel5 and solaris. It seemed like my sudo config using sssd
 in rhel6.5 was working and then we patched to 6.6 and it is
 broken. I had followed these setup instructions
 previously:
 >
 >yum
 install -y libsss_sudo
 >
 >Added to /etc/nsswitch.conf
 >
 >sudoers: sss files
 >
 >Add nisdomainname:
 >
 >nisdomainname
 ipadomain.com
 >echo
 "NISDOMAIN=ipadomain.com" >>
 /etc/sysconfig/network
 >
 >Added the following to /etc/sssd/sssd.conf
 (is all this really necessary?)
 >
 >[domain/ipadomain.com]
 >???.
 >
 >sudo_provider = ldap
 >ldap_uri =
 ldaps://ipasrv2-corp.ipadomain.com,
 ldaps://ipasrv1-xo.ipadomain.com,
 ldaps://ipasrv1-io.ipadomain.com,
 ldaps://ipasrv1-corp.ipadomain.com,
 ldaps://ipasrv2-xo.ipadomain.com,
 ldaps://ipasrv2-io.ipadomain.com
 >ldap_sudo_search_base =
 ou=sudoers,dc=ipadomain,dc=com
 >ldap_sasl_mech = GSSAPI? ? 
 >ldap_sasl_authid =
 host/ipaclient1.ipadomain.com? 
 >ldap_sasl_realm = ipadomain.COM
 >krb5_server =ipasrv2-corp.ipadomain.com,
 ipasrv1-xo.ipadomain.com, ipasrv1-io.ipadomain.com,
 ipasrv1-corp.ipadomain.com, ipasrv2-xo.ipadomain.com,
 ipasrv2-io.ipadomain.com
 >
 >[sssd]
 >services =?
 nss, pam, sudo, ssh
 >
 >[sudo]
 >
 >
 >Restart sssd
 service
 >
 >I know that
 libsss_sudo is now included as part of another package and
 read that you need sssd-common which I tried installing to
 no avail as well. I had been told that despite the man pages
 on sssd I needed to specify the servers in ldap_uri (and I
 assume krb5_server) as it would not use SRV records but am
 not sure that is correct. 
 >
 >Questions:
 >1) What are
 the steps to get sudo working with sssd on an existing,
 newly patched (to rhel6.6) system
 Configuration from rhel 6.5 shoudl work also on
 rhel 6.6
 
 But rhel 6.6 can
 work also with sudo_provider = ipa
 In this
 case sssd configuration is easier. You cna find details in
 manual page
 man sssd-sudo.
 
 
 >2) Are
 the steps any different for a new system (i.e. I read it is
 "seamless" but I guess we still have to manually
 edit files?)
 On rhel6.6 ipa-client-install
 should configure sudo unless you executed
 ipa-client-install with --no-sudo
 
 >3) Does sssd in Rhel6.6 support SRV lookup
 for the ldap_uri and krb5_server and do we have to specify
 the ldap_sasl_authid with the client hostname
 Yes, it does.
 man sssd.ldap
 -> SERVICE DISCOVERY
 
 If
 you use sudo_provider=ipa then you will not need to
 configure all ldap_*
 krb5_* options on your
 own.
 
 LS
 



From sipazzo at yahoo.com  Fri Dec  5 14:43:25 2014
From: sipazzo at yahoo.com (sipazzo)
Date: Fri, 5 Dec 2014 06:43:25 -0800
Subject: [Freeipa-users] sudo utilizing sssd rhel6.6
In-Reply-To: <20141203153849.GH8388@mail.corp.redhat.com>
Message-ID: <1417790605.71041.YahooMailBasic@web122501.mail.ne1.yahoo.com>

Thank you both. I was able to get this working by just adding the sudo_provider = ipa to sssd.conf. I removed all the ldap_uri and krb5_server lines to keep the file tidier. I had read service discovery works with sssd but was told by Redhat support it does not. I am happy to hear it does as it is much easier to maintain.

Thanks again. 
--------------------------------------------_
On Wed, 12/3/14, Lukas Slebodnik <lslebodn at redhat.com> wrote:

 Subject: Re: [Freeipa-users] sudo utilizing sssd rhel6.6
 To: "sipazzo" <sipazzo at yahoo.com>
 Cc: freeipa-users at redhat.com
 Date: Wednesday, December 3, 2014, 7:38 AM
 
 On (03/12/14 06:05),
 sipazzo wrote:
 >Good morning, I have a
 fairly new ipa domain (server version 3.0.0-42 and clients
 mixed 3.0.0-37 and 3.0.0-42) set up with a mix of rhel6,
 rhel5 and solaris. It seemed like my sudo config using sssd
 in rhel6.5 was working and then we patched to 6.6 and it is
 broken. I had followed these setup instructions
 previously:
 >
 >yum
 install -y libsss_sudo
 >
 >Added to /etc/nsswitch.conf
 >
 >sudoers: sss files
 >
 >Add nisdomainname:
 >
 >nisdomainname
 ipadomain.com
 >echo
 "NISDOMAIN=ipadomain.com" >>
 /etc/sysconfig/network
 >
 >Added the following to /etc/sssd/sssd.conf
 (is all this really necessary?)
 >
 >[domain/ipadomain.com]
 >???.
 >
 >sudo_provider = ldap
 >ldap_uri =
 ldaps://ipasrv2-corp.ipadomain.com,
 ldaps://ipasrv1-xo.ipadomain.com,
 ldaps://ipasrv1-io.ipadomain.com,
 ldaps://ipasrv1-corp.ipadomain.com,
 ldaps://ipasrv2-xo.ipadomain.com,
 ldaps://ipasrv2-io.ipadomain.com
 >ldap_sudo_search_base =
 ou=sudoers,dc=ipadomain,dc=com
 >ldap_sasl_mech = GSSAPI? ? 
 >ldap_sasl_authid =
 host/ipaclient1.ipadomain.com? 
 >ldap_sasl_realm = ipadomain.COM
 >krb5_server =ipasrv2-corp.ipadomain.com,
 ipasrv1-xo.ipadomain.com, ipasrv1-io.ipadomain.com,
 ipasrv1-corp.ipadomain.com, ipasrv2-xo.ipadomain.com,
 ipasrv2-io.ipadomain.com
 >
 >[sssd]
 >services =?
 nss, pam, sudo, ssh
 >
 >[sudo]
 >
 >
 >Restart sssd
 service
 >
 >I know that
 libsss_sudo is now included as part of another package and
 read that you need sssd-common which I tried installing to
 no avail as well. I had been told that despite the man pages
 on sssd I needed to specify the servers in ldap_uri (and I
 assume krb5_server) as it would not use SRV records but am
 not sure that is correct. 
 >
 >Questions:
 >1) What are
 the steps to get sudo working with sssd on an existing,
 newly patched (to rhel6.6) system
 Configuration from rhel 6.5 shoudl work also on
 rhel 6.6
 
 But rhel 6.6 can
 work also with sudo_provider = ipa
 In this
 case sssd configuration is easier. You cna find details in
 manual page
 man sssd-sudo.
 
 
 >2) Are
 the steps any different for a new system (i.e. I read it is
 "seamless" but I guess we still have to manually
 edit files?)
 On rhel6.6 ipa-client-install
 should configure sudo unless you executed
 ipa-client-install with --no-sudo
 
 >3) Does sssd in Rhel6.6 support SRV lookup
 for the ldap_uri and krb5_server and do we have to specify
 the ldap_sasl_authid with the client hostname
 Yes, it does.
 man sssd.ldap
 -> SERVICE DISCOVERY
 
 If
 you use sudo_provider=ipa then you will not need to
 configure all ldap_*
 krb5_* options on your
 own.
 
 LS
 



From dpal at redhat.com  Fri Dec  5 18:54:39 2014
From: dpal at redhat.com (Dmitri Pal)
Date: Fri, 5 Dec 2014 13:54:39 -0500 (EST)
Subject: [Freeipa-users] [Freeipa-interest] Announcing FreeIPA 4.1.2 -
 NEED HELP WITH 2FA/OTP!!!
In-Reply-To: <54775877.6060102@redhat.com>
References: <54775877.6060102@redhat.com>
Message-ID: <176433463.23902008.1417805679430.JavaMail.zimbra@redhat.com>

Hello,

WE NEED HELP!

The biggest and the most interesting feature of FreeIPA 4.1.2 is support for the two factor authentication using HOTP/TOTP compatible software tokens like FreeOTP (open source compatible alternative to Google Authenticator) and hardware tokens like Yubikeys. This feature allows Kerberos and LDAP clients of a FreeIPA server to authenticate using the normal account password as the first factor and an OTP token as a second factor. For those environments where a 2FA solution is already in place, FreeIPA can act as a proxy via RADIUS. More about this feature can be read here.
http://www.freeipa.org/page/V4/OTP

If you want to see this feature in downstream distros sooner rather than later we need your help!
Please give it a try and provide feedback. We really, really need it!


Thank you,
FreeIPA development team



----- Original Message -----
From: "Petr Vobornik" <pvoborni at redhat.com>
To: "freeipa-devel" <freeipa-devel at redhat.com>, "freeipa-users" <freeipa-users at redhat.com>, freeipa-interest at redhat.com
Sent: Thursday, November 27, 2014 11:59:35 AM
Subject: [Freeipa-interest] Announcing FreeIPA 4.1.2

The FreeIPA team would like to announce FreeIPA v4.1.2 security release!

It can be downloaded from http://www.freeipa.org/page/Downloads. The 
builds will be available for Fedora 21. Builds for Fedora 20 are 
available in the official COPR repository 
[https://copr.fedoraproject.org/coprs/mkosek/freeipa/].

== Highlights in 4.1.2 ==

=== Bug fixes ===
* CVE-2014-7850: ensure that user input is properly escaped to prevent 
XSS attacks [https://fedorahosted.org/freeipa/ticket/4742] 
[http://www.freeipa.org/page/CVE-2014-7850]
* harden mod_nss config on update to use TLSv1.0, TLSv1.1, TLSv1.2
* fixed getkeytab operation 
[https://fedorahosted.org/freeipa/ticket/4718] 
[https://fedorahosted.org/freeipa/ticket/4728]
* backup and restore fixes related to certificates restore and SELinux 
context
* static code analysis fixes
* various small fixes

== Upgrading ==
An IPA server can be upgraded simply by installing updated rpms. The 
server does not need to be shut down in advance.

Please note that if you are doing the upgrade in special environment 
(e.g. FedUp) which does not allow running the LDAP server during upgrade 
process, upgrade scripts need to be run manually after the first boot:

  # ipa-ldap-updater --upgrade
  # ipa-upgradeconfig

Also note that the performance improvements require an extended set of 
indexes to be configured. RPM update for an IPA server with a excessive 
number of users may require several minutes to finish.

If you have multiple servers you may upgrade them one at a time. It is 
expected that all servers will be upgraded in a relatively short period 
(days or weeks, not months). They should be able to co-exist peacefully 
but new features will not be available on old servers and enrolling a 
new client against an old server will result in the SSH keys not being 
uploaded.

Downgrading a server once upgraded is not supported.

Upgrading from 3.3.0 and later versions is supported. Upgrading from 
previous versions is not supported and has not been tested.

An enrolled client does not need the new packages installed unless you 
want to re-enroll it. SSH keys for already installed clients are not 
uploaded, you will have to re-enroll the client or manually upload the keys.

== 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.1.1 ==

=== Alexander Bokovoy (2) ===
* Update slapi-nis dependency to pull 0.54.1
* AD trust: improve trust validation

=== David Kupka (6) ===
* Remove unneeded internal methods. Move code to public methods.
* Remove service file even if it isn't link.
* Produce better error in group-add command.
* Fix --{user,group}-ignore-attribute in migration plugin.
* ipa-restore: Check if directory is provided + better errors.
* Fix error message for nonexistent members and add tests.

=== Gabe Alford (1) ===
* ipa-server-install Directory Manager help incorrect

=== Jan Cholasta (15) ===
* Fix CA certificate backup and restore
* Update Requires on pki-ca to 10.2.1-0.1
* Fix wrong expiration date on renewed IPA CA certificates
* Restore file extended attributes and SELinux context in ipa-restore
* Use correct service name in cainstance.backup_config
* Stop tracking certificates before restoring them in ipa-restore
* Remove redefinition of LOG from ipa-otp-lasttoken
* Unload P11_Helper object's library when it is finalized in ipap11helper
* Fix Kerberos error handling in ipa-sam
* Fix unchecked return value in ipa-kdb
* Fix unchecked return values in ipa-winsync
* Fix unchecked return value in ipa-join
* Fix unchecked return value in krb5 common utils
* Fix memory leak in GetKeytabControl asn1 code
* Add TLS 1.2 to the protocol list in mod_nss config

=== Martin Ba?ti (12) ===
* Fix: DNS installer adds invalid zonemgr email
* Fix: DNS policy upgrade raises asertion error
* Fix upgrade referint plugin
* Upgrade: fix trusts objectclass violationi
* Fix named working directory permissions
* Fix: zonemgr must be unicode value
* Fix warning message should not contain CLI commands
* Show warning instead of error if CA did not start
* Raise right exception if domain name is not valid
* Fix pk11helper module compiler warnings
* Fix: read_ip_addresses should return ipaddr object
* Fix detection of encoding in zonemgr option

=== Martin Ko?ek (1) ===
* Lower pki-ca requires to 10.1.2

=== Nathaniel McCallum (3) ===
* Improve otptoken help messages
* Ensure users exist when assigning tokens to them
* Enable QR code display by default in otptoken-add

=== Petr Viktorin (5) ===
* ipa-restore: Don't crash if AD trust is not installed
* ipaplatform: Use the dirsrv service, not target
* Do not restore SELinux settings that were not backed up
* Add additional backup & restore checks
* copy_schema_to_ca: Fallback to old import location for 
ipaplatform.services

=== Petr Voborn?k (9) ===
* ranges: prohibit setting --rid-base with ipa-trust-ad-posix type
* unittests: baserid for ipa-ad-trust-posix idranges
* ldapupdater: set baserid to 0 for ipa-ad-trust-posix ranges
* idrange: include raw range type in output
* webui: prohibit setting rid base with ipa-trust-ad-posix type
* webui: fix potential XSS vulnerabilities
* restore: clear httpd ccache after restore
* webui: use domain name instead of domain SID in idrange adder dialog
* webui: normalize idview tab labels

=== Petr ?pa?ek (1) ===
* Fix minimal version of BIND for Fedora 20 and 21

=== Rob Crittenden (2) ===
* Search using proper scope when connecting CA instances
* Use NSS protocol range API to set available TLS protocols

=== Simo Sorce (4) ===
* Add UTC date to GIT snapshot version generation
* Fix filtering of enctypes in server code.
* Add asn1c generated code for keytab controls
* Use asn1c helpers to encode/decode the getkeytab control

=== Thorsten Scherf (1) ===
* Add help string on how to configure multiple DNS forwards for various 
cli tools

-- 
Petr Vobornik

_______________________________________________
Freeipa-interest mailing list
Freeipa-interest at redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-interest





From abokovoy at redhat.com  Fri Dec  5 20:26:55 2014
From: abokovoy at redhat.com (Alexander Bokovoy)
Date: Fri, 5 Dec 2014 22:26:55 +0200
Subject: [Freeipa-users] Cross-Realm authentification
In-Reply-To: <5481C02D.6000805@redhat.com>
References: <547F1233.4020709@kit.edu> <20141203135351.GG16288@redhat.com>
	<5480287B.4050406@kit.edu> <20141204110702.GH16288@redhat.com>
	<5481A47B.2000005@kit.edu> <20141205125637.GM16288@redhat.com>
	<20141205130426.GN16288@redhat.com> <5481BF4D.5060006@kit.edu>
	<5481C02D.6000805@redhat.com>
Message-ID: <20141205202655.GR16288@redhat.com>

On Fri, 05 Dec 2014, Petr Spacek wrote:
>On 5.12.2014 15:21, Andreas Ladanyi wrote:
>> Am 05.12.2014 um 14:04 schrieb Alexander Bokovoy:
>>>
>>>>>>
>>>>> Ok, i see one difference: i didnt use the "-requires_preauth" flag. Why
>>>>> did you use them ?
>>>> Because this is recommended by MIT documentation. The link between
>>>> realms has to be protected well, including preauth and good passwords
>>>> for the cross-realm principals.
>>>>
>>>>
>>>>> Is it possible or a good idea to add my trust domain, which isnt a AD
>>>>> domain, manualy to IPA 3.3 ?
>>>> Well, you can hack of course, that's up to you. I haven't checked that
>>>> myself and cannot give you definitive answer on this path, though.
>> At this time i havent an idea off the steps in detail how to do that.
>>>>
>>>>>>
>>>>>>
>>>>>> We may reconsider this check and instead of KRB5KRB_AP_ERR_ILL_CR_TKT
>>>>>> return KRB5_PLUGIN_NO_HANDLE to allow fallback to krb5.conf-defined
>>>>>> capaths but I remember we had some issues with krb5 versions prior to
>>>>>> 1.12 where capaths from krb5.conf were blocking work of the DAL
>>>>>> driver.
>>>>> I use MIT Kerberos 1.6 from OpenCSW on Solaris and FreeIPA 3.3.5. So
>>>>> this shouldnt be a problem ?!
>> Sorry i made a little typing mistake. The foreign realm ist MIT Kerberos
>> 1.9.2 and not 1.6
>>>> 1.6 does not support cross-realm communication as support for RFC6806
>>>> was added only in 1.7. So I don't think your setup would have any chance
>>>> to work at all.
>>> Hm.. on the other hand, 1.6 documentation talks about it:
>>> http://web.mit.edu/kerberos/krb5-1.6/krb5-1.6.3/doc/krb5-admin.html#Cross_002drealm-Authentication
>>>
>>> So may be their changelogs aren't as complete as they should be. :)
>>>
>>> With the link above you can also see with disabling preauth on the
>>> cross-realm krbtgt records is recommended.
>>>
>>> But I think most of your issues were because of the 88 port not being
>>> available and no other means to traverse firewall were configured.
>> I will look particular for that.
>>
>> There is no firewall between the two KDCs.
>>
>>> That
>>> is, aside from the fact that IPA will reject cross-realm tickets because
>>> of how we programmed DAL driver as I explained above.
>>
>>
>> I dont know in detail what DAL is doing.
>>
>> OK, it sounds like with IPA my setup wont be very easy :-)
>
>I guess that Alexander or Simo could point you to the line in the source code
>you have to change (or send you one-line patch?) but you will have to
>recompile the driver from source.
>
>Do you want to try this way?
Attached please find a patch that solves the issue of cross-realm trust
for me:
[root at ipa-05-m ~]# kinit admin
Password for admin at IPA5.TEST: 
[root at ipa-05-m ~]# KRB5_TRACE=/dev/stderr kvno -S host master.f21.test
[16101] 1417810641.441614: Convert service host (service with host as instance) on host master.f21.test to principal
[16101] 1417810641.449424: Remote host after forward canonicalization: master.f21.test
[16101] 1417810641.449501: Remote host after reverse DNS processing: master.f21.test
[16101] 1417810641.449549: Get host realm for master.f21.test
[16101] 1417810641.449593: Use local host master.f21.test to get host realm
[16101] 1417810641.449630: Look up master.f21.test in the domain_realm map
[16101] 1417810641.449655: Look up .f21.test in the domain_realm map
[16101] 1417810641.449677: Temporary realm is F21.TEST
[16101] 1417810641.449697: Got realm F21.TEST for host master.f21.test
[16101] 1417810641.449724: Got service principal host/master.f21.test at F21.TEST
[16101] 1417810641.449750: Getting credentials admin at IPA5.TEST -> host/master.f21.test at F21.TEST using ccache KEYRING:persistent:0:0
[16101] 1417810641.449888: Retrieving admin at IPA5.TEST -> host/master.f21.test at F21.TEST from KEYRING:persistent:0:0 with result: -1765328243/Matching credential not found
[16101] 1417810641.449946: Retrieving admin at IPA5.TEST -> krbtgt/F21.TEST at IPA5.TEST from KEYRING:persistent:0:0 with result: -1765328243/Matching credential not found
[16101] 1417810641.450065: Retrieving admin at IPA5.TEST -> krbtgt/IPA5.TEST at IPA5.TEST from KEYRING:persistent:0:0 with result: 0/Success
[16101] 1417810641.450095: Starting with TGT for client realm: admin at IPA5.TEST -> krbtgt/IPA5.TEST at IPA5.TEST
[16101] 1417810641.450144: Retrieving admin at IPA5.TEST -> krbtgt/F21.TEST at IPA5.TEST from KEYRING:persistent:0:0 with result: -1765328243/Matching credential not found
[16101] 1417810641.450171: Requesting TGT krbtgt/F21.TEST at IPA5.TEST using TGT krbtgt/IPA5.TEST at IPA5.TEST
[16101] 1417810641.450216: Generated subkey for TGS request: aes256-cts/3A06
[16101] 1417810641.450267: etypes requested in TGS request: aes256-cts, aes128-cts, des3-cbc-sha1, rc4-hmac, camellia128-cts, camellia256-cts
[16101] 1417810641.450364: Encoding request body and padata into FAST request
[16101] 1417810641.450422: Sending request (890 bytes) to IPA5.TEST
[16101] 1417810641.450559: Sending initial UDP request to dgram 192.168.5.109:88
[16101] 1417810641.452191: Received answer from dgram 192.168.5.109:88
[16101] 1417810641.452241: Response was from master KDC
[16101] 1417810641.452273: Decoding FAST response
[16101] 1417810641.452366: FAST reply key: aes256-cts/ADA3
[16101] 1417810641.452420: TGS reply is for admin at IPA5.TEST -> krbtgt/F21.TEST at IPA5.TEST with session key aes256-cts/2C28
[16101] 1417810641.452453: TGS request result: 0/Success
[16101] 1417810641.452479: Removing admin at IPA5.TEST -> krbtgt/F21.TEST at IPA5.TEST from KEYRING:persistent:0:0
[16101] 1417810641.452509: Storing admin at IPA5.TEST -> krbtgt/F21.TEST at IPA5.TEST in KEYRING:persistent:0:0
[16101] 1417810641.452572: Received TGT for service realm: krbtgt/F21.TEST at IPA5.TEST
[16101] 1417810641.452600: Requesting tickets for host/master.f21.test at F21.TEST, referrals on
[16101] 1417810641.452626: Generated subkey for TGS request: aes256-cts/599E
[16101] 1417810641.452662: etypes requested in TGS request: aes256-cts, aes128-cts, des3-cbc-sha1, rc4-hmac, camellia128-cts, camellia256-cts
[16101] 1417810641.452707: Encoding request body and padata into FAST request
[16101] 1417810641.452754: Sending request (855 bytes) to F21.TEST
[16101] 1417810641.452805: Resolving hostname master.f21.test
[16101] 1417810641.453031: Sending initial UDP request to dgram 192.168.5.169:88
[16101] 1417810641.456205: Received answer from dgram 192.168.5.169:88
[16101] 1417810641.456285: Response was from master KDC
[16101] 1417810641.456318: Decoding FAST response
[16101] 1417810641.456380: FAST reply key: aes256-cts/E5C4
[16101] 1417810641.456422: TGS reply is for admin at IPA5.TEST -> host/master.f21.test at F21.TEST with session key aes256-cts/5D01
[16101] 1417810641.456456: TGS request result: 0/Success
[16101] 1417810641.456479: Received creds for desired service host/master.f21.test at F21.TEST
[16101] 1417810641.456522: Removing admin at IPA5.TEST -> host/master.f21.test at F21.TEST from KEYRING:persistent:0:0
[16101] 1417810641.456564: Storing admin at IPA5.TEST -> host/master.f21.test at F21.TEST in KEYRING:persistent:0:0
host/master.f21.test at F21.TEST: kvno = 2

[root at ipa-05-m ~]# klist -edf
Ticket cache: KEYRING:persistent:0:0
Default principal: admin at IPA5.TEST

Valid starting       Expires              Service principal
05.12.2014 22:17:10  06.12.2014 22:17:10  host/master.f21.test at F21.TEST
	Flags: FAT, Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96 
05.12.2014 22:17:21  06.12.2014 22:17:14  krbtgt/F21.TEST at IPA5.TEST
	Flags: FAT, Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96 
05.12.2014 22:17:17  06.12.2014 22:17:14  krbtgt/IPA5.TEST at IPA5.TEST
	Flags: FIA, Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96 

Of course, the fact that Kerberos tickets can get issued doesn't mean
that user can login and gain certain privileges. After all, SSSDs on IPA
hosts will not be able to map these Kerberos principals to anything
locally unless you would explicitly instruct libkrb5 via /etc/krb5.conf
on each IPA host.
-- 
/ Alexander Bokovoy



From nagemnna at gmail.com  Fri Dec  5 20:46:32 2014
From: nagemnna at gmail.com (Megan .)
Date: Fri, 5 Dec 2014 15:46:32 -0500
Subject: [Freeipa-users] can't register new clients
Message-ID: <CACMA5-xsgZ2RcF7rx9MS+jtxpyMOofhpU0MnPn+1mcmHGOxNkg@mail.gmail.com>

Good Day!

I am getting an error when i register new clients.

libcurl failed to execute the HTTP POST transaction.  SSL connect error

I can't find anything useful not the internet about the error.  Can
someone help me troubleshoot?

CentOS 6.6  x64
ipa-client-3.0.0-42.el6.centos.x86_64
ipa-server-3.0.0-42.el6.centos.x86_64
curl-7.19.7-40.el6_6.1.x86_64


I checked the 443 connection to the ipa server and it is open to the client.


[root at data2-uat ipa]# ipa-client-install --domain=somewhere.com
--server=dir1.somewhere.com  --no-ntp  --realm=somewhere.com -d
/usr/sbin/ipa-client-install was invoked with options: {'domain':
'somewhere.com', 'force': False, 'krb5_offline_passwords': True,
'primary': False, 'mkhomedir': False, 'create_sshfp': True,
'conf_sshd': True, 'conf_ntp': False, 'on_master': False,
'ntp_server': None, 'server': ['dir1.somewhere.com'], 'no_nisdomain':
False, 'principal': None, 'hostname': None, 'no_ac': False,
'unattended': None, 'sssd': True, 'trust_sshfp': False, 'realm_name':
'somewhere.com', 'dns_updates': False, 'conf_sudo': True, 'conf_ssh':
True, 'force_join': False, 'ca_cert_file': None, 'nisdomain': None,
'prompt_password': False, 'permit': False, 'debug': True,
'preserve_sssd': False, 'uninstall': False}
missing options might be asked for interactively later
Loading Index file from '/var/lib/ipa-client/sysrestore/sysrestore.index'
Loading StateFile from '/var/lib/ipa-client/sysrestore/sysrestore.state'
[IPA Discovery]
Starting IPA discovery with domain=somewhere.com,
servers=['dir1.somewhere.com'], hostname=data2-uat.somewhere.com
Server and domain forced
[Kerberos realm search]
Search DNS for TXT record of _kerberos.somewhere.com.
No DNS record found
[LDAP server check]
Verifying that dir1.somewhere.com (realm None) is an IPA server
Init LDAP connection with: ldap://dir1.somewhere.com:389
Search LDAP server for IPA base DN
Check if naming context 'dc=proj,dc=somewhere,dc=com' is for IPA
Naming context 'dc=proj,dc=somewhere,dc=com' is a valid IPA context
Search for (objectClass=krbRealmContainer) in dc=proj,dc=somewhere,dc=com (sub)
Found: cn=somewhere.com,cn=kerberos,dc=proj,dc=somewhere,dc=com
Discovery result: Success; server=dir1.somewhere.com,
domain=somewhere.com, kdc=None, basedn=dc=proj,dc=somewhere,dc=com
Validated servers: dir1.somewhere.com
will use discovered domain: somewhere.com
Using servers from command line, disabling DNS discovery
will use provided server: dir1.somewhere.com
Autodiscovery of servers for failover cannot work with this configuration.
If you proceed with the installation, services will be configured to
always access the discovered server for all operations and will not
fail over to other servers in case of failure.
Proceed with fixed values and no DNS discovery? [no]: yes
will use discovered realm: somewhere.com
will use discovered basedn: dc=proj,dc=somewhere,dc=com
Hostname: data2-uat.somewhere.com
Hostname source: Machine's FQDN
Realm: somewhere.com
Realm source: Discovered from LDAP DNS records in dir1.somewhere.com
DNS Domain: somewhere.com
DNS Domain source: Forced
IPA Server: dir1.somewhere.com
IPA Server source: Provided as option
BaseDN: dc=proj,dc=somewhere,dc=com
BaseDN source: From IPA server ldap://dir1.somewhere.com:389

Continue to configure the system with these values? [no]: yes
args=/usr/sbin/ipa-rmkeytab -k /etc/krb5.keytab -r somewhere.com
stdout=
stderr=Failed to open keytab '/etc/krb5.keytab': No such file or directory

User authorized to enroll computers: mkispert
will use principal provided as option: mkispert
Synchronizing time with KDC...
Search DNS for SRV record of _ntp._udp.somewhere.com.
No DNS record found
args=/usr/sbin/ntpdate -U ntp -s -b -v dir1.somewhere.com
stdout=
stderr=
args=/usr/sbin/ntpdate -U ntp -s -b -v dir1.somewhere.com
stdout=
stderr=
args=/usr/sbin/ntpdate -U ntp -s -b -v dir1.somewhere.com
stdout=
stderr=
Unable to sync time with IPA NTP server, assuming the time is in sync.
Please check that 123 UDP port is opened.
Writing Kerberos configuration to /tmp/tmphDx3Aq:
#File modified by ipa-client-install

includedir /var/lib/sss/pubconf/krb5.include.d/

[libdefaults]
  default_realm = somewhere.com
  dns_lookup_realm = false
  dns_lookup_kdc = false
  rdns = false
  ticket_lifetime = 24h
  forwardable = yes

[realms]
  somewhere.com = {
    kdc = dir1.somewhere.com:88
    master_kdc = dir1.somewhere.com:88
    admin_server = dir1.somewhere.com:749
    default_domain = somewhere.com
    pkinit_anchors = FILE:/etc/ipa/ca.crt
  }

[domain_realm]
  .somewhere.com = somewhere.com
  somewhere.com = somewhere.com

Password for mkispert at somewhere.com:
args=kinit mkispert at somewhere.com
stdout=Password for mkispert at somewhere.com:
Warning: Your password will expire in 2 days on Mon Dec  8 11:48:37 2014

stderr=
trying to retrieve CA cert via LDAP from ldap://dir1.somewhere.com
Successfully retrieved CA cert
    Subject:     CN=Certificate Authority,O=somewhere.com
    Issuer:      CN=Certificate Authority,O=somewhere.com
    Valid From:  Thu Aug 07 17:55:15 2014 UTC
    Valid Until: Mon Aug 07 17:55:15 2034 UTC

args=/usr/sbin/ipa-join -s dir1.somewhere.com -b dc=proj,dc=somewhere,dc=com -d
stdout=
stderr=XML-RPC CALL:

<?xml version="1.0" encoding="UTF-8"?>\r\n
<methodCall>\r\n
<methodName>join</methodName>\r\n
<params>\r\n
<param><value><array><data>\r\n
<value><string>data2-uat.somewhere.com</string></value>\r\n
</data></array></value></param>\r\n
<param><value><struct>\r\n
<member><name>nsosversion</name>\r\n
<value><string>2.6.32-504.1.3.el6.x86_64</string></value></member>\r\n
<member><name>nshardwareplatform</name>\r\n
<value><string>x86_64</string></value></member>\r\n
</struct></value></param>\r\n
</params>\r\n
</methodCall>\r\n

* About to connect() to dir1.somewhere.com port 443 (#0)
*   Trying x.x.27.170... * Connected to dir1.somewhere.com
(x.x.27.170) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
*   CAfile: /etc/ipa/ca.crt
  CApath: none
* NSS error -8054
* Closing connection #0
libcurl failed to execute the HTTP POST transaction.  SSL connect error

Joining realm failed: XML-RPC CALL:

<?xml version="1.0" encoding="UTF-8"?>\r\n
<methodCall>\r\n
<methodName>join</methodName>\r\n
<params>\r\n
<param><value><array><data>\r\n
<value><string>data2-uat.somewhere.com</string></value>\r\n
</data></array></value></param>\r\n
<param><value><struct>\r\n
<member><name>nsosversion</name>\r\n
<value><string>2.6.32-504.1.3.el6.x86_64</string></value></member>\r\n
<member><name>nshardwareplatform</name>\r\n
<value><string>x86_64</string></value></member>\r\n
</struct></value></param>\r\n
</params>\r\n
</methodCall>\r\n

* About to connect() to dir1.somewhere.com port 443 (#0)
*   Trying x.x.27.170... * Connected to dir1.somewhere.com
(x.x.27.170) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
*   CAfile: /etc/ipa/ca.crt
  CApath: none
* NSS error -8054
* Closing connection #0
libcurl failed to execute the HTTP POST transaction.  SSL connect error

Installation failed. Rolling back changes.
IPA client is not configured on this system.
[root at data2-uat ipa]#



From rcritten at redhat.com  Fri Dec  5 20:50:47 2014
From: rcritten at redhat.com (Rob Crittenden)
Date: Fri, 05 Dec 2014 15:50:47 -0500
Subject: [Freeipa-users] can't register new clients
In-Reply-To: <CACMA5-xsgZ2RcF7rx9MS+jtxpyMOofhpU0MnPn+1mcmHGOxNkg@mail.gmail.com>
References: <CACMA5-xsgZ2RcF7rx9MS+jtxpyMOofhpU0MnPn+1mcmHGOxNkg@mail.gmail.com>
Message-ID: <54821AA7.1000007@redhat.com>

Megan . wrote:
> Good Day!
> 
> I am getting an error when i register new clients.
> 
> libcurl failed to execute the HTTP POST transaction.  SSL connect error
> 
> I can't find anything useful not the internet about the error.  Can
> someone help me troubleshoot?
> 
> CentOS 6.6  x64
> ipa-client-3.0.0-42.el6.centos.x86_64
> ipa-server-3.0.0-42.el6.centos.x86_64
> curl-7.19.7-40.el6_6.1.x86_64

Do you have NSS_DEFAULT_DB_TYPE set to sql? I don't know that we've done
any testing on the client with this set.

rob



From abokovoy at redhat.com  Fri Dec  5 20:53:07 2014
From: abokovoy at redhat.com (Alexander Bokovoy)
Date: Fri, 5 Dec 2014 22:53:07 +0200
Subject: [Freeipa-users] Cross-Realm authentification
In-Reply-To: <20141205202655.GR16288@redhat.com>
References: <547F1233.4020709@kit.edu> <20141203135351.GG16288@redhat.com>
	<5480287B.4050406@kit.edu> <20141204110702.GH16288@redhat.com>
	<5481A47B.2000005@kit.edu> <20141205125637.GM16288@redhat.com>
	<20141205130426.GN16288@redhat.com> <5481BF4D.5060006@kit.edu>
	<5481C02D.6000805@redhat.com> <20141205202655.GR16288@redhat.com>
Message-ID: <20141205205307.GS16288@redhat.com>

On Fri, 05 Dec 2014, Alexander Bokovoy wrote:
>On Fri, 05 Dec 2014, Petr Spacek wrote:
>>On 5.12.2014 15:21, Andreas Ladanyi wrote:
>>>Am 05.12.2014 um 14:04 schrieb Alexander Bokovoy:
>>>>
>>>>>>>
>>>>>>Ok, i see one difference: i didnt use the "-requires_preauth" flag. Why
>>>>>>did you use them ?
>>>>>Because this is recommended by MIT documentation. The link between
>>>>>realms has to be protected well, including preauth and good passwords
>>>>>for the cross-realm principals.
>>>>>
>>>>>
>>>>>>Is it possible or a good idea to add my trust domain, which isnt a AD
>>>>>>domain, manualy to IPA 3.3 ?
>>>>>Well, you can hack of course, that's up to you. I haven't checked that
>>>>>myself and cannot give you definitive answer on this path, though.
>>>At this time i havent an idea off the steps in detail how to do that.
>>>>>
>>>>>>>
>>>>>>>
>>>>>>>We may reconsider this check and instead of KRB5KRB_AP_ERR_ILL_CR_TKT
>>>>>>>return KRB5_PLUGIN_NO_HANDLE to allow fallback to krb5.conf-defined
>>>>>>>capaths but I remember we had some issues with krb5 versions prior to
>>>>>>>1.12 where capaths from krb5.conf were blocking work of the DAL
>>>>>>>driver.
>>>>>>I use MIT Kerberos 1.6 from OpenCSW on Solaris and FreeIPA 3.3.5. So
>>>>>>this shouldnt be a problem ?!
>>>Sorry i made a little typing mistake. The foreign realm ist MIT Kerberos
>>>1.9.2 and not 1.6
>>>>>1.6 does not support cross-realm communication as support for RFC6806
>>>>>was added only in 1.7. So I don't think your setup would have any chance
>>>>>to work at all.
>>>>Hm.. on the other hand, 1.6 documentation talks about it:
>>>>http://web.mit.edu/kerberos/krb5-1.6/krb5-1.6.3/doc/krb5-admin.html#Cross_002drealm-Authentication
>>>>
>>>>So may be their changelogs aren't as complete as they should be. :)
>>>>
>>>>With the link above you can also see with disabling preauth on the
>>>>cross-realm krbtgt records is recommended.
>>>>
>>>>But I think most of your issues were because of the 88 port not being
>>>>available and no other means to traverse firewall were configured.
>>>I will look particular for that.
>>>
>>>There is no firewall between the two KDCs.
>>>
>>>>That
>>>>is, aside from the fact that IPA will reject cross-realm tickets because
>>>>of how we programmed DAL driver as I explained above.
>>>
>>>
>>>I dont know in detail what DAL is doing.
>>>
>>>OK, it sounds like with IPA my setup wont be very easy :-)
>>
>>I guess that Alexander or Simo could point you to the line in the source code
>>you have to change (or send you one-line patch?) but you will have to
>>recompile the driver from source.
>>
>>Do you want to try this way?
>Attached please find a patch that solves the issue of cross-realm trust
>for me:
>[root at ipa-05-m ~]# kinit admin
>Password for admin at IPA5.TEST: [root at ipa-05-m ~]# 
>KRB5_TRACE=/dev/stderr kvno -S host master.f21.test
>[16101] 1417810641.441614: Convert service host (service with host as instance) on host master.f21.test to principal
>[16101] 1417810641.449424: Remote host after forward canonicalization: master.f21.test
>[16101] 1417810641.449501: Remote host after reverse DNS processing: master.f21.test
>[16101] 1417810641.449549: Get host realm for master.f21.test
>[16101] 1417810641.449593: Use local host master.f21.test to get host realm
>[16101] 1417810641.449630: Look up master.f21.test in the domain_realm map
>[16101] 1417810641.449655: Look up .f21.test in the domain_realm map
>[16101] 1417810641.449677: Temporary realm is F21.TEST
>[16101] 1417810641.449697: Got realm F21.TEST for host master.f21.test
>[16101] 1417810641.449724: Got service principal host/master.f21.test at F21.TEST
>[16101] 1417810641.449750: Getting credentials admin at IPA5.TEST -> host/master.f21.test at F21.TEST using ccache KEYRING:persistent:0:0
>[16101] 1417810641.449888: Retrieving admin at IPA5.TEST -> host/master.f21.test at F21.TEST from KEYRING:persistent:0:0 with result: -1765328243/Matching credential not found
>[16101] 1417810641.449946: Retrieving admin at IPA5.TEST -> krbtgt/F21.TEST at IPA5.TEST from KEYRING:persistent:0:0 with result: -1765328243/Matching credential not found
>[16101] 1417810641.450065: Retrieving admin at IPA5.TEST -> krbtgt/IPA5.TEST at IPA5.TEST from KEYRING:persistent:0:0 with result: 0/Success
>[16101] 1417810641.450095: Starting with TGT for client realm: admin at IPA5.TEST -> krbtgt/IPA5.TEST at IPA5.TEST
>[16101] 1417810641.450144: Retrieving admin at IPA5.TEST -> krbtgt/F21.TEST at IPA5.TEST from KEYRING:persistent:0:0 with result: -1765328243/Matching credential not found
>[16101] 1417810641.450171: Requesting TGT krbtgt/F21.TEST at IPA5.TEST using TGT krbtgt/IPA5.TEST at IPA5.TEST
>[16101] 1417810641.450216: Generated subkey for TGS request: aes256-cts/3A06
>[16101] 1417810641.450267: etypes requested in TGS request: aes256-cts, aes128-cts, des3-cbc-sha1, rc4-hmac, camellia128-cts, camellia256-cts
>[16101] 1417810641.450364: Encoding request body and padata into FAST request
>[16101] 1417810641.450422: Sending request (890 bytes) to IPA5.TEST
>[16101] 1417810641.450559: Sending initial UDP request to dgram 192.168.5.109:88
>[16101] 1417810641.452191: Received answer from dgram 192.168.5.109:88
>[16101] 1417810641.452241: Response was from master KDC
>[16101] 1417810641.452273: Decoding FAST response
>[16101] 1417810641.452366: FAST reply key: aes256-cts/ADA3
>[16101] 1417810641.452420: TGS reply is for admin at IPA5.TEST -> krbtgt/F21.TEST at IPA5.TEST with session key aes256-cts/2C28
>[16101] 1417810641.452453: TGS request result: 0/Success
>[16101] 1417810641.452479: Removing admin at IPA5.TEST -> krbtgt/F21.TEST at IPA5.TEST from KEYRING:persistent:0:0
>[16101] 1417810641.452509: Storing admin at IPA5.TEST -> krbtgt/F21.TEST at IPA5.TEST in KEYRING:persistent:0:0
>[16101] 1417810641.452572: Received TGT for service realm: krbtgt/F21.TEST at IPA5.TEST
>[16101] 1417810641.452600: Requesting tickets for host/master.f21.test at F21.TEST, referrals on
>[16101] 1417810641.452626: Generated subkey for TGS request: aes256-cts/599E
>[16101] 1417810641.452662: etypes requested in TGS request: aes256-cts, aes128-cts, des3-cbc-sha1, rc4-hmac, camellia128-cts, camellia256-cts
>[16101] 1417810641.452707: Encoding request body and padata into FAST request
>[16101] 1417810641.452754: Sending request (855 bytes) to F21.TEST
>[16101] 1417810641.452805: Resolving hostname master.f21.test
>[16101] 1417810641.453031: Sending initial UDP request to dgram 192.168.5.169:88
>[16101] 1417810641.456205: Received answer from dgram 192.168.5.169:88
>[16101] 1417810641.456285: Response was from master KDC
>[16101] 1417810641.456318: Decoding FAST response
>[16101] 1417810641.456380: FAST reply key: aes256-cts/E5C4
>[16101] 1417810641.456422: TGS reply is for admin at IPA5.TEST -> host/master.f21.test at F21.TEST with session key aes256-cts/5D01
>[16101] 1417810641.456456: TGS request result: 0/Success
>[16101] 1417810641.456479: Received creds for desired service host/master.f21.test at F21.TEST
>[16101] 1417810641.456522: Removing admin at IPA5.TEST -> host/master.f21.test at F21.TEST from KEYRING:persistent:0:0
>[16101] 1417810641.456564: Storing admin at IPA5.TEST -> host/master.f21.test at F21.TEST in KEYRING:persistent:0:0
>host/master.f21.test at F21.TEST: kvno = 2
>
>[root at ipa-05-m ~]# klist -edf
>Ticket cache: KEYRING:persistent:0:0
>Default principal: admin at IPA5.TEST
>
>Valid starting       Expires              Service principal
>05.12.2014 22:17:10  06.12.2014 22:17:10  host/master.f21.test at F21.TEST
>	Flags: FAT, Etype (skey, tkt): aes256-cts-hmac-sha1-96, 
>aes256-cts-hmac-sha1-96 05.12.2014 22:17:21  06.12.2014 22:17:14  
>krbtgt/F21.TEST at IPA5.TEST
>	Flags: FAT, Etype (skey, tkt): aes256-cts-hmac-sha1-96, 
>aes256-cts-hmac-sha1-96 05.12.2014 22:17:17  06.12.2014 22:17:14  
>krbtgt/IPA5.TEST at IPA5.TEST
>	Flags: FIA, Etype (skey, tkt): aes256-cts-hmac-sha1-96, 
>aes256-cts-hmac-sha1-96
>
>Of course, the fact that Kerberos tickets can get issued doesn't mean
>that user can login and gain certain privileges. After all, SSSDs on IPA
>hosts will not be able to map these Kerberos principals to anything
>locally unless you would explicitly instruct libkrb5 via /etc/krb5.conf
>on each IPA host.
Patch attached.
-- 
/ Alexander Bokovoy
-------------- next part --------------
From d7d73e1e34aaa8c7042c332d09853a96955f6635 Mon Sep 17 00:00:00 2001
From: Alexander Bokovoy <abokovoy at redhat.com>
Date: Fri, 5 Dec 2014 21:22:23 +0200
Subject: [PATCH] WIP: ipa-kdb: when processing transitions, hand over unknown
 ones to KDC

When processing cross-realm trust transitions, let the KDC to handle
those we don't know about. Admins might define the transitions as
explicit [capaths] in krb5.conf.

This is work-in-progress fix for
https://fedorahosted.org/freeipa/ticket/4791
---
 daemons/ipa-kdb/ipa_kdb_mspac.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/daemons/ipa-kdb/ipa_kdb_mspac.c b/daemons/ipa-kdb/ipa_kdb_mspac.c
index a73a3cb..39fa583 100644
--- a/daemons/ipa-kdb/ipa_kdb_mspac.c
+++ b/daemons/ipa-kdb/ipa_kdb_mspac.c
@@ -2680,7 +2680,8 @@ krb5_error_code ipadb_check_transited_realms(krb5_context kcontext,
 		}
 	}
 
-	ret = KRB5KRB_AP_ERR_ILL_CR_TKT;
+	/* Tell to KDC that we don't handle this transition so that rules in krb5.conf could play its role */
+	ret = KRB5_PLUGIN_NO_HANDLE;
 	if (has_client_realm && has_transited_contents && has_server_realm) {
 		ret = 0;
 	}
-- 
2.1.0


From rcritten at redhat.com  Fri Dec  5 21:03:23 2014
From: rcritten at redhat.com (Rob Crittenden)
Date: Fri, 05 Dec 2014 16:03:23 -0500
Subject: [Freeipa-users] can't register new clients
In-Reply-To: <54821AA7.1000007@redhat.com>
References: <CACMA5-xsgZ2RcF7rx9MS+jtxpyMOofhpU0MnPn+1mcmHGOxNkg@mail.gmail.com>
	<54821AA7.1000007@redhat.com>
Message-ID: <54821D9B.80502@redhat.com>

Rob Crittenden wrote:
> Megan . wrote:
>> Good Day!
>>
>> I am getting an error when i register new clients.
>>
>> libcurl failed to execute the HTTP POST transaction.  SSL connect error
>>
>> I can't find anything useful not the internet about the error.  Can
>> someone help me troubleshoot?
>>
>> CentOS 6.6  x64
>> ipa-client-3.0.0-42.el6.centos.x86_64
>> ipa-server-3.0.0-42.el6.centos.x86_64
>> curl-7.19.7-40.el6_6.1.x86_64
> 
> Do you have NSS_DEFAULT_DB_TYPE set to sql? I don't know that we've done
> any testing on the client with this set.

Never mind, that's not it. The problem is:

* NSS error -8054

Which is SEC_ERROR_REUSED_ISSUER_AND_SERIAL

So I'd do this:

# rm /etc/ipa/ca.crt

You may also want to ensure that the IPA CA certificate isn't in
/etc/pki/nssdb:

# certutil -L -d /etc/pki/nssdb

And then perhaps

# certutil -D -n 'IPA CA' -d /etc/pki/nssdb

rob



From pspacek at redhat.com  Fri Dec  5 21:24:25 2014
From: pspacek at redhat.com (Petr Spacek)
Date: Fri, 05 Dec 2014 22:24:25 +0100
Subject: [Freeipa-users] Cross-Realm authentification
In-Reply-To: <20141205205307.GS16288@redhat.com>
References: <547F1233.4020709@kit.edu> <20141203135351.GG16288@redhat.com>
	<5480287B.4050406@kit.edu> <20141204110702.GH16288@redhat.com>
	<5481A47B.2000005@kit.edu> <20141205125637.GM16288@redhat.com>
	<20141205130426.GN16288@redhat.com> <5481BF4D.5060006@kit.edu>
	<5481C02D.6000805@redhat.com> <20141205202655.GR16288@redhat.com>
	<20141205205307.GS16288@redhat.com>
Message-ID: <54822289.3090901@redhat.com>

On 5.12.2014 21:53, Alexander Bokovoy wrote:
> On Fri, 05 Dec 2014, Alexander Bokovoy wrote:
>> On Fri, 05 Dec 2014, Petr Spacek wrote:
>>> On 5.12.2014 15:21, Andreas Ladanyi wrote:
>>>> Am 05.12.2014 um 14:04 schrieb Alexander Bokovoy:
>>>>>
>>>>>>>>
>>>>>>> Ok, i see one difference: i didnt use the "-requires_preauth" flag. Why
>>>>>>> did you use them ?
>>>>>> Because this is recommended by MIT documentation. The link between
>>>>>> realms has to be protected well, including preauth and good passwords
>>>>>> for the cross-realm principals.
>>>>>>
>>>>>>
>>>>>>> Is it possible or a good idea to add my trust domain, which isnt a AD
>>>>>>> domain, manualy to IPA 3.3 ?
>>>>>> Well, you can hack of course, that's up to you. I haven't checked that
>>>>>> myself and cannot give you definitive answer on this path, though.
>>>> At this time i havent an idea off the steps in detail how to do that.
>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> We may reconsider this check and instead of KRB5KRB_AP_ERR_ILL_CR_TKT
>>>>>>>> return KRB5_PLUGIN_NO_HANDLE to allow fallback to krb5.conf-defined
>>>>>>>> capaths but I remember we had some issues with krb5 versions prior to
>>>>>>>> 1.12 where capaths from krb5.conf were blocking work of the DAL
>>>>>>>> driver.
>>>>>>> I use MIT Kerberos 1.6 from OpenCSW on Solaris and FreeIPA 3.3.5. So
>>>>>>> this shouldnt be a problem ?!
>>>> Sorry i made a little typing mistake. The foreign realm ist MIT Kerberos
>>>> 1.9.2 and not 1.6
>>>>>> 1.6 does not support cross-realm communication as support for RFC6806
>>>>>> was added only in 1.7. So I don't think your setup would have any chance
>>>>>> to work at all.
>>>>> Hm.. on the other hand, 1.6 documentation talks about it:
>>>>> http://web.mit.edu/kerberos/krb5-1.6/krb5-1.6.3/doc/krb5-admin.html#Cross_002drealm-Authentication
>>>>>
>>>>>
>>>>> So may be their changelogs aren't as complete as they should be. :)
>>>>>
>>>>> With the link above you can also see with disabling preauth on the
>>>>> cross-realm krbtgt records is recommended.
>>>>>
>>>>> But I think most of your issues were because of the 88 port not being
>>>>> available and no other means to traverse firewall were configured.
>>>> I will look particular for that.
>>>>
>>>> There is no firewall between the two KDCs.
>>>>
>>>>> That
>>>>> is, aside from the fact that IPA will reject cross-realm tickets because
>>>>> of how we programmed DAL driver as I explained above.
>>>>
>>>>
>>>> I dont know in detail what DAL is doing.
>>>>
>>>> OK, it sounds like with IPA my setup wont be very easy :-)
>>>
>>> I guess that Alexander or Simo could point you to the line in the source code
>>> you have to change (or send you one-line patch?) but you will have to
>>> recompile the driver from source.
>>>
>>> Do you want to try this way?
>> Attached please find a patch that solves the issue of cross-realm trust
>> for me:
>> [root at ipa-05-m ~]# kinit admin
>> Password for admin at IPA5.TEST: [root at ipa-05-m ~]# KRB5_TRACE=/dev/stderr kvno
>> -S host master.f21.test
>> [16101] 1417810641.441614: Convert service host (service with host as
>> instance) on host master.f21.test to principal
>> [16101] 1417810641.449424: Remote host after forward canonicalization:
>> master.f21.test
>> [16101] 1417810641.449501: Remote host after reverse DNS processing:
>> master.f21.test
>> [16101] 1417810641.449549: Get host realm for master.f21.test
>> [16101] 1417810641.449593: Use local host master.f21.test to get host realm
>> [16101] 1417810641.449630: Look up master.f21.test in the domain_realm map
>> [16101] 1417810641.449655: Look up .f21.test in the domain_realm map
>> [16101] 1417810641.449677: Temporary realm is F21.TEST
>> [16101] 1417810641.449697: Got realm F21.TEST for host master.f21.test
>> [16101] 1417810641.449724: Got service principal host/master.f21.test at F21.TEST
>> [16101] 1417810641.449750: Getting credentials admin at IPA5.TEST ->
>> host/master.f21.test at F21.TEST using ccache KEYRING:persistent:0:0
>> [16101] 1417810641.449888: Retrieving admin at IPA5.TEST ->
>> host/master.f21.test at F21.TEST from KEYRING:persistent:0:0 with result:
>> -1765328243/Matching credential not found
>> [16101] 1417810641.449946: Retrieving admin at IPA5.TEST ->
>> krbtgt/F21.TEST at IPA5.TEST from KEYRING:persistent:0:0 with result:
>> -1765328243/Matching credential not found
>> [16101] 1417810641.450065: Retrieving admin at IPA5.TEST ->
>> krbtgt/IPA5.TEST at IPA5.TEST from KEYRING:persistent:0:0 with result: 0/Success
>> [16101] 1417810641.450095: Starting with TGT for client realm:
>> admin at IPA5.TEST -> krbtgt/IPA5.TEST at IPA5.TEST
>> [16101] 1417810641.450144: Retrieving admin at IPA5.TEST ->
>> krbtgt/F21.TEST at IPA5.TEST from KEYRING:persistent:0:0 with result:
>> -1765328243/Matching credential not found
>> [16101] 1417810641.450171: Requesting TGT krbtgt/F21.TEST at IPA5.TEST using
>> TGT krbtgt/IPA5.TEST at IPA5.TEST
>> [16101] 1417810641.450216: Generated subkey for TGS request: aes256-cts/3A06
>> [16101] 1417810641.450267: etypes requested in TGS request: aes256-cts,
>> aes128-cts, des3-cbc-sha1, rc4-hmac, camellia128-cts, camellia256-cts
>> [16101] 1417810641.450364: Encoding request body and padata into FAST request
>> [16101] 1417810641.450422: Sending request (890 bytes) to IPA5.TEST
>> [16101] 1417810641.450559: Sending initial UDP request to dgram
>> 192.168.5.109:88
>> [16101] 1417810641.452191: Received answer from dgram 192.168.5.109:88
>> [16101] 1417810641.452241: Response was from master KDC
>> [16101] 1417810641.452273: Decoding FAST response
>> [16101] 1417810641.452366: FAST reply key: aes256-cts/ADA3
>> [16101] 1417810641.452420: TGS reply is for admin at IPA5.TEST ->
>> krbtgt/F21.TEST at IPA5.TEST with session key aes256-cts/2C28
>> [16101] 1417810641.452453: TGS request result: 0/Success
>> [16101] 1417810641.452479: Removing admin at IPA5.TEST ->
>> krbtgt/F21.TEST at IPA5.TEST from KEYRING:persistent:0:0
>> [16101] 1417810641.452509: Storing admin at IPA5.TEST ->
>> krbtgt/F21.TEST at IPA5.TEST in KEYRING:persistent:0:0
>> [16101] 1417810641.452572: Received TGT for service realm:
>> krbtgt/F21.TEST at IPA5.TEST
>> [16101] 1417810641.452600: Requesting tickets for
>> host/master.f21.test at F21.TEST, referrals on
>> [16101] 1417810641.452626: Generated subkey for TGS request: aes256-cts/599E
>> [16101] 1417810641.452662: etypes requested in TGS request: aes256-cts,
>> aes128-cts, des3-cbc-sha1, rc4-hmac, camellia128-cts, camellia256-cts
>> [16101] 1417810641.452707: Encoding request body and padata into FAST request
>> [16101] 1417810641.452754: Sending request (855 bytes) to F21.TEST
>> [16101] 1417810641.452805: Resolving hostname master.f21.test
>> [16101] 1417810641.453031: Sending initial UDP request to dgram
>> 192.168.5.169:88
>> [16101] 1417810641.456205: Received answer from dgram 192.168.5.169:88
>> [16101] 1417810641.456285: Response was from master KDC
>> [16101] 1417810641.456318: Decoding FAST response
>> [16101] 1417810641.456380: FAST reply key: aes256-cts/E5C4
>> [16101] 1417810641.456422: TGS reply is for admin at IPA5.TEST ->
>> host/master.f21.test at F21.TEST with session key aes256-cts/5D01
>> [16101] 1417810641.456456: TGS request result: 0/Success
>> [16101] 1417810641.456479: Received creds for desired service
>> host/master.f21.test at F21.TEST
>> [16101] 1417810641.456522: Removing admin at IPA5.TEST ->
>> host/master.f21.test at F21.TEST from KEYRING:persistent:0:0
>> [16101] 1417810641.456564: Storing admin at IPA5.TEST ->
>> host/master.f21.test at F21.TEST in KEYRING:persistent:0:0
>> host/master.f21.test at F21.TEST: kvno = 2
>>
>> [root at ipa-05-m ~]# klist -edf
>> Ticket cache: KEYRING:persistent:0:0
>> Default principal: admin at IPA5.TEST
>>
>> Valid starting       Expires              Service principal
>> 05.12.2014 22:17:10  06.12.2014 22:17:10  host/master.f21.test at F21.TEST
>>     Flags: FAT, Etype (skey, tkt): aes256-cts-hmac-sha1-96,
>> aes256-cts-hmac-sha1-96 05.12.2014 22:17:21  06.12.2014 22:17:14 
>> krbtgt/F21.TEST at IPA5.TEST
>>     Flags: FAT, Etype (skey, tkt): aes256-cts-hmac-sha1-96,
>> aes256-cts-hmac-sha1-96 05.12.2014 22:17:17  06.12.2014 22:17:14 
>> krbtgt/IPA5.TEST at IPA5.TEST
>>     Flags: FIA, Etype (skey, tkt): aes256-cts-hmac-sha1-96,
>> aes256-cts-hmac-sha1-96
>>
>> Of course, the fact that Kerberos tickets can get issued doesn't mean
>> that user can login and gain certain privileges. After all, SSSDs on IPA
>> hosts will not be able to map these Kerberos principals to anything
>> locally unless you would explicitly instruct libkrb5 via /etc/krb5.conf
>> on each IPA host.
> Patch attached.

For build instructions please see
http://www.freeipa.org/page/Build

-- 
Petr^2 Spacek



From rcritten at redhat.com  Fri Dec  5 22:10:53 2014
From: rcritten at redhat.com (Rob Crittenden)
Date: Fri, 05 Dec 2014 17:10:53 -0500
Subject: [Freeipa-users] can't register new clients
In-Reply-To: <CACMA5-w=BmD+=9Gj7Q=U0oheEQOb40zfdzST_ASixiuKs5TqHA@mail.gmail.com>
References: <CACMA5-xsgZ2RcF7rx9MS+jtxpyMOofhpU0MnPn+1mcmHGOxNkg@mail.gmail.com>	<54821AA7.1000007@redhat.com>	<54821D9B.80502@redhat.com>	<CACMA5-xs3gOMAdjg3o5aG6d58d-CvqPh5k9yo23pLSD9uXAq9Q@mail.gmail.com>	<548225F9.7010001@redhat.com>
	<CACMA5-w=BmD+=9Gj7Q=U0oheEQOb40zfdzST_ASixiuKs5TqHA@mail.gmail.com>
Message-ID: <54822D6D.1050807@redhat.com>

Megan . wrote:
> Sorry for being unclear. It still fails.  Same error.

Hmm, strange. Try being explicit about sql:

# certutil -L -d sql:/etc/pki/nssdb

And if there is a CA cert there, delete it.

rob

> 
> On Dec 5, 2014 4:39 PM, "Rob Crittenden" <rcritten at redhat.com
> <mailto:rcritten at redhat.com>> wrote:
> 
>     Megan . wrote:
>     > Thanks.
>     >
>     > I did have an issue last week where i tried to do the client install
>     > and it failed because of a firewall issue.  Networks has it opened
>     > now.  I deleted ca.crt before trying again.  There doesn't seem to be
>     > a certificate in /etc/pki/nssdb for it.
>     >
>     >
>     >
>     > [root at data2-uat ipa]# certutil -L -d /etc/pki/nssdb
>     >
>     >
>     > Certificate Nickname                                         Trust
>     Attributes
>     >
>     >                                                             
>     SSL,S/MIME,JAR/XPI
>     >
>     >
>     > [root at data2-uat ipa]# certutil -D -n 'IPA CA' -d /etc/pki/nssdb
>     >
>     > certutil: could not find certificate named "IPA CA":
>     > SEC_ERROR_BAD_DATABASE: security library: bad database.
>     >
>     > [root at data2-uat ipa]# ls
>     >
>     > [root at data2-uat ipa]# pwd
>     >
>     > /etc/ipa
>     >
>     > [root at data2-uat ipa]# ls -al
>     >
>     > total 16
>     >
>     > drwxr-xr-x.  2 root root  4096 Dec  5 21:16 .
>     >
>     > drwxr-xr-x. 82 root root 12288 Dec  5 21:16 ..
>     >
>     > [root at data2-uat ipa]#
> 
>     So trying to install the client again fails or succeeds now?
> 
>     rob
> 
>     >
>     > On Fri, Dec 5, 2014 at 4:03 PM, Rob Crittenden
>     <rcritten at redhat.com <mailto:rcritten at redhat.com>> wrote:
>     >> Rob Crittenden wrote:
>     >>> Megan . wrote:
>     >>>> Good Day!
>     >>>>
>     >>>> I am getting an error when i register new clients.
>     >>>>
>     >>>> libcurl failed to execute the HTTP POST transaction.  SSL
>     connect error
>     >>>>
>     >>>> I can't find anything useful not the internet about the error.  Can
>     >>>> someone help me troubleshoot?
>     >>>>
>     >>>> CentOS 6.6  x64
>     >>>> ipa-client-3.0.0-42.el6.centos.x86_64
>     >>>> ipa-server-3.0.0-42.el6.centos.x86_64
>     >>>> curl-7.19.7-40.el6_6.1.x86_64
>     >>>
>     >>> Do you have NSS_DEFAULT_DB_TYPE set to sql? I don't know that
>     we've done
>     >>> any testing on the client with this set.
>     >>
>     >> Never mind, that's not it. The problem is:
>     >>
>     >> * NSS error -8054
>     >>
>     >> Which is SEC_ERROR_REUSED_ISSUER_AND_SERIAL
>     >>
>     >> So I'd do this:
>     >>
>     >> # rm /etc/ipa/ca.crt
>     >>
>     >> You may also want to ensure that the IPA CA certificate isn't in
>     >> /etc/pki/nssdb:
>     >>
>     >> # certutil -L -d /etc/pki/nssdb
>     >>
>     >> And then perhaps
>     >>
>     >> # certutil -D -n 'IPA CA' -d /etc/pki/nssdb
>     >>
>     >> rob
>     >>
> 



From nagemnna at gmail.com  Sat Dec  6 00:51:46 2014
From: nagemnna at gmail.com (Megan .)
Date: Fri, 5 Dec 2014 19:51:46 -0500
Subject: [Freeipa-users] can't register new clients
In-Reply-To: <54822D6D.1050807@redhat.com>
References: <CACMA5-xsgZ2RcF7rx9MS+jtxpyMOofhpU0MnPn+1mcmHGOxNkg@mail.gmail.com>
	<54821AA7.1000007@redhat.com> <54821D9B.80502@redhat.com>
	<CACMA5-xs3gOMAdjg3o5aG6d58d-CvqPh5k9yo23pLSD9uXAq9Q@mail.gmail.com>
	<548225F9.7010001@redhat.com>
	<CACMA5-w=BmD+=9Gj7Q=U0oheEQOb40zfdzST_ASixiuKs5TqHA@mail.gmail.com>
	<54822D6D.1050807@redhat.com>
Message-ID: <CACMA5-z+rt0e7tkf_UY5L_YzbQNcmRrNbNDQv3H01a=O9sXmxg@mail.gmail.com>

It failed again.


[root at cache2-uat ~]# certutil -L -d sql:/etc/pki/nssdb

Certificate Nickname                                         Trust Attributes
                                                             SSL,S/MIME,JAR/XPI
[root at cache2-uat ~]#

Not sure if its related, but on the directory server in the apache
error.log I see the below every time a client tries to register:

[Sat Dec 06 00:48:35 2014] [error] SSL Library Error: -12271 SSL
client cannot verify your certificate

On the directory server i ran ipa-getcert list and the certs seem ok.



On Fri, Dec 5, 2014 at 5:10 PM, Rob Crittenden <rcritten at redhat.com> wrote:
> Megan . wrote:
>> Sorry for being unclear. It still fails.  Same error.
>
> Hmm, strange. Try being explicit about sql:
>
> # certutil -L -d sql:/etc/pki/nssdb
>
> And if there is a CA cert there, delete it.
>
> rob
>
>>
>> On Dec 5, 2014 4:39 PM, "Rob Crittenden" <rcritten at redhat.com
>> <mailto:rcritten at redhat.com>> wrote:
>>
>>     Megan . wrote:
>>     > Thanks.
>>     >
>>     > I did have an issue last week where i tried to do the client install
>>     > and it failed because of a firewall issue.  Networks has it opened
>>     > now.  I deleted ca.crt before trying again.  There doesn't seem to be
>>     > a certificate in /etc/pki/nssdb for it.
>>     >
>>     >
>>     >
>>     > [root at data2-uat ipa]# certutil -L -d /etc/pki/nssdb
>>     >
>>     >
>>     > Certificate Nickname                                         Trust
>>     Attributes
>>     >
>>     >
>>     SSL,S/MIME,JAR/XPI
>>     >
>>     >
>>     > [root at data2-uat ipa]# certutil -D -n 'IPA CA' -d /etc/pki/nssdb
>>     >
>>     > certutil: could not find certificate named "IPA CA":
>>     > SEC_ERROR_BAD_DATABASE: security library: bad database.
>>     >
>>     > [root at data2-uat ipa]# ls
>>     >
>>     > [root at data2-uat ipa]# pwd
>>     >
>>     > /etc/ipa
>>     >
>>     > [root at data2-uat ipa]# ls -al
>>     >
>>     > total 16
>>     >
>>     > drwxr-xr-x.  2 root root  4096 Dec  5 21:16 .
>>     >
>>     > drwxr-xr-x. 82 root root 12288 Dec  5 21:16 ..
>>     >
>>     > [root at data2-uat ipa]#
>>
>>     So trying to install the client again fails or succeeds now?
>>
>>     rob
>>
>>     >
>>     > On Fri, Dec 5, 2014 at 4:03 PM, Rob Crittenden
>>     <rcritten at redhat.com <mailto:rcritten at redhat.com>> wrote:
>>     >> Rob Crittenden wrote:
>>     >>> Megan . wrote:
>>     >>>> Good Day!
>>     >>>>
>>     >>>> I am getting an error when i register new clients.
>>     >>>>
>>     >>>> libcurl failed to execute the HTTP POST transaction.  SSL
>>     connect error
>>     >>>>
>>     >>>> I can't find anything useful not the internet about the error.  Can
>>     >>>> someone help me troubleshoot?
>>     >>>>
>>     >>>> CentOS 6.6  x64
>>     >>>> ipa-client-3.0.0-42.el6.centos.x86_64
>>     >>>> ipa-server-3.0.0-42.el6.centos.x86_64
>>     >>>> curl-7.19.7-40.el6_6.1.x86_64
>>     >>>
>>     >>> Do you have NSS_DEFAULT_DB_TYPE set to sql? I don't know that
>>     we've done
>>     >>> any testing on the client with this set.
>>     >>
>>     >> Never mind, that's not it. The problem is:
>>     >>
>>     >> * NSS error -8054
>>     >>
>>     >> Which is SEC_ERROR_REUSED_ISSUER_AND_SERIAL
>>     >>
>>     >> So I'd do this:
>>     >>
>>     >> # rm /etc/ipa/ca.crt
>>     >>
>>     >> You may also want to ensure that the IPA CA certificate isn't in
>>     >> /etc/pki/nssdb:
>>     >>
>>     >> # certutil -L -d /etc/pki/nssdb
>>     >>
>>     >> And then perhaps
>>     >>
>>     >> # certutil -D -n 'IPA CA' -d /etc/pki/nssdb
>>     >>
>>     >> rob
>>     >>
>>
>



From gianluca.cecchi at gmail.com  Sun Dec  7 14:44:00 2014
From: gianluca.cecchi at gmail.com (Gianluca Cecchi)
Date: Sun, 7 Dec 2014 15:44:00 +0100
Subject: [Freeipa-users] one step away from having freeipa work with vsphere
	ldap
Message-ID: <CAG2kNCyKOiD69pfiu9ZqAifjBKeUoCJTpK9C_H=hDURdbAcn9w@mail.gmail.com>

Hello,
I'm quite near to have users and groups working using ipa 3.3 as in CentOS
7 as this gives ability to do binds against compat tree.
This is with the use of schema compatibility

The last step I need is getting components of groups so that vSphere con
enforce group membership permission over user set.

The query from vsphere after my modifications when it searches for users
belonging to groups is sort of

ldapsearch -x -b "cn=groups,cn=compat,dc=localdomain,dc=local"
"(&(objectClass=groupOfUniqueNames)(uniqueMember=uid=gcecchi,cn=users,cn=compat,dc=localdomain,dc=local))"

so I provided ldif modification for cn=groups, cn=compat this way

schema-compat-entry-attribute: uniqueMember=%{member}

but this produces somthing like this when I query for example a created
group named esxpower to be used for power users

# esxpower, groups, compat, localdomain.local
dn: cn=esxpower,cn=groups,cn=compat,dc=localdomain,dc=local
objectClass: posixGroup
objectClass: groupOfUniqueNames
objectClass: top
gidNumber: 1639600006
memberUid: gcecchi
memberUid: vadmin
uniqueMember: uid=gcecchi,cn=users,cn=accounts,dc=localdomain,dc=local
uniqueMember: uid=vadmin,cn=users,cn=accounts,dc=localdomain,dc=local
cn: esxpower

so the problem is I have to change the entry
schema-compat-entry-attribute: uniqueMember=%{member}

with a sort of function that gives cn=compat instead of cn=accounts in the
line
uniqueMember: uid=gcecchi,cn=users,cn=accounts,dc=localdomain,dc=local

I read also /usr/share/doc/slapi-nis-0.52/format-specifiers.txt
but I didn't come to a sort of "substitute" function so that I can change
%{member} with the same but with "compat" word instead of "accounts"

I plan to detail all my steps once I can accomplish this.

Thanks in advance,

Gianluca
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141207/7be14fb4/attachment.htm>

From mrniranjan at redhat.com  Sun Dec  7 14:01:07 2014
From: mrniranjan at redhat.com (Niranjan M.R)
Date: Sun, 07 Dec 2014 19:31:07 +0530
Subject: [Freeipa-users] [Freeipa-interest] Announcing FreeIPA 4.1.2 -
 NEED HELP WITH 2FA/OTP!!!
In-Reply-To: <176433463.23902008.1417805679430.JavaMail.zimbra@redhat.com>
References: <54775877.6060102@redhat.com>
	<176433463.23902008.1417805679430.JavaMail.zimbra@redhat.com>
Message-ID: <54845DA3.3070104@redhat.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 12/06/2014 12:24 AM, Dmitri Pal wrote:
> Hello,
> 
> WE NEED HELP!
> 
> The biggest and the most interesting feature of FreeIPA 4.1.2 is support for the two factor authentication using HOTP/TOTP compatible software tokens like FreeOTP (open source compatible alternative to Google Authenticator) and hardware tokens like Yubikeys. This feature allows Kerberos and LDAP clients of a FreeIPA server to authenticate using the normal account password as the first factor and an OTP token as a second factor. For those environments where a 2FA solution is already in place, FreeIPA can act as a proxy via RADIUS. More about this feature can be read here.
> http://www.freeipa.org/page/V4/OTP
> 
> If you want to see this feature in downstream distros sooner rather than later we need your help!
> Please give it a try and provide feedback. We really, really need it!
I am unable to configure ipa-server with freeipa-server-4.1.2-1.fc20.x86_64,  ipa-server-install fails with below error:

Done configuring certificate server (pki-tomcatd).
Configuring directory server (dirsrv): Estimated time 10 seconds
  [1/3]: configuring ssl for ds instance
  [2/3]: restarting directory server
ipa         : CRITICAL Failed to restart the directory server ([Errno 2] No such file or directory:
'/etc/systemd/system/dirsrv.target.wants/dirsrv at EXAMPLE-ORG.service'). See the installation log for details.
  [3/3]: adding CA certificate entry
Done configuring directory server (dirsrv).
CA did not start in 300.0s


Versions used:
==============
freeipa-client-4.1.2-1.fc20.x86_64
freeipa-server-4.1.2-1.fc20.x86_64
libipa_hbac-1.12.2-2.fc20.x86_64
libipa_hbac-python-1.12.2-2.fc20.x86_64
sssd-ipa-1.12.2-2.fc20.x86_64
device-mapper-multipath-0.4.9-56.fc20.x86_64
python-iniparse-0.4-9.fc20.noarch
freeipa-admintools-4.1.2-1.fc20.x86_64
freeipa-python-4.1.2-1.fc20.x86_64
389-ds-base-libs-1.3.3.5-1.fc20.x86_64
389-ds-base-1.3.3.5-1.fc20.x86_64

BaseOS:Fedora release 20 (Heisenbug)


Steps to reproduce:
- ---------------

1. On Fedora-20 system, Used mkosek freeipa repo:
[mkosek-freeipa]
name=Copr repo for freeipa owned by mkosek
baseurl=http://copr-be.cloud.fedoraproject.org/results/mkosek/freeipa/fedora-$releasever-$basearch/
skip_if_unavailable=True
gpgcheck=0
enabled=1

2. Install freeipa-server packages from the above repo

3. Issue ipa-server-install

[root at pkiserver1 ~]# ipa-server-install

The log file for this installation can be found in /var/log/ipaserver-install.log
==============================================================================
This program will set up the FreeIPA Server.

This includes:
  * Configure a stand-alone CA (dogtag) for certificate management
  * Configure the Network Time Daemon (ntpd)
  * Create and configure an instance of Directory Server
  * Create and configure a Kerberos Key Distribution Center (KDC)
  * Configure Apache (httpd)

To accept the default shown in brackets, press the Enter key.

WARNING: conflicting time&date synchronization service 'chronyd' will be disabled
in favor of ntpd

Do you want to configure integrated DNS (BIND)? [no]: yes

Existing BIND configuration detected, overwrite? [no]: yes
Enter the fully qualified domain name of the computer
on which you're setting up server software. Using the form
<hostname>.<domainname>
Example: master.example.com.


Server host name [pkiserver1.example.org]:

Warning: skipping DNS resolution of host pkiserver1.example.org
The domain name has been determined based on the host name.

Please confirm the domain name [example.org]:

The kerberos protocol requires a Realm name to be defined.
This is typically the domain name converted to uppercase.

Please provide a realm name [EXAMPLE.ORG]:
Certain directory server operations require an administrative user.
This user is referred to as the Directory Manager and has full access
to the Directory for system management tasks and will be added to the

The IPA server requires an administrative user, named 'admin'.
This user is a regular system account used for IPA server administration.

IPA admin password:
Password (confirm):

Do you want to configure DNS forwarders? [yes]: no
No DNS forwarders configured
Do you want to configure the reverse zone? [yes]:
Please specify the reverse zone name [122.168.192.in-addr.arpa.]:
Using reverse zone(s) 122.168.192.in-addr.arpa.

The IPA Master Server will be configured with:
Hostname:       pkiserver1.example.org
IP address(es): 192.168.122.246
Domain name:    example.org
Realm name:     EXAMPLE.ORG

BIND DNS server will be configured to serve IPA domain with:
Forwarders:    No forwarders
Reverse zone(s):  122.168.192.in-addr.arpa.

Continue to configure the system with these values? [no]: yes

The following operations may take some minutes to complete.
Please wait until the prompt is returned.


instance of directory server created for IPA.
The password must be at least 8 characters long.

Directory Manager password:
Password (confirm):
Configuring NTP daemon (ntpd)
  [1/4]: stopping ntpd
  [2/4]: writing configuration
  [3/4]: configuring ntpd to start on boot
  [4/4]: starting ntpd
Done configuring NTP daemon (ntpd).
Configuring directory server (dirsrv): Estimated time 1 minute
  [1/38]: creating directory server user
  [2/38]: creating directory server instance
  [3/38]: adding default schema
  [4/38]: enabling memberof plugin
  [5/38]: enabling winsync plugin
  [6/38]: configuring replication version plugin
  [7/38]: enabling IPA enrollment plugin
  [8/38]: enabling ldapi
  [9/38]: configuring uniqueness plugin
  [10/38]: configuring uuid plugin
  [11/38]: configuring modrdn plugin
  [12/38]: configuring DNS plugin
  [13/38]: enabling entryUSN plugin
  [14/38]: configuring lockout plugin
  [15/38]: creating indices
  [16/38]: enabling referential integrity plugin
  [17/38]: configuring certmap.conf
  [18/38]: configure autobind for root
  [19/38]: configure new location for managed entries
  [20/38]: configure dirsrv ccache
  [21/38]: enable SASL mapping fallback
  [22/38]: restarting directory server
  [23/38]: adding default layout
  [24/38]: adding delegation layout
  [25/38]: creating container for managed entries
  [26/38]: configuring user private groups
  [27/38]: configuring netgroups from hostgroups
  [28/38]: creating default Sudo bind user
  [29/38]: creating default Auto Member layout
  [30/38]: adding range check plugin
  [31/38]: creating default HBAC rule allow_all
  [32/38]: initializing group membership
  [33/38]: adding master entry
  [34/38]: configuring Posix uid/gid generation
  [35/38]: adding replication acis
  [36/38]: enabling compatibility plugin
  [37/38]: tuning directory server
  [38/38]: configuring directory to start on boot
Done configuring directory server (dirsrv).
Configuring certificate server (pki-tomcatd): Estimated time 3 minutes 30 seconds
  [1/27]: creating certificate server user
  [2/27]: configuring certificate server instance
  [3/27]: stopping certificate server instance to update CS.cfg
  [4/27]: backing up CS.cfg
  [5/27]: disabling nonces
  [6/27]: set up CRL publishing
  [7/27]: enable PKIX certificate path discovery and validation
  [8/27]: starting certificate server instance
  [9/27]: creating RA agent certificate database
  [10/27]: importing CA chain to RA certificate database
  [11/27]: fixing RA database permissions
  [12/27]: setting up signing cert profile
  [13/27]: set certificate subject base
  [14/27]: enabling Subject Key Identifier
  [15/27]: enabling Subject Alternative Name
  [16/27]: enabling CRL and OCSP extensions for certificates
  [17/27]: setting audit signing renewal to 2 years
  [18/27]: configuring certificate server to start on boot
  [19/27]: restarting certificate server
  [20/27]: requesting RA certificate from CA
  [21/27]: issuing RA agent certificate
  [22/27]: adding RA agent as a trusted user
  [23/27]: configure certmonger for renewals
  [24/27]: configure certificate renewals
  [25/27]: configure RA certificate renewal
  [26/27]: configure Server-Cert certificate renewal
  [27/27]: Configure HTTP to proxy connections
Done configuring certificate server (pki-tomcatd).
Configuring directory server (dirsrv): Estimated time 10 seconds
  [1/3]: configuring ssl for ds instance
  [2/3]: restarting directory server
ipa         : CRITICAL Failed to restart the directory server ([Errno 2] No such file or directory:
'/etc/systemd/system/dirsrv.target.wants/dirsrv at EXAMPLE-ORG.service'). See the installation log for details.
  [3/3]: adding CA certificate entry
Done configuring directory server (dirsrv).

CA did not start in 300.0s

Attaching ipaserver-install.log, pkispawn logs

Any hints on how to overcome the above error.

> 
> 
> Thank you,
> FreeIPA development team
> 
> 
> 
> ----- Original Message -----
> From: "Petr Vobornik" <pvoborni at redhat.com>
> To: "freeipa-devel" <freeipa-devel at redhat.com>, "freeipa-users" <freeipa-users at redhat.com>, freeipa-interest at redhat.com
> Sent: Thursday, November 27, 2014 11:59:35 AM
> Subject: [Freeipa-interest] Announcing FreeIPA 4.1.2
> 
> The FreeIPA team would like to announce FreeIPA v4.1.2 security release!
> 
> It can be downloaded from http://www.freeipa.org/page/Downloads. The 
> builds will be available for Fedora 21. Builds for Fedora 20 are 
> available in the official COPR repository 
> [https://copr.fedoraproject.org/coprs/mkosek/freeipa/].
> 
> == Highlights in 4.1.2 ==
> 
> === Bug fixes ===
> * CVE-2014-7850: ensure that user input is properly escaped to prevent 
> XSS attacks [https://fedorahosted.org/freeipa/ticket/4742] 
> [http://www.freeipa.org/page/CVE-2014-7850]
> * harden mod_nss config on update to use TLSv1.0, TLSv1.1, TLSv1.2
> * fixed getkeytab operation 
> [https://fedorahosted.org/freeipa/ticket/4718] 
> [https://fedorahosted.org/freeipa/ticket/4728]
> * backup and restore fixes related to certificates restore and SELinux 
> context
> * static code analysis fixes
> * various small fixes
> 
> == Upgrading ==
> An IPA server can be upgraded simply by installing updated rpms. The 
> server does not need to be shut down in advance.
> 
> Please note that if you are doing the upgrade in special environment 
> (e.g. FedUp) which does not allow running the LDAP server during upgrade 
> process, upgrade scripts need to be run manually after the first boot:
> 
>   # ipa-ldap-updater --upgrade
>   # ipa-upgradeconfig
> 
> Also note that the performance improvements require an extended set of 
> indexes to be configured. RPM update for an IPA server with a excessive 
> number of users may require several minutes to finish.
> 
> If you have multiple servers you may upgrade them one at a time. It is 
> expected that all servers will be upgraded in a relatively short period 
> (days or weeks, not months). They should be able to co-exist peacefully 
> but new features will not be available on old servers and enrolling a 
> new client against an old server will result in the SSH keys not being 
> uploaded.
> 
> Downgrading a server once upgraded is not supported.
> 
> Upgrading from 3.3.0 and later versions is supported. Upgrading from 
> previous versions is not supported and has not been tested.
> 
> An enrolled client does not need the new packages installed unless you 
> want to re-enroll it. SSH keys for already installed clients are not 
> uploaded, you will have to re-enroll the client or manually upload the keys.
> 
> == 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.1.1 ==
> 
> === Alexander Bokovoy (2) ===
> * Update slapi-nis dependency to pull 0.54.1
> * AD trust: improve trust validation
> 
> === David Kupka (6) ===
> * Remove unneeded internal methods. Move code to public methods.
> * Remove service file even if it isn't link.
> * Produce better error in group-add command.
> * Fix --{user,group}-ignore-attribute in migration plugin.
> * ipa-restore: Check if directory is provided + better errors.
> * Fix error message for nonexistent members and add tests.
> 
> === Gabe Alford (1) ===
> * ipa-server-install Directory Manager help incorrect
> 
> === Jan Cholasta (15) ===
> * Fix CA certificate backup and restore
> * Update Requires on pki-ca to 10.2.1-0.1
> * Fix wrong expiration date on renewed IPA CA certificates
> * Restore file extended attributes and SELinux context in ipa-restore
> * Use correct service name in cainstance.backup_config
> * Stop tracking certificates before restoring them in ipa-restore
> * Remove redefinition of LOG from ipa-otp-lasttoken
> * Unload P11_Helper object's library when it is finalized in ipap11helper
> * Fix Kerberos error handling in ipa-sam
> * Fix unchecked return value in ipa-kdb
> * Fix unchecked return values in ipa-winsync
> * Fix unchecked return value in ipa-join
> * Fix unchecked return value in krb5 common utils
> * Fix memory leak in GetKeytabControl asn1 code
> * Add TLS 1.2 to the protocol list in mod_nss config
> 
> === Martin Ba?ti (12) ===
> * Fix: DNS installer adds invalid zonemgr email
> * Fix: DNS policy upgrade raises asertion error
> * Fix upgrade referint plugin
> * Upgrade: fix trusts objectclass violationi
> * Fix named working directory permissions
> * Fix: zonemgr must be unicode value
> * Fix warning message should not contain CLI commands
> * Show warning instead of error if CA did not start
> * Raise right exception if domain name is not valid
> * Fix pk11helper module compiler warnings
> * Fix: read_ip_addresses should return ipaddr object
> * Fix detection of encoding in zonemgr option
> 
> === Martin Ko?ek (1) ===
> * Lower pki-ca requires to 10.1.2
> 
> === Nathaniel McCallum (3) ===
> * Improve otptoken help messages
> * Ensure users exist when assigning tokens to them
> * Enable QR code display by default in otptoken-add
> 
> === Petr Viktorin (5) ===
> * ipa-restore: Don't crash if AD trust is not installed
> * ipaplatform: Use the dirsrv service, not target
> * Do not restore SELinux settings that were not backed up
> * Add additional backup & restore checks
> * copy_schema_to_ca: Fallback to old import location for 
> ipaplatform.services
> 
> === Petr Voborn?k (9) ===
> * ranges: prohibit setting --rid-base with ipa-trust-ad-posix type
> * unittests: baserid for ipa-ad-trust-posix idranges
> * ldapupdater: set baserid to 0 for ipa-ad-trust-posix ranges
> * idrange: include raw range type in output
> * webui: prohibit setting rid base with ipa-trust-ad-posix type
> * webui: fix potential XSS vulnerabilities
> * restore: clear httpd ccache after restore
> * webui: use domain name instead of domain SID in idrange adder dialog
> * webui: normalize idview tab labels
> 
> === Petr ?pa?ek (1) ===
> * Fix minimal version of BIND for Fedora 20 and 21
> 
> === Rob Crittenden (2) ===
> * Search using proper scope when connecting CA instances
> * Use NSS protocol range API to set available TLS protocols
> 
> === Simo Sorce (4) ===
> * Add UTC date to GIT snapshot version generation
> * Fix filtering of enctypes in server code.
> * Add asn1c generated code for keytab controls
> * Use asn1c helpers to encode/decode the getkeytab control
> 
> === Thorsten Scherf (1) ===
> * Add help string on how to configure multiple DNS forwards for various 
> cli tools
> 


- -- 
Niranjan
irc: mrniranjan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iKYEARECAGYFAlSEXaNfFIAAAAAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl
bnBncC5maWZ0aGhvcnNlbWFuLm5ldEY3OTE3QTg3ODE0RkVCQ0YyNjgyOTRENjJF
RURDNTVGNjA0N0M3QzcACgkQLu3FX2BHx8cstACgwILDx03m5R3g+ZMopuA9qdd6
seMAoLN1Bh8LvYsZZQr1AKFbgNAqN2rq
=Zfro
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ipa-logs.tar.gz
Type: application/x-gzip
Size: 140374 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141207/bfea62ba/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x6047C7C7.asc
Type: application/pgp-keys
Size: 1893 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141207/bfea62ba/attachment-0001.bin>

From gianluca.cecchi at gmail.com  Sun Dec  7 18:29:27 2014
From: gianluca.cecchi at gmail.com (Gianluca Cecchi)
Date: Sun, 7 Dec 2014 19:29:27 +0100
Subject: [Freeipa-users] one step away from having freeipa work with
	vsphere ldap
In-Reply-To: <CAG2kNCyKOiD69pfiu9ZqAifjBKeUoCJTpK9C_H=hDURdbAcn9w@mail.gmail.com>
References: <CAG2kNCyKOiD69pfiu9ZqAifjBKeUoCJTpK9C_H=hDURdbAcn9w@mail.gmail.com>
Message-ID: <CAG2kNCwBXz-58cDnSuYqyF9fvkrd-T7-CdjR9GsLtc5_L_X-uA@mail.gmail.com>

On Sun, Dec 7, 2014 at 3:44 PM, Gianluca Cecchi <gianluca.cecchi at gmail.com>
wrote:

> Hello,
> I'm quite near to have users and groups working using ipa 3.3 as in CentOS
> 7 as this gives ability to do binds against compat tree.
> This is with the use of schema compatibility
>
> The last step I need is getting components of groups so that vSphere con
> enforce group membership permission over user set.
>
> The query from vsphere after my modifications when it searches for users
> belonging to groups is sort of
>
> ldapsearch -x -b "cn=groups,cn=compat,dc=localdomain,dc=local"
> "(&(objectClass=groupOfUniqueNames)(uniqueMember=uid=gcecchi,cn=users,cn=compat,dc=localdomain,dc=local))"
>
> so I provided ldif modification for cn=groups, cn=compat this way
>
> schema-compat-entry-attribute: uniqueMember=%{member}
>
> but this produces somthing like this when I query for example a created
> group named esxpower to be used for power users
>
> # esxpower, groups, compat, localdomain.local
> dn: cn=esxpower,cn=groups,cn=compat,dc=localdomain,dc=local
> objectClass: posixGroup
> objectClass: groupOfUniqueNames
> objectClass: top
> gidNumber: 1639600006
> memberUid: gcecchi
> memberUid: vadmin
> uniqueMember: uid=gcecchi,cn=users,cn=accounts,dc=localdomain,dc=local
> uniqueMember: uid=vadmin,cn=users,cn=accounts,dc=localdomain,dc=local
> cn: esxpower
>
> so the problem is I have to change the entry
> schema-compat-entry-attribute: uniqueMember=%{member}
>
> with a sort of function that gives cn=compat instead of cn=accounts in the
> line
> uniqueMember: uid=gcecchi,cn=users,cn=accounts,dc=localdomain,dc=local
>
> I read also /usr/share/doc/slapi-nis-0.52/format-specifiers.txt
> but I didn't come to a sort of "substitute" function so that I can change
> %{member} with the same but with "compat" word instead of "accounts"
>
> I plan to detail all my steps once I can accomplish this.
>
> Thanks in advance,
>
> Gianluca
>
>

Tried with
schema-compat-entry-attribute:
uniqueMember=%regsub("%{member}","^(.*)accounts(.*)","%1compat%2")

but it seems it works with some groups (the system groups) but not with the
other ones I have created...

ldapsearch -x -b "cn=groups,cn=compat,dc=localdomain,dc=local"

gives

# admins, groups, compat, localdomain.local
dn: cn=admins,cn=groups,cn=compat,dc=localdomain,dc=local
objectClass: posixGroup
objectClass: groupOfUniqueNames
objectClass: top
gidNumber: 1639600000
memberUid: admin
uniqueMember: uid=admin,cn=users,cn=compat,dc=localdomain,dc=local
cn: admins


but in esxpower group I see only the memberUid entry and not the
uniqueMember entry

# esxpower, groups, compat, localdomain.local
dn: cn=esxpower,cn=groups,cn=compat,dc=localdomain,dc=local
objectClass: posixGroup
objectClass: groupOfUniqueNames
objectClass: top
gidNumber: 1639600006
memberUid: gcecchi
memberUid: vadmin
cn: esxpower

Gianluca
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141207/d344cb9d/attachment.htm>

From matthew.herzog at gmail.com  Sun Dec  7 23:44:45 2014
From: matthew.herzog at gmail.com (Matthew Herzog)
Date: Sun, 7 Dec 2014 18:44:45 -0500
Subject: [Freeipa-users] DNS configuration
In-Reply-To: <547ECDDC.3090001@redhat.com>
References: <CABhyZ34TCzUz+fNUSCvdZ38MS7rsLMMdb_jTdfKUsmYs86fn_Q@mail.gmail.com>
	<547DEA9E.2030203@redhat.com> <547DEFB5.1020205@redhat.com>
	<CABhyZ347EU+Q85jQJGU30yx4njC3OtL_QsJZi1MMu1ZR2Lfd2Q@mail.gmail.com>
	<547E851C.1020407@redhat.com> <547ECDDC.3090001@redhat.com>
Message-ID: <CABhyZ37XChaQF+4rRY-L=OU9pVNp7Mw_NQifTk3NhrewzJtyVQ@mail.gmail.com>

Thanks guys. I'm sorry for my delay in responding.

Firstly, I was under the impression (from reading the docs) that having
named running on IPA server was critical.
Also, the first question the ipa-server-install script asks is, "Do you
want to configure integrated DNS (BIND)? ." While it's true the default
answer is no, it leads one to believe that DNS is central to IPA. Also the
ipa-client-install script says,

[root at freeipa-poc-client02 ~]# ipa-client-install
DNS discovery failed to determine your DNS domain
Provide the domain name of your IPA server (ex: example.com):

I can resolve -anything- from the machine using dig or whatever.

Ultimately, the reason I started to be concerned about my IPA server's DNS
config was because I was not able to authenticate AD accounts to a client
machine. I saw a bunch of errors in the client's sssd logs which of course
I can't find now.

Perhaps it was these . . .

(Thu Dec  4 13:45:23 2014) [sssd] [ping_check] (0x0100): Service nss
replied to ping
(Thu Dec  4 13:45:23 2014) [sssd] [ping_check] (0x0100): Service sudo
replied to ping
(Thu Dec  4 13:45:23 2014) [sssd] [ping_check] (0x0100): Service pam
replied to ping
(Thu Dec  4 13:45:23 2014) [sssd] [ping_check] (0x0100): Service ssh
replied to ping
(Thu Dec  4 13:45:23 2014) [sssd] [ping_check] (0x0100): Service pac
replied to ping
(Thu Dec  4 13:45:23 2014) [sssd] [ping_check] (0x0100): Service
bo3.e-bozo.com replied to ping

I'm not allowed onto the AD domain controllers to examine log files or I'd
be checking those first.

So ultimately the goal is to authenticate AD users and users that exist in
our ldap schema. We need to set up groups of users that can run sudo
commands on specific groups of hosts.



On Wed, Dec 3, 2014 at 3:46 AM, Petr Spacek <pspacek at redhat.com> wrote:

> On 3.12.2014 04:35, Dmitri Pal wrote:
> > On 12/02/2014 08:54 PM, Matthew Herzog wrote:
> >> Any other ideas? I just spun up a new VM and took the defaults on
> everything
> >> while running ipa-server-install (the defaults did make sense) and my
> new VM
> >> can't resolve -anything- in the domain in which it lives. The "old" VM
> >> (running the same versions of everything on the same OS) can't even
> resolve
> >> the clients I have registered with it!
> >>
> >> So I'm pretty frustrated and am wondering, what _exactly_ is the role of
> >> bind in the IPA server and how is it expected to know anything about the
> >> local DNS domain without becoming a bind slave server?
> >
> > I am not sure I am 100% with you but...
> > If you use the defaults and nothing else you get to the scenario when
> IPA has
> > its DNS but it is a self contained environment. It seems that this is
> what you
> > observe.
> > It is expected that you decide in advance what you want to do with DNS.
> There
> > are several options:
> > 1) You can delegate a zone to IPA to manage, then you need to connect
> your IPA
> > DNS to your existing DNS during install or after.
> > In this case the systems joined to IPA will be a part of IPA domain/zone
> and
> > would also be able to resolve other systems around
> > 2) Not use IPA DNS if you do not want to take advantage of it
> > 3) Have a self contained demo/lab environment that you currently observe.
> >
> > What is the intent?
>
> I agree with Dmitri, we need more information from you:
> - You said "my new VM can't resolve -anything- in the domain in which it
> lives." - Which domain do you mean?
>
> - Apparently you have configured FreeIPA to serve zone e-bozo.com. Do you
> have
> this zone configured on some other DNS server at the same time?
>
> Please keep in mind that authoritative servers should share the database.
> You
> will get naming collisions if e-bozo.com is served by FreeIPA DNS servers
> and
> some other servers at the same time. Maybe that is the problem you see
> right now.
>
> As Dmitri said, the architecturally correct solution is to decide if you
> want
> to use FreeIPA DNS or not. You have option to either remove non-FreeIPA DNS
> servers and import data to FreeIPA or to add FreeIPA-specific DNS records
> to
> existing DNS servers and do not configure FreeIPA to act as DNS server.
>
> Petr^2 Spacek
>
> >> Thanks.
> >>
> >> On Tue, Dec 2, 2014 at 11:58 AM, Petr Spacek <pspacek at redhat.com
> >> <mailto:pspacek at redhat.com>> wrote:
> >>
> >>     On 2.12.2014 17:36, Martin Basti wrote:
> >>     > On 02/12/14 17:28, Matthew Herzog wrote:
> >>     >> I just realized that my IPA servers cannot resolve ANY servers
> >>     in my domain.
> >>     >> What do I need to do to fix this? Below is my named.conf.
> >>     >>
> >>     >>
> >>     >> options {
> >>     >>         // turns on IPv6 for port 53, IPv4 is on by default for
> >>     all ifaces
> >>     >>         listen-on-v6 {any;};
> >>     >>
> >>     >>         // Put files that named is allowed to write in the
> >>     data/ directory:
> >>     >>         directory "/var/named"; // the default
> >>     >>         dump-file  "data/cache_dump.db";
> >>     >>         statistics-file  "data/named_stats.txt";
> >>     >>         memstatistics-file "data/named_mem_stats.txt";
> >>     >>
> >>     >>         forward first;
> >>     >>         forwarders {
> >>     >>                 10.100.8.41;
> >>     >>                 10.100.8.40;
> >>     >>                 10.100.4.13;
> >>     >>                 10.100.4.14;
> >>     >>                 10.100.4.19;
> >>     >>                 10.100.4.44;
> >>     >>         };
> >>     >>
> >>     >>         // Any host is permitted to issue recursive queries
> >>     >>         allow-recursion { any; };
> >>     >>
> >>     >>         tkey-gssapi-keytab "/etc/named.keytab";
> >>     >>         pid-file "/run/named/named.pid";
> >>     >> };
> >>     >>
> >>     >> /* If you want to enable debugging, eg. using the 'rndc trace'
> >>     command,
> >>     >>  * By default, SELinux policy does not allow named to modify
> >>     the /var/named
> >>     >> directory,
> >>     >>  * so put the default debug log file in data/ :
> >>     >>  */
> >>     >> logging {
> >>     >>         channel default_debug {
> >>     >>                 file "data/named.run";
> >>     >>                 severity dynamic;
> >>     >>                 print-time yes;
> >>     >>         };
> >>     >>         };
> >>     >> };
> >>     >>
> >>     >> zone "." IN {
> >>     >>         type hint;
> >>     >>         file "named.ca <http://named.ca> <http://named.ca>";
> >>     >> };
> >>     >>
> >>     >> include "/etc/named.rfc1912.zones";
> >>     >>
> >>     >> dynamic-db "ipa" {
> >>     >>         library "ldap.so";
> >>     >>         arg "uri
> >>     ldapi://%2fvar%2frun%2fslapd-BO3-E-BOZO-COM.socket";
> >>     >>         arg "base cn=dns, dc=bo3,dc=e-bozo,dc=com";
> >>     >>         arg "fake_mname freeipa-poc01.bo3.e-bozo.com
> >>     <http://freeipa-poc01.bo3.e-bozo.com>
> >>     >> <http://freeipa-poc01.bo3.e-bozo.com>.";
> >>     >>         arg "auth_method sasl";
> >>     >>         arg "sasl_mech GSSAPI";
> >>     >>         arg "sasl_user DNS/freeipa-poc01.bo3.e-bozo.com
> >>     <http://freeipa-poc01.bo3.e-bozo.com>
> >>     >> <http://freeipa-poc01.bo3.e-bozo.com>";
> >>     >>         arg "serial_autoincrement yes";
> >>     >> };
> >>     >>
> >>     >>
> >>     >>
> >>     >>
> >>     > Hello,
> >>     >
> >>     > which version ipa do you use? which platform? Which version
> >>     bind-dyndb-ldap?
> >>     >
> >>     > Can you run these commands, and check if there any errors?
> >>     > ipactl status
> >>     > systemctl status named  (respectively journalctl -u named)
> >>
> >>     We also may want to see information listed on page
> >>     https://fedorahosted.org/bind-dyndb-ldap/wiki/BugReporting
>
> --
> 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
>



-- 
If life gives you melons, you may be dyslexic.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141207/5397712c/attachment.htm>

From dpal at redhat.com  Mon Dec  8 02:44:30 2014
From: dpal at redhat.com (Dmitri Pal)
Date: Sun, 07 Dec 2014 21:44:30 -0500
Subject: [Freeipa-users] DNS configuration
In-Reply-To: <CABhyZ37XChaQF+4rRY-L=OU9pVNp7Mw_NQifTk3NhrewzJtyVQ@mail.gmail.com>
References: <CABhyZ34TCzUz+fNUSCvdZ38MS7rsLMMdb_jTdfKUsmYs86fn_Q@mail.gmail.com>	<547DEA9E.2030203@redhat.com>
	<547DEFB5.1020205@redhat.com>	<CABhyZ347EU+Q85jQJGU30yx4njC3OtL_QsJZi1MMu1ZR2Lfd2Q@mail.gmail.com>	<547E851C.1020407@redhat.com>
	<547ECDDC.3090001@redhat.com>
	<CABhyZ37XChaQF+4rRY-L=OU9pVNp7Mw_NQifTk3NhrewzJtyVQ@mail.gmail.com>
Message-ID: <5485108E.60409@redhat.com>

On 12/07/2014 06:44 PM, Matthew Herzog wrote:
> Thanks guys. I'm sorry for my delay in responding.
>
> Firstly, I was under the impression (from reading the docs) that 
> having named running on IPA server was critical.

Properly configured DNS is critical.
How you accomplish it is up to you.
IPA allows you to have a DNS server that would simplify DNS management 
but it can be done manually too. This is why DNS is optional.


> Also, the first question the ipa-server-install script asks is, "Do 
> you want to configure integrated DNS (BIND)? ." While it's true the 
> default answer is no, it leads one to believe that DNS is central to 
> IPA. Also the ipa-client-install script says,
>
> [root at freeipa-poc-client02 ~]# ipa-client-install
> DNS discovery failed to determine your DNS domain
> Provide the domain name of your IPA server (ex: example.com 
> <http://example.com>):
>
> I can resolve -anything- from the machine using dig or whatever.
>
> Ultimately, the reason I started to be concerned about my IPA server's 
> DNS config was because I was not able to authenticate AD accounts to a 
> client machine. I saw a bunch of errors in the client's sssd logs 
> which of course I can't find now.
>
> Perhaps it was these . . .
>
> (Thu Dec  4 13:45:23 2014) [sssd] [ping_check] (0x0100): Service nss 
> replied to ping
> (Thu Dec  4 13:45:23 2014) [sssd] [ping_check] (0x0100): Service sudo 
> replied to ping
> (Thu Dec  4 13:45:23 2014) [sssd] [ping_check] (0x0100): Service pam 
> replied to ping
> (Thu Dec  4 13:45:23 2014) [sssd] [ping_check] (0x0100): Service ssh 
> replied to ping
> (Thu Dec  4 13:45:23 2014) [sssd] [ping_check] (0x0100): Service pac 
> replied to ping
> (Thu Dec  4 13:45:23 2014) [sssd] [ping_check] (0x0100): Service 
> bo3.e-bozo.com <http://bo3.e-bozo.com> replied to ping
>
> I'm not allowed onto the AD domain controllers to examine log files or 
> I'd be checking those first.
>
> So ultimately the goal is to authenticate AD users and users that 
> exist in our ldap schema. We need to set up groups of users that can 
> run sudo commands on specific groups of hosts.

Did you setup trusts as explained on the following page?
http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup

>
>
>
> On Wed, Dec 3, 2014 at 3:46 AM, Petr Spacek <pspacek at redhat.com 
> <mailto:pspacek at redhat.com>> wrote:
>
>     On 3.12.2014 04:35, Dmitri Pal wrote:
>     > On 12/02/2014 08:54 PM, Matthew Herzog wrote:
>     >> Any other ideas? I just spun up a new VM and took the defaults
>     on everything
>     >> while running ipa-server-install (the defaults did make sense)
>     and my new VM
>     >> can't resolve -anything- in the domain in which it lives. The
>     "old" VM
>     >> (running the same versions of everything on the same OS) can't
>     even resolve
>     >> the clients I have registered with it!
>     >>
>     >> So I'm pretty frustrated and am wondering, what _exactly_ is
>     the role of
>     >> bind in the IPA server and how is it expected to know anything
>     about the
>     >> local DNS domain without becoming a bind slave server?
>     >
>     > I am not sure I am 100% with you but...
>     > If you use the defaults and nothing else you get to the scenario
>     when IPA has
>     > its DNS but it is a self contained environment. It seems that
>     this is what you
>     > observe.
>     > It is expected that you decide in advance what you want to do
>     with DNS. There
>     > are several options:
>     > 1) You can delegate a zone to IPA to manage, then you need to
>     connect your IPA
>     > DNS to your existing DNS during install or after.
>     > In this case the systems joined to IPA will be a part of IPA
>     domain/zone and
>     > would also be able to resolve other systems around
>     > 2) Not use IPA DNS if you do not want to take advantage of it
>     > 3) Have a self contained demo/lab environment that you currently
>     observe.
>     >
>     > What is the intent?
>
>     I agree with Dmitri, we need more information from you:
>     - You said "my new VM can't resolve -anything- in the domain in
>     which it
>     lives." - Which domain do you mean?
>
>     - Apparently you have configured FreeIPA to serve zone e-bozo.com
>     <http://e-bozo.com>. Do you have
>     this zone configured on some other DNS server at the same time?
>
>     Please keep in mind that authoritative servers should share the
>     database. You
>     will get naming collisions if e-bozo.com <http://e-bozo.com> is
>     served by FreeIPA DNS servers and
>     some other servers at the same time. Maybe that is the problem you
>     see right now.
>
>     As Dmitri said, the architecturally correct solution is to decide
>     if you want
>     to use FreeIPA DNS or not. You have option to either remove
>     non-FreeIPA DNS
>     servers and import data to FreeIPA or to add FreeIPA-specific DNS
>     records to
>     existing DNS servers and do not configure FreeIPA to act as DNS
>     server.
>
>     Petr^2 Spacek
>
>     >> Thanks.
>     >>
>     >> On Tue, Dec 2, 2014 at 11:58 AM, Petr Spacek
>     <pspacek at redhat.com <mailto:pspacek at redhat.com>
>     >> <mailto:pspacek at redhat.com <mailto:pspacek at redhat.com>>> wrote:
>     >>
>     >>     On 2.12.2014 17:36, Martin Basti wrote:
>     >>     > On 02/12/14 17:28, Matthew Herzog wrote:
>     >>     >> I just realized that my IPA servers cannot resolve ANY
>     servers
>     >>     in my domain.
>     >>     >> What do I need to do to fix this? Below is my named.conf.
>     >>     >>
>     >>     >>
>     >>     >> options {
>     >>     >>         // turns on IPv6 for port 53, IPv4 is on by
>     default for
>     >>     all ifaces
>     >>     >>         listen-on-v6 {any;};
>     >>     >>
>     >>     >>         // Put files that named is allowed to write in the
>     >>     data/ directory:
>     >>     >>         directory "/var/named"; // the default
>     >>     >>         dump-file "data/cache_dump.db";
>     >>     >>         statistics-file "data/named_stats.txt";
>     >>     >>         memstatistics-file "data/named_mem_stats.txt";
>     >>     >>
>     >>     >>         forward first;
>     >>     >>         forwarders {
>     >>     >>                 10.100.8.41;
>     >>     >>                 10.100.8.40;
>     >>     >>                 10.100.4.13;
>     >>     >>                 10.100.4.14;
>     >>     >>                 10.100.4.19;
>     >>     >>                 10.100.4.44;
>     >>     >>         };
>     >>     >>
>     >>     >>         // Any host is permitted to issue recursive queries
>     >>     >>         allow-recursion { any; };
>     >>     >>
>     >>     >>         tkey-gssapi-keytab "/etc/named.keytab";
>     >>     >>         pid-file "/run/named/named.pid";
>     >>     >> };
>     >>     >>
>     >>     >> /* If you want to enable debugging, eg. using the 'rndc
>     trace'
>     >>     command,
>     >>     >>  * By default, SELinux policy does not allow named to modify
>     >>     the /var/named
>     >>     >> directory,
>     >>     >>  * so put the default debug log file in data/ :
>     >>     >>  */
>     >>     >> logging {
>     >>     >>         channel default_debug {
>     >>     >>                 file "data/named.run";
>     >>     >>                 severity dynamic;
>     >>     >>                 print-time yes;
>     >>     >>         };
>     >>     >>         };
>     >>     >> };
>     >>     >>
>     >>     >> zone "." IN {
>     >>     >>         type hint;
>     >>     >>         file "named.ca <http://named.ca>
>     <http://named.ca> <http://named.ca>";
>     >>     >> };
>     >>     >>
>     >>     >> include "/etc/named.rfc1912.zones";
>     >>     >>
>     >>     >> dynamic-db "ipa" {
>     >>     >>         library "ldap.so";
>     >>     >>         arg "uri
>     >>  ldapi://%2fvar%2frun%2fslapd-BO3-E-BOZO-COM.socket";
>     >>     >>         arg "base cn=dns, dc=bo3,dc=e-bozo,dc=com";
>     >>     >>         arg "fake_mname freeipa-poc01.bo3.e-bozo.com
>     <http://freeipa-poc01.bo3.e-bozo.com>
>     >>     <http://freeipa-poc01.bo3.e-bozo.com>
>     >>     >> <http://freeipa-poc01.bo3.e-bozo.com>.";
>     >>     >>         arg "auth_method sasl";
>     >>     >>         arg "sasl_mech GSSAPI";
>     >>     >>         arg "sasl_user DNS/freeipa-poc01.bo3.e-bozo.com
>     <http://freeipa-poc01.bo3.e-bozo.com>
>     >>     <http://freeipa-poc01.bo3.e-bozo.com>
>     >>     >> <http://freeipa-poc01.bo3.e-bozo.com>";
>     >>     >>         arg "serial_autoincrement yes";
>     >>     >> };
>     >>     >>
>     >>     >>
>     >>     >>
>     >>     >>
>     >>     > Hello,
>     >>     >
>     >>     > which version ipa do you use? which platform? Which version
>     >>     bind-dyndb-ldap?
>     >>     >
>     >>     > Can you run these commands, and check if there any errors?
>     >>     > ipactl status
>     >>     > systemctl status named  (respectively journalctl -u named)
>     >>
>     >>     We also may want to see information listed on page
>     >> https://fedorahosted.org/bind-dyndb-ldap/wiki/BugReporting
>
>     --
>     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
>
>
>
>
> -- 
> If life gives you melons, you may be dyslexic.
>
>


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141207/b872b820/attachment.htm>

From dpal at redhat.com  Mon Dec  8 02:57:09 2014
From: dpal at redhat.com (Dmitri Pal)
Date: Sun, 07 Dec 2014 21:57:09 -0500
Subject: [Freeipa-users] DNS configuration
In-Reply-To: <CABhyZ36DDM6icM+haMbVErdVdDWonGqbPE+3Tpad4K=u9QHjAQ@mail.gmail.com>
References: <CABhyZ34TCzUz+fNUSCvdZ38MS7rsLMMdb_jTdfKUsmYs86fn_Q@mail.gmail.com>	<547DEA9E.2030203@redhat.com>	<547DEFB5.1020205@redhat.com>	<CABhyZ347EU+Q85jQJGU30yx4njC3OtL_QsJZi1MMu1ZR2Lfd2Q@mail.gmail.com>	<547E851C.1020407@redhat.com>	<547ECDDC.3090001@redhat.com>	<CABhyZ37XChaQF+4rRY-L=OU9pVNp7Mw_NQifTk3NhrewzJtyVQ@mail.gmail.com>	<5485108E.60409@redhat.com>
	<CABhyZ36DDM6icM+haMbVErdVdDWonGqbPE+3Tpad4K=u9QHjAQ@mail.gmail.com>
Message-ID: <54851385.3050709@redhat.com>

On 12/07/2014 09:51 PM, Matthew Herzog wrote:
> What must be done in or on the ipa server with regard to DNS, if 
> anything?
>
> Our DNS works. It works well. We have four Linux DNS servers and two 
> AD domain controllers that also do DNS.
>
> So if we already have DNS working well in our domain, why do we want 
> to manage DNS in IPA?

Let us keep the discussion on the list.
IPA when used with AD trust presents itself as a separate forest. AD 
thinks that it is working with another AD forest.
For that to work we need to follow MSFT rules about relationship between 
Kerberos realm and DNS domain.
AD assumes that for every trusted forest Kerberos realm = DNS domain. 
IPA makes it easy to do because it has integrated tools to manage IPA 
DNS domain.
If you want to manage it yourself through your DNS you can do it, just 
more manual operations for you.

HTH

Thanks
Dmitri

>
> On Sun, Dec 7, 2014 at 9:44 PM, Dmitri Pal <dpal at redhat.com 
> <mailto:dpal at redhat.com>> wrote:
>
>     On 12/07/2014 06:44 PM, Matthew Herzog wrote:
>>     Thanks guys. I'm sorry for my delay in responding.
>>
>>     Firstly, I was under the impression (from reading the docs) that
>>     having named running on IPA server was critical.
>
>     Properly configured DNS is critical.
>     How you accomplish it is up to you.
>     IPA allows you to have a DNS server that would simplify DNS
>     management but it can be done manually too. This is why DNS is
>     optional.
>
>
>>     Also, the first question the ipa-server-install script asks is,
>>     "Do you want to configure integrated DNS (BIND)? ." While it's
>>     true the default answer is no, it leads one to believe that DNS
>>     is central to IPA. Also the ipa-client-install script says,
>>
>>     [root at freeipa-poc-client02 ~]# ipa-client-install
>>     DNS discovery failed to determine your DNS domain
>>     Provide the domain name of your IPA server (ex: example.com
>>     <http://example.com>):
>>
>>     I can resolve -anything- from the machine using dig or whatever.
>>
>>     Ultimately, the reason I started to be concerned about my IPA
>>     server's DNS config was because I was not able to authenticate AD
>>     accounts to a client machine. I saw a bunch of errors in the
>>     client's sssd logs which of course I can't find now.
>>
>>     Perhaps it was these . . .
>>
>>     (Thu Dec  4 13:45:23 2014) [sssd] [ping_check] (0x0100): Service
>>     nss replied to ping
>>     (Thu Dec  4 13:45:23 2014) [sssd] [ping_check] (0x0100): Service
>>     sudo replied to ping
>>     (Thu Dec  4 13:45:23 2014) [sssd] [ping_check] (0x0100): Service
>>     pam replied to ping
>>     (Thu Dec  4 13:45:23 2014) [sssd] [ping_check] (0x0100): Service
>>     ssh replied to ping
>>     (Thu Dec  4 13:45:23 2014) [sssd] [ping_check] (0x0100): Service
>>     pac replied to ping
>>     (Thu Dec  4 13:45:23 2014) [sssd] [ping_check] (0x0100): Service
>>     bo3.e-bozo.com <http://bo3.e-bozo.com> replied to ping
>>
>>     I'm not allowed onto the AD domain controllers to examine log
>>     files or I'd be checking those first.
>>
>>     So ultimately the goal is to authenticate AD users and users that
>>     exist in our ldap schema. We need to set up groups of users that
>>     can run sudo commands on specific groups of hosts.
>
>     Did you setup trusts as explained on the following page?
>     http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup
>
>
>>
>>
>>
>>     On Wed, Dec 3, 2014 at 3:46 AM, Petr Spacek <pspacek at redhat.com
>>     <mailto:pspacek at redhat.com>> wrote:
>>
>>         On 3.12.2014 04:35, Dmitri Pal wrote:
>>         > On 12/02/2014 08:54 PM, Matthew Herzog wrote:
>>         >> Any other ideas? I just spun up a new VM and took the
>>         defaults on everything
>>         >> while running ipa-server-install (the defaults did make
>>         sense) and my new VM
>>         >> can't resolve -anything- in the domain in which it lives.
>>         The "old" VM
>>         >> (running the same versions of everything on the same OS)
>>         can't even resolve
>>         >> the clients I have registered with it!
>>         >>
>>         >> So I'm pretty frustrated and am wondering, what _exactly_
>>         is the role of
>>         >> bind in the IPA server and how is it expected to know
>>         anything about the
>>         >> local DNS domain without becoming a bind slave server?
>>         >
>>         > I am not sure I am 100% with you but...
>>         > If you use the defaults and nothing else you get to the
>>         scenario when IPA has
>>         > its DNS but it is a self contained environment. It seems
>>         that this is what you
>>         > observe.
>>         > It is expected that you decide in advance what you want to
>>         do with DNS. There
>>         > are several options:
>>         > 1) You can delegate a zone to IPA to manage, then you need
>>         to connect your IPA
>>         > DNS to your existing DNS during install or after.
>>         > In this case the systems joined to IPA will be a part of
>>         IPA domain/zone and
>>         > would also be able to resolve other systems around
>>         > 2) Not use IPA DNS if you do not want to take advantage of it
>>         > 3) Have a self contained demo/lab environment that you
>>         currently observe.
>>         >
>>         > What is the intent?
>>
>>         I agree with Dmitri, we need more information from you:
>>         - You said "my new VM can't resolve -anything- in the domain
>>         in which it
>>         lives." - Which domain do you mean?
>>
>>         - Apparently you have configured FreeIPA to serve zone
>>         e-bozo.com <http://e-bozo.com>. Do you have
>>         this zone configured on some other DNS server at the same time?
>>
>>         Please keep in mind that authoritative servers should share
>>         the database. You
>>         will get naming collisions if e-bozo.com <http://e-bozo.com>
>>         is served by FreeIPA DNS servers and
>>         some other servers at the same time. Maybe that is the
>>         problem you see right now.
>>
>>         As Dmitri said, the architecturally correct solution is to
>>         decide if you want
>>         to use FreeIPA DNS or not. You have option to either remove
>>         non-FreeIPA DNS
>>         servers and import data to FreeIPA or to add FreeIPA-specific
>>         DNS records to
>>         existing DNS servers and do not configure FreeIPA to act as
>>         DNS server.
>>
>>         Petr^2 Spacek
>>
>>         >> Thanks.
>>         >>
>>         >> On Tue, Dec 2, 2014 at 11:58 AM, Petr Spacek
>>         <pspacek at redhat.com <mailto:pspacek at redhat.com>
>>         >> <mailto:pspacek at redhat.com <mailto:pspacek at redhat.com>>>
>>         wrote:
>>         >>
>>         >>     On 2.12.2014 17:36, Martin Basti wrote:
>>         >>     > On 02/12/14 17:28, Matthew Herzog wrote:
>>         >>     >> I just realized that my IPA servers cannot resolve
>>         ANY servers
>>         >>     in my domain.
>>         >>     >> What do I need to do to fix this? Below is my
>>         named.conf.
>>         >>     >>
>>         >>     >>
>>         >>     >> options {
>>         >>     >>         // turns on IPv6 for port 53, IPv4 is on by
>>         default for
>>         >>     all ifaces
>>         >>     >>         listen-on-v6 {any;};
>>         >>     >>
>>         >>     >>         // Put files that named is allowed to write
>>         in the
>>         >>     data/ directory:
>>         >>     >>         directory "/var/named"; // the default
>>         >>     >>         dump-file "data/cache_dump.db";
>>         >>     >>  statistics-file  "data/named_stats.txt";
>>         >>     >>  memstatistics-file "data/named_mem_stats.txt";
>>         >>     >>
>>         >>     >>         forward first;
>>         >>     >>         forwarders {
>>         >>     >>  10.100.8.41;
>>         >>     >>  10.100.8.40;
>>         >>     >>  10.100.4.13;
>>         >>     >>  10.100.4.14;
>>         >>     >>  10.100.4.19;
>>         >>     >>  10.100.4.44;
>>         >>     >>         };
>>         >>     >>
>>         >>     >>         // Any host is permitted to issue recursive
>>         queries
>>         >>     >>  allow-recursion { any; };
>>         >>     >>
>>         >>     >>  tkey-gssapi-keytab "/etc/named.keytab";
>>         >>     >>         pid-file "/run/named/named.pid";
>>         >>     >> };
>>         >>     >>
>>         >>     >> /* If you want to enable debugging, eg. using the
>>         'rndc trace'
>>         >>     command,
>>         >>     >>  * By default, SELinux policy does not allow named
>>         to modify
>>         >>     the /var/named
>>         >>     >> directory,
>>         >>     >>  * so put the default debug log file in data/ :
>>         >>     >>  */
>>         >>     >> logging {
>>         >>     >>         channel default_debug {
>>         >>     >>                 file "data/named.run";
>>         >>     >>  severity dynamic;
>>         >>     >>  print-time yes;
>>         >>     >>         };
>>         >>     >>         };
>>         >>     >> };
>>         >>     >>
>>         >>     >> zone "." IN {
>>         >>     >>         type hint;
>>         >>     >>         file "named.ca <http://named.ca>
>>         <http://named.ca> <http://named.ca>";
>>         >>     >> };
>>         >>     >>
>>         >>     >> include "/etc/named.rfc1912.zones";
>>         >>     >>
>>         >>     >> dynamic-db "ipa" {
>>         >>     >>         library "ldap.so";
>>         >>     >>         arg "uri
>>         >>  ldapi://%2fvar%2frun%2fslapd-BO3-E-BOZO-COM.socket";
>>         >>     >>         arg "base cn=dns, dc=bo3,dc=e-bozo,dc=com";
>>         >>     >>         arg "fake_mname
>>         freeipa-poc01.bo3.e-bozo.com
>>         <http://freeipa-poc01.bo3.e-bozo.com>
>>         >>     <http://freeipa-poc01.bo3.e-bozo.com>
>>         >>     >> <http://freeipa-poc01.bo3.e-bozo.com>.";
>>         >>     >>         arg "auth_method sasl";
>>         >>     >>         arg "sasl_mech GSSAPI";
>>         >>     >>         arg "sasl_user
>>         DNS/freeipa-poc01.bo3.e-bozo.com
>>         <http://freeipa-poc01.bo3.e-bozo.com>
>>         >>     <http://freeipa-poc01.bo3.e-bozo.com>
>>         >>     >> <http://freeipa-poc01.bo3.e-bozo.com>";
>>         >>     >>         arg "serial_autoincrement yes";
>>         >>     >> };
>>         >>     >>
>>         >>     >>
>>         >>     >>
>>         >>     >>
>>         >>     > Hello,
>>         >>     >
>>         >>     > which version ipa do you use? which platform? Which
>>         version
>>         >>     bind-dyndb-ldap?
>>         >>     >
>>         >>     > Can you run these commands, and check if there any
>>         errors?
>>         >>     > ipactl status
>>         >>     > systemctl status named (respectively journalctl -u
>>         named)
>>         >>
>>         >>     We also may want to see information listed on page
>>         >> https://fedorahosted.org/bind-dyndb-ldap/wiki/BugReporting
>>
>>         --
>>         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
>>
>>
>>
>>
>>     -- 
>>     If life gives you melons, you may be dyslexic.
>>
>>
>
>
>     -- 
>     Thank you,
>     Dmitri Pal
>
>     Sr. Engineering Manager IdM portfolio
>     Red Hat, Inc.
>
>
>     --
>     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
>
>
>
>
> -- 
> If life gives you melons, you may be dyslexic.


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141207/afbb084f/attachment.htm>

From matthew.herzog at gmail.com  Mon Dec  8 03:10:59 2014
From: matthew.herzog at gmail.com (Matthew Herzog)
Date: Sun, 7 Dec 2014 22:10:59 -0500
Subject: [Freeipa-users] DNS configuration
In-Reply-To: <54851385.3050709@redhat.com>
References: <CABhyZ34TCzUz+fNUSCvdZ38MS7rsLMMdb_jTdfKUsmYs86fn_Q@mail.gmail.com>
	<547DEA9E.2030203@redhat.com> <547DEFB5.1020205@redhat.com>
	<CABhyZ347EU+Q85jQJGU30yx4njC3OtL_QsJZi1MMu1ZR2Lfd2Q@mail.gmail.com>
	<547E851C.1020407@redhat.com> <547ECDDC.3090001@redhat.com>
	<CABhyZ37XChaQF+4rRY-L=OU9pVNp7Mw_NQifTk3NhrewzJtyVQ@mail.gmail.com>
	<5485108E.60409@redhat.com>
	<CABhyZ36DDM6icM+haMbVErdVdDWonGqbPE+3Tpad4K=u9QHjAQ@mail.gmail.com>
	<54851385.3050709@redhat.com>
Message-ID: <CABhyZ36D_SVLezC=wZ3tsYHn00tdBGsxpOxCtpVgWZo8EdH2hw@mail.gmail.com>

So should the FreeIPA server be authoritative for the Kerb. realm/DNS
domain or can it/should it be a slave DNS server instead? Or caching only?

On Sun, Dec 7, 2014 at 9:57 PM, Dmitri Pal <dpal at redhat.com> wrote:

>  On 12/07/2014 09:51 PM, Matthew Herzog wrote:
>
> What must be done in or on the ipa server with regard to DNS, if anything?
>
>  Our DNS works. It works well. We have four Linux DNS servers and two AD
> domain controllers that also do DNS.
>
>  So if we already have DNS working well in our domain, why do we want to
> manage DNS in IPA?
>
>
> Let us keep the discussion on the list.
> IPA when used with AD trust presents itself as a separate forest. AD
> thinks that it is working with another AD forest.
> For that to work we need to follow MSFT rules about relationship between
> Kerberos realm and DNS domain.
> AD assumes that for every trusted forest Kerberos realm = DNS domain. IPA
> makes it easy to do because it has integrated tools to manage IPA DNS
> domain.
> If you want to manage it yourself through your DNS you can do it, just
> more manual operations for you.
>
> HTH
>
> Thanks
> Dmitri
>
>
>
> On Sun, Dec 7, 2014 at 9:44 PM, Dmitri Pal <dpal at redhat.com> wrote:
>
>>  On 12/07/2014 06:44 PM, Matthew Herzog wrote:
>>
>> Thanks guys. I'm sorry for my delay in responding.
>>
>>  Firstly, I was under the impression (from reading the docs) that having
>> named running on IPA server was critical.
>>
>>
>>  Properly configured DNS is critical.
>> How you accomplish it is up to you.
>> IPA allows you to have a DNS server that would simplify DNS management
>> but it can be done manually too. This is why DNS is optional.
>>
>>
>>  Also, the first question the ipa-server-install script asks is, "Do you
>> want to configure integrated DNS (BIND)? ." While it's true the default
>> answer is no, it leads one to believe that DNS is central to IPA. Also the
>> ipa-client-install script says,
>>
>>  [root at freeipa-poc-client02 ~]# ipa-client-install
>> DNS discovery failed to determine your DNS domain
>> Provide the domain name of your IPA server (ex: example.com):
>>
>>  I can resolve -anything- from the machine using dig or whatever.
>>
>>  Ultimately, the reason I started to be concerned about my IPA server's
>> DNS config was because I was not able to authenticate AD accounts to a
>> client machine. I saw a bunch of errors in the client's sssd logs which of
>> course I can't find now.
>>
>>  Perhaps it was these . . .
>>
>>  (Thu Dec  4 13:45:23 2014) [sssd] [ping_check] (0x0100): Service nss
>> replied to ping
>> (Thu Dec  4 13:45:23 2014) [sssd] [ping_check] (0x0100): Service sudo
>> replied to ping
>> (Thu Dec  4 13:45:23 2014) [sssd] [ping_check] (0x0100): Service pam
>> replied to ping
>> (Thu Dec  4 13:45:23 2014) [sssd] [ping_check] (0x0100): Service ssh
>> replied to ping
>> (Thu Dec  4 13:45:23 2014) [sssd] [ping_check] (0x0100): Service pac
>> replied to ping
>> (Thu Dec  4 13:45:23 2014) [sssd] [ping_check] (0x0100): Service
>> bo3.e-bozo.com replied to ping
>>
>>  I'm not allowed onto the AD domain controllers to examine log files or
>> I'd be checking those first.
>>
>>  So ultimately the goal is to authenticate AD users and users that exist
>> in our ldap schema. We need to set up groups of users that can run sudo
>> commands on specific groups of hosts.
>>
>>
>>  Did you setup trusts as explained on the following page?
>> http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup
>>
>>
>>
>>
>>
>> On Wed, Dec 3, 2014 at 3:46 AM, Petr Spacek <pspacek at redhat.com> wrote:
>>
>>> On 3.12.2014 04:35, Dmitri Pal wrote:
>>> > On 12/02/2014 08:54 PM, Matthew Herzog wrote:
>>> >> Any other ideas? I just spun up a new VM and took the defaults on
>>> everything
>>> >> while running ipa-server-install (the defaults did make sense) and my
>>> new VM
>>> >> can't resolve -anything- in the domain in which it lives. The "old" VM
>>> >> (running the same versions of everything on the same OS) can't even
>>> resolve
>>> >> the clients I have registered with it!
>>> >>
>>> >> So I'm pretty frustrated and am wondering, what _exactly_ is the role
>>> of
>>> >> bind in the IPA server and how is it expected to know anything about
>>> the
>>> >> local DNS domain without becoming a bind slave server?
>>> >
>>> > I am not sure I am 100% with you but...
>>> > If you use the defaults and nothing else you get to the scenario when
>>> IPA has
>>> > its DNS but it is a self contained environment. It seems that this is
>>> what you
>>> > observe.
>>> > It is expected that you decide in advance what you want to do with
>>> DNS. There
>>> > are several options:
>>> > 1) You can delegate a zone to IPA to manage, then you need to connect
>>> your IPA
>>> > DNS to your existing DNS during install or after.
>>> > In this case the systems joined to IPA will be a part of IPA
>>> domain/zone and
>>> > would also be able to resolve other systems around
>>> > 2) Not use IPA DNS if you do not want to take advantage of it
>>> > 3) Have a self contained demo/lab environment that you currently
>>> observe.
>>> >
>>> > What is the intent?
>>>
>>> I agree with Dmitri, we need more information from you:
>>> - You said "my new VM can't resolve -anything- in the domain in which it
>>> lives." - Which domain do you mean?
>>>
>>> - Apparently you have configured FreeIPA to serve zone e-bozo.com. Do
>>> you have
>>> this zone configured on some other DNS server at the same time?
>>>
>>> Please keep in mind that authoritative servers should share the
>>> database. You
>>> will get naming collisions if e-bozo.com is served by FreeIPA DNS
>>> servers and
>>> some other servers at the same time. Maybe that is the problem you see
>>> right now.
>>>
>>> As Dmitri said, the architecturally correct solution is to decide if you
>>> want
>>> to use FreeIPA DNS or not. You have option to either remove non-FreeIPA
>>> DNS
>>> servers and import data to FreeIPA or to add FreeIPA-specific DNS
>>> records to
>>> existing DNS servers and do not configure FreeIPA to act as DNS server.
>>>
>>> Petr^2 Spacek
>>>
>>> >> Thanks.
>>> >>
>>> >> On Tue, Dec 2, 2014 at 11:58 AM, Petr Spacek <pspacek at redhat.com
>>>  >> <mailto:pspacek at redhat.com>> wrote:
>>> >>
>>> >>     On 2.12.2014 17:36, Martin Basti wrote:
>>> >>     > On 02/12/14 17:28, Matthew Herzog wrote:
>>> >>     >> I just realized that my IPA servers cannot resolve ANY servers
>>> >>     in my domain.
>>> >>     >> What do I need to do to fix this? Below is my named.conf.
>>> >>     >>
>>> >>     >>
>>> >>     >> options {
>>> >>     >>         // turns on IPv6 for port 53, IPv4 is on by default for
>>> >>     all ifaces
>>> >>     >>         listen-on-v6 {any;};
>>> >>     >>
>>> >>     >>         // Put files that named is allowed to write in the
>>> >>     data/ directory:
>>> >>     >>         directory "/var/named"; // the default
>>> >>     >>         dump-file  "data/cache_dump.db";
>>> >>     >>         statistics-file  "data/named_stats.txt";
>>> >>     >>         memstatistics-file "data/named_mem_stats.txt";
>>> >>     >>
>>> >>     >>         forward first;
>>> >>     >>         forwarders {
>>> >>     >>                 10.100.8.41;
>>> >>     >>                 10.100.8.40;
>>> >>     >>                 10.100.4.13;
>>> >>     >>                 10.100.4.14;
>>> >>     >>                 10.100.4.19;
>>> >>     >>                 10.100.4.44;
>>> >>     >>         };
>>> >>     >>
>>> >>     >>         // Any host is permitted to issue recursive queries
>>> >>     >>         allow-recursion { any; };
>>> >>     >>
>>> >>     >>         tkey-gssapi-keytab "/etc/named.keytab";
>>> >>     >>         pid-file "/run/named/named.pid";
>>> >>     >> };
>>> >>     >>
>>> >>     >> /* If you want to enable debugging, eg. using the 'rndc trace'
>>> >>     command,
>>> >>     >>  * By default, SELinux policy does not allow named to modify
>>> >>     the /var/named
>>> >>     >> directory,
>>> >>     >>  * so put the default debug log file in data/ :
>>> >>     >>  */
>>> >>     >> logging {
>>> >>     >>         channel default_debug {
>>> >>     >>                 file "data/named.run";
>>> >>     >>                 severity dynamic;
>>> >>     >>                 print-time yes;
>>> >>     >>         };
>>> >>     >>         };
>>> >>     >> };
>>> >>     >>
>>> >>     >> zone "." IN {
>>> >>     >>         type hint;
>>>  >>     >>         file "named.ca <http://named.ca> <http://named.ca>";
>>> >>     >> };
>>> >>     >>
>>> >>     >> include "/etc/named.rfc1912.zones";
>>> >>     >>
>>> >>     >> dynamic-db "ipa" {
>>> >>     >>         library "ldap.so";
>>> >>     >>         arg "uri
>>> >>     ldapi://%2fvar%2frun%2fslapd-BO3-E-BOZO-COM.socket";
>>> >>     >>         arg "base cn=dns, dc=bo3,dc=e-bozo,dc=com";
>>> >>     >>         arg "fake_mname freeipa-poc01.bo3.e-bozo.com
>>> >>     <http://freeipa-poc01.bo3.e-bozo.com>
>>> >>     >> <http://freeipa-poc01.bo3.e-bozo.com>.";
>>> >>     >>         arg "auth_method sasl";
>>> >>     >>         arg "sasl_mech GSSAPI";
>>> >>     >>         arg "sasl_user DNS/freeipa-poc01.bo3.e-bozo.com
>>> >>     <http://freeipa-poc01.bo3.e-bozo.com>
>>> >>     >> <http://freeipa-poc01.bo3.e-bozo.com>";
>>> >>     >>         arg "serial_autoincrement yes";
>>> >>     >> };
>>> >>     >>
>>> >>     >>
>>> >>     >>
>>> >>     >>
>>> >>     > Hello,
>>> >>     >
>>> >>     > which version ipa do you use? which platform? Which version
>>> >>     bind-dyndb-ldap?
>>> >>     >
>>> >>     > Can you run these commands, and check if there any errors?
>>> >>     > ipactl status
>>> >>     > systemctl status named  (respectively journalctl -u named)
>>> >>
>>> >>     We also may want to see information listed on page
>>> >>     https://fedorahosted.org/bind-dyndb-ldap/wiki/BugReporting
>>>
>>> --
>>>  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
>>>
>>
>>
>>
>>  --
>>  If life gives you melons, you may be dyslexic.
>>
>>
>>
>>
>>   --
>> Thank you,
>> Dmitri Pal
>>
>> Sr. Engineering Manager IdM portfolio
>> Red Hat, Inc.
>>
>>
>> --
>> 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
>>
>
>
>
>  --
>  If life gives you melons, you may be dyslexic.
>
>
>
> --
> Thank you,
> Dmitri Pal
>
> Sr. Engineering Manager IdM portfolio
> Red Hat, Inc.
>
>


-- 
If life gives you melons, you may be dyslexic.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141207/c99ab9d6/attachment.htm>

From dpal at redhat.com  Mon Dec  8 04:02:00 2014
From: dpal at redhat.com (Dmitri Pal)
Date: Sun, 07 Dec 2014 23:02:00 -0500
Subject: [Freeipa-users] DNS configuration
In-Reply-To: <CABhyZ36D_SVLezC=wZ3tsYHn00tdBGsxpOxCtpVgWZo8EdH2hw@mail.gmail.com>
References: <CABhyZ34TCzUz+fNUSCvdZ38MS7rsLMMdb_jTdfKUsmYs86fn_Q@mail.gmail.com>	<547DEA9E.2030203@redhat.com>
	<547DEFB5.1020205@redhat.com>	<CABhyZ347EU+Q85jQJGU30yx4njC3OtL_QsJZi1MMu1ZR2Lfd2Q@mail.gmail.com>	<547E851C.1020407@redhat.com>
	<547ECDDC.3090001@redhat.com>	<CABhyZ37XChaQF+4rRY-L=OU9pVNp7Mw_NQifTk3NhrewzJtyVQ@mail.gmail.com>	<5485108E.60409@redhat.com>	<CABhyZ36DDM6icM+haMbVErdVdDWonGqbPE+3Tpad4K=u9QHjAQ@mail.gmail.com>	<54851385.3050709@redhat.com>
	<CABhyZ36D_SVLezC=wZ3tsYHn00tdBGsxpOxCtpVgWZo8EdH2hw@mail.gmail.com>
Message-ID: <548522B8.8040805@redhat.com>

On 12/07/2014 10:10 PM, Matthew Herzog wrote:
> So should the FreeIPA server be authoritative for the Kerb. realm/DNS 
> domain or can it/should it be a slave DNS server instead? Or caching only?

IPA DNS can't be a slave so you either delegate a whole zone to it or 
manage IPA DNS domain via your own DNS server.

>
> On Sun, Dec 7, 2014 at 9:57 PM, Dmitri Pal <dpal at redhat.com 
> <mailto:dpal at redhat.com>> wrote:
>
>     On 12/07/2014 09:51 PM, Matthew Herzog wrote:
>>     What must be done in or on the ipa server with regard to DNS, if
>>     anything?
>>
>>     Our DNS works. It works well. We have four Linux DNS servers and
>>     two AD domain controllers that also do DNS.
>>
>>     So if we already have DNS working well in our domain, why do we
>>     want to manage DNS in IPA?
>
>     Let us keep the discussion on the list.
>     IPA when used with AD trust presents itself as a separate forest.
>     AD thinks that it is working with another AD forest.
>     For that to work we need to follow MSFT rules about relationship
>     between Kerberos realm and DNS domain.
>     AD assumes that for every trusted forest Kerberos realm = DNS
>     domain. IPA makes it easy to do because it has integrated tools to
>     manage IPA DNS domain.
>     If you want to manage it yourself through your DNS you can do it,
>     just more manual operations for you.
>
>     HTH
>
>     Thanks
>     Dmitri
>
>
>>
>>     On Sun, Dec 7, 2014 at 9:44 PM, Dmitri Pal <dpal at redhat.com
>>     <mailto:dpal at redhat.com>> wrote:
>>
>>         On 12/07/2014 06:44 PM, Matthew Herzog wrote:
>>>         Thanks guys. I'm sorry for my delay in responding.
>>>
>>>         Firstly, I was under the impression (from reading the docs)
>>>         that having named running on IPA server was critical.
>>
>>         Properly configured DNS is critical.
>>         How you accomplish it is up to you.
>>         IPA allows you to have a DNS server that would simplify DNS
>>         management but it can be done manually too. This is why DNS
>>         is optional.
>>
>>
>>>         Also, the first question the ipa-server-install script asks
>>>         is, "Do you want to configure integrated DNS (BIND)? ."
>>>         While it's true the default answer is no, it leads one to
>>>         believe that DNS is central to IPA. Also the
>>>         ipa-client-install script says,
>>>
>>>         [root at freeipa-poc-client02 ~]# ipa-client-install
>>>         DNS discovery failed to determine your DNS domain
>>>         Provide the domain name of your IPA server (ex: example.com
>>>         <http://example.com>):
>>>
>>>         I can resolve -anything- from the machine using dig or whatever.
>>>
>>>         Ultimately, the reason I started to be concerned about my
>>>         IPA server's DNS config was because I was not able to
>>>         authenticate AD accounts to a client machine. I saw a bunch
>>>         of errors in the client's sssd logs which of course I can't
>>>         find now.
>>>
>>>         Perhaps it was these . . .
>>>
>>>         (Thu Dec  4 13:45:23 2014) [sssd] [ping_check] (0x0100):
>>>         Service nss replied to ping
>>>         (Thu Dec  4 13:45:23 2014) [sssd] [ping_check] (0x0100):
>>>         Service sudo replied to ping
>>>         (Thu Dec  4 13:45:23 2014) [sssd] [ping_check] (0x0100):
>>>         Service pam replied to ping
>>>         (Thu Dec  4 13:45:23 2014) [sssd] [ping_check] (0x0100):
>>>         Service ssh replied to ping
>>>         (Thu Dec  4 13:45:23 2014) [sssd] [ping_check] (0x0100):
>>>         Service pac replied to ping
>>>         (Thu Dec  4 13:45:23 2014) [sssd] [ping_check] (0x0100):
>>>         Service bo3.e-bozo.com <http://bo3.e-bozo.com> replied to ping
>>>
>>>         I'm not allowed onto the AD domain controllers to examine
>>>         log files or I'd be checking those first.
>>>
>>>         So ultimately the goal is to authenticate AD users and users
>>>         that exist in our ldap schema. We need to set up groups of
>>>         users that can run sudo commands on specific groups of hosts.
>>
>>         Did you setup trusts as explained on the following page?
>>         http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup
>>
>>
>>>
>>>
>>>
>>>         On Wed, Dec 3, 2014 at 3:46 AM, Petr Spacek
>>>         <pspacek at redhat.com <mailto:pspacek at redhat.com>> wrote:
>>>
>>>             On 3.12.2014 04:35, Dmitri Pal wrote:
>>>             > On 12/02/2014 08:54 PM, Matthew Herzog wrote:
>>>             >> Any other ideas? I just spun up a new VM and took the
>>>             defaults on everything
>>>             >> while running ipa-server-install (the defaults did
>>>             make sense) and my new VM
>>>             >> can't resolve -anything- in the domain in which it
>>>             lives. The "old" VM
>>>             >> (running the same versions of everything on the same
>>>             OS) can't even resolve
>>>             >> the clients I have registered with it!
>>>             >>
>>>             >> So I'm pretty frustrated and am wondering, what
>>>             _exactly_ is the role of
>>>             >> bind in the IPA server and how is it expected to know
>>>             anything about the
>>>             >> local DNS domain without becoming a bind slave server?
>>>             >
>>>             > I am not sure I am 100% with you but...
>>>             > If you use the defaults and nothing else you get to
>>>             the scenario when IPA has
>>>             > its DNS but it is a self contained environment. It
>>>             seems that this is what you
>>>             > observe.
>>>             > It is expected that you decide in advance what you
>>>             want to do with DNS. There
>>>             > are several options:
>>>             > 1) You can delegate a zone to IPA to manage, then you
>>>             need to connect your IPA
>>>             > DNS to your existing DNS during install or after.
>>>             > In this case the systems joined to IPA will be a part
>>>             of IPA domain/zone and
>>>             > would also be able to resolve other systems around
>>>             > 2) Not use IPA DNS if you do not want to take
>>>             advantage of it
>>>             > 3) Have a self contained demo/lab environment that you
>>>             currently observe.
>>>             >
>>>             > What is the intent?
>>>
>>>             I agree with Dmitri, we need more information from you:
>>>             - You said "my new VM can't resolve -anything- in the
>>>             domain in which it
>>>             lives." - Which domain do you mean?
>>>
>>>             - Apparently you have configured FreeIPA to serve zone
>>>             e-bozo.com <http://e-bozo.com>. Do you have
>>>             this zone configured on some other DNS server at the
>>>             same time?
>>>
>>>             Please keep in mind that authoritative servers should
>>>             share the database. You
>>>             will get naming collisions if e-bozo.com
>>>             <http://e-bozo.com> is served by FreeIPA DNS servers and
>>>             some other servers at the same time. Maybe that is the
>>>             problem you see right now.
>>>
>>>             As Dmitri said, the architecturally correct solution is
>>>             to decide if you want
>>>             to use FreeIPA DNS or not. You have option to either
>>>             remove non-FreeIPA DNS
>>>             servers and import data to FreeIPA or to add
>>>             FreeIPA-specific DNS records to
>>>             existing DNS servers and do not configure FreeIPA to act
>>>             as DNS server.
>>>
>>>             Petr^2 Spacek
>>>
>>>             >> Thanks.
>>>             >>
>>>             >> On Tue, Dec 2, 2014 at 11:58 AM, Petr Spacek
>>>             <pspacek at redhat.com <mailto:pspacek at redhat.com>
>>>             >> <mailto:pspacek at redhat.com
>>>             <mailto:pspacek at redhat.com>>> wrote:
>>>             >>
>>>             >>     On 2.12.2014 17:36, Martin Basti wrote:
>>>             >>     > On 02/12/14 17:28, Matthew Herzog wrote:
>>>             >>     >> I just realized that my IPA servers cannot
>>>             resolve ANY servers
>>>             >>     in my domain.
>>>             >>     >> What do I need to do to fix this? Below is my
>>>             named.conf.
>>>             >>     >>
>>>             >>     >>
>>>             >>     >> options {
>>>             >>     >>  // turns on IPv6 for port 53, IPv4 is on by
>>>             default for
>>>             >>     all ifaces
>>>             >>     >>  listen-on-v6 {any;};
>>>             >>     >>
>>>             >>     >>  // Put files that named is allowed to write
>>>             in the
>>>             >>     data/ directory:
>>>             >>     >>  directory "/var/named"; // the default
>>>             >>     >>  dump-file "data/cache_dump.db";
>>>             >>     >>  statistics-file "data/named_stats.txt";
>>>             >>     >>  memstatistics-file "data/named_mem_stats.txt";
>>>             >>     >>
>>>             >>     >>  forward first;
>>>             >>     >>  forwarders {
>>>             >>     >>          10.100.8.41;
>>>             >>     >>          10.100.8.40;
>>>             >>     >>          10.100.4.13;
>>>             >>     >>          10.100.4.14;
>>>             >>     >>          10.100.4.19;
>>>             >>     >>          10.100.4.44;
>>>             >>     >>  };
>>>             >>     >>
>>>             >>     >>  // Any host is permitted to issue recursive
>>>             queries
>>>             >>     >>  allow-recursion { any; };
>>>             >>     >>
>>>             >>     >>  tkey-gssapi-keytab "/etc/named.keytab";
>>>             >>     >>  pid-file "/run/named/named.pid";
>>>             >>     >> };
>>>             >>     >>
>>>             >>     >> /* If you want to enable debugging, eg. using
>>>             the 'rndc trace'
>>>             >>     command,
>>>             >>     >>  * By default, SELinux policy does not allow
>>>             named to modify
>>>             >>     the /var/named
>>>             >>     >> directory,
>>>             >>     >>  * so put the default debug log file in data/ :
>>>             >>     >>  */
>>>             >>     >> logging {
>>>             >>     >>  channel default_debug {
>>>             >>     >>          file "data/named.run";
>>>             >>     >>          severity dynamic;
>>>             >>     >>          print-time yes;
>>>             >>     >>  };
>>>             >>     >>  };
>>>             >>     >> };
>>>             >>     >>
>>>             >>     >> zone "." IN {
>>>             >>     >>  type hint;
>>>             >>     >>  file "named.ca <http://named.ca>
>>>             <http://named.ca> <http://named.ca>";
>>>             >>     >> };
>>>             >>     >>
>>>             >>     >> include "/etc/named.rfc1912.zones";
>>>             >>     >>
>>>             >>     >> dynamic-db "ipa" {
>>>             >>     >>  library "ldap.so";
>>>             >>     >>  arg "uri
>>>             >>  ldapi://%2fvar%2frun%2fslapd-BO3-E-BOZO-COM.socket";
>>>             >>     >>  arg "base cn=dns, dc=bo3,dc=e-bozo,dc=com";
>>>             >>     >>  arg "fake_mname freeipa-poc01.bo3.e-bozo.com
>>>             <http://freeipa-poc01.bo3.e-bozo.com>
>>>             >>     <http://freeipa-poc01.bo3.e-bozo.com>
>>>             >>     >> <http://freeipa-poc01.bo3.e-bozo.com>.";
>>>             >>     >>  arg "auth_method sasl";
>>>             >>     >>  arg "sasl_mech GSSAPI";
>>>             >>     >>  arg "sasl_user
>>>             DNS/freeipa-poc01.bo3.e-bozo.com
>>>             <http://freeipa-poc01.bo3.e-bozo.com>
>>>             >>     <http://freeipa-poc01.bo3.e-bozo.com>
>>>             >>     >> <http://freeipa-poc01.bo3.e-bozo.com>";
>>>             >>     >>  arg "serial_autoincrement yes";
>>>             >>     >> };
>>>             >>     >>
>>>             >>     >>
>>>             >>     >>
>>>             >>     >>
>>>             >>     > Hello,
>>>             >>     >
>>>             >>     > which version ipa do you use? which platform?
>>>             Which version
>>>             >>     bind-dyndb-ldap?
>>>             >>     >
>>>             >>     > Can you run these commands, and check if there
>>>             any errors?
>>>             >>     > ipactl status
>>>             >>     > systemctl status named  (respectively
>>>             journalctl -u named)
>>>             >>
>>>             >>     We also may want to see information listed on page
>>>             >>
>>>             https://fedorahosted.org/bind-dyndb-ldap/wiki/BugReporting
>>>
>>>             --
>>>             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
>>>
>>>
>>>
>>>
>>>         -- 
>>>         If life gives you melons, you may be dyslexic.
>>>
>>>
>>
>>
>>         -- 
>>         Thank you,
>>         Dmitri Pal
>>
>>         Sr. Engineering Manager IdM portfolio
>>         Red Hat, Inc.
>>
>>
>>         --
>>         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
>>
>>
>>
>>
>>     -- 
>>     If life gives you melons, you may be dyslexic.
>
>
>     -- 
>     Thank you,
>     Dmitri Pal
>
>     Sr. Engineering Manager IdM portfolio
>     Red Hat, Inc.
>
>
>
>
> -- 
> If life gives you melons, you may be dyslexic.
>
>


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141207/228298fe/attachment.htm>

From pspacek at redhat.com  Mon Dec  8 07:56:14 2014
From: pspacek at redhat.com (Petr Spacek)
Date: Mon, 08 Dec 2014 08:56:14 +0100
Subject: [Freeipa-users] DNS configuration
In-Reply-To: <548522B8.8040805@redhat.com>
References: <CABhyZ34TCzUz+fNUSCvdZ38MS7rsLMMdb_jTdfKUsmYs86fn_Q@mail.gmail.com>	<547DEA9E.2030203@redhat.com>	<547DEFB5.1020205@redhat.com>	<CABhyZ347EU+Q85jQJGU30yx4njC3OtL_QsJZi1MMu1ZR2Lfd2Q@mail.gmail.com>	<547E851C.1020407@redhat.com>	<547ECDDC.3090001@redhat.com>	<CABhyZ37XChaQF+4rRY-L=OU9pVNp7Mw_NQifTk3NhrewzJtyVQ@mail.gmail.com>	<5485108E.60409@redhat.com>	<CABhyZ36DDM6icM+haMbVErdVdDWonGqbPE+3Tpad4K=u9QHjAQ@mail.gmail.com>	<54851385.3050709@redhat.com>	<CABhyZ36D_SVLezC=wZ3tsYHn00tdBGsxpOxCtpVgWZo8EdH2hw@mail.gmail.com>
	<548522B8.8040805@redhat.com>
Message-ID: <5485599E.8030801@redhat.com>

On 8.12.2014 05:02, Dmitri Pal wrote:
> On 12/07/2014 10:10 PM, Matthew Herzog wrote:
>> So should the FreeIPA server be authoritative for the Kerb. realm/DNS domain
>> or can it/should it be a slave DNS server instead? Or caching only?
> 
> IPA DNS can't be a slave so you either delegate a whole zone to it or manage
> IPA DNS domain via your own DNS server.

Generally, "slave" is not allowed to do any changes so it is useless in your
scenario.

You can run ipa-server-install *without* --setup-dns option and at the end of
installation it will produce DNS records which you have to manually add to
your existing DNS database.

Did you try that?

Petr^2 Spacek

>> On Sun, Dec 7, 2014 at 9:57 PM, Dmitri Pal <dpal at redhat.com
>> <mailto:dpal at redhat.com>> wrote:
>>
>>     On 12/07/2014 09:51 PM, Matthew Herzog wrote:
>>>     What must be done in or on the ipa server with regard to DNS, if
>>>     anything?
>>>
>>>     Our DNS works. It works well. We have four Linux DNS servers and
>>>     two AD domain controllers that also do DNS.
>>>
>>>     So if we already have DNS working well in our domain, why do we
>>>     want to manage DNS in IPA?
>>
>>     Let us keep the discussion on the list.
>>     IPA when used with AD trust presents itself as a separate forest.
>>     AD thinks that it is working with another AD forest.
>>     For that to work we need to follow MSFT rules about relationship
>>     between Kerberos realm and DNS domain.
>>     AD assumes that for every trusted forest Kerberos realm = DNS
>>     domain. IPA makes it easy to do because it has integrated tools to
>>     manage IPA DNS domain.
>>     If you want to manage it yourself through your DNS you can do it,
>>     just more manual operations for you.
>>
>>     HTH
>>
>>     Thanks
>>     Dmitri
>>
>>
>>>
>>>     On Sun, Dec 7, 2014 at 9:44 PM, Dmitri Pal <dpal at redhat.com
>>>     <mailto:dpal at redhat.com>> wrote:
>>>
>>>         On 12/07/2014 06:44 PM, Matthew Herzog wrote:
>>>>         Thanks guys. I'm sorry for my delay in responding.
>>>>
>>>>         Firstly, I was under the impression (from reading the docs)
>>>>         that having named running on IPA server was critical.
>>>
>>>         Properly configured DNS is critical.
>>>         How you accomplish it is up to you.
>>>         IPA allows you to have a DNS server that would simplify DNS
>>>         management but it can be done manually too. This is why DNS
>>>         is optional.
>>>
>>>
>>>>         Also, the first question the ipa-server-install script asks
>>>>         is, "Do you want to configure integrated DNS (BIND)? ."
>>>>         While it's true the default answer is no, it leads one to
>>>>         believe that DNS is central to IPA. Also the
>>>>         ipa-client-install script says,
>>>>
>>>>         [root at freeipa-poc-client02 ~]# ipa-client-install
>>>>         DNS discovery failed to determine your DNS domain
>>>>         Provide the domain name of your IPA server (ex: example.com
>>>>         <http://example.com>):
>>>>
>>>>         I can resolve -anything- from the machine using dig or whatever.
>>>>
>>>>         Ultimately, the reason I started to be concerned about my
>>>>         IPA server's DNS config was because I was not able to
>>>>         authenticate AD accounts to a client machine. I saw a bunch
>>>>         of errors in the client's sssd logs which of course I can't
>>>>         find now.
>>>>
>>>>         Perhaps it was these . . .
>>>>
>>>>         (Thu Dec  4 13:45:23 2014) [sssd] [ping_check] (0x0100):
>>>>         Service nss replied to ping
>>>>         (Thu Dec  4 13:45:23 2014) [sssd] [ping_check] (0x0100):
>>>>         Service sudo replied to ping
>>>>         (Thu Dec  4 13:45:23 2014) [sssd] [ping_check] (0x0100):
>>>>         Service pam replied to ping
>>>>         (Thu Dec  4 13:45:23 2014) [sssd] [ping_check] (0x0100):
>>>>         Service ssh replied to ping
>>>>         (Thu Dec  4 13:45:23 2014) [sssd] [ping_check] (0x0100):
>>>>         Service pac replied to ping
>>>>         (Thu Dec  4 13:45:23 2014) [sssd] [ping_check] (0x0100):
>>>>         Service bo3.e-bozo.com <http://bo3.e-bozo.com> replied to ping
>>>>
>>>>         I'm not allowed onto the AD domain controllers to examine
>>>>         log files or I'd be checking those first.
>>>>
>>>>         So ultimately the goal is to authenticate AD users and users
>>>>         that exist in our ldap schema. We need to set up groups of
>>>>         users that can run sudo commands on specific groups of hosts.
>>>
>>>         Did you setup trusts as explained on the following page?
>>>         http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup
>>>
>>>
>>>>
>>>>
>>>>
>>>>         On Wed, Dec 3, 2014 at 3:46 AM, Petr Spacek
>>>>         <pspacek at redhat.com <mailto:pspacek at redhat.com>> wrote:
>>>>
>>>>             On 3.12.2014 04:35, Dmitri Pal wrote:
>>>>             > On 12/02/2014 08:54 PM, Matthew Herzog wrote:
>>>>             >> Any other ideas? I just spun up a new VM and took the
>>>>             defaults on everything
>>>>             >> while running ipa-server-install (the defaults did
>>>>             make sense) and my new VM
>>>>             >> can't resolve -anything- in the domain in which it
>>>>             lives. The "old" VM
>>>>             >> (running the same versions of everything on the same
>>>>             OS) can't even resolve
>>>>             >> the clients I have registered with it!
>>>>             >>
>>>>             >> So I'm pretty frustrated and am wondering, what
>>>>             _exactly_ is the role of
>>>>             >> bind in the IPA server and how is it expected to know
>>>>             anything about the
>>>>             >> local DNS domain without becoming a bind slave server?
>>>>             >
>>>>             > I am not sure I am 100% with you but...
>>>>             > If you use the defaults and nothing else you get to
>>>>             the scenario when IPA has
>>>>             > its DNS but it is a self contained environment. It
>>>>             seems that this is what you
>>>>             > observe.
>>>>             > It is expected that you decide in advance what you
>>>>             want to do with DNS. There
>>>>             > are several options:
>>>>             > 1) You can delegate a zone to IPA to manage, then you
>>>>             need to connect your IPA
>>>>             > DNS to your existing DNS during install or after.
>>>>             > In this case the systems joined to IPA will be a part
>>>>             of IPA domain/zone and
>>>>             > would also be able to resolve other systems around
>>>>             > 2) Not use IPA DNS if you do not want to take
>>>>             advantage of it
>>>>             > 3) Have a self contained demo/lab environment that you
>>>>             currently observe.
>>>>             >
>>>>             > What is the intent?
>>>>
>>>>             I agree with Dmitri, we need more information from you:
>>>>             - You said "my new VM can't resolve -anything- in the
>>>>             domain in which it
>>>>             lives." - Which domain do you mean?
>>>>
>>>>             - Apparently you have configured FreeIPA to serve zone
>>>>             e-bozo.com <http://e-bozo.com>. Do you have
>>>>             this zone configured on some other DNS server at the
>>>>             same time?
>>>>
>>>>             Please keep in mind that authoritative servers should
>>>>             share the database. You
>>>>             will get naming collisions if e-bozo.com
>>>>             <http://e-bozo.com> is served by FreeIPA DNS servers and
>>>>             some other servers at the same time. Maybe that is the
>>>>             problem you see right now.
>>>>
>>>>             As Dmitri said, the architecturally correct solution is
>>>>             to decide if you want
>>>>             to use FreeIPA DNS or not. You have option to either
>>>>             remove non-FreeIPA DNS
>>>>             servers and import data to FreeIPA or to add
>>>>             FreeIPA-specific DNS records to
>>>>             existing DNS servers and do not configure FreeIPA to act
>>>>             as DNS server.
>>>>
>>>>             Petr^2 Spacek
>>>>
>>>>             >> Thanks.
>>>>             >>
>>>>             >> On Tue, Dec 2, 2014 at 11:58 AM, Petr Spacek
>>>>             <pspacek at redhat.com <mailto:pspacek at redhat.com>
>>>>             >> <mailto:pspacek at redhat.com
>>>>             <mailto:pspacek at redhat.com>>> wrote:
>>>>             >>
>>>>             >>     On 2.12.2014 17:36, Martin Basti wrote:
>>>>             >>     > On 02/12/14 17:28, Matthew Herzog wrote:
>>>>             >>     >> I just realized that my IPA servers cannot
>>>>             resolve ANY servers
>>>>             >>     in my domain.
>>>>             >>     >> What do I need to do to fix this? Below is my
>>>>             named.conf.
>>>>             >>     >>
>>>>             >>     >>
>>>>             >>     >> options {
>>>>             >>     >>  // turns on IPv6 for port 53, IPv4 is on by
>>>>             default for
>>>>             >>     all ifaces
>>>>             >>     >>  listen-on-v6 {any;};
>>>>             >>     >>
>>>>             >>     >>  // Put files that named is allowed to write
>>>>             in the
>>>>             >>     data/ directory:
>>>>             >>     >>  directory "/var/named"; // the default
>>>>             >>     >>  dump-file "data/cache_dump.db";
>>>>             >>     >>  statistics-file "data/named_stats.txt";
>>>>             >>     >>  memstatistics-file "data/named_mem_stats.txt";
>>>>             >>     >>
>>>>             >>     >>  forward first;
>>>>             >>     >>  forwarders {
>>>>             >>     >>          10.100.8.41;
>>>>             >>     >>          10.100.8.40;
>>>>             >>     >>          10.100.4.13;
>>>>             >>     >>          10.100.4.14;
>>>>             >>     >>          10.100.4.19;
>>>>             >>     >>          10.100.4.44;
>>>>             >>     >>  };
>>>>             >>     >>
>>>>             >>     >>  // Any host is permitted to issue recursive
>>>>             queries
>>>>             >>     >>  allow-recursion { any; };
>>>>             >>     >>
>>>>             >>     >>  tkey-gssapi-keytab "/etc/named.keytab";
>>>>             >>     >>  pid-file "/run/named/named.pid";
>>>>             >>     >> };
>>>>             >>     >>
>>>>             >>     >> /* If you want to enable debugging, eg. using
>>>>             the 'rndc trace'
>>>>             >>     command,
>>>>             >>     >>  * By default, SELinux policy does not allow
>>>>             named to modify
>>>>             >>     the /var/named
>>>>             >>     >> directory,
>>>>             >>     >>  * so put the default debug log file in data/ :
>>>>             >>     >>  */
>>>>             >>     >> logging {
>>>>             >>     >>  channel default_debug {
>>>>             >>     >>          file "data/named.run";
>>>>             >>     >>          severity dynamic;
>>>>             >>     >>          print-time yes;
>>>>             >>     >>  };
>>>>             >>     >>  };
>>>>             >>     >> };
>>>>             >>     >>
>>>>             >>     >> zone "." IN {
>>>>             >>     >>  type hint;
>>>>             >>     >>  file "named.ca <http://named.ca>
>>>>             <http://named.ca> <http://named.ca>";
>>>>             >>     >> };
>>>>             >>     >>
>>>>             >>     >> include "/etc/named.rfc1912.zones";
>>>>             >>     >>
>>>>             >>     >> dynamic-db "ipa" {
>>>>             >>     >>  library "ldap.so";
>>>>             >>     >>  arg "uri
>>>>             >>  ldapi://%2fvar%2frun%2fslapd-BO3-E-BOZO-COM.socket";
>>>>             >>     >>  arg "base cn=dns, dc=bo3,dc=e-bozo,dc=com";
>>>>             >>     >>  arg "fake_mname freeipa-poc01.bo3.e-bozo.com
>>>>             <http://freeipa-poc01.bo3.e-bozo.com>
>>>>             >>     <http://freeipa-poc01.bo3.e-bozo.com>
>>>>             >>     >> <http://freeipa-poc01.bo3.e-bozo.com>.";
>>>>             >>     >>  arg "auth_method sasl";
>>>>             >>     >>  arg "sasl_mech GSSAPI";
>>>>             >>     >>  arg "sasl_user
>>>>             DNS/freeipa-poc01.bo3.e-bozo.com
>>>>             <http://freeipa-poc01.bo3.e-bozo.com>
>>>>             >>     <http://freeipa-poc01.bo3.e-bozo.com>
>>>>             >>     >> <http://freeipa-poc01.bo3.e-bozo.com>";
>>>>             >>     >>  arg "serial_autoincrement yes";
>>>>             >>     >> };
>>>>             >>     >>
>>>>             >>     >>
>>>>             >>     >>
>>>>             >>     >>
>>>>             >>     > Hello,
>>>>             >>     >
>>>>             >>     > which version ipa do you use? which platform?
>>>>             Which version
>>>>             >>     bind-dyndb-ldap?
>>>>             >>     >
>>>>             >>     > Can you run these commands, and check if there
>>>>             any errors?
>>>>             >>     > ipactl status
>>>>             >>     > systemctl status named  (respectively
>>>>             journalctl -u named)
>>>>             >>
>>>>             >>     We also may want to see information listed on page
>>>>             >>
>>>>             https://fedorahosted.org/bind-dyndb-ldap/wiki/BugReporting



From matthew.herzog at gmail.com  Mon Dec  8 13:44:21 2014
From: matthew.herzog at gmail.com (Matthew Herzog)
Date: Mon, 8 Dec 2014 08:44:21 -0500
Subject: [Freeipa-users] DNS configuration
In-Reply-To: <5485599E.8030801@redhat.com>
References: <CABhyZ34TCzUz+fNUSCvdZ38MS7rsLMMdb_jTdfKUsmYs86fn_Q@mail.gmail.com>
	<547DEA9E.2030203@redhat.com> <547DEFB5.1020205@redhat.com>
	<CABhyZ347EU+Q85jQJGU30yx4njC3OtL_QsJZi1MMu1ZR2Lfd2Q@mail.gmail.com>
	<547E851C.1020407@redhat.com> <547ECDDC.3090001@redhat.com>
	<CABhyZ37XChaQF+4rRY-L=OU9pVNp7Mw_NQifTk3NhrewzJtyVQ@mail.gmail.com>
	<5485108E.60409@redhat.com>
	<CABhyZ36DDM6icM+haMbVErdVdDWonGqbPE+3Tpad4K=u9QHjAQ@mail.gmail.com>
	<54851385.3050709@redhat.com>
	<CABhyZ36D_SVLezC=wZ3tsYHn00tdBGsxpOxCtpVgWZo8EdH2hw@mail.gmail.com>
	<548522B8.8040805@redhat.com> <5485599E.8030801@redhat.com>
Message-ID: <CABhyZ34Pbr4J6YDdLSmP=qPqAB7Pa=tWvw273aB-BNX4dRq-GQ@mail.gmail.com>

Petr said, "You can run ipa-server-install *without* --setup-dns option and
at the end of
installation it will produce DNS records which you have to manually add to
your existing DNS database."

I can't see how this would be useful or which machines I would need to add
to our DNS.

Perhaps I should have explained that we are not going to set up a new DNS
domain for the ipa-managed servers. We have an Oracle dsee7 server doing
LDAP for our Linux servers and accounts. We want to migrate to IPA so we
don't have to maintain a Linux/LDAP account for every user who needs access
to Linux servers. All of our users start with an account in AD and since
none of my predecessors knew about Winbind, they set up dsee7.

So I'm thinking we'll need to import all our dsee7 accounts AND make it
possible for AD users to access the Linux systems without needing to create
them in IPA.

On Mon, Dec 8, 2014 at 2:56 AM, Petr Spacek <pspacek at redhat.com> wrote:

> On 8.12.2014 05:02, Dmitri Pal wrote:
> > On 12/07/2014 10:10 PM, Matthew Herzog wrote:
> >> So should the FreeIPA server be authoritative for the Kerb. realm/DNS
> domain
> >> or can it/should it be a slave DNS server instead? Or caching only?
> >
> > IPA DNS can't be a slave so you either delegate a whole zone to it or
> manage
> > IPA DNS domain via your own DNS server.
>
> Generally, "slave" is not allowed to do any changes so it is useless in
> your
> scenario.
>
> You can run ipa-server-install *without* --setup-dns option and at the end
> of
> installation it will produce DNS records which you have to manually add to
> your existing DNS database.
>
> Did you try that?
>
> Petr^2 Spacek
>
> >> On Sun, Dec 7, 2014 at 9:57 PM, Dmitri Pal <dpal at redhat.com
> >> <mailto:dpal at redhat.com>> wrote:
> >>
> >>     On 12/07/2014 09:51 PM, Matthew Herzog wrote:
> >>>     What must be done in or on the ipa server with regard to DNS, if
> >>>     anything?
> >>>
> >>>     Our DNS works. It works well. We have four Linux DNS servers and
> >>>     two AD domain controllers that also do DNS.
> >>>
> >>>     So if we already have DNS working well in our domain, why do we
> >>>     want to manage DNS in IPA?
> >>
> >>     Let us keep the discussion on the list.
> >>     IPA when used with AD trust presents itself as a separate forest.
> >>     AD thinks that it is working with another AD forest.
> >>     For that to work we need to follow MSFT rules about relationship
> >>     between Kerberos realm and DNS domain.
> >>     AD assumes that for every trusted forest Kerberos realm = DNS
> >>     domain. IPA makes it easy to do because it has integrated tools to
> >>     manage IPA DNS domain.
> >>     If you want to manage it yourself through your DNS you can do it,
> >>     just more manual operations for you.
> >>
> >>     HTH
> >>
> >>     Thanks
> >>     Dmitri
> >>
> >>
> >>>
> >>>     On Sun, Dec 7, 2014 at 9:44 PM, Dmitri Pal <dpal at redhat.com
> >>>     <mailto:dpal at redhat.com>> wrote:
> >>>
> >>>         On 12/07/2014 06:44 PM, Matthew Herzog wrote:
> >>>>         Thanks guys. I'm sorry for my delay in responding.
> >>>>
> >>>>         Firstly, I was under the impression (from reading the docs)
> >>>>         that having named running on IPA server was critical.
> >>>
> >>>         Properly configured DNS is critical.
> >>>         How you accomplish it is up to you.
> >>>         IPA allows you to have a DNS server that would simplify DNS
> >>>         management but it can be done manually too. This is why DNS
> >>>         is optional.
> >>>
> >>>
> >>>>         Also, the first question the ipa-server-install script asks
> >>>>         is, "Do you want to configure integrated DNS (BIND)? ."
> >>>>         While it's true the default answer is no, it leads one to
> >>>>         believe that DNS is central to IPA. Also the
> >>>>         ipa-client-install script says,
> >>>>
> >>>>         [root at freeipa-poc-client02 ~]# ipa-client-install
> >>>>         DNS discovery failed to determine your DNS domain
> >>>>         Provide the domain name of your IPA server (ex: example.com
> >>>>         <http://example.com>):
> >>>>
> >>>>         I can resolve -anything- from the machine using dig or
> whatever.
> >>>>
> >>>>         Ultimately, the reason I started to be concerned about my
> >>>>         IPA server's DNS config was because I was not able to
> >>>>         authenticate AD accounts to a client machine. I saw a bunch
> >>>>         of errors in the client's sssd logs which of course I can't
> >>>>         find now.
> >>>>
> >>>>         Perhaps it was these . . .
> >>>>
> >>>>         (Thu Dec  4 13:45:23 2014) [sssd] [ping_check] (0x0100):
> >>>>         Service nss replied to ping
> >>>>         (Thu Dec  4 13:45:23 2014) [sssd] [ping_check] (0x0100):
> >>>>         Service sudo replied to ping
> >>>>         (Thu Dec  4 13:45:23 2014) [sssd] [ping_check] (0x0100):
> >>>>         Service pam replied to ping
> >>>>         (Thu Dec  4 13:45:23 2014) [sssd] [ping_check] (0x0100):
> >>>>         Service ssh replied to ping
> >>>>         (Thu Dec  4 13:45:23 2014) [sssd] [ping_check] (0x0100):
> >>>>         Service pac replied to ping
> >>>>         (Thu Dec  4 13:45:23 2014) [sssd] [ping_check] (0x0100):
> >>>>         Service bo3.e-bozo.com <http://bo3.e-bozo.com> replied to
> ping
> >>>>
> >>>>         I'm not allowed onto the AD domain controllers to examine
> >>>>         log files or I'd be checking those first.
> >>>>
> >>>>         So ultimately the goal is to authenticate AD users and users
> >>>>         that exist in our ldap schema. We need to set up groups of
> >>>>         users that can run sudo commands on specific groups of hosts.
> >>>
> >>>         Did you setup trusts as explained on the following page?
> >>>         http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup
> >>>
> >>>
> >>>>
> >>>>
> >>>>
> >>>>         On Wed, Dec 3, 2014 at 3:46 AM, Petr Spacek
> >>>>         <pspacek at redhat.com <mailto:pspacek at redhat.com>> wrote:
> >>>>
> >>>>             On 3.12.2014 04:35, Dmitri Pal wrote:
> >>>>             > On 12/02/2014 08:54 PM, Matthew Herzog wrote:
> >>>>             >> Any other ideas? I just spun up a new VM and took the
> >>>>             defaults on everything
> >>>>             >> while running ipa-server-install (the defaults did
> >>>>             make sense) and my new VM
> >>>>             >> can't resolve -anything- in the domain in which it
> >>>>             lives. The "old" VM
> >>>>             >> (running the same versions of everything on the same
> >>>>             OS) can't even resolve
> >>>>             >> the clients I have registered with it!
> >>>>             >>
> >>>>             >> So I'm pretty frustrated and am wondering, what
> >>>>             _exactly_ is the role of
> >>>>             >> bind in the IPA server and how is it expected to know
> >>>>             anything about the
> >>>>             >> local DNS domain without becoming a bind slave server?
> >>>>             >
> >>>>             > I am not sure I am 100% with you but...
> >>>>             > If you use the defaults and nothing else you get to
> >>>>             the scenario when IPA has
> >>>>             > its DNS but it is a self contained environment. It
> >>>>             seems that this is what you
> >>>>             > observe.
> >>>>             > It is expected that you decide in advance what you
> >>>>             want to do with DNS. There
> >>>>             > are several options:
> >>>>             > 1) You can delegate a zone to IPA to manage, then you
> >>>>             need to connect your IPA
> >>>>             > DNS to your existing DNS during install or after.
> >>>>             > In this case the systems joined to IPA will be a part
> >>>>             of IPA domain/zone and
> >>>>             > would also be able to resolve other systems around
> >>>>             > 2) Not use IPA DNS if you do not want to take
> >>>>             advantage of it
> >>>>             > 3) Have a self contained demo/lab environment that you
> >>>>             currently observe.
> >>>>             >
> >>>>             > What is the intent?
> >>>>
> >>>>             I agree with Dmitri, we need more information from you:
> >>>>             - You said "my new VM can't resolve -anything- in the
> >>>>             domain in which it
> >>>>             lives." - Which domain do you mean?
> >>>>
> >>>>             - Apparently you have configured FreeIPA to serve zone
> >>>>             e-bozo.com <http://e-bozo.com>. Do you have
> >>>>             this zone configured on some other DNS server at the
> >>>>             same time?
> >>>>
> >>>>             Please keep in mind that authoritative servers should
> >>>>             share the database. You
> >>>>             will get naming collisions if e-bozo.com
> >>>>             <http://e-bozo.com> is served by FreeIPA DNS servers and
> >>>>             some other servers at the same time. Maybe that is the
> >>>>             problem you see right now.
> >>>>
> >>>>             As Dmitri said, the architecturally correct solution is
> >>>>             to decide if you want
> >>>>             to use FreeIPA DNS or not. You have option to either
> >>>>             remove non-FreeIPA DNS
> >>>>             servers and import data to FreeIPA or to add
> >>>>             FreeIPA-specific DNS records to
> >>>>             existing DNS servers and do not configure FreeIPA to act
> >>>>             as DNS server.
> >>>>
> >>>>             Petr^2 Spacek
> >>>>
> >>>>             >> Thanks.
> >>>>             >>
> >>>>             >> On Tue, Dec 2, 2014 at 11:58 AM, Petr Spacek
> >>>>             <pspacek at redhat.com <mailto:pspacek at redhat.com>
> >>>>             >> <mailto:pspacek at redhat.com
> >>>>             <mailto:pspacek at redhat.com>>> wrote:
> >>>>             >>
> >>>>             >>     On 2.12.2014 17:36, Martin Basti wrote:
> >>>>             >>     > On 02/12/14 17:28, Matthew Herzog wrote:
> >>>>             >>     >> I just realized that my IPA servers cannot
> >>>>             resolve ANY servers
> >>>>             >>     in my domain.
> >>>>             >>     >> What do I need to do to fix this? Below is my
> >>>>             named.conf.
> >>>>             >>     >>
> >>>>             >>     >>
> >>>>             >>     >> options {
> >>>>             >>     >>  // turns on IPv6 for port 53, IPv4 is on by
> >>>>             default for
> >>>>             >>     all ifaces
> >>>>             >>     >>  listen-on-v6 {any;};
> >>>>             >>     >>
> >>>>             >>     >>  // Put files that named is allowed to write
> >>>>             in the
> >>>>             >>     data/ directory:
> >>>>             >>     >>  directory "/var/named"; // the default
> >>>>             >>     >>  dump-file "data/cache_dump.db";
> >>>>             >>     >>  statistics-file "data/named_stats.txt";
> >>>>             >>     >>  memstatistics-file "data/named_mem_stats.txt";
> >>>>             >>     >>
> >>>>             >>     >>  forward first;
> >>>>             >>     >>  forwarders {
> >>>>             >>     >>          10.100.8.41;
> >>>>             >>     >>          10.100.8.40;
> >>>>             >>     >>          10.100.4.13;
> >>>>             >>     >>          10.100.4.14;
> >>>>             >>     >>          10.100.4.19;
> >>>>             >>     >>          10.100.4.44;
> >>>>             >>     >>  };
> >>>>             >>     >>
> >>>>             >>     >>  // Any host is permitted to issue recursive
> >>>>             queries
> >>>>             >>     >>  allow-recursion { any; };
> >>>>             >>     >>
> >>>>             >>     >>  tkey-gssapi-keytab "/etc/named.keytab";
> >>>>             >>     >>  pid-file "/run/named/named.pid";
> >>>>             >>     >> };
> >>>>             >>     >>
> >>>>             >>     >> /* If you want to enable debugging, eg. using
> >>>>             the 'rndc trace'
> >>>>             >>     command,
> >>>>             >>     >>  * By default, SELinux policy does not allow
> >>>>             named to modify
> >>>>             >>     the /var/named
> >>>>             >>     >> directory,
> >>>>             >>     >>  * so put the default debug log file in data/ :
> >>>>             >>     >>  */
> >>>>             >>     >> logging {
> >>>>             >>     >>  channel default_debug {
> >>>>             >>     >>          file "data/named.run";
> >>>>             >>     >>          severity dynamic;
> >>>>             >>     >>          print-time yes;
> >>>>             >>     >>  };
> >>>>             >>     >>  };
> >>>>             >>     >> };
> >>>>             >>     >>
> >>>>             >>     >> zone "." IN {
> >>>>             >>     >>  type hint;
> >>>>             >>     >>  file "named.ca <http://named.ca>
> >>>>             <http://named.ca> <http://named.ca>";
> >>>>             >>     >> };
> >>>>             >>     >>
> >>>>             >>     >> include "/etc/named.rfc1912.zones";
> >>>>             >>     >>
> >>>>             >>     >> dynamic-db "ipa" {
> >>>>             >>     >>  library "ldap.so";
> >>>>             >>     >>  arg "uri
> >>>>             >>  ldapi://%2fvar%2frun%2fslapd-BO3-E-BOZO-COM.socket";
> >>>>             >>     >>  arg "base cn=dns, dc=bo3,dc=e-bozo,dc=com";
> >>>>             >>     >>  arg "fake_mname freeipa-poc01.bo3.e-bozo.com
> >>>>             <http://freeipa-poc01.bo3.e-bozo.com>
> >>>>             >>     <http://freeipa-poc01.bo3.e-bozo.com>
> >>>>             >>     >> <http://freeipa-poc01.bo3.e-bozo.com>.";
> >>>>             >>     >>  arg "auth_method sasl";
> >>>>             >>     >>  arg "sasl_mech GSSAPI";
> >>>>             >>     >>  arg "sasl_user
> >>>>             DNS/freeipa-poc01.bo3.e-bozo.com
> >>>>             <http://freeipa-poc01.bo3.e-bozo.com>
> >>>>             >>     <http://freeipa-poc01.bo3.e-bozo.com>
> >>>>             >>     >> <http://freeipa-poc01.bo3.e-bozo.com>";
> >>>>             >>     >>  arg "serial_autoincrement yes";
> >>>>             >>     >> };
> >>>>             >>     >>
> >>>>             >>     >>
> >>>>             >>     >>
> >>>>             >>     >>
> >>>>             >>     > Hello,
> >>>>             >>     >
> >>>>             >>     > which version ipa do you use? which platform?
> >>>>             Which version
> >>>>             >>     bind-dyndb-ldap?
> >>>>             >>     >
> >>>>             >>     > Can you run these commands, and check if there
> >>>>             any errors?
> >>>>             >>     > ipactl status
> >>>>             >>     > systemctl status named  (respectively
> >>>>             journalctl -u named)
> >>>>             >>
> >>>>             >>     We also may want to see information listed on page
> >>>>             >>
> >>>>
> https://fedorahosted.org/bind-dyndb-ldap/wiki/BugReporting
>
> --
> 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
>



-- 
If life gives you melons, you may be dyslexic.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141208/50baa982/attachment.htm>

From dpal at redhat.com  Mon Dec  8 13:58:46 2014
From: dpal at redhat.com (Dmitri Pal)
Date: Mon, 08 Dec 2014 08:58:46 -0500
Subject: [Freeipa-users] DNS configuration
In-Reply-To: <CABhyZ34Pbr4J6YDdLSmP=qPqAB7Pa=tWvw273aB-BNX4dRq-GQ@mail.gmail.com>
References: <CABhyZ34TCzUz+fNUSCvdZ38MS7rsLMMdb_jTdfKUsmYs86fn_Q@mail.gmail.com>	<547DEA9E.2030203@redhat.com>
	<547DEFB5.1020205@redhat.com>	<CABhyZ347EU+Q85jQJGU30yx4njC3OtL_QsJZi1MMu1ZR2Lfd2Q@mail.gmail.com>	<547E851C.1020407@redhat.com>
	<547ECDDC.3090001@redhat.com>	<CABhyZ37XChaQF+4rRY-L=OU9pVNp7Mw_NQifTk3NhrewzJtyVQ@mail.gmail.com>	<5485108E.60409@redhat.com>	<CABhyZ36DDM6icM+haMbVErdVdDWonGqbPE+3Tpad4K=u9QHjAQ@mail.gmail.com>	<54851385.3050709@redhat.com>	<CABhyZ36D_SVLezC=wZ3tsYHn00tdBGsxpOxCtpVgWZo8EdH2hw@mail.gmail.com>	<548522B8.8040805@redhat.com>
	<5485599E.8030801@redhat.com>
	<CABhyZ34Pbr4J6YDdLSmP=qPqAB7Pa=tWvw273aB-BNX4dRq-GQ@mail.gmail.com>
Message-ID: <5485AE96.7020604@redhat.com>

On 12/08/2014 08:44 AM, Matthew Herzog wrote:
> Petr said, "You can run ipa-server-install *without* --setup-dns 
> option and at the end of
> installation it will produce DNS records which you have to manually add to
> your existing DNS database."
>
> I can't see how this would be useful or which machines I would need to 
> add to our DNS.
>
> Perhaps I should have explained that we are not going to set up a new 
> DNS domain for the ipa-managed servers. We have an Oracle dsee7 server 
> doing LDAP for our Linux servers and accounts. We want to migrate to 
> IPA so we don't have to maintain a Linux/LDAP account for every user 
> who needs access to Linux servers. All of our users start with an 
> account in AD and since none of my predecessors knew about Winbind, 
> they set up dsee7.
>
> So I'm thinking we'll need to import all our dsee7 accounts AND make 
> it possible for AD users to access the Linux systems without needing 
> to create them in IPA.


So the approach would be:

1) Install IPA (do not migrate users)
2) Establish trust with AD
3) Start switching client configuration from using LDAP with dsee7 to 
SSSD pointing to IPA

You do not need to migrate users.

>
> On Mon, Dec 8, 2014 at 2:56 AM, Petr Spacek <pspacek at redhat.com 
> <mailto:pspacek at redhat.com>> wrote:
>
>     On 8.12.2014 05:02, Dmitri Pal wrote:
>     > On 12/07/2014 10:10 PM, Matthew Herzog wrote:
>     >> So should the FreeIPA server be authoritative for the Kerb.
>     realm/DNS domain
>     >> or can it/should it be a slave DNS server instead? Or caching only?
>     >
>     > IPA DNS can't be a slave so you either delegate a whole zone to
>     it or manage
>     > IPA DNS domain via your own DNS server.
>
>     Generally, "slave" is not allowed to do any changes so it is
>     useless in your
>     scenario.
>
>     You can run ipa-server-install *without* --setup-dns option and at
>     the end of
>     installation it will produce DNS records which you have to
>     manually add to
>     your existing DNS database.
>
>     Did you try that?
>
>     Petr^2 Spacek
>
>     >> On Sun, Dec 7, 2014 at 9:57 PM, Dmitri Pal <dpal at redhat.com
>     <mailto:dpal at redhat.com>
>     >> <mailto:dpal at redhat.com <mailto:dpal at redhat.com>>> wrote:
>     >>
>     >>     On 12/07/2014 09:51 PM, Matthew Herzog wrote:
>     >>>     What must be done in or on the ipa server with regard to
>     DNS, if
>     >>>     anything?
>     >>>
>     >>>     Our DNS works. It works well. We have four Linux DNS
>     servers and
>     >>>     two AD domain controllers that also do DNS.
>     >>>
>     >>>     So if we already have DNS working well in our domain, why
>     do we
>     >>>     want to manage DNS in IPA?
>     >>
>     >>     Let us keep the discussion on the list.
>     >>     IPA when used with AD trust presents itself as a separate
>     forest.
>     >>     AD thinks that it is working with another AD forest.
>     >>     For that to work we need to follow MSFT rules about
>     relationship
>     >>     between Kerberos realm and DNS domain.
>     >>     AD assumes that for every trusted forest Kerberos realm = DNS
>     >>     domain. IPA makes it easy to do because it has integrated
>     tools to
>     >>     manage IPA DNS domain.
>     >>     If you want to manage it yourself through your DNS you can
>     do it,
>     >>     just more manual operations for you.
>     >>
>     >>     HTH
>     >>
>     >>     Thanks
>     >>     Dmitri
>     >>
>     >>
>     >>>
>     >>>     On Sun, Dec 7, 2014 at 9:44 PM, Dmitri Pal
>     <dpal at redhat.com <mailto:dpal at redhat.com>
>     >>>     <mailto:dpal at redhat.com <mailto:dpal at redhat.com>>> wrote:
>     >>>
>     >>>         On 12/07/2014 06:44 PM, Matthew Herzog wrote:
>     >>>>         Thanks guys. I'm sorry for my delay in responding.
>     >>>>
>     >>>>         Firstly, I was under the impression (from reading the
>     docs)
>     >>>>         that having named running on IPA server was critical.
>     >>>
>     >>>         Properly configured DNS is critical.
>     >>>         How you accomplish it is up to you.
>     >>>         IPA allows you to have a DNS server that would
>     simplify DNS
>     >>>         management but it can be done manually too. This is
>     why DNS
>     >>>         is optional.
>     >>>
>     >>>
>     >>>>         Also, the first question the ipa-server-install
>     script asks
>     >>>>         is, "Do you want to configure integrated DNS (BIND)? ."
>     >>>>         While it's true the default answer is no, it leads one to
>     >>>>         believe that DNS is central to IPA. Also the
>     >>>>         ipa-client-install script says,
>     >>>>
>     >>>>         [root at freeipa-poc-client02 ~]# ipa-client-install
>     >>>>         DNS discovery failed to determine your DNS domain
>     >>>>         Provide the domain name of your IPA server (ex:
>     example.com <http://example.com>
>     >>>>         <http://example.com>):
>     >>>>
>     >>>>         I can resolve -anything- from the machine using dig
>     or whatever.
>     >>>>
>     >>>>         Ultimately, the reason I started to be concerned about my
>     >>>>         IPA server's DNS config was because I was not able to
>     >>>>         authenticate AD accounts to a client machine. I saw a
>     bunch
>     >>>>         of errors in the client's sssd logs which of course I
>     can't
>     >>>>         find now.
>     >>>>
>     >>>>         Perhaps it was these . . .
>     >>>>
>     >>>>         (Thu Dec  4 13:45:23 2014) [sssd] [ping_check] (0x0100):
>     >>>>         Service nss replied to ping
>     >>>>         (Thu Dec  4 13:45:23 2014) [sssd] [ping_check] (0x0100):
>     >>>>         Service sudo replied to ping
>     >>>>         (Thu Dec  4 13:45:23 2014) [sssd] [ping_check] (0x0100):
>     >>>>         Service pam replied to ping
>     >>>>         (Thu Dec  4 13:45:23 2014) [sssd] [ping_check] (0x0100):
>     >>>>         Service ssh replied to ping
>     >>>>         (Thu Dec  4 13:45:23 2014) [sssd] [ping_check] (0x0100):
>     >>>>         Service pac replied to ping
>     >>>>         (Thu Dec  4 13:45:23 2014) [sssd] [ping_check] (0x0100):
>     >>>>         Service bo3.e-bozo.com <http://bo3.e-bozo.com>
>     <http://bo3.e-bozo.com> replied to ping
>     >>>>
>     >>>>         I'm not allowed onto the AD domain controllers to examine
>     >>>>         log files or I'd be checking those first.
>     >>>>
>     >>>>         So ultimately the goal is to authenticate AD users
>     and users
>     >>>>         that exist in our ldap schema. We need to set up
>     groups of
>     >>>>         users that can run sudo commands on specific groups
>     of hosts.
>     >>>
>     >>>         Did you setup trusts as explained on the following page?
>     >>> http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup
>     >>>
>     >>>
>     >>>>
>     >>>>
>     >>>>
>     >>>>         On Wed, Dec 3, 2014 at 3:46 AM, Petr Spacek
>     >>>>         <pspacek at redhat.com <mailto:pspacek at redhat.com>
>     <mailto:pspacek at redhat.com <mailto:pspacek at redhat.com>>> wrote:
>     >>>>
>     >>>>             On 3.12.2014 04:35, Dmitri Pal wrote:
>     >>>>             > On 12/02/2014 08:54 PM, Matthew Herzog wrote:
>     >>>>             >> Any other ideas? I just spun up a new VM and
>     took the
>     >>>>             defaults on everything
>     >>>>             >> while running ipa-server-install (the defaults did
>     >>>>             make sense) and my new VM
>     >>>>             >> can't resolve -anything- in the domain in which it
>     >>>>             lives. The "old" VM
>     >>>>             >> (running the same versions of everything on
>     the same
>     >>>>             OS) can't even resolve
>     >>>>             >> the clients I have registered with it!
>     >>>>             >>
>     >>>>             >> So I'm pretty frustrated and am wondering, what
>     >>>>             _exactly_ is the role of
>     >>>>             >> bind in the IPA server and how is it expected
>     to know
>     >>>>             anything about the
>     >>>>             >> local DNS domain without becoming a bind slave
>     server?
>     >>>>             >
>     >>>>             > I am not sure I am 100% with you but...
>     >>>>             > If you use the defaults and nothing else you get to
>     >>>>             the scenario when IPA has
>     >>>>             > its DNS but it is a self contained environment. It
>     >>>>             seems that this is what you
>     >>>>             > observe.
>     >>>>             > It is expected that you decide in advance what you
>     >>>>             want to do with DNS. There
>     >>>>             > are several options:
>     >>>>             > 1) You can delegate a zone to IPA to manage,
>     then you
>     >>>>             need to connect your IPA
>     >>>>             > DNS to your existing DNS during install or after.
>     >>>>             > In this case the systems joined to IPA will be
>     a part
>     >>>>             of IPA domain/zone and
>     >>>>             > would also be able to resolve other systems around
>     >>>>             > 2) Not use IPA DNS if you do not want to take
>     >>>>             advantage of it
>     >>>>             > 3) Have a self contained demo/lab environment
>     that you
>     >>>>             currently observe.
>     >>>>             >
>     >>>>             > What is the intent?
>     >>>>
>     >>>>             I agree with Dmitri, we need more information
>     from you:
>     >>>>             - You said "my new VM can't resolve -anything- in the
>     >>>>             domain in which it
>     >>>>             lives." - Which domain do you mean?
>     >>>>
>     >>>>             - Apparently you have configured FreeIPA to serve
>     zone
>     >>>> e-bozo.com <http://e-bozo.com> <http://e-bozo.com>. Do you have
>     >>>>             this zone configured on some other DNS server at the
>     >>>>             same time?
>     >>>>
>     >>>>             Please keep in mind that authoritative servers should
>     >>>>             share the database. You
>     >>>>             will get naming collisions if e-bozo.com
>     <http://e-bozo.com>
>     >>>>             <http://e-bozo.com> is served by FreeIPA DNS
>     servers and
>     >>>>             some other servers at the same time. Maybe that is the
>     >>>>             problem you see right now.
>     >>>>
>     >>>>             As Dmitri said, the architecturally correct
>     solution is
>     >>>>             to decide if you want
>     >>>>             to use FreeIPA DNS or not. You have option to either
>     >>>>             remove non-FreeIPA DNS
>     >>>>             servers and import data to FreeIPA or to add
>     >>>>             FreeIPA-specific DNS records to
>     >>>>             existing DNS servers and do not configure FreeIPA
>     to act
>     >>>>             as DNS server.
>     >>>>
>     >>>>             Petr^2 Spacek
>     >>>>
>     >>>>             >> Thanks.
>     >>>>             >>
>     >>>>             >> On Tue, Dec 2, 2014 at 11:58 AM, Petr Spacek
>     >>>>             <pspacek at redhat.com <mailto:pspacek at redhat.com>
>     <mailto:pspacek at redhat.com <mailto:pspacek at redhat.com>>
>     >>>>             >> <mailto:pspacek at redhat.com
>     <mailto:pspacek at redhat.com>
>     >>>>             <mailto:pspacek at redhat.com
>     <mailto:pspacek at redhat.com>>>> wrote:
>     >>>>             >>
>     >>>>             >>     On 2.12.2014 17:36, Martin Basti wrote:
>     >>>>             >>     > On 02/12/14 17:28, Matthew Herzog wrote:
>     >>>>             >>     >> I just realized that my IPA servers cannot
>     >>>>             resolve ANY servers
>     >>>>             >>     in my domain.
>     >>>>             >>     >> What do I need to do to fix this? Below
>     is my
>     >>>>             named.conf.
>     >>>>             >>     >>
>     >>>>             >>     >>
>     >>>>             >>     >> options {
>     >>>>             >>     >>  // turns on IPv6 for port 53, IPv4 is
>     on by
>     >>>>             default for
>     >>>>             >>     all ifaces
>     >>>>             >>     >> listen-on-v6 {any;};
>     >>>>             >>     >>
>     >>>>             >>     >>  // Put files that named is allowed to
>     write
>     >>>>             in the
>     >>>>             >>     data/ directory:
>     >>>>             >>     >> directory "/var/named"; // the default
>     >>>>             >>     >> dump-file "data/cache_dump.db";
>     >>>>             >>     >> statistics-file "data/named_stats.txt";
>     >>>>             >>     >> memstatistics-file
>     "data/named_mem_stats.txt";
>     >>>>             >>     >>
>     >>>>             >>     >> forward first;
>     >>>>             >>     >> forwarders {
>     >>>>             >>     >>     10.100.8.41;
>     >>>>             >>     >>     10.100.8.40;
>     >>>>             >>     >>     10.100.4.13;
>     >>>>             >>     >>     10.100.4.14;
>     >>>>             >>     >>     10.100.4.19;
>     >>>>             >>     >>     10.100.4.44;
>     >>>>             >>     >>  };
>     >>>>             >>     >>
>     >>>>             >>     >>  // Any host is permitted to issue
>     recursive
>     >>>>             queries
>     >>>>             >>     >> allow-recursion { any; };
>     >>>>             >>     >>
>     >>>>             >>     >> tkey-gssapi-keytab "/etc/named.keytab";
>     >>>>             >>     >> pid-file "/run/named/named.pid";
>     >>>>             >>     >> };
>     >>>>             >>     >>
>     >>>>             >>     >> /* If you want to enable debugging, eg.
>     using
>     >>>>             the 'rndc trace'
>     >>>>             >>     command,
>     >>>>             >>     >>  * By default, SELinux policy does not
>     allow
>     >>>>             named to modify
>     >>>>             >>     the /var/named
>     >>>>             >>     >> directory,
>     >>>>             >>     >>  * so put the default debug log file in
>     data/ :
>     >>>>             >>     >>  */
>     >>>>             >>     >> logging {
>     >>>>             >>     >> channel default_debug {
>     >>>>             >>     >>     file "data/named.run";
>     >>>>             >>     >>     severity dynamic;
>     >>>>             >>     >>     print-time yes;
>     >>>>             >>     >>  };
>     >>>>             >>     >>  };
>     >>>>             >>     >> };
>     >>>>             >>     >>
>     >>>>             >>     >> zone "." IN {
>     >>>>             >>     >>  type hint;
>     >>>>             >>     >>  file "named.ca <http://named.ca>
>     <http://named.ca>
>     >>>>             <http://named.ca> <http://named.ca>";
>     >>>>             >>     >> };
>     >>>>             >>     >>
>     >>>>             >>     >> include "/etc/named.rfc1912.zones";
>     >>>>             >>     >>
>     >>>>             >>     >> dynamic-db "ipa" {
>     >>>>             >>     >> library "ldap.so";
>     >>>>             >>     >>  arg "uri
>     >>>>             >>
>     ldapi://%2fvar%2frun%2fslapd-BO3-E-BOZO-COM.socket";
>     >>>>             >>     >>  arg "base cn=dns,
>     dc=bo3,dc=e-bozo,dc=com";
>     >>>>             >>     >>  arg "fake_mname
>     freeipa-poc01.bo3.e-bozo.com <http://freeipa-poc01.bo3.e-bozo.com>
>     >>>>             <http://freeipa-poc01.bo3.e-bozo.com>
>     >>>>             >>     <http://freeipa-poc01.bo3.e-bozo.com>
>     >>>>             >>     >> <http://freeipa-poc01.bo3.e-bozo.com>.";
>     >>>>             >>     >>  arg "auth_method sasl";
>     >>>>             >>     >>  arg "sasl_mech GSSAPI";
>     >>>>             >>     >>  arg "sasl_user
>     >>>>             DNS/freeipa-poc01.bo3.e-bozo.com
>     <http://freeipa-poc01.bo3.e-bozo.com>
>     >>>>             <http://freeipa-poc01.bo3.e-bozo.com>
>     >>>>             >>     <http://freeipa-poc01.bo3.e-bozo.com>
>     >>>>             >>     >> <http://freeipa-poc01.bo3.e-bozo.com>";
>     >>>>             >>     >>  arg "serial_autoincrement yes";
>     >>>>             >>     >> };
>     >>>>             >>     >>
>     >>>>             >>     >>
>     >>>>             >>     >>
>     >>>>             >>     >>
>     >>>>             >>     > Hello,
>     >>>>             >>     >
>     >>>>             >>     > which version ipa do you use? which
>     platform?
>     >>>>             Which version
>     >>>>             >>  bind-dyndb-ldap?
>     >>>>             >>     >
>     >>>>             >>     > Can you run these commands, and check if
>     there
>     >>>>             any errors?
>     >>>>             >>     > ipactl status
>     >>>>             >>     > systemctl status named  (respectively
>     >>>>             journalctl -u named)
>     >>>>             >>
>     >>>>             >>     We also may want to see information listed
>     on page
>     >>>>             >>
>     >>>> https://fedorahosted.org/bind-dyndb-ldap/wiki/BugReporting
>
>     --
>     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
>
>
>
>
> -- 
> If life gives you melons, you may be dyslexic.
>
>


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141208/da615426/attachment.htm>

From gianluca.cecchi at gmail.com  Mon Dec  8 14:47:39 2014
From: gianluca.cecchi at gmail.com (Gianluca Cecchi)
Date: Mon, 8 Dec 2014 15:47:39 +0100
Subject: [Freeipa-users] Problem adding group after update IPA from CentOS
	6.6 to 7.0
Message-ID: <CAG2kNCzuj7goy+gHh0kvM7mrqn9o77rMvewJKRq6KeXqqZCYKw@mail.gmail.com>

Hello,
I followed the guide here to migrate IPA from CentOS 6.6 to CentOS 7.0:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/upgrading.html

Now, adding a group from console with command
ipa group-add
I get this kind of error:
ipa: ERROR: Operations error: Allocation of a new value for range cn=posix
ids,cn=distributed numeric assignment plugin,cn=plugins,cn=config failed!
Unable to proceed.

the same if I add from web gui without specifying GID.
Instead if I specify a GID it gets completed, both from console and web gui

[root at c7server slapd-LOCALDOMAIN-LOCAL]# ipa group-add --gid 1639600009
Group name: mynewgroup
Description: My New Group
-----------------------
Added group "mynewgroup"
-----------------------
  Group name: mynewgroup
  Description: My New Group
  GID: 1639600009


I notice that previously created groups (from command line) in 6.5 got GIDs
starting from 1639600001.
The system generated groups admins and editors have 1639600000
and 1639600002.

my dna config in migrated CentOS 7 server is this:

dn: cn=Posix IDs,cn=Distributed Numeric Assignment
Plugin,cn=plugins,cn=config
objectClass: top
objectClass: extensibleObject
cn: Posix IDs
dnaType: uidNumber
dnaType: gidNumber
dnaNextValue: 1101
dnaMaxValue: 1100
dnaMagicRegen: -1
dnaFilter:
(|(objectClass=posixAccount)(objectClass=posixGroup)(objectClass=ip
 aIDobject))
dnaScope: dc=localdomain,dc=local
dnaThreshold: 500
dnaSharedCfgDN: cn=posix-ids,cn=dna,cn=ipa,cn=etc,dc=localdomain,dc=local
creatorsName: cn=directory manager
modifiersName: cn=directory manager
createTimestamp: 20141206144811Z
modifyTimestamp: 20141206144811Z
aci: (targetattr=dnaNextRange || dnaNextValue || dnaMaxValue)(version
3.0;acl
 "permission:Modify DNA Range";allow (write) groupdn = "ldap:///cn=Modify
DNA
 Range,cn=permissions,cn=pbac,dc=localdomain,dc=local";)

My CentOS 6.5 server was created with command
ipa-server-install
without any options

And after install, the creation of the first userid got this output....

[root at infra install]# ipa user-add
First name: Gianluca
Last name: Cecchi
User login [gcecchi]:
--------------------
Added user "gcecchi"
--------------------
  User login: gcecchi
  First name: Gianluca
  Last name: Cecchi
  Full name: Gianluca Cecchi
  Display name: Gianluca Cecchi
  Initials: GC
  Home directory: /home/gcecchi
  GECOS field: Gianluca Cecchi
  Login shell: /bin/sh
  Kerberos principal: gcecchi at LOCALDOMAIN.LOCAL
  Email address: gcecchi at localdomain.local
  UID: 1639600001
  GID: 1639600001
  Password: False
  Kerberos keys available: False

So the GID was autoset to 1639600001
Could it be that sort of "dnaNextRange:" was not migrated from CentOS 6.5
to CentOS 7.0?

I found this kind of information in manual about adding ranges...

ldapmodify -x -D "cn=Directory Manager" -W -h server.example.com -p 389
Enter LDAP Password: *******
dn: cn=POSIX IDs,cn=Distributed Numeric Assignment
Plugin,cn=plugins,cn=config
changetype: modify
add: dnaNextRange
dnaNextRange: 123400000-123500000

But I also see in CentOS 7 config thei line that I don't understand...
aci: (targetattr=dnaNextRange || dnaNextValue || dnaMaxValue)(version
3.0;acl
 "permission:Modify DNA Range";allow (write) groupdn = "ldap:///cn=Modify
DNA
 Range,cn=permissions,cn=pbac,dc=localdomain,dc=local";)


Inside the log file about the required schema update for CentOS 6.5 to be
run before creating replica for CentOS 7 I see:

2014-12-06T11:42:10Z INFO Updating existing entry: cn=Posix
IDs,cn=Distributed Numeric Assignment Plugin,cn
=plugins,cn=config
2014-12-06T11:42:10Z DEBUG ---------------------------------------------
2014-12-06T11:42:10Z DEBUG Initial value
2014-12-06T11:42:10Z DEBUG dn: cn=Posix IDs,cn=Distributed Numeric
Assignment Plugin,cn=plugins,cn=config
2014-12-06T11:42:10Z DEBUG dnascope: dc=localdomain,dc=local
2014-12-06T11:42:10Z DEBUG dnathreshold: 500
2014-12-06T11:42:10Z DEBUG cn: Posix IDs
2014-12-06T11:42:10Z DEBUG objectclass:
2014-12-06T11:42:10Z DEBUG      top
2014-12-06T11:42:10Z DEBUG      extensibleObject
2014-12-06T11:42:10Z DEBUG dnanextvalue: 1639600008
2014-12-06T11:42:10Z DEBUG dnamagicregen: 999
2014-12-06T11:42:10Z DEBUG dnafilter:
(|(objectClass=posixAccount)(objectClass=posixGroup)(objectClass=ipaI
Dobject))
2014-12-06T11:42:10Z DEBUG dnatype:
2014-12-06T11:42:10Z DEBUG      uidNumber
2014-12-06T11:42:10Z DEBUG      gidNumber
2014-12-06T11:42:10Z DEBUG dnamaxvalue: 1639799999
2014-12-06T11:42:10Z DEBUG dnasharedcfgdn:
cn=posix-ids,cn=dna,cn=ipa,cn=etc,dc=localdomain,dc=local
2014-12-06T11:42:10Z DEBUG replace:
(|(objectclass=posixAccount)(objectClass=posixGroup)) not found, skipping
2014-12-06T11:42:10Z DEBUG ---------------------------------------------
2014-12-06T11:42:10Z DEBUG Final value after applying updates
2014-12-06T11:42:10Z DEBUG dn: cn=Posix IDs,cn=Distributed Numeric
Assignment Plugin,cn=plugins,cn=config
2014-12-06T11:42:10Z DEBUG dnascope: dc=localdomain,dc=local
2014-12-06T11:42:10Z DEBUG dnathreshold: 500
2014-12-06T11:42:10Z DEBUG cn: Posix IDs
2014-12-06T11:42:10Z DEBUG objectclass:
2014-12-06T11:42:10Z DEBUG      top
2014-12-06T11:42:10Z DEBUG      extensibleObject
2014-12-06T11:42:10Z DEBUG dnanextvalue: 1639600008
2014-12-06T11:42:10Z DEBUG dnamagicregen: 999
2014-12-06T11:42:10Z DEBUG dnafilter:
(|(objectClass=posixAccount)(objectClass=posixGroup)(objectClass=ipaIDobject))
2014-12-06T11:42:10Z DEBUG dnatype:
2014-12-06T11:42:10Z DEBUG      uidNumber
2014-12-06T11:42:10Z DEBUG      gidNumber
2014-12-06T11:42:10Z DEBUG dnamaxvalue: 1639799999
2014-12-06T11:42:10Z DEBUG dnasharedcfgdn:
cn=posix-ids,cn=dna,cn=ipa,cn=etc,dc=localdomain,dc=local
2014-12-06T11:42:10Z DEBUG []
2014-12-06T11:42:10Z DEBUG Live 1, updated 0
2014-12-06T11:42:10Z INFO Done

Thanks in advance for any insight and help to fix the problem.

Gianluca
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141208/0f35352c/attachment.htm>

From simo at redhat.com  Mon Dec  8 14:48:01 2014
From: simo at redhat.com (Simo Sorce)
Date: Mon, 8 Dec 2014 09:48:01 -0500
Subject: [Freeipa-users] DNS configuration
In-Reply-To: <5485AE96.7020604@redhat.com>
References: <CABhyZ34TCzUz+fNUSCvdZ38MS7rsLMMdb_jTdfKUsmYs86fn_Q@mail.gmail.com>
	<547DEA9E.2030203@redhat.com> <547DEFB5.1020205@redhat.com>
	<CABhyZ347EU+Q85jQJGU30yx4njC3OtL_QsJZi1MMu1ZR2Lfd2Q@mail.gmail.com>
	<547E851C.1020407@redhat.com> <547ECDDC.3090001@redhat.com>
	<CABhyZ37XChaQF+4rRY-L=OU9pVNp7Mw_NQifTk3NhrewzJtyVQ@mail.gmail.com>
	<5485108E.60409@redhat.com>
	<CABhyZ36DDM6icM+haMbVErdVdDWonGqbPE+3Tpad4K=u9QHjAQ@mail.gmail.com>
	<54851385.3050709@redhat.com>
	<CABhyZ36D_SVLezC=wZ3tsYHn00tdBGsxpOxCtpVgWZo8EdH2hw@mail.gmail.com>
	<548522B8.8040805@redhat.com> <5485599E.8030801@redhat.com>
	<CABhyZ34Pbr4J6YDdLSmP=qPqAB7Pa=tWvw273aB-BNX4dRq-GQ@mail.gmail.com>
	<5485AE96.7020604@redhat.com>
Message-ID: <20141208094801.209dc7d2@willson.usersys.redhat.com>

On Mon, 08 Dec 2014 08:58:46 -0500
Dmitri Pal <dpal at redhat.com> wrote:

> > Perhaps I should have explained that we are not going to set up a
> > new DNS domain for the ipa-managed servers.

Note that if you cannot set up a new DNS domain and this domain is the
same as the AD domain then you cannot to the stuff Dmitri describe
below. The only way to have accounts on freeipa in this case is to use
the winsync method, which has a number of limitation.
Also clients will be rather confused when you try to
ipa-client-install as they will find AD servers instead of ipa servers,
finally you'll have to use a different realm name for the IPA domain,
one that doesn't match the AD domain.

HTH,
Simo.

> > We have an Oracle dsee7
> > server doing LDAP for our Linux servers and accounts. We want to
> > migrate to IPA so we don't have to maintain a Linux/LDAP account
> > for every user who needs access to Linux servers. All of our users
> > start with an account in AD and since none of my predecessors knew
> > about Winbind, they set up dsee7.
> >
> > So I'm thinking we'll need to import all our dsee7 accounts AND
> > make it possible for AD users to access the Linux systems without
> > needing to create them in IPA.  
> 
> 
> So the approach would be:
> 
> 1) Install IPA (do not migrate users)
> 2) Establish trust with AD
> 3) Start switching client configuration from using LDAP with dsee7 to 
> SSSD pointing to IPA
> 
> You do not need to migrate users.



-- 
Simo Sorce * Red Hat, Inc * New York



From matthew.herzog at gmail.com  Mon Dec  8 15:07:06 2014
From: matthew.herzog at gmail.com (Matthew Herzog)
Date: Mon, 8 Dec 2014 10:07:06 -0500
Subject: [Freeipa-users] DNS configuration
In-Reply-To: <20141208094801.209dc7d2@willson.usersys.redhat.com>
References: <CABhyZ34TCzUz+fNUSCvdZ38MS7rsLMMdb_jTdfKUsmYs86fn_Q@mail.gmail.com>
	<547DEA9E.2030203@redhat.com> <547DEFB5.1020205@redhat.com>
	<CABhyZ347EU+Q85jQJGU30yx4njC3OtL_QsJZi1MMu1ZR2Lfd2Q@mail.gmail.com>
	<547E851C.1020407@redhat.com> <547ECDDC.3090001@redhat.com>
	<CABhyZ37XChaQF+4rRY-L=OU9pVNp7Mw_NQifTk3NhrewzJtyVQ@mail.gmail.com>
	<5485108E.60409@redhat.com>
	<CABhyZ36DDM6icM+haMbVErdVdDWonGqbPE+3Tpad4K=u9QHjAQ@mail.gmail.com>
	<54851385.3050709@redhat.com>
	<CABhyZ36D_SVLezC=wZ3tsYHn00tdBGsxpOxCtpVgWZo8EdH2hw@mail.gmail.com>
	<548522B8.8040805@redhat.com> <5485599E.8030801@redhat.com>
	<CABhyZ34Pbr4J6YDdLSmP=qPqAB7Pa=tWvw273aB-BNX4dRq-GQ@mail.gmail.com>
	<5485AE96.7020604@redhat.com>
	<20141208094801.209dc7d2@willson.usersys.redhat.com>
Message-ID: <CABhyZ36a7RCg2SzXeM9xzhVTtJto_T8eJcpAFAZ2p_PHVSo2ig@mail.gmail.com>

My Linux/LDAP domain is lnx.e-bozo.com. The AD domain is ad.e-bozo.com.
This has always been the case. I set up my FreeIPA server in the
lnx.e-bozo.com domain using realm LNX.E-BOZO.COM. In light of this, how
should I proceed?

On Mon, Dec 8, 2014 at 9:48 AM, Simo Sorce <simo at redhat.com> wrote:

> On Mon, 08 Dec 2014 08:58:46 -0500
> Dmitri Pal <dpal at redhat.com> wrote:
>
> > > Perhaps I should have explained that we are not going to set up a
> > > new DNS domain for the ipa-managed servers.
>
> Note that if you cannot set up a new DNS domain and this domain is the
> same as the AD domain then you cannot to the stuff Dmitri describe
> below. The only way to have accounts on freeipa in this case is to use
> the winsync method, which has a number of limitation.
> Also clients will be rather confused when you try to
> ipa-client-install as they will find AD servers instead of ipa servers,
> finally you'll have to use a different realm name for the IPA domain,
> one that doesn't match the AD domain.
>
> HTH,
> Simo.
>
> > > We have an Oracle dsee7
> > > server doing LDAP for our Linux servers and accounts. We want to
> > > migrate to IPA so we don't have to maintain a Linux/LDAP account
> > > for every user who needs access to Linux servers. All of our users
> > > start with an account in AD and since none of my predecessors knew
> > > about Winbind, they set up dsee7.
> > >
> > > So I'm thinking we'll need to import all our dsee7 accounts AND
> > > make it possible for AD users to access the Linux systems without
> > > needing to create them in IPA.
> >
> >
> > So the approach would be:
> >
> > 1) Install IPA (do not migrate users)
> > 2) Establish trust with AD
> > 3) Start switching client configuration from using LDAP with dsee7 to
> > SSSD pointing to IPA
> >
> > You do not need to migrate users.
>
>
>
> --
> Simo Sorce * Red Hat, Inc * New York
>
> --
> 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
>



-- 
If life gives you melons, you may be dyslexic.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141208/c6db62b2/attachment.htm>

From gianluca.cecchi at gmail.com  Mon Dec  8 15:17:19 2014
From: gianluca.cecchi at gmail.com (Gianluca Cecchi)
Date: Mon, 8 Dec 2014 16:17:19 +0100
Subject: [Freeipa-users] Problem adding group after update IPA from
	CentOS 6.6 to 7.0
In-Reply-To: <CAG2kNCzuj7goy+gHh0kvM7mrqn9o77rMvewJKRq6KeXqqZCYKw@mail.gmail.com>
References: <CAG2kNCzuj7goy+gHh0kvM7mrqn9o77rMvewJKRq6KeXqqZCYKw@mail.gmail.com>
Message-ID: <CAG2kNCz9yRkEeKiR2EYSEL3AbBhyQUo6CYw61chs3h9Rm-tBEw@mail.gmail.com>

On Mon, Dec 8, 2014 at 3:47 PM, Gianluca Cecchi <gianluca.cecchi at gmail.com>
wrote:

> Hello,
> I followed the guide here to migrate IPA from CentOS 6.6 to CentOS 7.0:
>
> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/upgrading.html
>
> Now, adding a group from console with command
> ipa group-add
> I get this kind of error:
> ipa: ERROR: Operations error: Allocation of a new value for range cn=posix
> ids,cn=distributed numeric assignment plugin,cn=plugins,cn=config failed!
> Unable to proceed.
>
>
>
Based on info on og of CentOS 6.5 system, at the moment I solved the
probelm this way and it seems it works.
Let me know if you think I misunderstood anything.

created /root/dna_addrange.ldif
dn: cn=POSIX IDs,cn=Distributed Numeric Assignment
Plugin,cn=plugins,cn=config
changetype: modify
add: dnaNextRange
dnaNextRange: 1639600001-1639799999
-

[root at c7server slapd-LOCALDOMAIN-LOCAL]# ldapmodify -x -D "cn=Directory
Manager" -f /root/dna_addrange.ldif -W
Enter LDAP Password:
modifying entry "cn=POSIX IDs,cn=Distributed Numeric Assignment
Plugin,cn=plugins,cn=config"

Now the group create command automatically insert an unallocated GID
1639600005:
[root at c7server slapd-LOCALDOMAIN-LOCAL]# ipa group-add
Group name: testgroup
Description: test group per generazione gid
-----------------------
Added group "testgroup"
-----------------------
  Group name: testgroup
  Description: test group per generazione gid
  GID: 1639600005

Gianluca
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141208/16db510f/attachment.htm>

From dpal at redhat.com  Mon Dec  8 15:29:15 2014
From: dpal at redhat.com (Dmitri Pal)
Date: Mon, 08 Dec 2014 10:29:15 -0500
Subject: [Freeipa-users] DNS configuration
In-Reply-To: <CABhyZ36a7RCg2SzXeM9xzhVTtJto_T8eJcpAFAZ2p_PHVSo2ig@mail.gmail.com>
References: <CABhyZ34TCzUz+fNUSCvdZ38MS7rsLMMdb_jTdfKUsmYs86fn_Q@mail.gmail.com>	<547DEA9E.2030203@redhat.com>	<547DEFB5.1020205@redhat.com>	<CABhyZ347EU+Q85jQJGU30yx4njC3OtL_QsJZi1MMu1ZR2Lfd2Q@mail.gmail.com>	<547E851C.1020407@redhat.com>	<547ECDDC.3090001@redhat.com>	<CABhyZ37XChaQF+4rRY-L=OU9pVNp7Mw_NQifTk3NhrewzJtyVQ@mail.gmail.com>	<5485108E.60409@redhat.com>	<CABhyZ36DDM6icM+haMbVErdVdDWonGqbPE+3Tpad4K=u9QHjAQ@mail.gmail.com>	<54851385.3050709@redhat.com>	<CABhyZ36D_SVLezC=wZ3tsYHn00tdBGsxpOxCtpVgWZo8EdH2hw@mail.gmail.com>	<548522B8.8040805@redhat.com>	<5485599E.8030801@redhat.com>	<CABhyZ34Pbr4J6YDdLSmP=qPqAB7Pa=tWvw273aB-BNX4dRq-GQ@mail.gmail.com>	<5485AE96.7020604@redhat.com>	<20141208094801.209dc7d2@willson.usersys.redhat.com>
	<CABhyZ36a7RCg2SzXeM9xzhVTtJto_T8eJcpAFAZ2p_PHVSo2ig@mail.gmail.com>
Message-ID: <5485C3CB.5050704@redhat.com>

On 12/08/2014 10:07 AM, Matthew Herzog wrote:
> My Linux/LDAP domain is lnx.e-bozo.com <http://lnx.e-bozo.com>. The AD 
> domain is ad.e-bozo.com <http://ad.e-bozo.com>. This has always been 
> the case. I set up my FreeIPA server in the lnx.e-bozo.com 
> <http://lnx.e-bozo.com> domain using realm LNX.E-BOZO.COM 
> <http://LNX.E-BOZO.COM>. In light of this, how should I proceed?

If you prefer to continue using your DNS servers then you need to add 
all DNS records that FreeIPA defined for you at the end of the 
installation, manually to your DNS.
As soon as you did this you should be able to establish the trust.

You would need to update your DNS server with any new replicas you add.

>
> On Mon, Dec 8, 2014 at 9:48 AM, Simo Sorce <simo at redhat.com 
> <mailto:simo at redhat.com>> wrote:
>
>     On Mon, 08 Dec 2014 08:58:46 -0500
>     Dmitri Pal <dpal at redhat.com <mailto:dpal at redhat.com>> wrote:
>
>     > > Perhaps I should have explained that we are not going to set up a
>     > > new DNS domain for the ipa-managed servers.
>
>     Note that if you cannot set up a new DNS domain and this domain is the
>     same as the AD domain then you cannot to the stuff Dmitri describe
>     below. The only way to have accounts on freeipa in this case is to use
>     the winsync method, which has a number of limitation.
>     Also clients will be rather confused when you try to
>     ipa-client-install as they will find AD servers instead of ipa
>     servers,
>     finally you'll have to use a different realm name for the IPA domain,
>     one that doesn't match the AD domain.
>
>     HTH,
>     Simo.
>
>     > > We have an Oracle dsee7
>     > > server doing LDAP for our Linux servers and accounts. We want to
>     > > migrate to IPA so we don't have to maintain a Linux/LDAP account
>     > > for every user who needs access to Linux servers. All of our users
>     > > start with an account in AD and since none of my predecessors knew
>     > > about Winbind, they set up dsee7.
>     > >
>     > > So I'm thinking we'll need to import all our dsee7 accounts AND
>     > > make it possible for AD users to access the Linux systems without
>     > > needing to create them in IPA.
>     >
>     >
>     > So the approach would be:
>     >
>     > 1) Install IPA (do not migrate users)
>     > 2) Establish trust with AD
>     > 3) Start switching client configuration from using LDAP with
>     dsee7 to
>     > SSSD pointing to IPA
>     >
>     > You do not need to migrate users.
>
>
>
>     --
>     Simo Sorce * Red Hat, Inc * New York
>
>     --
>     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
>
>
>
>
> -- 
> If life gives you melons, you may be dyslexic.


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141208/d93b1927/attachment.htm>

From pspacek at redhat.com  Mon Dec  8 15:41:12 2014
From: pspacek at redhat.com (Petr Spacek)
Date: Mon, 08 Dec 2014 16:41:12 +0100
Subject: [Freeipa-users] DNS configuration
In-Reply-To: <CABhyZ34Pbr4J6YDdLSmP=qPqAB7Pa=tWvw273aB-BNX4dRq-GQ@mail.gmail.com>
References: <CABhyZ34TCzUz+fNUSCvdZ38MS7rsLMMdb_jTdfKUsmYs86fn_Q@mail.gmail.com>	<547DEA9E.2030203@redhat.com>	<547DEFB5.1020205@redhat.com>	<CABhyZ347EU+Q85jQJGU30yx4njC3OtL_QsJZi1MMu1ZR2Lfd2Q@mail.gmail.com>	<547E851C.1020407@redhat.com>	<547ECDDC.3090001@redhat.com>	<CABhyZ37XChaQF+4rRY-L=OU9pVNp7Mw_NQifTk3NhrewzJtyVQ@mail.gmail.com>	<5485108E.60409@redhat.com>	<CABhyZ36DDM6icM+haMbVErdVdDWonGqbPE+3Tpad4K=u9QHjAQ@mail.gmail.com>	<54851385.3050709@redhat.com>	<CABhyZ36D_SVLezC=wZ3tsYHn00tdBGsxpOxCtpVgWZo8EdH2hw@mail.gmail.com>	<548522B8.8040805@redhat.com>	<5485599E.8030801@redhat.com>
	<CABhyZ34Pbr4J6YDdLSmP=qPqAB7Pa=tWvw273aB-BNX4dRq-GQ@mail.gmail.com>
Message-ID: <5485C698.9000406@redhat.com>

On 8.12.2014 14:44, Matthew Herzog wrote:
> Petr said, "You can run ipa-server-install *without* --setup-dns option and
> at the end of
> installation it will produce DNS records which you have to manually add to
> your existing DNS database."
> 
> I can't see how this would be useful or which machines I would need to add
> to our DNS.
> 
> Perhaps I should have explained that we are not going to set up a new DNS
> domain for the ipa-managed servers.
Good.

Now you should run ipa-server-install *without* --setup-dns, using
lnx.e-bozo.com as you IPA domain. It will install full IPA server and spit out
DNS zone file.

Then you *have to* take this zone file and import it to your existing DNS
infrastructure - that will give you fully functional IPA domain lnx.e-bozo.com.

Caveat:
Preceding text assumes that 'dsee7' is nor using either Kerberos nor DNS SRV
records for LDAP service in domain lnx.e-bozo.com, i.e. clients connecting to
DSEE7 should be (most likely) statically configured with DSEE7 server name.

Petr^2 Spacek

> We have an Oracle dsee7 server doing
> LDAP for our Linux servers and accounts. We want to migrate to IPA so we
> don't have to maintain a Linux/LDAP account for every user who needs access
> to Linux servers. All of our users start with an account in AD and since
> none of my predecessors knew about Winbind, they set up dsee7.
> 
> So I'm thinking we'll need to import all our dsee7 accounts AND make it
> possible for AD users to access the Linux systems without needing to create
> them in IPA.
> 
> On Mon, Dec 8, 2014 at 2:56 AM, Petr Spacek <pspacek at redhat.com> wrote:
> 
>> On 8.12.2014 05:02, Dmitri Pal wrote:
>>> On 12/07/2014 10:10 PM, Matthew Herzog wrote:
>>>> So should the FreeIPA server be authoritative for the Kerb. realm/DNS
>> domain
>>>> or can it/should it be a slave DNS server instead? Or caching only?
>>>
>>> IPA DNS can't be a slave so you either delegate a whole zone to it or
>> manage
>>> IPA DNS domain via your own DNS server.
>>
>> Generally, "slave" is not allowed to do any changes so it is useless in
>> your
>> scenario.
>>
>> You can run ipa-server-install *without* --setup-dns option and at the end
>> of
>> installation it will produce DNS records which you have to manually add to
>> your existing DNS database.
>>
>> Did you try that?
>>
>> Petr^2 Spacek
>>
>>>> On Sun, Dec 7, 2014 at 9:57 PM, Dmitri Pal <dpal at redhat.com
>>>> <mailto:dpal at redhat.com>> wrote:
>>>>
>>>>     On 12/07/2014 09:51 PM, Matthew Herzog wrote:
>>>>>     What must be done in or on the ipa server with regard to DNS, if
>>>>>     anything?
>>>>>
>>>>>     Our DNS works. It works well. We have four Linux DNS servers and
>>>>>     two AD domain controllers that also do DNS.
>>>>>
>>>>>     So if we already have DNS working well in our domain, why do we
>>>>>     want to manage DNS in IPA?
>>>>
>>>>     Let us keep the discussion on the list.
>>>>     IPA when used with AD trust presents itself as a separate forest.
>>>>     AD thinks that it is working with another AD forest.
>>>>     For that to work we need to follow MSFT rules about relationship
>>>>     between Kerberos realm and DNS domain.
>>>>     AD assumes that for every trusted forest Kerberos realm = DNS
>>>>     domain. IPA makes it easy to do because it has integrated tools to
>>>>     manage IPA DNS domain.
>>>>     If you want to manage it yourself through your DNS you can do it,
>>>>     just more manual operations for you.
>>>>
>>>>     HTH
>>>>
>>>>     Thanks
>>>>     Dmitri
>>>>
>>>>
>>>>>
>>>>>     On Sun, Dec 7, 2014 at 9:44 PM, Dmitri Pal <dpal at redhat.com
>>>>>     <mailto:dpal at redhat.com>> wrote:
>>>>>
>>>>>         On 12/07/2014 06:44 PM, Matthew Herzog wrote:
>>>>>>         Thanks guys. I'm sorry for my delay in responding.
>>>>>>
>>>>>>         Firstly, I was under the impression (from reading the docs)
>>>>>>         that having named running on IPA server was critical.
>>>>>
>>>>>         Properly configured DNS is critical.
>>>>>         How you accomplish it is up to you.
>>>>>         IPA allows you to have a DNS server that would simplify DNS
>>>>>         management but it can be done manually too. This is why DNS
>>>>>         is optional.
>>>>>
>>>>>
>>>>>>         Also, the first question the ipa-server-install script asks
>>>>>>         is, "Do you want to configure integrated DNS (BIND)? ."
>>>>>>         While it's true the default answer is no, it leads one to
>>>>>>         believe that DNS is central to IPA. Also the
>>>>>>         ipa-client-install script says,
>>>>>>
>>>>>>         [root at freeipa-poc-client02 ~]# ipa-client-install
>>>>>>         DNS discovery failed to determine your DNS domain
>>>>>>         Provide the domain name of your IPA server (ex: example.com
>>>>>>         <http://example.com>):
>>>>>>
>>>>>>         I can resolve -anything- from the machine using dig or
>> whatever.
>>>>>>
>>>>>>         Ultimately, the reason I started to be concerned about my
>>>>>>         IPA server's DNS config was because I was not able to
>>>>>>         authenticate AD accounts to a client machine. I saw a bunch
>>>>>>         of errors in the client's sssd logs which of course I can't
>>>>>>         find now.
>>>>>>
>>>>>>         Perhaps it was these . . .
>>>>>>
>>>>>>         (Thu Dec  4 13:45:23 2014) [sssd] [ping_check] (0x0100):
>>>>>>         Service nss replied to ping
>>>>>>         (Thu Dec  4 13:45:23 2014) [sssd] [ping_check] (0x0100):
>>>>>>         Service sudo replied to ping
>>>>>>         (Thu Dec  4 13:45:23 2014) [sssd] [ping_check] (0x0100):
>>>>>>         Service pam replied to ping
>>>>>>         (Thu Dec  4 13:45:23 2014) [sssd] [ping_check] (0x0100):
>>>>>>         Service ssh replied to ping
>>>>>>         (Thu Dec  4 13:45:23 2014) [sssd] [ping_check] (0x0100):
>>>>>>         Service pac replied to ping
>>>>>>         (Thu Dec  4 13:45:23 2014) [sssd] [ping_check] (0x0100):
>>>>>>         Service bo3.e-bozo.com <http://bo3.e-bozo.com> replied to
>> ping
>>>>>>
>>>>>>         I'm not allowed onto the AD domain controllers to examine
>>>>>>         log files or I'd be checking those first.
>>>>>>
>>>>>>         So ultimately the goal is to authenticate AD users and users
>>>>>>         that exist in our ldap schema. We need to set up groups of
>>>>>>         users that can run sudo commands on specific groups of hosts.
>>>>>
>>>>>         Did you setup trusts as explained on the following page?
>>>>>         http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>         On Wed, Dec 3, 2014 at 3:46 AM, Petr Spacek
>>>>>>         <pspacek at redhat.com <mailto:pspacek at redhat.com>> wrote:
>>>>>>
>>>>>>             On 3.12.2014 04:35, Dmitri Pal wrote:
>>>>>>             > On 12/02/2014 08:54 PM, Matthew Herzog wrote:
>>>>>>             >> Any other ideas? I just spun up a new VM and took the
>>>>>>             defaults on everything
>>>>>>             >> while running ipa-server-install (the defaults did
>>>>>>             make sense) and my new VM
>>>>>>             >> can't resolve -anything- in the domain in which it
>>>>>>             lives. The "old" VM
>>>>>>             >> (running the same versions of everything on the same
>>>>>>             OS) can't even resolve
>>>>>>             >> the clients I have registered with it!
>>>>>>             >>
>>>>>>             >> So I'm pretty frustrated and am wondering, what
>>>>>>             _exactly_ is the role of
>>>>>>             >> bind in the IPA server and how is it expected to know
>>>>>>             anything about the
>>>>>>             >> local DNS domain without becoming a bind slave server?
>>>>>>             >
>>>>>>             > I am not sure I am 100% with you but...
>>>>>>             > If you use the defaults and nothing else you get to
>>>>>>             the scenario when IPA has
>>>>>>             > its DNS but it is a self contained environment. It
>>>>>>             seems that this is what you
>>>>>>             > observe.
>>>>>>             > It is expected that you decide in advance what you
>>>>>>             want to do with DNS. There
>>>>>>             > are several options:
>>>>>>             > 1) You can delegate a zone to IPA to manage, then you
>>>>>>             need to connect your IPA
>>>>>>             > DNS to your existing DNS during install or after.
>>>>>>             > In this case the systems joined to IPA will be a part
>>>>>>             of IPA domain/zone and
>>>>>>             > would also be able to resolve other systems around
>>>>>>             > 2) Not use IPA DNS if you do not want to take
>>>>>>             advantage of it
>>>>>>             > 3) Have a self contained demo/lab environment that you
>>>>>>             currently observe.
>>>>>>             >
>>>>>>             > What is the intent?
>>>>>>
>>>>>>             I agree with Dmitri, we need more information from you:
>>>>>>             - You said "my new VM can't resolve -anything- in the
>>>>>>             domain in which it
>>>>>>             lives." - Which domain do you mean?
>>>>>>
>>>>>>             - Apparently you have configured FreeIPA to serve zone
>>>>>>             e-bozo.com <http://e-bozo.com>. Do you have
>>>>>>             this zone configured on some other DNS server at the
>>>>>>             same time?
>>>>>>
>>>>>>             Please keep in mind that authoritative servers should
>>>>>>             share the database. You
>>>>>>             will get naming collisions if e-bozo.com
>>>>>>             <http://e-bozo.com> is served by FreeIPA DNS servers and
>>>>>>             some other servers at the same time. Maybe that is the
>>>>>>             problem you see right now.
>>>>>>
>>>>>>             As Dmitri said, the architecturally correct solution is
>>>>>>             to decide if you want
>>>>>>             to use FreeIPA DNS or not. You have option to either
>>>>>>             remove non-FreeIPA DNS
>>>>>>             servers and import data to FreeIPA or to add
>>>>>>             FreeIPA-specific DNS records to
>>>>>>             existing DNS servers and do not configure FreeIPA to act
>>>>>>             as DNS server.
>>>>>>
>>>>>>             Petr^2 Spacek
>>>>>>
>>>>>>             >> Thanks.
>>>>>>             >>
>>>>>>             >> On Tue, Dec 2, 2014 at 11:58 AM, Petr Spacek
>>>>>>             <pspacek at redhat.com <mailto:pspacek at redhat.com>
>>>>>>             >> <mailto:pspacek at redhat.com
>>>>>>             <mailto:pspacek at redhat.com>>> wrote:
>>>>>>             >>
>>>>>>             >>     On 2.12.2014 17:36, Martin Basti wrote:
>>>>>>             >>     > On 02/12/14 17:28, Matthew Herzog wrote:
>>>>>>             >>     >> I just realized that my IPA servers cannot
>>>>>>             resolve ANY servers
>>>>>>             >>     in my domain.
>>>>>>             >>     >> What do I need to do to fix this? Below is my
>>>>>>             named.conf.
>>>>>>             >>     >>
>>>>>>             >>     >>
>>>>>>             >>     >> options {
>>>>>>             >>     >>  // turns on IPv6 for port 53, IPv4 is on by
>>>>>>             default for
>>>>>>             >>     all ifaces
>>>>>>             >>     >>  listen-on-v6 {any;};
>>>>>>             >>     >>
>>>>>>             >>     >>  // Put files that named is allowed to write
>>>>>>             in the
>>>>>>             >>     data/ directory:
>>>>>>             >>     >>  directory "/var/named"; // the default
>>>>>>             >>     >>  dump-file "data/cache_dump.db";
>>>>>>             >>     >>  statistics-file "data/named_stats.txt";
>>>>>>             >>     >>  memstatistics-file "data/named_mem_stats.txt";
>>>>>>             >>     >>
>>>>>>             >>     >>  forward first;
>>>>>>             >>     >>  forwarders {
>>>>>>             >>     >>          10.100.8.41;
>>>>>>             >>     >>          10.100.8.40;
>>>>>>             >>     >>          10.100.4.13;
>>>>>>             >>     >>          10.100.4.14;
>>>>>>             >>     >>          10.100.4.19;
>>>>>>             >>     >>          10.100.4.44;
>>>>>>             >>     >>  };
>>>>>>             >>     >>
>>>>>>             >>     >>  // Any host is permitted to issue recursive
>>>>>>             queries
>>>>>>             >>     >>  allow-recursion { any; };
>>>>>>             >>     >>
>>>>>>             >>     >>  tkey-gssapi-keytab "/etc/named.keytab";
>>>>>>             >>     >>  pid-file "/run/named/named.pid";
>>>>>>             >>     >> };
>>>>>>             >>     >>
>>>>>>             >>     >> /* If you want to enable debugging, eg. using
>>>>>>             the 'rndc trace'
>>>>>>             >>     command,
>>>>>>             >>     >>  * By default, SELinux policy does not allow
>>>>>>             named to modify
>>>>>>             >>     the /var/named
>>>>>>             >>     >> directory,
>>>>>>             >>     >>  * so put the default debug log file in data/ :
>>>>>>             >>     >>  */
>>>>>>             >>     >> logging {
>>>>>>             >>     >>  channel default_debug {
>>>>>>             >>     >>          file "data/named.run";
>>>>>>             >>     >>          severity dynamic;
>>>>>>             >>     >>          print-time yes;
>>>>>>             >>     >>  };
>>>>>>             >>     >>  };
>>>>>>             >>     >> };
>>>>>>             >>     >>
>>>>>>             >>     >> zone "." IN {
>>>>>>             >>     >>  type hint;
>>>>>>             >>     >>  file "named.ca <http://named.ca>
>>>>>>             <http://named.ca> <http://named.ca>";
>>>>>>             >>     >> };
>>>>>>             >>     >>
>>>>>>             >>     >> include "/etc/named.rfc1912.zones";
>>>>>>             >>     >>
>>>>>>             >>     >> dynamic-db "ipa" {
>>>>>>             >>     >>  library "ldap.so";
>>>>>>             >>     >>  arg "uri
>>>>>>             >>  ldapi://%2fvar%2frun%2fslapd-BO3-E-BOZO-COM.socket";
>>>>>>             >>     >>  arg "base cn=dns, dc=bo3,dc=e-bozo,dc=com";
>>>>>>             >>     >>  arg "fake_mname freeipa-poc01.bo3.e-bozo.com
>>>>>>             <http://freeipa-poc01.bo3.e-bozo.com>
>>>>>>             >>     <http://freeipa-poc01.bo3.e-bozo.com>
>>>>>>             >>     >> <http://freeipa-poc01.bo3.e-bozo.com>.";
>>>>>>             >>     >>  arg "auth_method sasl";
>>>>>>             >>     >>  arg "sasl_mech GSSAPI";
>>>>>>             >>     >>  arg "sasl_user
>>>>>>             DNS/freeipa-poc01.bo3.e-bozo.com
>>>>>>             <http://freeipa-poc01.bo3.e-bozo.com>
>>>>>>             >>     <http://freeipa-poc01.bo3.e-bozo.com>
>>>>>>             >>     >> <http://freeipa-poc01.bo3.e-bozo.com>";
>>>>>>             >>     >>  arg "serial_autoincrement yes";
>>>>>>             >>     >> };
>>>>>>             >>     >>
>>>>>>             >>     >>
>>>>>>             >>     >>
>>>>>>             >>     >>
>>>>>>             >>     > Hello,
>>>>>>             >>     >
>>>>>>             >>     > which version ipa do you use? which platform?
>>>>>>             Which version
>>>>>>             >>     bind-dyndb-ldap?
>>>>>>             >>     >
>>>>>>             >>     > Can you run these commands, and check if there
>>>>>>             any errors?
>>>>>>             >>     > ipactl status
>>>>>>             >>     > systemctl status named  (respectively
>>>>>>             journalctl -u named)
>>>>>>             >>
>>>>>>             >>     We also may want to see information listed on page
>>>>>>             >>
>>>>>>
>> https://fedorahosted.org/bind-dyndb-ldap/wiki/BugReporting

-- 
Petr^2 Spacek



From gianluca.cecchi at gmail.com  Mon Dec  8 16:44:28 2014
From: gianluca.cecchi at gmail.com (Gianluca Cecchi)
Date: Mon, 8 Dec 2014 17:44:28 +0100
Subject: [Freeipa-users] vSphere 5.1 and FreeIPA 3.3 on CentOS 7 finally
	works! [How I did it...]
Message-ID: <CAG2kNCyXWXxMx0V96bYgMq--9zaBwhWMBENrOgSXnMMr9=F85Q@mail.gmail.com>

Hello,
I finally was able to configure the integration between what in subject.
I have made basic tests and all seems ok.

If anyone wants to test further integration scenarios and also test with
vSPhere 5.5, he/she then can report here and I will crosscheck eventually.

My environment is based on pure vSphere 5.1 that I'm right now using in
trial mode with vcenter server defined as a virtual appliance.

NOTE that there is a bug in this version of vSphere regarding OpenLDAP
integration in vShere WebClient, so that you are unable to change Base DN
for groups after its initial configuration. In case you need to modify that
field, you have to delete and recreate the whole LDAP definition.
The bug is solved in vsphere 5.1 update 1a.

As suggested in other threads on this and other lists, I used slapi-nis
(schema compat) plugin.
Initially I tested it on CentOS 6.6 with IPA 3.0.0-42 and  slapi-nis-0.40-4.
I was able to get both users and groups enumeration in vSphere client
(using cn=accounts for bind definition), but then no authentication of
defined users due to inability of IPA 3.0 to do bind on compat tree.

I read on this list that I had to use IPA 3.3 and slapi-nis >= 0.47.5, how
is indeed provided now in CentOS 7 with:

ipa-server-3.3.3-28.0.1.el7.centos.3.x86_64
slapi-nis-0.52-4.el7.x86_64

So I migrated my IPA test server from CentOS 6.6 to another server in
CentOS 7.0, following the chapter 6 of the detailed guide here (only some
typos and use of "systemctl" commands for version 6 that should be read as
"service" commands instead):
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/upgrading.html

After update these were my two ldif files to adapt schema compat entries
for vSphere

1) vsphere_usermod.ldif

dn: cn=users,cn=Schema Compatibility,cn=plugins,cn=config
changetype: modify
add: schema-compat-entry-attribute
schema-compat-entry-attribute: objectclass=uniqueMember
-
add: schema-compat-entry-attribute
schema-compat-entry-attribute: objectclass=inetOrgPerson
-

2) vsphere_groupmod.ldif

dn: cn=groups,cn=Schema Compatibility,cn=plugins,cn=config
changetype: modify
add: schema-compat-entry-attribute
schema-compat-entry-attribute: objectclass=groupOfUniqueNames
-
add: schema-compat-entry-attribute
schema-compat-entry-attribute:
uniqueMember=%regsub("%{member}","^(.*)accounts(.*)","%1compat%2")
-

Applied with the command:
ldapmodify -x -D "cn=Directory Manager" -f /root/vsphere_usermod.ldif -W
vsphere_usermod.ldif

and
ldapmodify -x -D "cn=Directory Manager" -f /root/vsphere_usermod.ldif -W
vsphere_groupmod.ldif


Configuration in vSphere Web Client under Identity Sources of
Administration --> Sign-On and Discovery --> Configuration
was this one

Primary server URL: ldaps://c7server.localdomain.local:636
Base DN for users: cn=users,cn=compat,dc=localdomain,dc=local
Domain name: localdomain.local
Base DN for groups: cn=groups,cn=compat,dc=localdomain,dc=local
Authentication type: Password
Username: uid=vadmin,cn=users,cn=compat,dc=localdomain,dc=local

NOTE: vadmin is a normal IPA user I created only for bind with no ESX
permissions (it is only part of the default ipausers IPA group)

NOTE: I used ldaps and as certificate I had to use the file /etc/ipa/ca.crt
on IPA server, after copying to client where running the browser and
renaming it to ca.cer without any modification at all. vSphere accepted it
without any problem.

My tests at the moment have been ok both in vSphere fat client (5.1
1471691) and vSphere Web Client (Version 5.1.0 Build 869765). I tried this:

- add gcecchi IPA user at top vcenter server permissions level as a virtual
machine user (sample) default role
- verify gcecchi is able to connect both in fat and web clients
- edit settings of the vm VC1 and verify that the "add..." button in
hardware tab is greyed out
- add the defined esxpower IPA group at VC1 permissions level granting it
the virtual machine power user (sample) role
- logout/login gcecchi and verify nothing changed in his permissions
- add gcecchi to the IPA group esxpower
- logout/login gcecchi and verify the user now can select the "add..."
button in hardware tab of VC1
- logout gcecchi and remove gcecchi from IPA group esxpower
- login as gcecchi in vSphere and verify that now the "add..." button is
disabled again
- create an IPA group named esxnestedpower and insert it in esxpower group
- login as gcecchi in vSphere and verify he is still unable to add devices
- modify IPA user gcecchi adding him to esxnestedpower group
- logout/login gcecchi from vSphere and verify that now gcecchi is able to
add device to VC1

NOTE: as my tests began in CentOS 6.6, I noticed that the IPA groups
created in IPA 3.0 and CentOS 6.6 didn't get the uniqueMember property for
their group members... I didn't investigate more, but I noticed that for
the system group "admins" and for newly created groups, instead it was ok...
NOTE: after my migration from IPA 3.0 to 3.3 it seems I lost dna settings,
so that group addition failed without explicitly specifying its GID. I
solved as described here adding the missing dnaNextRange:
1639600001-1639799999:
https://www.redhat.com/archives/freeipa-users/2014-December/msg00090.html

Screenshot with permissions of VC1
https://drive.google.com/file/d/0BwoPbcrMv8mvdUgwanQzNWpBbkE/view?usp=sharing

Some outputs of ldapsearch queries:
[root at c7server slapd-LOCALDOMAIN-LOCAL]# ldapsearch -x -b
"cn=groups,cn=compat,dc=localdomain,dc=local" cn=esxpower
# extended LDIF
#
# LDAPv3
# base <cn=groups,cn=compat,dc=localdomain,dc=local> with scope subtree
# filter: cn=esxpower
# requesting: ALL
#

# esxpower, groups, compat, localdomain.local
dn: cn=esxpower,cn=groups,cn=compat,dc=localdomain,dc=local
objectClass: posixGroup
objectClass: groupOfUniqueNames
objectClass: top
gidNumber: 1639600010
memberUid: gcecchi
uniqueMember: cn=esxnestedpower,cn=groups,cn=compat,dc=localdomain,dc=local
cn: esxpower

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1


[root at c7server slapd-LOCALDOMAIN-LOCAL]# ldapsearch -x -b
"cn=groups,cn=compat,dc=localdomain,dc=local" cn=esxnestedpower
# extended LDIF
#
# LDAPv3
# base <cn=groups,cn=compat,dc=localdomain,dc=local> with scope subtree
# filter: cn=esxnestedpower
# requesting: ALL
#

# esxnestedpower, groups, compat, localdomain.local
dn: cn=esxnestedpower,cn=groups,cn=compat,dc=localdomain,dc=local
objectClass: posixGroup
objectClass: groupOfUniqueNames
objectClass: top
gidNumber: 1639600012
memberUid: gcecchi
uniqueMember: uid=gcecchi,cn=users,cn=compat,dc=localdomain,dc=local
cn: esxnestedpower

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

[root at c7server slapd-LOCALDOMAIN-LOCAL]# ldapsearch -x -b
"cn=users,cn=compat,dc=localdomain,dc=local" uid=gcecchi
# extended LDIF
#
# LDAPv3
# base <cn=users,cn=compat,dc=localdomain,dc=local> with scope subtree
# filter: uid=gcecchi
# requesting: ALL
#

# gcecchi, users, compat, localdomain.local
dn: uid=gcecchi,cn=users,cn=compat,dc=localdomain,dc=local
objectClass: posixAccount
objectClass: uniqueMember
objectClass: inetOrgPerson
objectClass: extensibleObject
objectClass: top
objectClass: organizationalPerson
objectClass: person
gecos: Gianluca Cecchi
cn: Gianluca Cecchi
uidNumber: 1639600001
gidNumber: 1639600001
loginShell: /bin/sh
homeDirectory: /home/gcecchi
uid: gcecchi

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1


Hope that this can help others trying to accomplish vSphere/IPA integration
and feel free to comment as I'm far from an IPA expert and my main approach
is RTFM and ask help... ;-)

Gianluca Cecchi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141208/1a6a1bd4/attachment.htm>

From dpal at redhat.com  Mon Dec  8 17:34:17 2014
From: dpal at redhat.com (Dmitri Pal)
Date: Mon, 08 Dec 2014 12:34:17 -0500
Subject: [Freeipa-users] vSphere 5.1 and FreeIPA 3.3 on CentOS 7 finally
 works! [How I did it...]
In-Reply-To: <CAG2kNCyXWXxMx0V96bYgMq--9zaBwhWMBENrOgSXnMMr9=F85Q@mail.gmail.com>
References: <CAG2kNCyXWXxMx0V96bYgMq--9zaBwhWMBENrOgSXnMMr9=F85Q@mail.gmail.com>
Message-ID: <5485E119.10203@redhat.com>

On 12/08/2014 11:44 AM, Gianluca Cecchi wrote:
> Hello,
> I finally was able to configure the integration between what in subject.
> I have made basic tests and all seems ok.
>
> If anyone wants to test further integration scenarios and also test 
> with vSPhere 5.5, he/she then can report here and I will crosscheck 
> eventually.
>
> My environment is based on pure vSphere 5.1 that I'm right now using 
> in trial mode with vcenter server defined as a virtual appliance.
>
> NOTE that there is a bug in this version of vSphere regarding OpenLDAP 
> integration in vShere WebClient, so that you are unable to change Base 
> DN for groups after its initial configuration. In case you need to 
> modify that field, you have to delete and recreate the whole LDAP 
> definition.
> The bug is solved in vsphere 5.1 update 1a.
>
> As suggested in other threads on this and other lists, I 
> used slapi-nis (schema compat) plugin.
> Initially I tested it on CentOS 6.6 with IPA 3.0.0-42 
> and  slapi-nis-0.40-4.
> I was able to get both users and groups enumeration in vSphere client 
> (using cn=accounts for bind definition), but then no authentication of 
> defined users due to inability of IPA 3.0 to do bind on compat tree.
>
> I read on this list that I had to use IPA 3.3 and slapi-nis >= 0.47.5, 
> how is indeed provided now in CentOS 7 with:
>
> ipa-server-3.3.3-28.0.1.el7.centos.3.x86_64
> slapi-nis-0.52-4.el7.x86_64
>
> So I migrated my IPA test server from CentOS 6.6 to another server in 
> CentOS 7.0, following the chapter 6 of the detailed guide here (only 
> some typos and use of "systemctl" commands for version 6 that should 
> be read as "service" commands instead):
> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/upgrading.html
>
> After update these were my two ldif files to adapt schema compat 
> entries for vSphere
>
> 1) vsphere_usermod.ldif
>
> dn: cn=users,cn=Schema Compatibility,cn=plugins,cn=config
> changetype: modify
> add: schema-compat-entry-attribute
> schema-compat-entry-attribute: objectclass=uniqueMember
> -
> add: schema-compat-entry-attribute
> schema-compat-entry-attribute: objectclass=inetOrgPerson
> -
>
> 2) vsphere_groupmod.ldif
>
> dn: cn=groups,cn=Schema Compatibility,cn=plugins,cn=config
> changetype: modify
> add: schema-compat-entry-attribute
> schema-compat-entry-attribute: objectclass=groupOfUniqueNames
> -
> add: schema-compat-entry-attribute
> schema-compat-entry-attribute: 
> uniqueMember=%regsub("%{member}","^(.*)accounts(.*)","%1compat%2")
> -
>
> Applied with the command:
> ldapmodify -x -D "cn=Directory Manager" -f /root/vsphere_usermod.ldif 
> -W vsphere_usermod.ldif
>
> and
> ldapmodify -x -D "cn=Directory Manager" -f /root/vsphere_usermod.ldif 
> -W vsphere_groupmod.ldif
>
>
> Configuration in vSphere Web Client under Identity Sources of
> Administration --> Sign-On and Discovery --> Configuration
> was this one
>
> Primary server URL: ldaps://c7server.localdomain.local:636
> Base DN for users: cn=users,cn=compat,dc=localdomain,dc=local
> Domain name: localdomain.local
> Base DN for groups: cn=groups,cn=compat,dc=localdomain,dc=local
> Authentication type: Password
> Username: uid=vadmin,cn=users,cn=compat,dc=localdomain,dc=local
>
> NOTE: vadmin is a normal IPA user I created only for bind with no ESX 
> permissions (it is only part of the default ipausers IPA group)
>
> NOTE: I used ldaps and as certificate I had to use the file 
> /etc/ipa/ca.crt on IPA server, after copying to client where running 
> the browser and renaming it to ca.cer without any modification at all. 
> vSphere accepted it without any problem.
>
> My tests at the moment have been ok both in vSphere fat client (5.1 
> 1471691) and vSphere Web Client (Version 5.1.0 Build 869765). I tried 
> this:
>
> - add gcecchi IPA user at top vcenter server permissions level as a 
> virtual machine user (sample) default role
> - verify gcecchi is able to connect both in fat and web clients
> - edit settings of the vm VC1 and verify that the "add..." button in 
> hardware tab is greyed out
> - add the defined esxpower IPA group at VC1 permissions level granting 
> it the virtual machine power user (sample) role
> - logout/login gcecchi and verify nothing changed in his permissions
> - add gcecchi to the IPA group esxpower
> - logout/login gcecchi and verify the user now can select the "add..." 
> button in hardware tab of VC1
> - logout gcecchi and remove gcecchi from IPA group esxpower
> - login as gcecchi in vSphere and verify that now the "add..." button 
> is disabled again
> - create an IPA group named esxnestedpower and insert it in esxpower group
> - login as gcecchi in vSphere and verify he is still unable to add devices
> - modify IPA user gcecchi adding him to esxnestedpower group
> - logout/login gcecchi from vSphere and verify that now gcecchi is 
> able to add device to VC1
>
> NOTE: as my tests began in CentOS 6.6, I noticed that the IPA groups 
> created in IPA 3.0 and CentOS 6.6 didn't get the uniqueMember property 
> for their group members... I didn't investigate more, but I noticed 
> that for the system group "admins" and for newly created groups, 
> instead it was ok...
> NOTE: after my migration from IPA 3.0 to 3.3 it seems I lost dna 
> settings, so that group addition failed without explicitly specifying 
> its GID. I solved as described here adding the missingdnaNextRange: 
> 1639600001-1639799999:
> https://www.redhat.com/archives/freeipa-users/2014-December/msg00090.html
>
> Screenshot with permissions of VC1
> https://drive.google.com/file/d/0BwoPbcrMv8mvdUgwanQzNWpBbkE/view?usp=sharing
>
> Some outputs of ldapsearch queries:
> [root at c7server slapd-LOCALDOMAIN-LOCAL]# ldapsearch -x -b 
> "cn=groups,cn=compat,dc=localdomain,dc=local" cn=esxpower
> # extended LDIF
> #
> # LDAPv3
> # base <cn=groups,cn=compat,dc=localdomain,dc=local> with scope subtree
> # filter: cn=esxpower
> # requesting: ALL
> #
>
> # esxpower, groups, compat, localdomain.local
> dn: cn=esxpower,cn=groups,cn=compat,dc=localdomain,dc=local
> objectClass: posixGroup
> objectClass: groupOfUniqueNames
> objectClass: top
> gidNumber: 1639600010
> memberUid: gcecchi
> uniqueMember: 
> cn=esxnestedpower,cn=groups,cn=compat,dc=localdomain,dc=local
> cn: esxpower
>
> # search result
> search: 2
> result: 0 Success
>
> # numResponses: 2
> # numEntries: 1
>
>
> [root at c7server slapd-LOCALDOMAIN-LOCAL]# ldapsearch -x -b 
> "cn=groups,cn=compat,dc=localdomain,dc=local" cn=esxnestedpower
> # extended LDIF
> #
> # LDAPv3
> # base <cn=groups,cn=compat,dc=localdomain,dc=local> with scope subtree
> # filter: cn=esxnestedpower
> # requesting: ALL
> #
>
> # esxnestedpower, groups, compat, localdomain.local
> dn: cn=esxnestedpower,cn=groups,cn=compat,dc=localdomain,dc=local
> objectClass: posixGroup
> objectClass: groupOfUniqueNames
> objectClass: top
> gidNumber: 1639600012
> memberUid: gcecchi
> uniqueMember: uid=gcecchi,cn=users,cn=compat,dc=localdomain,dc=local
> cn: esxnestedpower
>
> # search result
> search: 2
> result: 0 Success
>
> # numResponses: 2
> # numEntries: 1
> [root at c7server slapd-LOCALDOMAIN-LOCAL]# ldapsearch -x -b 
> "cn=users,cn=compat,dc=localdomain,dc=local" uid=gcecchi
> # extended LDIF
> #
> # LDAPv3
> # base <cn=users,cn=compat,dc=localdomain,dc=local> with scope subtree
> # filter: uid=gcecchi
> # requesting: ALL
> #
>
> # gcecchi, users, compat, localdomain.local
> dn: uid=gcecchi,cn=users,cn=compat,dc=localdomain,dc=local
> objectClass: posixAccount
> objectClass: uniqueMember
> objectClass: inetOrgPerson
> objectClass: extensibleObject
> objectClass: top
> objectClass: organizationalPerson
> objectClass: person
> gecos: Gianluca Cecchi
> cn: Gianluca Cecchi
> uidNumber: 1639600001
> gidNumber: 1639600001
> loginShell: /bin/sh
> homeDirectory: /home/gcecchi
> uid: gcecchi
>
> # search result
> search: 2
> result: 0 Success
>
> # numResponses: 2
> # numEntries: 1
>
>
> Hope that this can help others trying to accomplish vSphere/IPA 
> integration and feel free to comment as I'm far from an IPA expert and 
> my main approach is RTFM and ask help... ;-)
>
> Gianluca Cecchi
>
>
>
Thank you for a detailed summary!
Would you mind turning it into a wiki page?
http://www.freeipa.org/page/HowTos


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141208/ebd15f73/attachment.htm>

From gianluca.cecchi at gmail.com  Mon Dec  8 18:17:53 2014
From: gianluca.cecchi at gmail.com (Gianluca Cecchi)
Date: Mon, 8 Dec 2014 19:17:53 +0100
Subject: [Freeipa-users] vSphere 5.1 and FreeIPA 3.3 on CentOS 7 finally
 works! [How I did it...]
In-Reply-To: <5485E119.10203@redhat.com>
References: <CAG2kNCyXWXxMx0V96bYgMq--9zaBwhWMBENrOgSXnMMr9=F85Q@mail.gmail.com>
	<5485E119.10203@redhat.com>
Message-ID: <CAG2kNCyWUhbVZUbpo0rgE_NAucs5S4x6_dj4JcCXTNWyLNSAFw@mail.gmail.com>

OK. I will check requirements to write into The wiki
Il 08/dic/2014 18:36 "Dmitri Pal" <dpal at redhat.com> ha scritto:

>  On 12/08/2014 11:44 AM, Gianluca Cecchi wrote:
>
> Hello,
> I finally was able to configure the integration between what in subject.
> I have made basic tests and all seems ok.
>
>  If anyone wants to test further integration scenarios and also test with
> vSPhere 5.5, he/she then can report here and I will crosscheck eventually.
>
>  My environment is based on pure vSphere 5.1 that I'm right now using in
> trial mode with vcenter server defined as a virtual appliance.
>
>  NOTE that there is a bug in this version of vSphere regarding OpenLDAP
> integration in vShere WebClient, so that you are unable to change Base DN
> for groups after its initial configuration. In case you need to modify that
> field, you have to delete and recreate the whole LDAP definition.
> The bug is solved in vsphere 5.1 update 1a.
>
>  As suggested in other threads on this and other lists, I used slapi-nis
> (schema compat) plugin.
> Initially I tested it on CentOS 6.6 with IPA 3.0.0-42
> and  slapi-nis-0.40-4.
> I was able to get both users and groups enumeration in vSphere client
> (using cn=accounts for bind definition), but then no authentication of
> defined users due to inability of IPA 3.0 to do bind on compat tree.
>
>  I read on this list that I had to use IPA 3.3 and slapi-nis >= 0.47.5,
> how is indeed provided now in CentOS 7 with:
>
>  ipa-server-3.3.3-28.0.1.el7.centos.3.x86_64
> slapi-nis-0.52-4.el7.x86_64
>
>  So I migrated my IPA test server from CentOS 6.6 to another server in
> CentOS 7.0, following the chapter 6 of the detailed guide here (only some
> typos and use of "systemctl" commands for version 6 that should be read as
> "service" commands instead):
>
> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/upgrading.html
>
>  After update these were my two ldif files to adapt schema compat entries
> for vSphere
>
>  1) vsphere_usermod.ldif
>
>  dn: cn=users,cn=Schema Compatibility,cn=plugins,cn=config
> changetype: modify
> add: schema-compat-entry-attribute
> schema-compat-entry-attribute: objectclass=uniqueMember
> -
> add: schema-compat-entry-attribute
> schema-compat-entry-attribute: objectclass=inetOrgPerson
> -
>
>  2) vsphere_groupmod.ldif
>
>  dn: cn=groups,cn=Schema Compatibility,cn=plugins,cn=config
> changetype: modify
> add: schema-compat-entry-attribute
> schema-compat-entry-attribute: objectclass=groupOfUniqueNames
> -
> add: schema-compat-entry-attribute
> schema-compat-entry-attribute:
> uniqueMember=%regsub("%{member}","^(.*)accounts(.*)","%1compat%2")
> -
>
>  Applied with the command:
> ldapmodify -x -D "cn=Directory Manager" -f /root/vsphere_usermod.ldif -W
> vsphere_usermod.ldif
>
>  and
> ldapmodify -x -D "cn=Directory Manager" -f /root/vsphere_usermod.ldif -W
> vsphere_groupmod.ldif
>
>
>  Configuration in vSphere Web Client under Identity Sources of
> Administration --> Sign-On and Discovery --> Configuration
> was this one
>
>  Primary server URL: ldaps://c7server.localdomain.local:636
> Base DN for users: cn=users,cn=compat,dc=localdomain,dc=local
>  Domain name: localdomain.local
>  Base DN for groups: cn=groups,cn=compat,dc=localdomain,dc=local
>  Authentication type: Password
>  Username: uid=vadmin,cn=users,cn=compat,dc=localdomain,dc=local
>
>  NOTE: vadmin is a normal IPA user I created only for bind with no ESX
> permissions (it is only part of the default ipausers IPA group)
>
>  NOTE: I used ldaps and as certificate I had to use the file
> /etc/ipa/ca.crt on IPA server, after copying to client where running the
> browser and renaming it to ca.cer without any modification at all. vSphere
> accepted it without any problem.
>
>  My tests at the moment have been ok both in vSphere fat client (5.1
> 1471691) and vSphere Web Client (Version 5.1.0 Build 869765). I tried this:
>
>  - add gcecchi IPA user at top vcenter server permissions level as a
> virtual machine user (sample) default role
> - verify gcecchi is able to connect both in fat and web clients
> - edit settings of the vm VC1 and verify that the "add..." button in
> hardware tab is greyed out
> - add the defined esxpower IPA group at VC1 permissions level granting it
> the virtual machine power user (sample) role
> - logout/login gcecchi and verify nothing changed in his permissions
> - add gcecchi to the IPA group esxpower
> - logout/login gcecchi and verify the user now can select the "add..."
> button in hardware tab of VC1
> - logout gcecchi and remove gcecchi from IPA group esxpower
> - login as gcecchi in vSphere and verify that now the "add..." button is
> disabled again
> - create an IPA group named esxnestedpower and insert it in esxpower group
> - login as gcecchi in vSphere and verify he is still unable to add devices
> - modify IPA user gcecchi adding him to esxnestedpower group
> - logout/login gcecchi from vSphere and verify that now gcecchi is able to
> add device to VC1
>
>  NOTE: as my tests began in CentOS 6.6, I noticed that the IPA groups
> created in IPA 3.0 and CentOS 6.6 didn't get the uniqueMember property for
> their group members... I didn't investigate more, but I noticed that for
> the system group "admins" and for newly created groups, instead it was ok...
> NOTE: after my migration from IPA 3.0 to 3.3 it seems I lost dna settings,
> so that group addition failed without explicitly specifying its GID. I
> solved as described here adding the missing dnaNextRange:
> 1639600001-1639799999:
> https://www.redhat.com/archives/freeipa-users/2014-December/msg00090.html
>
>  Screenshot with permissions of VC1
>
> https://drive.google.com/file/d/0BwoPbcrMv8mvdUgwanQzNWpBbkE/view?usp=sharing
>
>  Some outputs of ldapsearch queries:
> [root at c7server slapd-LOCALDOMAIN-LOCAL]# ldapsearch -x -b
> "cn=groups,cn=compat,dc=localdomain,dc=local" cn=esxpower
> # extended LDIF
> #
> # LDAPv3
> # base <cn=groups,cn=compat,dc=localdomain,dc=local> with scope subtree
> # filter: cn=esxpower
> # requesting: ALL
> #
>
>  # esxpower, groups, compat, localdomain.local
> dn: cn=esxpower,cn=groups,cn=compat,dc=localdomain,dc=local
> objectClass: posixGroup
> objectClass: groupOfUniqueNames
> objectClass: top
> gidNumber: 1639600010
> memberUid: gcecchi
> uniqueMember: cn=esxnestedpower,cn=groups,cn=compat,dc=localdomain,dc=local
> cn: esxpower
>
>  # search result
> search: 2
> result: 0 Success
>
>  # numResponses: 2
> # numEntries: 1
>
>
>  [root at c7server slapd-LOCALDOMAIN-LOCAL]# ldapsearch -x -b
> "cn=groups,cn=compat,dc=localdomain,dc=local" cn=esxnestedpower
> # extended LDIF
> #
> # LDAPv3
> # base <cn=groups,cn=compat,dc=localdomain,dc=local> with scope subtree
> # filter: cn=esxnestedpower
> # requesting: ALL
> #
>
>  # esxnestedpower, groups, compat, localdomain.local
> dn: cn=esxnestedpower,cn=groups,cn=compat,dc=localdomain,dc=local
> objectClass: posixGroup
> objectClass: groupOfUniqueNames
> objectClass: top
> gidNumber: 1639600012
> memberUid: gcecchi
> uniqueMember: uid=gcecchi,cn=users,cn=compat,dc=localdomain,dc=local
> cn: esxnestedpower
>
>  # search result
> search: 2
> result: 0 Success
>
>  # numResponses: 2
> # numEntries: 1
>
>  [root at c7server slapd-LOCALDOMAIN-LOCAL]# ldapsearch -x -b
> "cn=users,cn=compat,dc=localdomain,dc=local" uid=gcecchi
> # extended LDIF
> #
> # LDAPv3
> # base <cn=users,cn=compat,dc=localdomain,dc=local> with scope subtree
> # filter: uid=gcecchi
> # requesting: ALL
> #
>
>  # gcecchi, users, compat, localdomain.local
> dn: uid=gcecchi,cn=users,cn=compat,dc=localdomain,dc=local
> objectClass: posixAccount
> objectClass: uniqueMember
> objectClass: inetOrgPerson
> objectClass: extensibleObject
> objectClass: top
> objectClass: organizationalPerson
> objectClass: person
> gecos: Gianluca Cecchi
> cn: Gianluca Cecchi
> uidNumber: 1639600001
> gidNumber: 1639600001
> loginShell: /bin/sh
> homeDirectory: /home/gcecchi
> uid: gcecchi
>
>  # search result
> search: 2
> result: 0 Success
>
>  # numResponses: 2
> # numEntries: 1
>
>
>  Hope that this can help others trying to accomplish vSphere/IPA
> integration and feel free to comment as I'm far from an IPA expert and my
> main approach is RTFM and ask help... ;-)
>
>  Gianluca Cecchi
>
>
>
>
>  Thank you for a detailed summary!
> Would you mind turning it into a wiki page?
> http://www.freeipa.org/page/HowTos
>
>
> --
> Thank you,
> Dmitri Pal
>
> Sr. Engineering Manager IdM portfolio
> Red Hat, Inc.
>
>
> --
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141208/ad968310/attachment.htm>

From nagemnna at gmail.com  Mon Dec  8 19:00:52 2014
From: nagemnna at gmail.com (Megan .)
Date: Mon, 8 Dec 2014 14:00:52 -0500
Subject: [Freeipa-users] can't register new clients
In-Reply-To: <CACMA5-z+rt0e7tkf_UY5L_YzbQNcmRrNbNDQv3H01a=O9sXmxg@mail.gmail.com>
References: <CACMA5-xsgZ2RcF7rx9MS+jtxpyMOofhpU0MnPn+1mcmHGOxNkg@mail.gmail.com>
	<54821AA7.1000007@redhat.com> <54821D9B.80502@redhat.com>
	<CACMA5-xs3gOMAdjg3o5aG6d58d-CvqPh5k9yo23pLSD9uXAq9Q@mail.gmail.com>
	<548225F9.7010001@redhat.com>
	<CACMA5-w=BmD+=9Gj7Q=U0oheEQOb40zfdzST_ASixiuKs5TqHA@mail.gmail.com>
	<54822D6D.1050807@redhat.com>
	<CACMA5-z+rt0e7tkf_UY5L_YzbQNcmRrNbNDQv3H01a=O9sXmxg@mail.gmail.com>
Message-ID: <CACMA5-wY7+ceQm8GOT11=8MttRgNcZfsS8sg8X25AOMfo+22Jg@mail.gmail.com>

I looked through the logs on the server and i see the below error in
the apache error log when i try to register a client:

[Mon Dec 08 12:20:38 2014] [error] SSL Library Error: -12195 Peer does
not recognize and trust the CA that issued your certificate


I ran ipa-getcert list and everything seems ok (nothing expired) but
i'm not sure where to troubleshoot from here.



On Fri, Dec 5, 2014 at 7:51 PM, Megan . <nagemnna at gmail.com> wrote:
> It failed again.
>
>
> [root at cache2-uat ~]# certutil -L -d sql:/etc/pki/nssdb
>
> Certificate Nickname                                         Trust Attributes
>                                                              SSL,S/MIME,JAR/XPI
> [root at cache2-uat ~]#
>
> Not sure if its related, but on the directory server in the apache
> error.log I see the below every time a client tries to register:
>
> [Sat Dec 06 00:48:35 2014] [error] SSL Library Error: -12271 SSL
> client cannot verify your certificate
>
> On the directory server i ran ipa-getcert list and the certs seem ok.
>
>
>
> On Fri, Dec 5, 2014 at 5:10 PM, Rob Crittenden <rcritten at redhat.com> wrote:
>> Megan . wrote:
>>> Sorry for being unclear. It still fails.  Same error.
>>
>> Hmm, strange. Try being explicit about sql:
>>
>> # certutil -L -d sql:/etc/pki/nssdb
>>
>> And if there is a CA cert there, delete it.
>>
>> rob
>>
>>>
>>> On Dec 5, 2014 4:39 PM, "Rob Crittenden" <rcritten at redhat.com
>>> <mailto:rcritten at redhat.com>> wrote:
>>>
>>>     Megan . wrote:
>>>     > Thanks.
>>>     >
>>>     > I did have an issue last week where i tried to do the client install
>>>     > and it failed because of a firewall issue.  Networks has it opened
>>>     > now.  I deleted ca.crt before trying again.  There doesn't seem to be
>>>     > a certificate in /etc/pki/nssdb for it.
>>>     >
>>>     >
>>>     >
>>>     > [root at data2-uat ipa]# certutil -L -d /etc/pki/nssdb
>>>     >
>>>     >
>>>     > Certificate Nickname                                         Trust
>>>     Attributes
>>>     >
>>>     >
>>>     SSL,S/MIME,JAR/XPI
>>>     >
>>>     >
>>>     > [root at data2-uat ipa]# certutil -D -n 'IPA CA' -d /etc/pki/nssdb
>>>     >
>>>     > certutil: could not find certificate named "IPA CA":
>>>     > SEC_ERROR_BAD_DATABASE: security library: bad database.
>>>     >
>>>     > [root at data2-uat ipa]# ls
>>>     >
>>>     > [root at data2-uat ipa]# pwd
>>>     >
>>>     > /etc/ipa
>>>     >
>>>     > [root at data2-uat ipa]# ls -al
>>>     >
>>>     > total 16
>>>     >
>>>     > drwxr-xr-x.  2 root root  4096 Dec  5 21:16 .
>>>     >
>>>     > drwxr-xr-x. 82 root root 12288 Dec  5 21:16 ..
>>>     >
>>>     > [root at data2-uat ipa]#
>>>
>>>     So trying to install the client again fails or succeeds now?
>>>
>>>     rob
>>>
>>>     >
>>>     > On Fri, Dec 5, 2014 at 4:03 PM, Rob Crittenden
>>>     <rcritten at redhat.com <mailto:rcritten at redhat.com>> wrote:
>>>     >> Rob Crittenden wrote:
>>>     >>> Megan . wrote:
>>>     >>>> Good Day!
>>>     >>>>
>>>     >>>> I am getting an error when i register new clients.
>>>     >>>>
>>>     >>>> libcurl failed to execute the HTTP POST transaction.  SSL
>>>     connect error
>>>     >>>>
>>>     >>>> I can't find anything useful not the internet about the error.  Can
>>>     >>>> someone help me troubleshoot?
>>>     >>>>
>>>     >>>> CentOS 6.6  x64
>>>     >>>> ipa-client-3.0.0-42.el6.centos.x86_64
>>>     >>>> ipa-server-3.0.0-42.el6.centos.x86_64
>>>     >>>> curl-7.19.7-40.el6_6.1.x86_64
>>>     >>>
>>>     >>> Do you have NSS_DEFAULT_DB_TYPE set to sql? I don't know that
>>>     we've done
>>>     >>> any testing on the client with this set.
>>>     >>
>>>     >> Never mind, that's not it. The problem is:
>>>     >>
>>>     >> * NSS error -8054
>>>     >>
>>>     >> Which is SEC_ERROR_REUSED_ISSUER_AND_SERIAL
>>>     >>
>>>     >> So I'd do this:
>>>     >>
>>>     >> # rm /etc/ipa/ca.crt
>>>     >>
>>>     >> You may also want to ensure that the IPA CA certificate isn't in
>>>     >> /etc/pki/nssdb:
>>>     >>
>>>     >> # certutil -L -d /etc/pki/nssdb
>>>     >>
>>>     >> And then perhaps
>>>     >>
>>>     >> # certutil -D -n 'IPA CA' -d /etc/pki/nssdb
>>>     >>
>>>     >> rob
>>>     >>
>>>
>>



From matthew.herzog at gmail.com  Mon Dec  8 19:10:58 2014
From: matthew.herzog at gmail.com (Matthew Herzog)
Date: Mon, 8 Dec 2014 14:10:58 -0500
Subject: [Freeipa-users] DNS configuration
In-Reply-To: <CABhyZ35qsCM0y8anFdqE7r60Fz8LAU8Yx3WWaF6zBhfg=dRUJA@mail.gmail.com>
References: <CABhyZ34TCzUz+fNUSCvdZ38MS7rsLMMdb_jTdfKUsmYs86fn_Q@mail.gmail.com>
	<547DEA9E.2030203@redhat.com> <547DEFB5.1020205@redhat.com>
	<CABhyZ347EU+Q85jQJGU30yx4njC3OtL_QsJZi1MMu1ZR2Lfd2Q@mail.gmail.com>
	<547E851C.1020407@redhat.com> <547ECDDC.3090001@redhat.com>
	<CABhyZ37XChaQF+4rRY-L=OU9pVNp7Mw_NQifTk3NhrewzJtyVQ@mail.gmail.com>
	<5485108E.60409@redhat.com>
	<CABhyZ36DDM6icM+haMbVErdVdDWonGqbPE+3Tpad4K=u9QHjAQ@mail.gmail.com>
	<54851385.3050709@redhat.com>
	<CABhyZ36D_SVLezC=wZ3tsYHn00tdBGsxpOxCtpVgWZo8EdH2hw@mail.gmail.com>
	<548522B8.8040805@redhat.com> <5485599E.8030801@redhat.com>
	<CABhyZ34Pbr4J6YDdLSmP=qPqAB7Pa=tWvw273aB-BNX4dRq-GQ@mail.gmail.com>
	<5485C698.9000406@redhat.com>
	<CABhyZ35qsCM0y8anFdqE7r60Fz8LAU8Yx3WWaF6zBhfg=dRUJA@mail.gmail.com>
Message-ID: <CABhyZ34exwjj4o8RRu651w2kik96wMS3Y6dvEk14MG1Y+LkY9w@mail.gmail.com>

Here are some errors I'm seeing on the client.

tail -f sssd_lnx.e-bozo.com.log
(Mon Dec  8 14:03:20 2014) [sssd[be[lnx.e-bozo.com]]] [sbus_dispatch]
(0x4000): dbus conn: 0x1e72ad0
(Mon Dec  8 14:03:20 2014) [sssd[be[lnx.e-bozo.com]]] [sbus_dispatch]
(0x4000): Dispatching.
(Mon Dec  8 14:03:20 2014) [sssd[be[lnx.e-bozo.com]]]
[sbus_message_handler] (0x4000): Received SBUS method [ping]
(Mon Dec  8 14:03:20 2014) [sssd[be[lnx.e-bozo.com]]]
[sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit
(Mon Dec  8 14:03:20 2014) [sssd[be[lnx.e-bozo.com]]]
[sbus_handler_got_caller_id] (0x4000): Received SBUS method [ping]
(Mon Dec  8 14:03:30 2014) [sssd[be[lnx.e-bozo.com]]] [sbus_dispatch]
(0x4000): dbus conn: 0x1e72ad0
(Mon Dec  8 14:03:30 2014) [sssd[be[lnx.e-bozo.com]]] [sbus_dispatch]
(0x4000): Dispatching.
(Mon Dec  8 14:03:30 2014) [sssd[be[lnx.e-bozo.com]]]
[sbus_message_handler] (0x4000): Received SBUS method [ping]
(Mon Dec  8 14:03:30 2014) [sssd[be[lnx.e-bozo.com]]]
[sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit
(Mon Dec  8 14:03:30 2014) [sssd[be[lnx.e-bozo.com]]]
[sbus_handler_got_caller_id] (0x4000): Received SBUS method [ping]
(Mon Dec  8 14:03:40 2014) [sssd[be[lnx.e-bozo.com]]] [sbus_dispatch]
(0x4000): dbus conn: 0x1e72ad0
(Mon Dec  8 14:03:40 2014) [sssd[be[lnx.e-bozo.com]]] [sbus_dispatch]
(0x4000): Dispatching.

[root at freeipa-poc-client02 sssd]# tail -f sssd_ssh.log
(Sun Dec  7 19:32:09 2014) [sssd[ssh]] [ssh_process_init] (0x0010):
sss_process_init() failed
(Sun Dec  7 19:32:09 2014) [sssd[ssh]] [sss_dp_init] (0x0010): Failed to
connect to monitor services.
(Sun Dec  7 19:32:09 2014) [sssd[ssh]] [sss_process_init] (0x0010): fatal
error setting up backend connector
(Sun Dec  7 19:32:09 2014) [sssd[ssh]] [ssh_process_init] (0x0010):
sss_process_init() failed
(Sun Dec  7 19:32:16 2014) [sssd[ssh]] [sss_dp_init] (0x0010): Failed to
connect to monitor services.
(Sun Dec  7 19:32:16 2014) [sssd[ssh]] [sss_process_init] (0x0010): fatal
error setting up backend connector
(Sun Dec  7 19:32:16 2014) [sssd[ssh]] [ssh_process_init] (0x0010):
sss_process_init() failed
(Sun Dec  7 19:32:16 2014) [sssd[ssh]] [sss_dp_init] (0x0010): Failed to
connect to monitor services.
(Sun Dec  7 19:32:16 2014) [sssd[ssh]] [sss_process_init] (0x0010): fatal
error setting up backend connector
(Sun Dec  7 19:32:16 2014) [sssd[ssh]] [ssh_process_init] (0x0010):
sss_process_init() failed


On Mon, Dec 8, 2014 at 11:48 AM, Matthew Herzog <matthew.herzog at gmail.com>
wrote:

> I have never seen my IPA servers produce a zone file nor has the install
> script ever mentioned the creation of such. In fact, I just ran
> ipa-server-install --uninstall && ipa-server-install and there was no
> mention of a zone file.
>
> Where should I look in the file system to be sure? I see nothing in
> /var/named. I'm using 3.3.3 IPA on Oracle Linux from Oracle's yum repo.
> (Not my choice.)
>
> dsee7 is *not *running Kerberos. dsee7 is *not *configured with SRV
> records. I guess I'll need to add SRV records for all my Linux hosts.
>
>
>
>
>
>
> On Mon, Dec 8, 2014 at 10:41 AM, Petr Spacek <pspacek at redhat.com> wrote:
>
>> On 8.12.2014 14:44, Matthew Herzog wrote:
>> > Petr said, "You can run ipa-server-install *without* --setup-dns option
>> and
>> > at the end of
>> > installation it will produce DNS records which you have to manually add
>> to
>> > your existing DNS database."
>> >
>> > I can't see how this would be useful or which machines I would need to
>> add
>> > to our DNS.
>> >
>> > Perhaps I should have explained that we are not going to set up a new
>> DNS
>> > domain for the ipa-managed servers.
>> Good.
>>
>> Now you should run ipa-server-install *without* --setup-dns, using
>> lnx.e-bozo.com as you IPA domain. It will install full IPA server and
>> spit out
>> DNS zone file.
>>
>> Then you *have to* take this zone file and import it to your existing DNS
>> infrastructure - that will give you fully functional IPA domain
>> lnx.e-bozo.com.
>>
>> Caveat:
>> Preceding text assumes that 'dsee7' is nor using either Kerberos nor DNS
>> SRV
>> records for LDAP service in domain lnx.e-bozo.com, i.e. clients
>> connecting to
>> DSEE7 should be (most likely) statically configured with DSEE7 server
>> name.
>>
>> Petr^2 Spacek
>>
>> > We have an Oracle dsee7 server doing
>> > LDAP for our Linux servers and accounts. We want to migrate to IPA so we
>> > don't have to maintain a Linux/LDAP account for every user who needs
>> access
>> > to Linux servers. All of our users start with an account in AD and since
>> > none of my predecessors knew about Winbind, they set up dsee7.
>> >
>> > So I'm thinking we'll need to import all our dsee7 accounts AND make it
>> > possible for AD users to access the Linux systems without needing to
>> create
>> > them in IPA.
>> >
>> > On Mon, Dec 8, 2014 at 2:56 AM, Petr Spacek <pspacek at redhat.com> wrote:
>> >
>> >> On 8.12.2014 05:02, Dmitri Pal wrote:
>> >>> On 12/07/2014 10:10 PM, Matthew Herzog wrote:
>> >>>> So should the FreeIPA server be authoritative for the Kerb. realm/DNS
>> >> domain
>> >>>> or can it/should it be a slave DNS server instead? Or caching only?
>> >>>
>> >>> IPA DNS can't be a slave so you either delegate a whole zone to it or
>> >> manage
>> >>> IPA DNS domain via your own DNS server.
>> >>
>> >> Generally, "slave" is not allowed to do any changes so it is useless in
>> >> your
>> >> scenario.
>> >>
>> >> You can run ipa-server-install *without* --setup-dns option and at the
>> end
>> >> of
>> >> installation it will produce DNS records which you have to manually
>> add to
>> >> your existing DNS database.
>> >>
>> >> Did you try that?
>> >>
>> >> Petr^2 Spacek
>> >>
>> >>>> On Sun, Dec 7, 2014 at 9:57 PM, Dmitri Pal <dpal at redhat.com
>> >>>> <mailto:dpal at redhat.com>> wrote:
>> >>>>
>> >>>>     On 12/07/2014 09:51 PM, Matthew Herzog wrote:
>> >>>>>     What must be done in or on the ipa server with regard to DNS, if
>> >>>>>     anything?
>> >>>>>
>> >>>>>     Our DNS works. It works well. We have four Linux DNS servers and
>> >>>>>     two AD domain controllers that also do DNS.
>> >>>>>
>> >>>>>     So if we already have DNS working well in our domain, why do we
>> >>>>>     want to manage DNS in IPA?
>> >>>>
>> >>>>     Let us keep the discussion on the list.
>> >>>>     IPA when used with AD trust presents itself as a separate forest.
>> >>>>     AD thinks that it is working with another AD forest.
>> >>>>     For that to work we need to follow MSFT rules about relationship
>> >>>>     between Kerberos realm and DNS domain.
>> >>>>     AD assumes that for every trusted forest Kerberos realm = DNS
>> >>>>     domain. IPA makes it easy to do because it has integrated tools
>> to
>> >>>>     manage IPA DNS domain.
>> >>>>     If you want to manage it yourself through your DNS you can do it,
>> >>>>     just more manual operations for you.
>> >>>>
>> >>>>     HTH
>> >>>>
>> >>>>     Thanks
>> >>>>     Dmitri
>> >>>>
>> >>>>
>> >>>>>
>> >>>>>     On Sun, Dec 7, 2014 at 9:44 PM, Dmitri Pal <dpal at redhat.com
>> >>>>>     <mailto:dpal at redhat.com>> wrote:
>> >>>>>
>> >>>>>         On 12/07/2014 06:44 PM, Matthew Herzog wrote:
>> >>>>>>         Thanks guys. I'm sorry for my delay in responding.
>> >>>>>>
>> >>>>>>         Firstly, I was under the impression (from reading the docs)
>> >>>>>>         that having named running on IPA server was critical.
>> >>>>>
>> >>>>>         Properly configured DNS is critical.
>> >>>>>         How you accomplish it is up to you.
>> >>>>>         IPA allows you to have a DNS server that would simplify DNS
>> >>>>>         management but it can be done manually too. This is why DNS
>> >>>>>         is optional.
>> >>>>>
>> >>>>>
>> >>>>>>         Also, the first question the ipa-server-install script asks
>> >>>>>>         is, "Do you want to configure integrated DNS (BIND)? ."
>> >>>>>>         While it's true the default answer is no, it leads one to
>> >>>>>>         believe that DNS is central to IPA. Also the
>> >>>>>>         ipa-client-install script says,
>> >>>>>>
>> >>>>>>         [root at freeipa-poc-client02 ~]# ipa-client-install
>> >>>>>>         DNS discovery failed to determine your DNS domain
>> >>>>>>         Provide the domain name of your IPA server (ex:
>> example.com
>> >>>>>>         <http://example.com>):
>> >>>>>>
>> >>>>>>         I can resolve -anything- from the machine using dig or
>> >> whatever.
>> >>>>>>
>> >>>>>>         Ultimately, the reason I started to be concerned about my
>> >>>>>>         IPA server's DNS config was because I was not able to
>> >>>>>>         authenticate AD accounts to a client machine. I saw a bunch
>> >>>>>>         of errors in the client's sssd logs which of course I can't
>> >>>>>>         find now.
>> >>>>>>
>> >>>>>>         Perhaps it was these . . .
>> >>>>>>
>> >>>>>>         (Thu Dec  4 13:45:23 2014) [sssd] [ping_check] (0x0100):
>> >>>>>>         Service nss replied to ping
>> >>>>>>         (Thu Dec  4 13:45:23 2014) [sssd] [ping_check] (0x0100):
>> >>>>>>         Service sudo replied to ping
>> >>>>>>         (Thu Dec  4 13:45:23 2014) [sssd] [ping_check] (0x0100):
>> >>>>>>         Service pam replied to ping
>> >>>>>>         (Thu Dec  4 13:45:23 2014) [sssd] [ping_check] (0x0100):
>> >>>>>>         Service ssh replied to ping
>> >>>>>>         (Thu Dec  4 13:45:23 2014) [sssd] [ping_check] (0x0100):
>> >>>>>>         Service pac replied to ping
>> >>>>>>         (Thu Dec  4 13:45:23 2014) [sssd] [ping_check] (0x0100):
>> >>>>>>         Service bo3.e-bozo.com <http://bo3.e-bozo.com> replied to
>> >> ping
>> >>>>>>
>> >>>>>>         I'm not allowed onto the AD domain controllers to examine
>> >>>>>>         log files or I'd be checking those first.
>> >>>>>>
>> >>>>>>         So ultimately the goal is to authenticate AD users and
>> users
>> >>>>>>         that exist in our ldap schema. We need to set up groups of
>> >>>>>>         users that can run sudo commands on specific groups of
>> hosts.
>> >>>>>
>> >>>>>         Did you setup trusts as explained on the following page?
>> >>>>>         http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup
>> >>>>>
>> >>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>         On Wed, Dec 3, 2014 at 3:46 AM, Petr Spacek
>> >>>>>>         <pspacek at redhat.com <mailto:pspacek at redhat.com>> wrote:
>> >>>>>>
>> >>>>>>             On 3.12.2014 04:35, Dmitri Pal wrote:
>> >>>>>>             > On 12/02/2014 08:54 PM, Matthew Herzog wrote:
>> >>>>>>             >> Any other ideas? I just spun up a new VM and took
>> the
>> >>>>>>             defaults on everything
>> >>>>>>             >> while running ipa-server-install (the defaults did
>> >>>>>>             make sense) and my new VM
>> >>>>>>             >> can't resolve -anything- in the domain in which it
>> >>>>>>             lives. The "old" VM
>> >>>>>>             >> (running the same versions of everything on the same
>> >>>>>>             OS) can't even resolve
>> >>>>>>             >> the clients I have registered with it!
>> >>>>>>             >>
>> >>>>>>             >> So I'm pretty frustrated and am wondering, what
>> >>>>>>             _exactly_ is the role of
>> >>>>>>             >> bind in the IPA server and how is it expected to
>> know
>> >>>>>>             anything about the
>> >>>>>>             >> local DNS domain without becoming a bind slave
>> server?
>> >>>>>>             >
>> >>>>>>             > I am not sure I am 100% with you but...
>> >>>>>>             > If you use the defaults and nothing else you get to
>> >>>>>>             the scenario when IPA has
>> >>>>>>             > its DNS but it is a self contained environment. It
>> >>>>>>             seems that this is what you
>> >>>>>>             > observe.
>> >>>>>>             > It is expected that you decide in advance what you
>> >>>>>>             want to do with DNS. There
>> >>>>>>             > are several options:
>> >>>>>>             > 1) You can delegate a zone to IPA to manage, then you
>> >>>>>>             need to connect your IPA
>> >>>>>>             > DNS to your existing DNS during install or after.
>> >>>>>>             > In this case the systems joined to IPA will be a part
>> >>>>>>             of IPA domain/zone and
>> >>>>>>             > would also be able to resolve other systems around
>> >>>>>>             > 2) Not use IPA DNS if you do not want to take
>> >>>>>>             advantage of it
>> >>>>>>             > 3) Have a self contained demo/lab environment that
>> you
>> >>>>>>             currently observe.
>> >>>>>>             >
>> >>>>>>             > What is the intent?
>> >>>>>>
>> >>>>>>             I agree with Dmitri, we need more information from you:
>> >>>>>>             - You said "my new VM can't resolve -anything- in the
>> >>>>>>             domain in which it
>> >>>>>>             lives." - Which domain do you mean?
>> >>>>>>
>> >>>>>>             - Apparently you have configured FreeIPA to serve zone
>> >>>>>>             e-bozo.com <http://e-bozo.com>. Do you have
>> >>>>>>             this zone configured on some other DNS server at the
>> >>>>>>             same time?
>> >>>>>>
>> >>>>>>             Please keep in mind that authoritative servers should
>> >>>>>>             share the database. You
>> >>>>>>             will get naming collisions if e-bozo.com
>> >>>>>>             <http://e-bozo.com> is served by FreeIPA DNS servers
>> and
>> >>>>>>             some other servers at the same time. Maybe that is the
>> >>>>>>             problem you see right now.
>> >>>>>>
>> >>>>>>             As Dmitri said, the architecturally correct solution is
>> >>>>>>             to decide if you want
>> >>>>>>             to use FreeIPA DNS or not. You have option to either
>> >>>>>>             remove non-FreeIPA DNS
>> >>>>>>             servers and import data to FreeIPA or to add
>> >>>>>>             FreeIPA-specific DNS records to
>> >>>>>>             existing DNS servers and do not configure FreeIPA to
>> act
>> >>>>>>             as DNS server.
>> >>>>>>
>> >>>>>>             Petr^2 Spacek
>> >>>>>>
>> >>>>>>             >> Thanks.
>> >>>>>>             >>
>> >>>>>>             >> On Tue, Dec 2, 2014 at 11:58 AM, Petr Spacek
>> >>>>>>             <pspacek at redhat.com <mailto:pspacek at redhat.com>
>> >>>>>>             >> <mailto:pspacek at redhat.com
>> >>>>>>             <mailto:pspacek at redhat.com>>> wrote:
>> >>>>>>             >>
>> >>>>>>             >>     On 2.12.2014 17:36, Martin Basti wrote:
>> >>>>>>             >>     > On 02/12/14 17:28, Matthew Herzog wrote:
>> >>>>>>             >>     >> I just realized that my IPA servers cannot
>> >>>>>>             resolve ANY servers
>> >>>>>>             >>     in my domain.
>> >>>>>>             >>     >> What do I need to do to fix this? Below is my
>> >>>>>>             named.conf.
>> >>>>>>             >>     >>
>> >>>>>>             >>     >>
>> >>>>>>             >>     >> options {
>> >>>>>>             >>     >>  // turns on IPv6 for port 53, IPv4 is on by
>> >>>>>>             default for
>> >>>>>>             >>     all ifaces
>> >>>>>>             >>     >>  listen-on-v6 {any;};
>> >>>>>>             >>     >>
>> >>>>>>             >>     >>  // Put files that named is allowed to write
>> >>>>>>             in the
>> >>>>>>             >>     data/ directory:
>> >>>>>>             >>     >>  directory "/var/named"; // the default
>> >>>>>>             >>     >>  dump-file "data/cache_dump.db";
>> >>>>>>             >>     >>  statistics-file "data/named_stats.txt";
>> >>>>>>             >>     >>  memstatistics-file
>> "data/named_mem_stats.txt";
>> >>>>>>             >>     >>
>> >>>>>>             >>     >>  forward first;
>> >>>>>>             >>     >>  forwarders {
>> >>>>>>             >>     >>          10.100.8.41;
>> >>>>>>             >>     >>          10.100.8.40;
>> >>>>>>             >>     >>          10.100.4.13;
>> >>>>>>             >>     >>          10.100.4.14;
>> >>>>>>             >>     >>          10.100.4.19;
>> >>>>>>             >>     >>          10.100.4.44;
>> >>>>>>             >>     >>  };
>> >>>>>>             >>     >>
>> >>>>>>             >>     >>  // Any host is permitted to issue recursive
>> >>>>>>             queries
>> >>>>>>             >>     >>  allow-recursion { any; };
>> >>>>>>             >>     >>
>> >>>>>>             >>     >>  tkey-gssapi-keytab "/etc/named.keytab";
>> >>>>>>             >>     >>  pid-file "/run/named/named.pid";
>> >>>>>>             >>     >> };
>> >>>>>>             >>     >>
>> >>>>>>             >>     >> /* If you want to enable debugging, eg. using
>> >>>>>>             the 'rndc trace'
>> >>>>>>             >>     command,
>> >>>>>>             >>     >>  * By default, SELinux policy does not allow
>> >>>>>>             named to modify
>> >>>>>>             >>     the /var/named
>> >>>>>>             >>     >> directory,
>> >>>>>>             >>     >>  * so put the default debug log file in
>> data/ :
>> >>>>>>             >>     >>  */
>> >>>>>>             >>     >> logging {
>> >>>>>>             >>     >>  channel default_debug {
>> >>>>>>             >>     >>          file "data/named.run";
>> >>>>>>             >>     >>          severity dynamic;
>> >>>>>>             >>     >>          print-time yes;
>> >>>>>>             >>     >>  };
>> >>>>>>             >>     >>  };
>> >>>>>>             >>     >> };
>> >>>>>>             >>     >>
>> >>>>>>             >>     >> zone "." IN {
>> >>>>>>             >>     >>  type hint;
>> >>>>>>             >>     >>  file "named.ca <http://named.ca>
>> >>>>>>             <http://named.ca> <http://named.ca>";
>> >>>>>>             >>     >> };
>> >>>>>>             >>     >>
>> >>>>>>             >>     >> include "/etc/named.rfc1912.zones";
>> >>>>>>             >>     >>
>> >>>>>>             >>     >> dynamic-db "ipa" {
>> >>>>>>             >>     >>  library "ldap.so";
>> >>>>>>             >>     >>  arg "uri
>> >>>>>>             >>
>> ldapi://%2fvar%2frun%2fslapd-BO3-E-BOZO-COM.socket";
>> >>>>>>             >>     >>  arg "base cn=dns, dc=bo3,dc=e-bozo,dc=com";
>> >>>>>>             >>     >>  arg "fake_mname
>> freeipa-poc01.bo3.e-bozo.com
>> >>>>>>             <http://freeipa-poc01.bo3.e-bozo.com>
>> >>>>>>             >>     <http://freeipa-poc01.bo3.e-bozo.com>
>> >>>>>>             >>     >> <http://freeipa-poc01.bo3.e-bozo.com>.";
>> >>>>>>             >>     >>  arg "auth_method sasl";
>> >>>>>>             >>     >>  arg "sasl_mech GSSAPI";
>> >>>>>>             >>     >>  arg "sasl_user
>> >>>>>>             DNS/freeipa-poc01.bo3.e-bozo.com
>> >>>>>>             <http://freeipa-poc01.bo3.e-bozo.com>
>> >>>>>>             >>     <http://freeipa-poc01.bo3.e-bozo.com>
>> >>>>>>             >>     >> <http://freeipa-poc01.bo3.e-bozo.com>";
>> >>>>>>             >>     >>  arg "serial_autoincrement yes";
>> >>>>>>             >>     >> };
>> >>>>>>             >>     >>
>> >>>>>>             >>     >>
>> >>>>>>             >>     >>
>> >>>>>>             >>     >>
>> >>>>>>             >>     > Hello,
>> >>>>>>             >>     >
>> >>>>>>             >>     > which version ipa do you use? which platform?
>> >>>>>>             Which version
>> >>>>>>             >>     bind-dyndb-ldap?
>> >>>>>>             >>     >
>> >>>>>>             >>     > Can you run these commands, and check if there
>> >>>>>>             any errors?
>> >>>>>>             >>     > ipactl status
>> >>>>>>             >>     > systemctl status named  (respectively
>> >>>>>>             journalctl -u named)
>> >>>>>>             >>
>> >>>>>>             >>     We also may want to see information listed on
>> page
>> >>>>>>             >>
>> >>>>>>
>> >> https://fedorahosted.org/bind-dyndb-ldap/wiki/BugReporting
>>
>> --
>> Petr^2 Spacek
>>
>
>
>
> --
> If life gives you melons, you may be dyslexic.
>



-- 
If life gives you melons, you may be dyslexic.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141208/28438308/attachment.htm>

From dpal at redhat.com  Mon Dec  8 19:26:37 2014
From: dpal at redhat.com (Dmitri Pal)
Date: Mon, 08 Dec 2014 14:26:37 -0500
Subject: [Freeipa-users] DNS configuration
In-Reply-To: <CABhyZ34exwjj4o8RRu651w2kik96wMS3Y6dvEk14MG1Y+LkY9w@mail.gmail.com>
References: <CABhyZ34TCzUz+fNUSCvdZ38MS7rsLMMdb_jTdfKUsmYs86fn_Q@mail.gmail.com>	<547DEA9E.2030203@redhat.com>
	<547DEFB5.1020205@redhat.com>	<CABhyZ347EU+Q85jQJGU30yx4njC3OtL_QsJZi1MMu1ZR2Lfd2Q@mail.gmail.com>	<547E851C.1020407@redhat.com>
	<547ECDDC.3090001@redhat.com>	<CABhyZ37XChaQF+4rRY-L=OU9pVNp7Mw_NQifTk3NhrewzJtyVQ@mail.gmail.com>	<5485108E.60409@redhat.com>	<CABhyZ36DDM6icM+haMbVErdVdDWonGqbPE+3Tpad4K=u9QHjAQ@mail.gmail.com>	<54851385.3050709@redhat.com>	<CABhyZ36D_SVLezC=wZ3tsYHn00tdBGsxpOxCtpVgWZo8EdH2hw@mail.gmail.com>	<548522B8.8040805@redhat.com>
	<5485599E.8030801@redhat.com>	<CABhyZ34Pbr4J6YDdLSmP=qPqAB7Pa=tWvw273aB-BNX4dRq-GQ@mail.gmail.com>	<5485C698.9000406@redhat.com>	<CABhyZ35qsCM0y8anFdqE7r60Fz8LAU8Yx3WWaF6zBhfg=dRUJA@mail.gmail.com>
	<CABhyZ34exwjj4o8RRu651w2kik96wMS3Y6dvEk14MG1Y+LkY9w@mail.gmail.com>
Message-ID: <5485FB6D.8000005@redhat.com>

On 12/08/2014 02:10 PM, Matthew Herzog wrote:
> Here are some errors I'm seeing on the client.
>
> tail -f sssd_lnx.e-bozo.com.log
> (Mon Dec  8 14:03:20 2014) [sssd[be[lnx.e-bozo.com 
> <http://lnx.e-bozo.com>]]] [sbus_dispatch] (0x4000): dbus conn: 0x1e72ad0
> (Mon Dec  8 14:03:20 2014) [sssd[be[lnx.e-bozo.com 
> <http://lnx.e-bozo.com>]]] [sbus_dispatch] (0x4000): Dispatching.
> (Mon Dec  8 14:03:20 2014) [sssd[be[lnx.e-bozo.com 
> <http://lnx.e-bozo.com>]]] [sbus_message_handler] (0x4000): Received 
> SBUS method [ping]
> (Mon Dec  8 14:03:20 2014) [sssd[be[lnx.e-bozo.com 
> <http://lnx.e-bozo.com>]]] [sbus_get_sender_id_send] (0x2000): Not a 
> sysbus message, quit
> (Mon Dec  8 14:03:20 2014) [sssd[be[lnx.e-bozo.com 
> <http://lnx.e-bozo.com>]]] [sbus_handler_got_caller_id] (0x4000): 
> Received SBUS method [ping]
> (Mon Dec  8 14:03:30 2014) [sssd[be[lnx.e-bozo.com 
> <http://lnx.e-bozo.com>]]] [sbus_dispatch] (0x4000): dbus conn: 0x1e72ad0
> (Mon Dec  8 14:03:30 2014) [sssd[be[lnx.e-bozo.com 
> <http://lnx.e-bozo.com>]]] [sbus_dispatch] (0x4000): Dispatching.
> (Mon Dec  8 14:03:30 2014) [sssd[be[lnx.e-bozo.com 
> <http://lnx.e-bozo.com>]]] [sbus_message_handler] (0x4000): Received 
> SBUS method [ping]
> (Mon Dec  8 14:03:30 2014) [sssd[be[lnx.e-bozo.com 
> <http://lnx.e-bozo.com>]]] [sbus_get_sender_id_send] (0x2000): Not a 
> sysbus message, quit
> (Mon Dec  8 14:03:30 2014) [sssd[be[lnx.e-bozo.com 
> <http://lnx.e-bozo.com>]]] [sbus_handler_got_caller_id] (0x4000): 
> Received SBUS method [ping]
> (Mon Dec  8 14:03:40 2014) [sssd[be[lnx.e-bozo.com 
> <http://lnx.e-bozo.com>]]] [sbus_dispatch] (0x4000): dbus conn: 0x1e72ad0
> (Mon Dec  8 14:03:40 2014) [sssd[be[lnx.e-bozo.com 
> <http://lnx.e-bozo.com>]]] [sbus_dispatch] (0x4000): Dispatching.
>
> [root at freeipa-poc-client02 sssd]# tail -f sssd_ssh.log
> (Sun Dec  7 19:32:09 2014) [sssd[ssh]] [ssh_process_init] (0x0010): 
> sss_process_init() failed
> (Sun Dec  7 19:32:09 2014) [sssd[ssh]] [sss_dp_init] (0x0010): Failed 
> to connect to monitor services.
> (Sun Dec  7 19:32:09 2014) [sssd[ssh]] [sss_process_init] (0x0010): 
> fatal error setting up backend connector
> (Sun Dec  7 19:32:09 2014) [sssd[ssh]] [ssh_process_init] (0x0010): 
> sss_process_init() failed
> (Sun Dec  7 19:32:16 2014) [sssd[ssh]] [sss_dp_init] (0x0010): Failed 
> to connect to monitor services.
> (Sun Dec  7 19:32:16 2014) [sssd[ssh]] [sss_process_init] (0x0010): 
> fatal error setting up backend connector
> (Sun Dec  7 19:32:16 2014) [sssd[ssh]] [ssh_process_init] (0x0010): 
> sss_process_init() failed
> (Sun Dec  7 19:32:16 2014) [sssd[ssh]] [sss_dp_init] (0x0010): Failed 
> to connect to monitor services.
> (Sun Dec  7 19:32:16 2014) [sssd[ssh]] [sss_process_init] (0x0010): 
> fatal error setting up backend connector
> (Sun Dec  7 19:32:16 2014) [sssd[ssh]] [ssh_process_init] (0x0010): 
> sss_process_init() failed

What is the version of the client?
Please add debug_level=9 to sssd.conf in different sections to rise the 
verbosity of the log and see what is really going on there.
https://fedorahosted.org/sssd/wiki/FAQ#BasicsofTroubleshooting


>
>
> On Mon, Dec 8, 2014 at 11:48 AM, Matthew Herzog 
> <matthew.herzog at gmail.com <mailto:matthew.herzog at gmail.com>> wrote:
>
>     I have never seen my IPA servers produce a zone file nor has the
>     install script ever mentioned the creation of such. In fact, I
>     just ran ipa-server-install --uninstall && ipa-server-install and
>     there was no mention of a zone file.
>
>     Where should I look in the file system to be sure? I see nothing
>     in /var/named. I'm using 3.3.3 IPA on Oracle Linux from Oracle's
>     yum repo. (Not my choice.)
>
>     dsee7 is /not /running Kerberos. dsee7 is /not /configured with
>     SRV records. I guess I'll need to add SRV records for all my Linux
>     hosts.
>
>
>
>
>
>
>     On Mon, Dec 8, 2014 at 10:41 AM, Petr Spacek <pspacek at redhat.com
>     <mailto:pspacek at redhat.com>> wrote:
>
>         On 8.12.2014 14:44, Matthew Herzog wrote:
>         > Petr said, "You can run ipa-server-install *without*
>         --setup-dns option and
>         > at the end of
>         > installation it will produce DNS records which you have to
>         manually add to
>         > your existing DNS database."
>         >
>         > I can't see how this would be useful or which machines I
>         would need to add
>         > to our DNS.
>         >
>         > Perhaps I should have explained that we are not going to set
>         up a new DNS
>         > domain for the ipa-managed servers.
>         Good.
>
>         Now you should run ipa-server-install *without* --setup-dns, using
>         lnx.e-bozo.com <http://lnx.e-bozo.com> as you IPA domain. It
>         will install full IPA server and spit out
>         DNS zone file.
>
>         Then you *have to* take this zone file and import it to your
>         existing DNS
>         infrastructure - that will give you fully functional IPA
>         domain lnx.e-bozo.com <http://lnx.e-bozo.com>.
>
>         Caveat:
>         Preceding text assumes that 'dsee7' is nor using either
>         Kerberos nor DNS SRV
>         records for LDAP service in domain lnx.e-bozo.com
>         <http://lnx.e-bozo.com>, i.e. clients connecting to
>         DSEE7 should be (most likely) statically configured with DSEE7
>         server name.
>
>         Petr^2 Spacek
>
>         > We have an Oracle dsee7 server doing
>         > LDAP for our Linux servers and accounts. We want to migrate
>         to IPA so we
>         > don't have to maintain a Linux/LDAP account for every user
>         who needs access
>         > to Linux servers. All of our users start with an account in
>         AD and since
>         > none of my predecessors knew about Winbind, they set up dsee7.
>         >
>         > So I'm thinking we'll need to import all our dsee7 accounts
>         AND make it
>         > possible for AD users to access the Linux systems without
>         needing to create
>         > them in IPA.
>         >
>         > On Mon, Dec 8, 2014 at 2:56 AM, Petr Spacek
>         <pspacek at redhat.com <mailto:pspacek at redhat.com>> wrote:
>         >
>         >> On 8.12.2014 05:02, Dmitri Pal wrote:
>         >>> On 12/07/2014 10:10 PM, Matthew Herzog wrote:
>         >>>> So should the FreeIPA server be authoritative for the
>         Kerb. realm/DNS
>         >> domain
>         >>>> or can it/should it be a slave DNS server instead? Or
>         caching only?
>         >>>
>         >>> IPA DNS can't be a slave so you either delegate a whole
>         zone to it or
>         >> manage
>         >>> IPA DNS domain via your own DNS server.
>         >>
>         >> Generally, "slave" is not allowed to do any changes so it
>         is useless in
>         >> your
>         >> scenario.
>         >>
>         >> You can run ipa-server-install *without* --setup-dns option
>         and at the end
>         >> of
>         >> installation it will produce DNS records which you have to
>         manually add to
>         >> your existing DNS database.
>         >>
>         >> Did you try that?
>         >>
>         >> Petr^2 Spacek
>         >>
>         >>>> On Sun, Dec 7, 2014 at 9:57 PM, Dmitri Pal
>         <dpal at redhat.com <mailto:dpal at redhat.com>
>         >>>> <mailto:dpal at redhat.com <mailto:dpal at redhat.com>>> wrote:
>         >>>>
>         >>>>     On 12/07/2014 09:51 PM, Matthew Herzog wrote:
>         >>>>>     What must be done in or on the ipa server with
>         regard to DNS, if
>         >>>>>     anything?
>         >>>>>
>         >>>>>     Our DNS works. It works well. We have four Linux DNS
>         servers and
>         >>>>>     two AD domain controllers that also do DNS.
>         >>>>>
>         >>>>>     So if we already have DNS working well in our
>         domain, why do we
>         >>>>>     want to manage DNS in IPA?
>         >>>>
>         >>>>     Let us keep the discussion on the list.
>         >>>>     IPA when used with AD trust presents itself as a
>         separate forest.
>         >>>>     AD thinks that it is working with another AD forest.
>         >>>>     For that to work we need to follow MSFT rules about
>         relationship
>         >>>>     between Kerberos realm and DNS domain.
>         >>>>     AD assumes that for every trusted forest Kerberos
>         realm = DNS
>         >>>>     domain. IPA makes it easy to do because it has
>         integrated tools to
>         >>>>     manage IPA DNS domain.
>         >>>>     If you want to manage it yourself through your DNS
>         you can do it,
>         >>>>     just more manual operations for you.
>         >>>>
>         >>>>     HTH
>         >>>>
>         >>>>     Thanks
>         >>>>     Dmitri
>         >>>>
>         >>>>
>         >>>>>
>         >>>>>     On Sun, Dec 7, 2014 at 9:44 PM, Dmitri Pal
>         <dpal at redhat.com <mailto:dpal at redhat.com>
>         >>>>>     <mailto:dpal at redhat.com <mailto:dpal at redhat.com>>>
>         wrote:
>         >>>>>
>         >>>>>         On 12/07/2014 06:44 PM, Matthew Herzog wrote:
>         >>>>>>         Thanks guys. I'm sorry for my delay in responding.
>         >>>>>>
>         >>>>>>         Firstly, I was under the impression (from
>         reading the docs)
>         >>>>>>         that having named running on IPA server was
>         critical.
>         >>>>>
>         >>>>>         Properly configured DNS is critical.
>         >>>>>         How you accomplish it is up to you.
>         >>>>>         IPA allows you to have a DNS server that would
>         simplify DNS
>         >>>>>         management but it can be done manually too. This
>         is why DNS
>         >>>>>         is optional.
>         >>>>>
>         >>>>>
>         >>>>>>         Also, the first question the ipa-server-install
>         script asks
>         >>>>>>         is, "Do you want to configure integrated DNS
>         (BIND)? ."
>         >>>>>>         While it's true the default answer is no, it
>         leads one to
>         >>>>>>         believe that DNS is central to IPA. Also the
>         >>>>>>  ipa-client-install script says,
>         >>>>>>
>         >>>>>>  [root at freeipa-poc-client02 ~]# ipa-client-install
>         >>>>>>         DNS discovery failed to determine your DNS domain
>         >>>>>>         Provide the domain name of your IPA server (ex:
>         example.com <http://example.com>
>         >>>>>>         <http://example.com>):
>         >>>>>>
>         >>>>>>         I can resolve -anything- from the machine using
>         dig or
>         >> whatever.
>         >>>>>>
>         >>>>>>         Ultimately, the reason I started to be
>         concerned about my
>         >>>>>>         IPA server's DNS config was because I was not
>         able to
>         >>>>>>         authenticate AD accounts to a client machine. I
>         saw a bunch
>         >>>>>>         of errors in the client's sssd logs which of
>         course I can't
>         >>>>>>         find now.
>         >>>>>>
>         >>>>>>         Perhaps it was these . . .
>         >>>>>>
>         >>>>>>         (Thu Dec  4 13:45:23 2014) [sssd] [ping_check]
>         (0x0100):
>         >>>>>>         Service nss replied to ping
>         >>>>>>         (Thu Dec  4 13:45:23 2014) [sssd] [ping_check]
>         (0x0100):
>         >>>>>>         Service sudo replied to ping
>         >>>>>>         (Thu Dec  4 13:45:23 2014) [sssd] [ping_check]
>         (0x0100):
>         >>>>>>         Service pam replied to ping
>         >>>>>>         (Thu Dec  4 13:45:23 2014) [sssd] [ping_check]
>         (0x0100):
>         >>>>>>         Service ssh replied to ping
>         >>>>>>         (Thu Dec  4 13:45:23 2014) [sssd] [ping_check]
>         (0x0100):
>         >>>>>>         Service pac replied to ping
>         >>>>>>         (Thu Dec  4 13:45:23 2014) [sssd] [ping_check]
>         (0x0100):
>         >>>>>>         Service bo3.e-bozo.com <http://bo3.e-bozo.com>
>         <http://bo3.e-bozo.com> replied to
>         >> ping
>         >>>>>>
>         >>>>>>         I'm not allowed onto the AD domain controllers
>         to examine
>         >>>>>>         log files or I'd be checking those first.
>         >>>>>>
>         >>>>>>         So ultimately the goal is to authenticate AD
>         users and users
>         >>>>>>         that exist in our ldap schema. We need to set
>         up groups of
>         >>>>>>         users that can run sudo commands on specific
>         groups of hosts.
>         >>>>>
>         >>>>>         Did you setup trusts as explained on the
>         following page?
>         >>>>> http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup
>         >>>>>
>         >>>>>
>         >>>>>>
>         >>>>>>
>         >>>>>>
>         >>>>>>         On Wed, Dec 3, 2014 at 3:46 AM, Petr Spacek
>         >>>>>>         <pspacek at redhat.com <mailto:pspacek at redhat.com>
>         <mailto:pspacek at redhat.com <mailto:pspacek at redhat.com>>> wrote:
>         >>>>>>
>         >>>>>>             On 3.12.2014 04:35, Dmitri Pal wrote:
>         >>>>>>             > On 12/02/2014 08:54 PM, Matthew Herzog wrote:
>         >>>>>>             >> Any other ideas? I just spun up a new VM
>         and took the
>         >>>>>>             defaults on everything
>         >>>>>>             >> while running ipa-server-install (the
>         defaults did
>         >>>>>>             make sense) and my new VM
>         >>>>>>             >> can't resolve -anything- in the domain
>         in which it
>         >>>>>>             lives. The "old" VM
>         >>>>>>             >> (running the same versions of everything
>         on the same
>         >>>>>>             OS) can't even resolve
>         >>>>>>             >> the clients I have registered with it!
>         >>>>>>             >>
>         >>>>>>             >> So I'm pretty frustrated and am
>         wondering, what
>         >>>>>>             _exactly_ is the role of
>         >>>>>>             >> bind in the IPA server and how is it
>         expected to know
>         >>>>>>             anything about the
>         >>>>>>             >> local DNS domain without becoming a bind
>         slave server?
>         >>>>>>             >
>         >>>>>>             > I am not sure I am 100% with you but...
>         >>>>>>             > If you use the defaults and nothing else
>         you get to
>         >>>>>>             the scenario when IPA has
>         >>>>>>             > its DNS but it is a self contained
>         environment. It
>         >>>>>>             seems that this is what you
>         >>>>>>             > observe.
>         >>>>>>             > It is expected that you decide in advance
>         what you
>         >>>>>>             want to do with DNS. There
>         >>>>>>             > are several options:
>         >>>>>>             > 1) You can delegate a zone to IPA to
>         manage, then you
>         >>>>>>             need to connect your IPA
>         >>>>>>             > DNS to your existing DNS during install
>         or after.
>         >>>>>>             > In this case the systems joined to IPA
>         will be a part
>         >>>>>>             of IPA domain/zone and
>         >>>>>>             > would also be able to resolve other
>         systems around
>         >>>>>>             > 2) Not use IPA DNS if you do not want to take
>         >>>>>>             advantage of it
>         >>>>>>             > 3) Have a self contained demo/lab
>         environment that you
>         >>>>>>             currently observe.
>         >>>>>>             >
>         >>>>>>             > What is the intent?
>         >>>>>>
>         >>>>>>             I agree with Dmitri, we need more
>         information from you:
>         >>>>>>             - You said "my new VM can't resolve
>         -anything- in the
>         >>>>>>             domain in which it
>         >>>>>>             lives." - Which domain do you mean?
>         >>>>>>
>         >>>>>>             - Apparently you have configured FreeIPA to
>         serve zone
>         >>>>>> e-bozo.com <http://e-bozo.com> <http://e-bozo.com>. Do
>         you have
>         >>>>>>             this zone configured on some other DNS
>         server at the
>         >>>>>>             same time?
>         >>>>>>
>         >>>>>>             Please keep in mind that authoritative
>         servers should
>         >>>>>>             share the database. You
>         >>>>>>             will get naming collisions if e-bozo.com
>         <http://e-bozo.com>
>         >>>>>>             <http://e-bozo.com> is served by FreeIPA
>         DNS servers and
>         >>>>>>             some other servers at the same time. Maybe
>         that is the
>         >>>>>>             problem you see right now.
>         >>>>>>
>         >>>>>>             As Dmitri said, the architecturally correct
>         solution is
>         >>>>>>             to decide if you want
>         >>>>>>             to use FreeIPA DNS or not. You have option
>         to either
>         >>>>>>             remove non-FreeIPA DNS
>         >>>>>>             servers and import data to FreeIPA or to add
>         >>>>>>  FreeIPA-specific DNS records to
>         >>>>>>             existing DNS servers and do not configure
>         FreeIPA to act
>         >>>>>>             as DNS server.
>         >>>>>>
>         >>>>>>             Petr^2 Spacek
>         >>>>>>
>         >>>>>>             >> Thanks.
>         >>>>>>             >>
>         >>>>>>             >> On Tue, Dec 2, 2014 at 11:58 AM, Petr Spacek
>         >>>>>>             <pspacek at redhat.com
>         <mailto:pspacek at redhat.com> <mailto:pspacek at redhat.com
>         <mailto:pspacek at redhat.com>>
>         >>>>>>             >> <mailto:pspacek at redhat.com
>         <mailto:pspacek at redhat.com>
>         >>>>>>  <mailto:pspacek at redhat.com
>         <mailto:pspacek at redhat.com>>>> wrote:
>         >>>>>>             >>
>         >>>>>>             >>    On 2.12.2014 17:36, Martin Basti wrote:
>         >>>>>>             >>    > On 02/12/14 17:28, Matthew Herzog
>         wrote:
>         >>>>>>             >>    >> I just realized that my IPA
>         servers cannot
>         >>>>>>             resolve ANY servers
>         >>>>>>             >>    in my domain.
>         >>>>>>             >>    >> What do I need to do to fix this?
>         Below is my
>         >>>>>>  named.conf.
>         >>>>>>             >>    >>
>         >>>>>>             >>    >>
>         >>>>>>             >>    >> options {
>         >>>>>>             >>    >>  // turns on IPv6 for port 53,
>         IPv4 is on by
>         >>>>>>             default for
>         >>>>>>             >>    all ifaces
>         >>>>>>             >>    >>  listen-on-v6 {any;};
>         >>>>>>             >>    >>
>         >>>>>>             >>    >>  // Put files that named is
>         allowed to write
>         >>>>>>             in the
>         >>>>>>             >>    data/ directory:
>         >>>>>>             >>    >>  directory "/var/named"; // the
>         default
>         >>>>>>             >>    >>  dump-file "data/cache_dump.db";
>         >>>>>>             >>    >>  statistics-file
>         "data/named_stats.txt";
>         >>>>>>             >>    >>  memstatistics-file
>         "data/named_mem_stats.txt";
>         >>>>>>             >>    >>
>         >>>>>>             >>    >>  forward first;
>         >>>>>>             >>    >>  forwarders {
>         >>>>>>             >>    >>          10.100.8.41;
>         >>>>>>             >>    >>          10.100.8.40;
>         >>>>>>             >>    >>          10.100.4.13;
>         >>>>>>             >>    >>          10.100.4.14;
>         >>>>>>             >>    >>          10.100.4.19;
>         >>>>>>             >>    >>          10.100.4.44;
>         >>>>>>             >>    >>  };
>         >>>>>>             >>    >>
>         >>>>>>             >>    >>  // Any host is permitted to issue
>         recursive
>         >>>>>>             queries
>         >>>>>>             >>    >>  allow-recursion { any; };
>         >>>>>>             >>    >>
>         >>>>>>             >>    >>  tkey-gssapi-keytab
>         "/etc/named.keytab";
>         >>>>>>             >>    >>  pid-file "/run/named/named.pid";
>         >>>>>>             >>    >> };
>         >>>>>>             >>    >>
>         >>>>>>             >>    >> /* If you want to enable
>         debugging, eg. using
>         >>>>>>             the 'rndc trace'
>         >>>>>>             >>    command,
>         >>>>>>             >>    >>  * By default, SELinux policy does
>         not allow
>         >>>>>>             named to modify
>         >>>>>>             >>    the /var/named
>         >>>>>>             >>    >> directory,
>         >>>>>>             >>    >>  * so put the default debug log
>         file in data/ :
>         >>>>>>             >>    >>  */
>         >>>>>>             >>    >> logging {
>         >>>>>>             >>    >>  channel default_debug {
>         >>>>>>             >>    >>          file "data/named.run";
>         >>>>>>             >>    >>          severity dynamic;
>         >>>>>>             >>    >>          print-time yes;
>         >>>>>>             >>    >>  };
>         >>>>>>             >>    >>  };
>         >>>>>>             >>    >> };
>         >>>>>>             >>    >>
>         >>>>>>             >>    >> zone "." IN {
>         >>>>>>             >>    >>  type hint;
>         >>>>>>             >>    >>  file "named.ca <http://named.ca>
>         <http://named.ca>
>         >>>>>>             <http://named.ca> <http://named.ca>";
>         >>>>>>             >>    >> };
>         >>>>>>             >>    >>
>         >>>>>>             >>    >> include "/etc/named.rfc1912.zones";
>         >>>>>>             >>    >>
>         >>>>>>             >>    >> dynamic-db "ipa" {
>         >>>>>>             >>    >>  library "ldap.so";
>         >>>>>>             >>    >>  arg "uri
>         >>>>>>             >>
>         ldapi://%2fvar%2frun%2fslapd-BO3-E-BOZO-COM.socket";
>         >>>>>>             >>    >>  arg "base cn=dns,
>         dc=bo3,dc=e-bozo,dc=com";
>         >>>>>>             >>    >>  arg "fake_mname
>         freeipa-poc01.bo3.e-bozo.com <http://freeipa-poc01.bo3.e-bozo.com>
>         >>>>>>             <http://freeipa-poc01.bo3.e-bozo.com>
>         >>>>>>             >>    <http://freeipa-poc01.bo3.e-bozo.com>
>         >>>>>>             >>    >>
>         <http://freeipa-poc01.bo3.e-bozo.com>.";
>         >>>>>>             >>    >>  arg "auth_method sasl";
>         >>>>>>             >>    >>  arg "sasl_mech GSSAPI";
>         >>>>>>             >>    >>  arg "sasl_user
>         >>>>>>             DNS/freeipa-poc01.bo3.e-bozo.com
>         <http://freeipa-poc01.bo3.e-bozo.com>
>         >>>>>>             <http://freeipa-poc01.bo3.e-bozo.com>
>         >>>>>>             >>    <http://freeipa-poc01.bo3.e-bozo.com>
>         >>>>>>             >>    >>
>         <http://freeipa-poc01.bo3.e-bozo.com>";
>         >>>>>>             >>    >>  arg "serial_autoincrement yes";
>         >>>>>>             >>    >> };
>         >>>>>>             >>    >>
>         >>>>>>             >>    >>
>         >>>>>>             >>    >>
>         >>>>>>             >>    >>
>         >>>>>>             >>    > Hello,
>         >>>>>>             >>    >
>         >>>>>>             >>    > which version ipa do you use? which
>         platform?
>         >>>>>>             Which version
>         >>>>>>             >>    bind-dyndb-ldap?
>         >>>>>>             >>    >
>         >>>>>>             >>    > Can you run these commands, and
>         check if there
>         >>>>>>             any errors?
>         >>>>>>             >>    > ipactl status
>         >>>>>>             >>    > systemctl status named  (respectively
>         >>>>>>  journalctl -u named)
>         >>>>>>             >>
>         >>>>>>             >>    We also may want to see information
>         listed on page
>         >>>>>>             >>
>         >>>>>>
>         >> https://fedorahosted.org/bind-dyndb-ldap/wiki/BugReporting
>
>         --
>         Petr^2 Spacek
>
>
>
>
>     -- 
>     If life gives you melons, you may be dyslexic.
>
>
>
>
> -- 
> If life gives you melons, you may be dyslexic.
>
>


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141208/a5796433/attachment.htm>

From matthew.herzog at gmail.com  Mon Dec  8 19:27:00 2014
From: matthew.herzog at gmail.com (Matthew Herzog)
Date: Mon, 8 Dec 2014 14:27:00 -0500
Subject: [Freeipa-users] DNS configuration
In-Reply-To: <CABhyZ34exwjj4o8RRu651w2kik96wMS3Y6dvEk14MG1Y+LkY9w@mail.gmail.com>
References: <CABhyZ34TCzUz+fNUSCvdZ38MS7rsLMMdb_jTdfKUsmYs86fn_Q@mail.gmail.com>
	<547DEA9E.2030203@redhat.com> <547DEFB5.1020205@redhat.com>
	<CABhyZ347EU+Q85jQJGU30yx4njC3OtL_QsJZi1MMu1ZR2Lfd2Q@mail.gmail.com>
	<547E851C.1020407@redhat.com> <547ECDDC.3090001@redhat.com>
	<CABhyZ37XChaQF+4rRY-L=OU9pVNp7Mw_NQifTk3NhrewzJtyVQ@mail.gmail.com>
	<5485108E.60409@redhat.com>
	<CABhyZ36DDM6icM+haMbVErdVdDWonGqbPE+3Tpad4K=u9QHjAQ@mail.gmail.com>
	<54851385.3050709@redhat.com>
	<CABhyZ36D_SVLezC=wZ3tsYHn00tdBGsxpOxCtpVgWZo8EdH2hw@mail.gmail.com>
	<548522B8.8040805@redhat.com> <5485599E.8030801@redhat.com>
	<CABhyZ34Pbr4J6YDdLSmP=qPqAB7Pa=tWvw273aB-BNX4dRq-GQ@mail.gmail.com>
	<5485C698.9000406@redhat.com>
	<CABhyZ35qsCM0y8anFdqE7r60Fz8LAU8Yx3WWaF6zBhfg=dRUJA@mail.gmail.com>
	<CABhyZ34exwjj4o8RRu651w2kik96wMS3Y6dvEk14MG1Y+LkY9w@mail.gmail.com>
Message-ID: <CABhyZ35Mi1P8J9pzF-q1Uh_dRES52xqBuQggDw5-m70XxaZN-Q@mail.gmail.com>

OK, I found the generated zoe file in /tmp and it looks sane.
Should I add those lines of config to our DNS servers?

On Mon, Dec 8, 2014 at 2:10 PM, Matthew Herzog <matthew.herzog at gmail.com>
wrote:

> Here are some errors I'm seeing on the client.
>
> tail -f sssd_lnx.e-bozo.com.log
> (Mon Dec  8 14:03:20 2014) [sssd[be[lnx.e-bozo.com]]] [sbus_dispatch]
> (0x4000): dbus conn: 0x1e72ad0
> (Mon Dec  8 14:03:20 2014) [sssd[be[lnx.e-bozo.com]]] [sbus_dispatch]
> (0x4000): Dispatching.
> (Mon Dec  8 14:03:20 2014) [sssd[be[lnx.e-bozo.com]]]
> [sbus_message_handler] (0x4000): Received SBUS method [ping]
> (Mon Dec  8 14:03:20 2014) [sssd[be[lnx.e-bozo.com]]]
> [sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit
> (Mon Dec  8 14:03:20 2014) [sssd[be[lnx.e-bozo.com]]]
> [sbus_handler_got_caller_id] (0x4000): Received SBUS method [ping]
> (Mon Dec  8 14:03:30 2014) [sssd[be[lnx.e-bozo.com]]] [sbus_dispatch]
> (0x4000): dbus conn: 0x1e72ad0
> (Mon Dec  8 14:03:30 2014) [sssd[be[lnx.e-bozo.com]]] [sbus_dispatch]
> (0x4000): Dispatching.
> (Mon Dec  8 14:03:30 2014) [sssd[be[lnx.e-bozo.com]]]
> [sbus_message_handler] (0x4000): Received SBUS method [ping]
> (Mon Dec  8 14:03:30 2014) [sssd[be[lnx.e-bozo.com]]]
> [sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit
> (Mon Dec  8 14:03:30 2014) [sssd[be[lnx.e-bozo.com]]]
> [sbus_handler_got_caller_id] (0x4000): Received SBUS method [ping]
> (Mon Dec  8 14:03:40 2014) [sssd[be[lnx.e-bozo.com]]] [sbus_dispatch]
> (0x4000): dbus conn: 0x1e72ad0
> (Mon Dec  8 14:03:40 2014) [sssd[be[lnx.e-bozo.com]]] [sbus_dispatch]
> (0x4000): Dispatching.
>
> [root at freeipa-poc-client02 sssd]# tail -f sssd_ssh.log
> (Sun Dec  7 19:32:09 2014) [sssd[ssh]] [ssh_process_init] (0x0010):
> sss_process_init() failed
> (Sun Dec  7 19:32:09 2014) [sssd[ssh]] [sss_dp_init] (0x0010): Failed to
> connect to monitor services.
> (Sun Dec  7 19:32:09 2014) [sssd[ssh]] [sss_process_init] (0x0010): fatal
> error setting up backend connector
> (Sun Dec  7 19:32:09 2014) [sssd[ssh]] [ssh_process_init] (0x0010):
> sss_process_init() failed
> (Sun Dec  7 19:32:16 2014) [sssd[ssh]] [sss_dp_init] (0x0010): Failed to
> connect to monitor services.
> (Sun Dec  7 19:32:16 2014) [sssd[ssh]] [sss_process_init] (0x0010): fatal
> error setting up backend connector
> (Sun Dec  7 19:32:16 2014) [sssd[ssh]] [ssh_process_init] (0x0010):
> sss_process_init() failed
> (Sun Dec  7 19:32:16 2014) [sssd[ssh]] [sss_dp_init] (0x0010): Failed to
> connect to monitor services.
> (Sun Dec  7 19:32:16 2014) [sssd[ssh]] [sss_process_init] (0x0010): fatal
> error setting up backend connector
> (Sun Dec  7 19:32:16 2014) [sssd[ssh]] [ssh_process_init] (0x0010):
> sss_process_init() failed
>
>
> On Mon, Dec 8, 2014 at 11:48 AM, Matthew Herzog <matthew.herzog at gmail.com>
> wrote:
>
>> I have never seen my IPA servers produce a zone file nor has the install
>> script ever mentioned the creation of such. In fact, I just ran
>> ipa-server-install --uninstall && ipa-server-install and there was no
>> mention of a zone file.
>>
>> Where should I look in the file system to be sure? I see nothing in
>> /var/named. I'm using 3.3.3 IPA on Oracle Linux from Oracle's yum repo.
>> (Not my choice.)
>>
>> dsee7 is *not *running Kerberos. dsee7 is *not *configured with SRV
>> records. I guess I'll need to add SRV records for all my Linux hosts.
>>
>>
>>
>>
>>
>>
>> On Mon, Dec 8, 2014 at 10:41 AM, Petr Spacek <pspacek at redhat.com> wrote:
>>
>>> On 8.12.2014 14:44, Matthew Herzog wrote:
>>> > Petr said, "You can run ipa-server-install *without* --setup-dns
>>> option and
>>> > at the end of
>>> > installation it will produce DNS records which you have to manually
>>> add to
>>> > your existing DNS database."
>>> >
>>> > I can't see how this would be useful or which machines I would need to
>>> add
>>> > to our DNS.
>>> >
>>> > Perhaps I should have explained that we are not going to set up a new
>>> DNS
>>> > domain for the ipa-managed servers.
>>> Good.
>>>
>>> Now you should run ipa-server-install *without* --setup-dns, using
>>> lnx.e-bozo.com as you IPA domain. It will install full IPA server and
>>> spit out
>>> DNS zone file.
>>>
>>> Then you *have to* take this zone file and import it to your existing DNS
>>> infrastructure - that will give you fully functional IPA domain
>>> lnx.e-bozo.com.
>>>
>>> Caveat:
>>> Preceding text assumes that 'dsee7' is nor using either Kerberos nor DNS
>>> SRV
>>> records for LDAP service in domain lnx.e-bozo.com, i.e. clients
>>> connecting to
>>> DSEE7 should be (most likely) statically configured with DSEE7 server
>>> name.
>>>
>>> Petr^2 Spacek
>>>
>>> > We have an Oracle dsee7 server doing
>>> > LDAP for our Linux servers and accounts. We want to migrate to IPA so
>>> we
>>> > don't have to maintain a Linux/LDAP account for every user who needs
>>> access
>>> > to Linux servers. All of our users start with an account in AD and
>>> since
>>> > none of my predecessors knew about Winbind, they set up dsee7.
>>> >
>>> > So I'm thinking we'll need to import all our dsee7 accounts AND make it
>>> > possible for AD users to access the Linux systems without needing to
>>> create
>>> > them in IPA.
>>> >
>>> > On Mon, Dec 8, 2014 at 2:56 AM, Petr Spacek <pspacek at redhat.com>
>>> wrote:
>>> >
>>> >> On 8.12.2014 05:02, Dmitri Pal wrote:
>>> >>> On 12/07/2014 10:10 PM, Matthew Herzog wrote:
>>> >>>> So should the FreeIPA server be authoritative for the Kerb.
>>> realm/DNS
>>> >> domain
>>> >>>> or can it/should it be a slave DNS server instead? Or caching only?
>>> >>>
>>> >>> IPA DNS can't be a slave so you either delegate a whole zone to it or
>>> >> manage
>>> >>> IPA DNS domain via your own DNS server.
>>> >>
>>> >> Generally, "slave" is not allowed to do any changes so it is useless
>>> in
>>> >> your
>>> >> scenario.
>>> >>
>>> >> You can run ipa-server-install *without* --setup-dns option and at
>>> the end
>>> >> of
>>> >> installation it will produce DNS records which you have to manually
>>> add to
>>> >> your existing DNS database.
>>> >>
>>> >> Did you try that?
>>> >>
>>> >> Petr^2 Spacek
>>> >>
>>> >>>> On Sun, Dec 7, 2014 at 9:57 PM, Dmitri Pal <dpal at redhat.com
>>> >>>> <mailto:dpal at redhat.com>> wrote:
>>> >>>>
>>> >>>>     On 12/07/2014 09:51 PM, Matthew Herzog wrote:
>>> >>>>>     What must be done in or on the ipa server with regard to DNS,
>>> if
>>> >>>>>     anything?
>>> >>>>>
>>> >>>>>     Our DNS works. It works well. We have four Linux DNS servers
>>> and
>>> >>>>>     two AD domain controllers that also do DNS.
>>> >>>>>
>>> >>>>>     So if we already have DNS working well in our domain, why do we
>>> >>>>>     want to manage DNS in IPA?
>>> >>>>
>>> >>>>     Let us keep the discussion on the list.
>>> >>>>     IPA when used with AD trust presents itself as a separate
>>> forest.
>>> >>>>     AD thinks that it is working with another AD forest.
>>> >>>>     For that to work we need to follow MSFT rules about relationship
>>> >>>>     between Kerberos realm and DNS domain.
>>> >>>>     AD assumes that for every trusted forest Kerberos realm = DNS
>>> >>>>     domain. IPA makes it easy to do because it has integrated tools
>>> to
>>> >>>>     manage IPA DNS domain.
>>> >>>>     If you want to manage it yourself through your DNS you can do
>>> it,
>>> >>>>     just more manual operations for you.
>>> >>>>
>>> >>>>     HTH
>>> >>>>
>>> >>>>     Thanks
>>> >>>>     Dmitri
>>> >>>>
>>> >>>>
>>> >>>>>
>>> >>>>>     On Sun, Dec 7, 2014 at 9:44 PM, Dmitri Pal <dpal at redhat.com
>>> >>>>>     <mailto:dpal at redhat.com>> wrote:
>>> >>>>>
>>> >>>>>         On 12/07/2014 06:44 PM, Matthew Herzog wrote:
>>> >>>>>>         Thanks guys. I'm sorry for my delay in responding.
>>> >>>>>>
>>> >>>>>>         Firstly, I was under the impression (from reading the
>>> docs)
>>> >>>>>>         that having named running on IPA server was critical.
>>> >>>>>
>>> >>>>>         Properly configured DNS is critical.
>>> >>>>>         How you accomplish it is up to you.
>>> >>>>>         IPA allows you to have a DNS server that would simplify DNS
>>> >>>>>         management but it can be done manually too. This is why DNS
>>> >>>>>         is optional.
>>> >>>>>
>>> >>>>>
>>> >>>>>>         Also, the first question the ipa-server-install script
>>> asks
>>> >>>>>>         is, "Do you want to configure integrated DNS (BIND)? ."
>>> >>>>>>         While it's true the default answer is no, it leads one to
>>> >>>>>>         believe that DNS is central to IPA. Also the
>>> >>>>>>         ipa-client-install script says,
>>> >>>>>>
>>> >>>>>>         [root at freeipa-poc-client02 ~]# ipa-client-install
>>> >>>>>>         DNS discovery failed to determine your DNS domain
>>> >>>>>>         Provide the domain name of your IPA server (ex:
>>> example.com
>>> >>>>>>         <http://example.com>):
>>> >>>>>>
>>> >>>>>>         I can resolve -anything- from the machine using dig or
>>> >> whatever.
>>> >>>>>>
>>> >>>>>>         Ultimately, the reason I started to be concerned about my
>>> >>>>>>         IPA server's DNS config was because I was not able to
>>> >>>>>>         authenticate AD accounts to a client machine. I saw a
>>> bunch
>>> >>>>>>         of errors in the client's sssd logs which of course I
>>> can't
>>> >>>>>>         find now.
>>> >>>>>>
>>> >>>>>>         Perhaps it was these . . .
>>> >>>>>>
>>> >>>>>>         (Thu Dec  4 13:45:23 2014) [sssd] [ping_check] (0x0100):
>>> >>>>>>         Service nss replied to ping
>>> >>>>>>         (Thu Dec  4 13:45:23 2014) [sssd] [ping_check] (0x0100):
>>> >>>>>>         Service sudo replied to ping
>>> >>>>>>         (Thu Dec  4 13:45:23 2014) [sssd] [ping_check] (0x0100):
>>> >>>>>>         Service pam replied to ping
>>> >>>>>>         (Thu Dec  4 13:45:23 2014) [sssd] [ping_check] (0x0100):
>>> >>>>>>         Service ssh replied to ping
>>> >>>>>>         (Thu Dec  4 13:45:23 2014) [sssd] [ping_check] (0x0100):
>>> >>>>>>         Service pac replied to ping
>>> >>>>>>         (Thu Dec  4 13:45:23 2014) [sssd] [ping_check] (0x0100):
>>> >>>>>>         Service bo3.e-bozo.com <http://bo3.e-bozo.com> replied to
>>> >> ping
>>> >>>>>>
>>> >>>>>>         I'm not allowed onto the AD domain controllers to examine
>>> >>>>>>         log files or I'd be checking those first.
>>> >>>>>>
>>> >>>>>>         So ultimately the goal is to authenticate AD users and
>>> users
>>> >>>>>>         that exist in our ldap schema. We need to set up groups of
>>> >>>>>>         users that can run sudo commands on specific groups of
>>> hosts.
>>> >>>>>
>>> >>>>>         Did you setup trusts as explained on the following page?
>>> >>>>>         http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup
>>> >>>>>
>>> >>>>>
>>> >>>>>>
>>> >>>>>>
>>> >>>>>>
>>> >>>>>>         On Wed, Dec 3, 2014 at 3:46 AM, Petr Spacek
>>> >>>>>>         <pspacek at redhat.com <mailto:pspacek at redhat.com>> wrote:
>>> >>>>>>
>>> >>>>>>             On 3.12.2014 04:35, Dmitri Pal wrote:
>>> >>>>>>             > On 12/02/2014 08:54 PM, Matthew Herzog wrote:
>>> >>>>>>             >> Any other ideas? I just spun up a new VM and took
>>> the
>>> >>>>>>             defaults on everything
>>> >>>>>>             >> while running ipa-server-install (the defaults did
>>> >>>>>>             make sense) and my new VM
>>> >>>>>>             >> can't resolve -anything- in the domain in which it
>>> >>>>>>             lives. The "old" VM
>>> >>>>>>             >> (running the same versions of everything on the
>>> same
>>> >>>>>>             OS) can't even resolve
>>> >>>>>>             >> the clients I have registered with it!
>>> >>>>>>             >>
>>> >>>>>>             >> So I'm pretty frustrated and am wondering, what
>>> >>>>>>             _exactly_ is the role of
>>> >>>>>>             >> bind in the IPA server and how is it expected to
>>> know
>>> >>>>>>             anything about the
>>> >>>>>>             >> local DNS domain without becoming a bind slave
>>> server?
>>> >>>>>>             >
>>> >>>>>>             > I am not sure I am 100% with you but...
>>> >>>>>>             > If you use the defaults and nothing else you get to
>>> >>>>>>             the scenario when IPA has
>>> >>>>>>             > its DNS but it is a self contained environment. It
>>> >>>>>>             seems that this is what you
>>> >>>>>>             > observe.
>>> >>>>>>             > It is expected that you decide in advance what you
>>> >>>>>>             want to do with DNS. There
>>> >>>>>>             > are several options:
>>> >>>>>>             > 1) You can delegate a zone to IPA to manage, then
>>> you
>>> >>>>>>             need to connect your IPA
>>> >>>>>>             > DNS to your existing DNS during install or after.
>>> >>>>>>             > In this case the systems joined to IPA will be a
>>> part
>>> >>>>>>             of IPA domain/zone and
>>> >>>>>>             > would also be able to resolve other systems around
>>> >>>>>>             > 2) Not use IPA DNS if you do not want to take
>>> >>>>>>             advantage of it
>>> >>>>>>             > 3) Have a self contained demo/lab environment that
>>> you
>>> >>>>>>             currently observe.
>>> >>>>>>             >
>>> >>>>>>             > What is the intent?
>>> >>>>>>
>>> >>>>>>             I agree with Dmitri, we need more information from
>>> you:
>>> >>>>>>             - You said "my new VM can't resolve -anything- in the
>>> >>>>>>             domain in which it
>>> >>>>>>             lives." - Which domain do you mean?
>>> >>>>>>
>>> >>>>>>             - Apparently you have configured FreeIPA to serve zone
>>> >>>>>>             e-bozo.com <http://e-bozo.com>. Do you have
>>> >>>>>>             this zone configured on some other DNS server at the
>>> >>>>>>             same time?
>>> >>>>>>
>>> >>>>>>             Please keep in mind that authoritative servers should
>>> >>>>>>             share the database. You
>>> >>>>>>             will get naming collisions if e-bozo.com
>>> >>>>>>             <http://e-bozo.com> is served by FreeIPA DNS servers
>>> and
>>> >>>>>>             some other servers at the same time. Maybe that is the
>>> >>>>>>             problem you see right now.
>>> >>>>>>
>>> >>>>>>             As Dmitri said, the architecturally correct solution
>>> is
>>> >>>>>>             to decide if you want
>>> >>>>>>             to use FreeIPA DNS or not. You have option to either
>>> >>>>>>             remove non-FreeIPA DNS
>>> >>>>>>             servers and import data to FreeIPA or to add
>>> >>>>>>             FreeIPA-specific DNS records to
>>> >>>>>>             existing DNS servers and do not configure FreeIPA to
>>> act
>>> >>>>>>             as DNS server.
>>> >>>>>>
>>> >>>>>>             Petr^2 Spacek
>>> >>>>>>
>>> >>>>>>             >> Thanks.
>>> >>>>>>             >>
>>> >>>>>>             >> On Tue, Dec 2, 2014 at 11:58 AM, Petr Spacek
>>> >>>>>>             <pspacek at redhat.com <mailto:pspacek at redhat.com>
>>> >>>>>>             >> <mailto:pspacek at redhat.com
>>> >>>>>>             <mailto:pspacek at redhat.com>>> wrote:
>>> >>>>>>             >>
>>> >>>>>>             >>     On 2.12.2014 17:36, Martin Basti wrote:
>>> >>>>>>             >>     > On 02/12/14 17:28, Matthew Herzog wrote:
>>> >>>>>>             >>     >> I just realized that my IPA servers cannot
>>> >>>>>>             resolve ANY servers
>>> >>>>>>             >>     in my domain.
>>> >>>>>>             >>     >> What do I need to do to fix this? Below is
>>> my
>>> >>>>>>             named.conf.
>>> >>>>>>             >>     >>
>>> >>>>>>             >>     >>
>>> >>>>>>             >>     >> options {
>>> >>>>>>             >>     >>  // turns on IPv6 for port 53, IPv4 is on by
>>> >>>>>>             default for
>>> >>>>>>             >>     all ifaces
>>> >>>>>>             >>     >>  listen-on-v6 {any;};
>>> >>>>>>             >>     >>
>>> >>>>>>             >>     >>  // Put files that named is allowed to write
>>> >>>>>>             in the
>>> >>>>>>             >>     data/ directory:
>>> >>>>>>             >>     >>  directory "/var/named"; // the default
>>> >>>>>>             >>     >>  dump-file "data/cache_dump.db";
>>> >>>>>>             >>     >>  statistics-file "data/named_stats.txt";
>>> >>>>>>             >>     >>  memstatistics-file
>>> "data/named_mem_stats.txt";
>>> >>>>>>             >>     >>
>>> >>>>>>             >>     >>  forward first;
>>> >>>>>>             >>     >>  forwarders {
>>> >>>>>>             >>     >>          10.100.8.41;
>>> >>>>>>             >>     >>          10.100.8.40;
>>> >>>>>>             >>     >>          10.100.4.13;
>>> >>>>>>             >>     >>          10.100.4.14;
>>> >>>>>>             >>     >>          10.100.4.19;
>>> >>>>>>             >>     >>          10.100.4.44;
>>> >>>>>>             >>     >>  };
>>> >>>>>>             >>     >>
>>> >>>>>>             >>     >>  // Any host is permitted to issue recursive
>>> >>>>>>             queries
>>> >>>>>>             >>     >>  allow-recursion { any; };
>>> >>>>>>             >>     >>
>>> >>>>>>             >>     >>  tkey-gssapi-keytab "/etc/named.keytab";
>>> >>>>>>             >>     >>  pid-file "/run/named/named.pid";
>>> >>>>>>             >>     >> };
>>> >>>>>>             >>     >>
>>> >>>>>>             >>     >> /* If you want to enable debugging, eg.
>>> using
>>> >>>>>>             the 'rndc trace'
>>> >>>>>>             >>     command,
>>> >>>>>>             >>     >>  * By default, SELinux policy does not allow
>>> >>>>>>             named to modify
>>> >>>>>>             >>     the /var/named
>>> >>>>>>             >>     >> directory,
>>> >>>>>>             >>     >>  * so put the default debug log file in
>>> data/ :
>>> >>>>>>             >>     >>  */
>>> >>>>>>             >>     >> logging {
>>> >>>>>>             >>     >>  channel default_debug {
>>> >>>>>>             >>     >>          file "data/named.run";
>>> >>>>>>             >>     >>          severity dynamic;
>>> >>>>>>             >>     >>          print-time yes;
>>> >>>>>>             >>     >>  };
>>> >>>>>>             >>     >>  };
>>> >>>>>>             >>     >> };
>>> >>>>>>             >>     >>
>>> >>>>>>             >>     >> zone "." IN {
>>> >>>>>>             >>     >>  type hint;
>>> >>>>>>             >>     >>  file "named.ca <http://named.ca>
>>> >>>>>>             <http://named.ca> <http://named.ca>";
>>> >>>>>>             >>     >> };
>>> >>>>>>             >>     >>
>>> >>>>>>             >>     >> include "/etc/named.rfc1912.zones";
>>> >>>>>>             >>     >>
>>> >>>>>>             >>     >> dynamic-db "ipa" {
>>> >>>>>>             >>     >>  library "ldap.so";
>>> >>>>>>             >>     >>  arg "uri
>>> >>>>>>             >>
>>> ldapi://%2fvar%2frun%2fslapd-BO3-E-BOZO-COM.socket";
>>> >>>>>>             >>     >>  arg "base cn=dns, dc=bo3,dc=e-bozo,dc=com";
>>> >>>>>>             >>     >>  arg "fake_mname
>>> freeipa-poc01.bo3.e-bozo.com
>>> >>>>>>             <http://freeipa-poc01.bo3.e-bozo.com>
>>> >>>>>>             >>     <http://freeipa-poc01.bo3.e-bozo.com>
>>> >>>>>>             >>     >> <http://freeipa-poc01.bo3.e-bozo.com>.";
>>> >>>>>>             >>     >>  arg "auth_method sasl";
>>> >>>>>>             >>     >>  arg "sasl_mech GSSAPI";
>>> >>>>>>             >>     >>  arg "sasl_user
>>> >>>>>>             DNS/freeipa-poc01.bo3.e-bozo.com
>>> >>>>>>             <http://freeipa-poc01.bo3.e-bozo.com>
>>> >>>>>>             >>     <http://freeipa-poc01.bo3.e-bozo.com>
>>> >>>>>>             >>     >> <http://freeipa-poc01.bo3.e-bozo.com>";
>>> >>>>>>             >>     >>  arg "serial_autoincrement yes";
>>> >>>>>>             >>     >> };
>>> >>>>>>             >>     >>
>>> >>>>>>             >>     >>
>>> >>>>>>             >>     >>
>>> >>>>>>             >>     >>
>>> >>>>>>             >>     > Hello,
>>> >>>>>>             >>     >
>>> >>>>>>             >>     > which version ipa do you use? which platform?
>>> >>>>>>             Which version
>>> >>>>>>             >>     bind-dyndb-ldap?
>>> >>>>>>             >>     >
>>> >>>>>>             >>     > Can you run these commands, and check if
>>> there
>>> >>>>>>             any errors?
>>> >>>>>>             >>     > ipactl status
>>> >>>>>>             >>     > systemctl status named  (respectively
>>> >>>>>>             journalctl -u named)
>>> >>>>>>             >>
>>> >>>>>>             >>     We also may want to see information listed on
>>> page
>>> >>>>>>             >>
>>> >>>>>>
>>> >> https://fedorahosted.org/bind-dyndb-ldap/wiki/BugReporting
>>>
>>> --
>>> Petr^2 Spacek
>>>
>>
>>
>>
>> --
>> If life gives you melons, you may be dyslexic.
>>
>
>
>
> --
> If life gives you melons, you may be dyslexic.
>



-- 
If life gives you melons, you may be dyslexic.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141208/9e2cca11/attachment.htm>

From matthew.herzog at gmail.com  Mon Dec  8 22:54:09 2014
From: matthew.herzog at gmail.com (Matthew Herzog)
Date: Mon, 8 Dec 2014 17:54:09 -0500
Subject: [Freeipa-users] DNS configuration
In-Reply-To: <CABhyZ37DH2w8o22Bi49F0y5zXb97NNaKYyO40iHWFyeMCYNkVA@mail.gmail.com>
References: <CABhyZ34TCzUz+fNUSCvdZ38MS7rsLMMdb_jTdfKUsmYs86fn_Q@mail.gmail.com>
	<547DEA9E.2030203@redhat.com> <547DEFB5.1020205@redhat.com>
	<CABhyZ347EU+Q85jQJGU30yx4njC3OtL_QsJZi1MMu1ZR2Lfd2Q@mail.gmail.com>
	<547E851C.1020407@redhat.com> <547ECDDC.3090001@redhat.com>
	<CABhyZ37XChaQF+4rRY-L=OU9pVNp7Mw_NQifTk3NhrewzJtyVQ@mail.gmail.com>
	<5485108E.60409@redhat.com>
	<CABhyZ36DDM6icM+haMbVErdVdDWonGqbPE+3Tpad4K=u9QHjAQ@mail.gmail.com>
	<54851385.3050709@redhat.com>
	<CABhyZ36D_SVLezC=wZ3tsYHn00tdBGsxpOxCtpVgWZo8EdH2hw@mail.gmail.com>
	<548522B8.8040805@redhat.com> <5485599E.8030801@redhat.com>
	<CABhyZ34Pbr4J6YDdLSmP=qPqAB7Pa=tWvw273aB-BNX4dRq-GQ@mail.gmail.com>
	<5485C698.9000406@redhat.com>
	<CABhyZ35qsCM0y8anFdqE7r60Fz8LAU8Yx3WWaF6zBhfg=dRUJA@mail.gmail.com>
	<CABhyZ34exwjj4o8RRu651w2kik96wMS3Y6dvEk14MG1Y+LkY9w@mail.gmail.com>
	<5485FB6D.8000005@redhat.com>
	<CABhyZ34y-UKFpvRwuKsgPx=w+nQ3VTvwJWZ-M9v-XzUpoQ8v1w@mail.gmail.com>
	<CABhyZ37DH2w8o22Bi49F0y5zXb97NNaKYyO40iHWFyeMCYNkVA@mail.gmail.com>
Message-ID: <CABhyZ367SZ9zK+s_49QR_DGXg3+PBqT0rr0jD-hGyJC+eGPMdQ@mail.gmail.com>

OK, I deserve a slap. I had forgotten to set up the two-way trust again
since the ipa-server-install --uninstall && reinstall. That's back in place.

So I found Sumit Bose's https://www.youtube.com/watch?v=infot4cmZgM and
realized I could not add groups to any new, external user group using the
ipa server's web interface.

Error in the GUI is, E-BOZO.COM\Domain Users: invalid 'truster domain
object': no trusted domain matched the specified flat name.



On Mon, Dec 8, 2014 at 2:49 PM, Matthew Herzog <matthew.herzog at gmail.com>
wrote:

> sssd_<hostname>.log
> (Mon Dec  8 14:46:54 2014) [sssd[be[bo3.e-bozo.com]]]
> [sysdb_search_groups] (0x2000): No such entry
> (Mon Dec  8 14:46:54 2014) [sssd[be[bo3.e-bozo.com]]] [sysdb_delete_user]
> (0x0400): Error: 2 (No such file or directory)
> (Mon Dec  8 14:46:54 2014) [sssd[be[bo3.e-bozo.com]]] [acctinfo_callback]
> (0x0100): Request processed. Returned 0,0,Success
> (Mon Dec  8 14:46:54 2014) [sssd[be[bo3.e-bozo.com]]]
> [sdap_process_result] (0x2000): Trace: sh[0x17b0030], connected[1],
> ops[(nil)], ldap[0x17ab240]
> (Mon Dec  8 14:46:54 2014) [sssd[be[bo3.e-bozo.com]]]
> [sdap_process_result] (0x2000): Trace: ldap_result found nothing!
> (Mon Dec  8 14:46:57 2014) [sssd[be[bo3.e-bozo.com]]] [sbus_dispatch]
> (0x4000): dbus conn: 0x178eb70
> (Mon Dec  8 14:46:57 2014) [sssd[be[bo3.e-bozo.com]]] [sbus_dispatch]
> (0x4000): Dispatching.
>
>
> On Mon, Dec 8, 2014 at 2:32 PM, Matthew Herzog <matthew.herzog at gmail.com>
> wrote:
>
>> ipa-client-3.0.0-42.el6.x86_64 on OEL 6.5 (server has 3.3.3 IPA)
>>
>>
>> On Mon, Dec 8, 2014 at 2:26 PM, Dmitri Pal <dpal at redhat.com> wrote:
>>
>>>  On 12/08/2014 02:10 PM, Matthew Herzog wrote:
>>>
>>>  Here are some errors I'm seeing on the client.
>>>
>>>  tail -f sssd_lnx.e-bozo.com.log
>>>  (Mon Dec  8 14:03:20 2014) [sssd[be[lnx.e-bozo.com]]] [sbus_dispatch]
>>> (0x4000): dbus conn: 0x1e72ad0
>>> (Mon Dec  8 14:03:20 2014) [sssd[be[lnx.e-bozo.com]]] [sbus_dispatch]
>>> (0x4000): Dispatching.
>>> (Mon Dec  8 14:03:20 2014) [sssd[be[lnx.e-bozo.com]]]
>>> [sbus_message_handler] (0x4000): Received SBUS method [ping]
>>> (Mon Dec  8 14:03:20 2014) [sssd[be[lnx.e-bozo.com]]]
>>> [sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit
>>> (Mon Dec  8 14:03:20 2014) [sssd[be[lnx.e-bozo.com]]]
>>> [sbus_handler_got_caller_id] (0x4000): Received SBUS method [ping]
>>> (Mon Dec  8 14:03:30 2014) [sssd[be[lnx.e-bozo.com]]] [sbus_dispatch]
>>> (0x4000): dbus conn: 0x1e72ad0
>>> (Mon Dec  8 14:03:30 2014) [sssd[be[lnx.e-bozo.com]]] [sbus_dispatch]
>>> (0x4000): Dispatching.
>>> (Mon Dec  8 14:03:30 2014) [sssd[be[lnx.e-bozo.com]]]
>>> [sbus_message_handler] (0x4000): Received SBUS method [ping]
>>> (Mon Dec  8 14:03:30 2014) [sssd[be[lnx.e-bozo.com]]]
>>> [sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit
>>> (Mon Dec  8 14:03:30 2014) [sssd[be[lnx.e-bozo.com]]]
>>> [sbus_handler_got_caller_id] (0x4000): Received SBUS method [ping]
>>> (Mon Dec  8 14:03:40 2014) [sssd[be[lnx.e-bozo.com]]] [sbus_dispatch]
>>> (0x4000): dbus conn: 0x1e72ad0
>>> (Mon Dec  8 14:03:40 2014) [sssd[be[lnx.e-bozo.com]]] [sbus_dispatch]
>>> (0x4000): Dispatching.
>>>
>>>  [root at freeipa-poc-client02 sssd]# tail -f sssd_ssh.log
>>> (Sun Dec  7 19:32:09 2014) [sssd[ssh]] [ssh_process_init] (0x0010):
>>> sss_process_init() failed
>>> (Sun Dec  7 19:32:09 2014) [sssd[ssh]] [sss_dp_init] (0x0010): Failed to
>>> connect to monitor services.
>>> (Sun Dec  7 19:32:09 2014) [sssd[ssh]] [sss_process_init] (0x0010):
>>> fatal error setting up backend connector
>>> (Sun Dec  7 19:32:09 2014) [sssd[ssh]] [ssh_process_init] (0x0010):
>>> sss_process_init() failed
>>> (Sun Dec  7 19:32:16 2014) [sssd[ssh]] [sss_dp_init] (0x0010): Failed to
>>> connect to monitor services.
>>> (Sun Dec  7 19:32:16 2014) [sssd[ssh]] [sss_process_init] (0x0010):
>>> fatal error setting up backend connector
>>> (Sun Dec  7 19:32:16 2014) [sssd[ssh]] [ssh_process_init] (0x0010):
>>> sss_process_init() failed
>>> (Sun Dec  7 19:32:16 2014) [sssd[ssh]] [sss_dp_init] (0x0010): Failed to
>>> connect to monitor services.
>>> (Sun Dec  7 19:32:16 2014) [sssd[ssh]] [sss_process_init] (0x0010):
>>> fatal error setting up backend connector
>>> (Sun Dec  7 19:32:16 2014) [sssd[ssh]] [ssh_process_init] (0x0010):
>>> sss_process_init() failed
>>>
>>>
>>> What is the version of the client?
>>> Please add debug_level=9 to sssd.conf in different sections to rise the
>>> verbosity of the log and see what is really going on there.
>>> https://fedorahosted.org/sssd/wiki/FAQ#BasicsofTroubleshooting
>>>
>>>
>>>
>>>
>>>
>>> On Mon, Dec 8, 2014 at 11:48 AM, Matthew Herzog <
>>> matthew.herzog at gmail.com> wrote:
>>>
>>>> I have never seen my IPA servers produce a zone file nor has the
>>>> install script ever mentioned the creation of such. In fact, I just ran
>>>> ipa-server-install --uninstall && ipa-server-install and there was no
>>>> mention of a zone file.
>>>>
>>>>  Where should I look in the file system to be sure? I see nothing in
>>>> /var/named. I'm using 3.3.3 IPA on Oracle Linux from Oracle's yum repo.
>>>> (Not my choice.)
>>>>
>>>>  dsee7 is *not *running Kerberos. dsee7 is *not *configured with SRV
>>>> records. I guess I'll need to add SRV records for all my Linux hosts.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Mon, Dec 8, 2014 at 10:41 AM, Petr Spacek <pspacek at redhat.com>
>>>> wrote:
>>>>
>>>>> On 8.12.2014 14:44, Matthew Herzog wrote:
>>>>> > Petr said, "You can run ipa-server-install *without* --setup-dns
>>>>> option and
>>>>> > at the end of
>>>>> > installation it will produce DNS records which you have to manually
>>>>> add to
>>>>> > your existing DNS database."
>>>>> >
>>>>> > I can't see how this would be useful or which machines I would need
>>>>> to add
>>>>> > to our DNS.
>>>>> >
>>>>> > Perhaps I should have explained that we are not going to set up a
>>>>> new DNS
>>>>> > domain for the ipa-managed servers.
>>>>> Good.
>>>>>
>>>>> Now you should run ipa-server-install *without* --setup-dns, using
>>>>> lnx.e-bozo.com as you IPA domain. It will install full IPA server and
>>>>> spit out
>>>>> DNS zone file.
>>>>>
>>>>> Then you *have to* take this zone file and import it to your existing
>>>>> DNS
>>>>> infrastructure - that will give you fully functional IPA domain
>>>>> lnx.e-bozo.com.
>>>>>
>>>>> Caveat:
>>>>> Preceding text assumes that 'dsee7' is nor using either Kerberos nor
>>>>> DNS SRV
>>>>> records for LDAP service in domain lnx.e-bozo.com, i.e. clients
>>>>> connecting to
>>>>> DSEE7 should be (most likely) statically configured with DSEE7 server
>>>>> name.
>>>>>
>>>>> Petr^2 Spacek
>>>>>
>>>>> > We have an Oracle dsee7 server doing
>>>>> > LDAP for our Linux servers and accounts. We want to migrate to IPA
>>>>> so we
>>>>> > don't have to maintain a Linux/LDAP account for every user who needs
>>>>> access
>>>>> > to Linux servers. All of our users start with an account in AD and
>>>>> since
>>>>> > none of my predecessors knew about Winbind, they set up dsee7.
>>>>> >
>>>>> > So I'm thinking we'll need to import all our dsee7 accounts AND make
>>>>> it
>>>>> > possible for AD users to access the Linux systems without needing to
>>>>> create
>>>>> > them in IPA.
>>>>> >
>>>>> > On Mon, Dec 8, 2014 at 2:56 AM, Petr Spacek <pspacek at redhat.com>
>>>>> wrote:
>>>>> >
>>>>> >> On 8.12.2014 05:02, Dmitri Pal wrote:
>>>>> >>> On 12/07/2014 10:10 PM, Matthew Herzog wrote:
>>>>> >>>> So should the FreeIPA server be authoritative for the Kerb.
>>>>> realm/DNS
>>>>> >> domain
>>>>> >>>> or can it/should it be a slave DNS server instead? Or caching
>>>>> only?
>>>>> >>>
>>>>> >>> IPA DNS can't be a slave so you either delegate a whole zone to it
>>>>> or
>>>>> >> manage
>>>>> >>> IPA DNS domain via your own DNS server.
>>>>> >>
>>>>> >> Generally, "slave" is not allowed to do any changes so it is
>>>>> useless in
>>>>> >> your
>>>>> >> scenario.
>>>>> >>
>>>>> >> You can run ipa-server-install *without* --setup-dns option and at
>>>>> the end
>>>>> >> of
>>>>> >> installation it will produce DNS records which you have to manually
>>>>> add to
>>>>> >> your existing DNS database.
>>>>> >>
>>>>> >> Did you try that?
>>>>> >>
>>>>> >> Petr^2 Spacek
>>>>> >>
>>>>> >>>> On Sun, Dec 7, 2014 at 9:57 PM, Dmitri Pal <dpal at redhat.com
>>>>> >>>> <mailto:dpal at redhat.com>> wrote:
>>>>> >>>>
>>>>> >>>>     On 12/07/2014 09:51 PM, Matthew Herzog wrote:
>>>>> >>>>>     What must be done in or on the ipa server with regard to
>>>>> DNS, if
>>>>> >>>>>     anything?
>>>>> >>>>>
>>>>> >>>>>     Our DNS works. It works well. We have four Linux DNS servers
>>>>> and
>>>>> >>>>>     two AD domain controllers that also do DNS.
>>>>> >>>>>
>>>>> >>>>>     So if we already have DNS working well in our domain, why do
>>>>> we
>>>>> >>>>>     want to manage DNS in IPA?
>>>>> >>>>
>>>>> >>>>     Let us keep the discussion on the list.
>>>>> >>>>     IPA when used with AD trust presents itself as a separate
>>>>> forest.
>>>>> >>>>     AD thinks that it is working with another AD forest.
>>>>> >>>>     For that to work we need to follow MSFT rules about
>>>>> relationship
>>>>> >>>>     between Kerberos realm and DNS domain.
>>>>> >>>>     AD assumes that for every trusted forest Kerberos realm = DNS
>>>>> >>>>     domain. IPA makes it easy to do because it has integrated
>>>>> tools to
>>>>> >>>>     manage IPA DNS domain.
>>>>> >>>>     If you want to manage it yourself through your DNS you can do
>>>>> it,
>>>>> >>>>     just more manual operations for you.
>>>>> >>>>
>>>>> >>>>     HTH
>>>>> >>>>
>>>>> >>>>     Thanks
>>>>> >>>>     Dmitri
>>>>> >>>>
>>>>> >>>>
>>>>> >>>>>
>>>>> >>>>>     On Sun, Dec 7, 2014 at 9:44 PM, Dmitri Pal <dpal at redhat.com
>>>>> >>>>>     <mailto:dpal at redhat.com>> wrote:
>>>>> >>>>>
>>>>> >>>>>         On 12/07/2014 06:44 PM, Matthew Herzog wrote:
>>>>> >>>>>>         Thanks guys. I'm sorry for my delay in responding.
>>>>> >>>>>>
>>>>> >>>>>>         Firstly, I was under the impression (from reading the
>>>>> docs)
>>>>> >>>>>>         that having named running on IPA server was critical.
>>>>> >>>>>
>>>>> >>>>>         Properly configured DNS is critical.
>>>>> >>>>>         How you accomplish it is up to you.
>>>>> >>>>>         IPA allows you to have a DNS server that would simplify
>>>>> DNS
>>>>> >>>>>         management but it can be done manually too. This is why
>>>>> DNS
>>>>> >>>>>         is optional.
>>>>> >>>>>
>>>>> >>>>>
>>>>> >>>>>>         Also, the first question the ipa-server-install script
>>>>> asks
>>>>> >>>>>>         is, "Do you want to configure integrated DNS (BIND)? ."
>>>>> >>>>>>         While it's true the default answer is no, it leads one
>>>>> to
>>>>> >>>>>>         believe that DNS is central to IPA. Also the
>>>>> >>>>>>         ipa-client-install script says,
>>>>> >>>>>>
>>>>> >>>>>>         [root at freeipa-poc-client02 ~]# ipa-client-install
>>>>> >>>>>>         DNS discovery failed to determine your DNS domain
>>>>> >>>>>>         Provide the domain name of your IPA server (ex:
>>>>> example.com
>>>>> >>>>>>         <http://example.com>):
>>>>> >>>>>>
>>>>> >>>>>>         I can resolve -anything- from the machine using dig or
>>>>> >> whatever.
>>>>> >>>>>>
>>>>> >>>>>>         Ultimately, the reason I started to be concerned about
>>>>> my
>>>>> >>>>>>         IPA server's DNS config was because I was not able to
>>>>> >>>>>>         authenticate AD accounts to a client machine. I saw a
>>>>> bunch
>>>>> >>>>>>         of errors in the client's sssd logs which of course I
>>>>> can't
>>>>> >>>>>>         find now.
>>>>> >>>>>>
>>>>> >>>>>>         Perhaps it was these . . .
>>>>> >>>>>>
>>>>> >>>>>>         (Thu Dec  4 13:45:23 2014) [sssd] [ping_check] (0x0100):
>>>>> >>>>>>         Service nss replied to ping
>>>>> >>>>>>         (Thu Dec  4 13:45:23 2014) [sssd] [ping_check] (0x0100):
>>>>> >>>>>>         Service sudo replied to ping
>>>>> >>>>>>         (Thu Dec  4 13:45:23 2014) [sssd] [ping_check] (0x0100):
>>>>> >>>>>>         Service pam replied to ping
>>>>> >>>>>>         (Thu Dec  4 13:45:23 2014) [sssd] [ping_check] (0x0100):
>>>>> >>>>>>         Service ssh replied to ping
>>>>> >>>>>>         (Thu Dec  4 13:45:23 2014) [sssd] [ping_check] (0x0100):
>>>>> >>>>>>         Service pac replied to ping
>>>>> >>>>>>         (Thu Dec  4 13:45:23 2014) [sssd] [ping_check] (0x0100):
>>>>> >>>>>>         Service bo3.e-bozo.com <http://bo3.e-bozo.com> replied
>>>>> to
>>>>> >> ping
>>>>> >>>>>>
>>>>> >>>>>>         I'm not allowed onto the AD domain controllers to
>>>>> examine
>>>>> >>>>>>         log files or I'd be checking those first.
>>>>> >>>>>>
>>>>> >>>>>>         So ultimately the goal is to authenticate AD users and
>>>>> users
>>>>> >>>>>>         that exist in our ldap schema. We need to set up groups
>>>>> of
>>>>> >>>>>>         users that can run sudo commands on specific groups of
>>>>> hosts.
>>>>> >>>>>
>>>>> >>>>>         Did you setup trusts as explained on the following page?
>>>>> >>>>>         http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup
>>>>> >>>>>
>>>>> >>>>>
>>>>> >>>>>>
>>>>> >>>>>>
>>>>> >>>>>>
>>>>> >>>>>>         On Wed, Dec 3, 2014 at 3:46 AM, Petr Spacek
>>>>> >>>>>>         <pspacek at redhat.com <mailto:pspacek at redhat.com>> wrote:
>>>>> >>>>>>
>>>>> >>>>>>             On 3.12.2014 04:35, Dmitri Pal wrote:
>>>>> >>>>>>             > On 12/02/2014 08:54 PM, Matthew Herzog wrote:
>>>>> >>>>>>             >> Any other ideas? I just spun up a new VM and
>>>>> took the
>>>>> >>>>>>             defaults on everything
>>>>> >>>>>>             >> while running ipa-server-install (the defaults
>>>>> did
>>>>> >>>>>>             make sense) and my new VM
>>>>> >>>>>>             >> can't resolve -anything- in the domain in which
>>>>> it
>>>>> >>>>>>             lives. The "old" VM
>>>>> >>>>>>             >> (running the same versions of everything on the
>>>>> same
>>>>> >>>>>>             OS) can't even resolve
>>>>> >>>>>>             >> the clients I have registered with it!
>>>>> >>>>>>             >>
>>>>> >>>>>>             >> So I'm pretty frustrated and am wondering, what
>>>>> >>>>>>             _exactly_ is the role of
>>>>> >>>>>>             >> bind in the IPA server and how is it expected to
>>>>> know
>>>>> >>>>>>             anything about the
>>>>> >>>>>>             >> local DNS domain without becoming a bind slave
>>>>> server?
>>>>> >>>>>>             >
>>>>> >>>>>>             > I am not sure I am 100% with you but...
>>>>> >>>>>>             > If you use the defaults and nothing else you get
>>>>> to
>>>>> >>>>>>             the scenario when IPA has
>>>>> >>>>>>             > its DNS but it is a self contained environment. It
>>>>> >>>>>>             seems that this is what you
>>>>> >>>>>>             > observe.
>>>>> >>>>>>             > It is expected that you decide in advance what you
>>>>> >>>>>>             want to do with DNS. There
>>>>> >>>>>>             > are several options:
>>>>> >>>>>>             > 1) You can delegate a zone to IPA to manage, then
>>>>> you
>>>>> >>>>>>             need to connect your IPA
>>>>> >>>>>>             > DNS to your existing DNS during install or after.
>>>>> >>>>>>             > In this case the systems joined to IPA will be a
>>>>> part
>>>>> >>>>>>             of IPA domain/zone and
>>>>> >>>>>>             > would also be able to resolve other systems around
>>>>> >>>>>>             > 2) Not use IPA DNS if you do not want to take
>>>>> >>>>>>             advantage of it
>>>>> >>>>>>             > 3) Have a self contained demo/lab environment
>>>>> that you
>>>>> >>>>>>             currently observe.
>>>>> >>>>>>             >
>>>>> >>>>>>             > What is the intent?
>>>>> >>>>>>
>>>>> >>>>>>             I agree with Dmitri, we need more information from
>>>>> you:
>>>>> >>>>>>             - You said "my new VM can't resolve -anything- in
>>>>> the
>>>>> >>>>>>             domain in which it
>>>>> >>>>>>             lives." - Which domain do you mean?
>>>>> >>>>>>
>>>>> >>>>>>             - Apparently you have configured FreeIPA to serve
>>>>> zone
>>>>> >>>>>>             e-bozo.com <http://e-bozo.com>. Do you have
>>>>> >>>>>>             this zone configured on some other DNS server at the
>>>>> >>>>>>             same time?
>>>>> >>>>>>
>>>>> >>>>>>             Please keep in mind that authoritative servers
>>>>> should
>>>>> >>>>>>             share the database. You
>>>>> >>>>>>             will get naming collisions if e-bozo.com
>>>>> >>>>>>             <http://e-bozo.com> is served by FreeIPA DNS
>>>>> servers and
>>>>> >>>>>>             some other servers at the same time. Maybe that is
>>>>> the
>>>>> >>>>>>             problem you see right now.
>>>>> >>>>>>
>>>>> >>>>>>             As Dmitri said, the architecturally correct
>>>>> solution is
>>>>> >>>>>>             to decide if you want
>>>>> >>>>>>             to use FreeIPA DNS or not. You have option to either
>>>>> >>>>>>             remove non-FreeIPA DNS
>>>>> >>>>>>             servers and import data to FreeIPA or to add
>>>>> >>>>>>             FreeIPA-specific DNS records to
>>>>> >>>>>>             existing DNS servers and do not configure FreeIPA
>>>>> to act
>>>>> >>>>>>             as DNS server.
>>>>> >>>>>>
>>>>> >>>>>>             Petr^2 Spacek
>>>>> >>>>>>
>>>>> >>>>>>             >> Thanks.
>>>>> >>>>>>             >>
>>>>> >>>>>>             >> On Tue, Dec 2, 2014 at 11:58 AM, Petr Spacek
>>>>> >>>>>>             <pspacek at redhat.com <mailto:pspacek at redhat.com>
>>>>> >>>>>>             >> <mailto:pspacek at redhat.com
>>>>> >>>>>>             <mailto:pspacek at redhat.com>>> wrote:
>>>>> >>>>>>             >>
>>>>> >>>>>>             >>     On 2.12.2014 17:36, Martin Basti wrote:
>>>>> >>>>>>             >>     > On 02/12/14 17:28, Matthew Herzog wrote:
>>>>> >>>>>>             >>     >> I just realized that my IPA servers cannot
>>>>> >>>>>>             resolve ANY servers
>>>>> >>>>>>             >>     in my domain.
>>>>> >>>>>>             >>     >> What do I need to do to fix this? Below
>>>>> is my
>>>>> >>>>>>             named.conf.
>>>>> >>>>>>             >>     >>
>>>>> >>>>>>             >>     >>
>>>>> >>>>>>             >>     >> options {
>>>>> >>>>>>             >>     >>  // turns on IPv6 for port 53, IPv4 is on
>>>>> by
>>>>> >>>>>>             default for
>>>>> >>>>>>             >>     all ifaces
>>>>> >>>>>>             >>     >>  listen-on-v6 {any;};
>>>>> >>>>>>             >>     >>
>>>>> >>>>>>             >>     >>  // Put files that named is allowed to
>>>>> write
>>>>> >>>>>>             in the
>>>>> >>>>>>             >>     data/ directory:
>>>>> >>>>>>             >>     >>  directory "/var/named"; // the default
>>>>> >>>>>>             >>     >>  dump-file "data/cache_dump.db";
>>>>> >>>>>>             >>     >>  statistics-file "data/named_stats.txt";
>>>>> >>>>>>             >>     >>  memstatistics-file
>>>>> "data/named_mem_stats.txt";
>>>>> >>>>>>             >>     >>
>>>>> >>>>>>             >>     >>  forward first;
>>>>> >>>>>>             >>     >>  forwarders {
>>>>> >>>>>>             >>     >>          10.100.8.41;
>>>>> >>>>>>             >>     >>          10.100.8.40;
>>>>> >>>>>>             >>     >>          10.100.4.13;
>>>>> >>>>>>             >>     >>          10.100.4.14;
>>>>> >>>>>>             >>     >>          10.100.4.19;
>>>>> >>>>>>             >>     >>          10.100.4.44;
>>>>> >>>>>>             >>     >>  };
>>>>> >>>>>>             >>     >>
>>>>> >>>>>>             >>     >>  // Any host is permitted to issue
>>>>> recursive
>>>>> >>>>>>             queries
>>>>> >>>>>>             >>     >>  allow-recursion { any; };
>>>>> >>>>>>             >>     >>
>>>>> >>>>>>             >>     >>  tkey-gssapi-keytab "/etc/named.keytab";
>>>>> >>>>>>             >>     >>  pid-file "/run/named/named.pid";
>>>>> >>>>>>             >>     >> };
>>>>> >>>>>>             >>     >>
>>>>> >>>>>>             >>     >> /* If you want to enable debugging, eg.
>>>>> using
>>>>> >>>>>>             the 'rndc trace'
>>>>> >>>>>>             >>     command,
>>>>> >>>>>>             >>     >>  * By default, SELinux policy does not
>>>>> allow
>>>>> >>>>>>             named to modify
>>>>> >>>>>>             >>     the /var/named
>>>>> >>>>>>             >>     >> directory,
>>>>> >>>>>>             >>     >>  * so put the default debug log file in
>>>>> data/ :
>>>>> >>>>>>             >>     >>  */
>>>>> >>>>>>             >>     >> logging {
>>>>> >>>>>>             >>     >>  channel default_debug {
>>>>> >>>>>>             >>     >>          file "data/named.run";
>>>>> >>>>>>             >>     >>          severity dynamic;
>>>>> >>>>>>             >>     >>          print-time yes;
>>>>> >>>>>>             >>     >>  };
>>>>> >>>>>>             >>     >>  };
>>>>> >>>>>>             >>     >> };
>>>>> >>>>>>             >>     >>
>>>>> >>>>>>             >>     >> zone "." IN {
>>>>> >>>>>>             >>     >>  type hint;
>>>>> >>>>>>             >>     >>  file "named.ca <http://named.ca>
>>>>> >>>>>>             <http://named.ca> <http://named.ca>";
>>>>> >>>>>>             >>     >> };
>>>>> >>>>>>             >>     >>
>>>>> >>>>>>             >>     >> include "/etc/named.rfc1912.zones";
>>>>> >>>>>>             >>     >>
>>>>> >>>>>>             >>     >> dynamic-db "ipa" {
>>>>> >>>>>>             >>     >>  library "ldap.so";
>>>>> >>>>>>             >>     >>  arg "uri
>>>>> >>>>>>             >>
>>>>> ldapi://%2fvar%2frun%2fslapd-BO3-E-BOZO-COM.socket";
>>>>> >>>>>>             >>     >>  arg "base cn=dns,
>>>>> dc=bo3,dc=e-bozo,dc=com";
>>>>> >>>>>>             >>     >>  arg "fake_mname
>>>>> freeipa-poc01.bo3.e-bozo.com
>>>>> >>>>>>             <http://freeipa-poc01.bo3.e-bozo.com>
>>>>> >>>>>>             >>     <http://freeipa-poc01.bo3.e-bozo.com>
>>>>> >>>>>>             >>     >> <http://freeipa-poc01.bo3.e-bozo.com>.";
>>>>> >>>>>>             >>     >>  arg "auth_method sasl";
>>>>> >>>>>>             >>     >>  arg "sasl_mech GSSAPI";
>>>>> >>>>>>             >>     >>  arg "sasl_user
>>>>> >>>>>>             DNS/freeipa-poc01.bo3.e-bozo.com
>>>>> >>>>>>             <http://freeipa-poc01.bo3.e-bozo.com>
>>>>> >>>>>>             >>     <http://freeipa-poc01.bo3.e-bozo.com>
>>>>> >>>>>>             >>     >> <http://freeipa-poc01.bo3.e-bozo.com>";
>>>>> >>>>>>             >>     >>  arg "serial_autoincrement yes";
>>>>> >>>>>>             >>     >> };
>>>>> >>>>>>             >>     >>
>>>>> >>>>>>             >>     >>
>>>>> >>>>>>             >>     >>
>>>>> >>>>>>             >>     >>
>>>>> >>>>>>             >>     > Hello,
>>>>> >>>>>>             >>     >
>>>>> >>>>>>             >>     > which version ipa do you use? which
>>>>> platform?
>>>>> >>>>>>             Which version
>>>>> >>>>>>             >>     bind-dyndb-ldap?
>>>>> >>>>>>             >>     >
>>>>> >>>>>>             >>     > Can you run these commands, and check if
>>>>> there
>>>>> >>>>>>             any errors?
>>>>> >>>>>>             >>     > ipactl status
>>>>> >>>>>>             >>     > systemctl status named  (respectively
>>>>> >>>>>>             journalctl -u named)
>>>>> >>>>>>             >>
>>>>> >>>>>>             >>     We also may want to see information listed
>>>>> on page
>>>>> >>>>>>             >>
>>>>> >>>>>>
>>>>> >> https://fedorahosted.org/bind-dyndb-ldap/wiki/BugReporting
>>>>>
>>>>> --
>>>>>  Petr^2 Spacek
>>>>>
>>>>
>>>>
>>>>
>>>>   --
>>>>  If life gives you melons, you may be dyslexic.
>>>>
>>>
>>>
>>>
>>>  --
>>>  If life gives you melons, you may be dyslexic.
>>>
>>>
>>>
>>>
>>> --
>>> Thank you,
>>> Dmitri Pal
>>>
>>> Sr. Engineering Manager IdM portfolio
>>> Red Hat, Inc.
>>>
>>>
>>> --
>>> 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
>>>
>>
>>
>>
>> --
>> If life gives you melons, you may be dyslexic.
>>
>
>
>
> --
> If life gives you melons, you may be dyslexic.
>



-- 
If life gives you melons, you may be dyslexic.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141208/50c2bc40/attachment.htm>

From matthew.herzog at gmail.com  Mon Dec  8 22:58:47 2014
From: matthew.herzog at gmail.com (Matthew Herzog)
Date: Mon, 8 Dec 2014 17:58:47 -0500
Subject: [Freeipa-users] DNS configuration
In-Reply-To: <CABhyZ367SZ9zK+s_49QR_DGXg3+PBqT0rr0jD-hGyJC+eGPMdQ@mail.gmail.com>
References: <CABhyZ34TCzUz+fNUSCvdZ38MS7rsLMMdb_jTdfKUsmYs86fn_Q@mail.gmail.com>
	<547DEA9E.2030203@redhat.com> <547DEFB5.1020205@redhat.com>
	<CABhyZ347EU+Q85jQJGU30yx4njC3OtL_QsJZi1MMu1ZR2Lfd2Q@mail.gmail.com>
	<547E851C.1020407@redhat.com> <547ECDDC.3090001@redhat.com>
	<CABhyZ37XChaQF+4rRY-L=OU9pVNp7Mw_NQifTk3NhrewzJtyVQ@mail.gmail.com>
	<5485108E.60409@redhat.com>
	<CABhyZ36DDM6icM+haMbVErdVdDWonGqbPE+3Tpad4K=u9QHjAQ@mail.gmail.com>
	<54851385.3050709@redhat.com>
	<CABhyZ36D_SVLezC=wZ3tsYHn00tdBGsxpOxCtpVgWZo8EdH2hw@mail.gmail.com>
	<548522B8.8040805@redhat.com> <5485599E.8030801@redhat.com>
	<CABhyZ34Pbr4J6YDdLSmP=qPqAB7Pa=tWvw273aB-BNX4dRq-GQ@mail.gmail.com>
	<5485C698.9000406@redhat.com>
	<CABhyZ35qsCM0y8anFdqE7r60Fz8LAU8Yx3WWaF6zBhfg=dRUJA@mail.gmail.com>
	<CABhyZ34exwjj4o8RRu651w2kik96wMS3Y6dvEk14MG1Y+LkY9w@mail.gmail.com>
	<5485FB6D.8000005@redhat.com>
	<CABhyZ34y-UKFpvRwuKsgPx=w+nQ3VTvwJWZ-M9v-XzUpoQ8v1w@mail.gmail.com>
	<CABhyZ37DH2w8o22Bi49F0y5zXb97NNaKYyO40iHWFyeMCYNkVA@mail.gmail.com>
	<CABhyZ367SZ9zK+s_49QR_DGXg3+PBqT0rr0jD-hGyJC+eGPMdQ@mail.gmail.com>
Message-ID: <CABhyZ36nxCA0OeeYt2pm8QbTKQE0XhaYtOHCz0uNnRqik6Kxbg@mail.gmail.com>

Also, I just realized the AD I'm trying to connect to is of type Windows
2000. Yay!

On Mon, Dec 8, 2014 at 5:54 PM, Matthew Herzog <matthew.herzog at gmail.com>
wrote:

> OK, I deserve a slap. I had forgotten to set up the two-way trust again
> since the ipa-server-install --uninstall && reinstall. That's back in place.
>
> So I found Sumit Bose's https://www.youtube.com/watch?v=infot4cmZgM and
> realized I could not add groups to any new, external user group using the
> ipa server's web interface.
>
> Error in the GUI is, E-BOZO.COM\Domain Users: invalid 'truster domain
> object': no trusted domain matched the specified flat name.
>
>
>
> On Mon, Dec 8, 2014 at 2:49 PM, Matthew Herzog <matthew.herzog at gmail.com>
> wrote:
>
>> sssd_<hostname>.log
>> (Mon Dec  8 14:46:54 2014) [sssd[be[bo3.e-bozo.com]]]
>> [sysdb_search_groups] (0x2000): No such entry
>> (Mon Dec  8 14:46:54 2014) [sssd[be[bo3.e-bozo.com]]]
>> [sysdb_delete_user] (0x0400): Error: 2 (No such file or directory)
>> (Mon Dec  8 14:46:54 2014) [sssd[be[bo3.e-bozo.com]]]
>> [acctinfo_callback] (0x0100): Request processed. Returned 0,0,Success
>> (Mon Dec  8 14:46:54 2014) [sssd[be[bo3.e-bozo.com]]]
>> [sdap_process_result] (0x2000): Trace: sh[0x17b0030], connected[1],
>> ops[(nil)], ldap[0x17ab240]
>> (Mon Dec  8 14:46:54 2014) [sssd[be[bo3.e-bozo.com]]]
>> [sdap_process_result] (0x2000): Trace: ldap_result found nothing!
>> (Mon Dec  8 14:46:57 2014) [sssd[be[bo3.e-bozo.com]]] [sbus_dispatch]
>> (0x4000): dbus conn: 0x178eb70
>> (Mon Dec  8 14:46:57 2014) [sssd[be[bo3.e-bozo.com]]] [sbus_dispatch]
>> (0x4000): Dispatching.
>>
>>
>> On Mon, Dec 8, 2014 at 2:32 PM, Matthew Herzog <matthew.herzog at gmail.com>
>> wrote:
>>
>>> ipa-client-3.0.0-42.el6.x86_64 on OEL 6.5 (server has 3.3.3 IPA)
>>>
>>>
>>> On Mon, Dec 8, 2014 at 2:26 PM, Dmitri Pal <dpal at redhat.com> wrote:
>>>
>>>>  On 12/08/2014 02:10 PM, Matthew Herzog wrote:
>>>>
>>>>  Here are some errors I'm seeing on the client.
>>>>
>>>>  tail -f sssd_lnx.e-bozo.com.log
>>>>  (Mon Dec  8 14:03:20 2014) [sssd[be[lnx.e-bozo.com]]] [sbus_dispatch]
>>>> (0x4000): dbus conn: 0x1e72ad0
>>>> (Mon Dec  8 14:03:20 2014) [sssd[be[lnx.e-bozo.com]]] [sbus_dispatch]
>>>> (0x4000): Dispatching.
>>>> (Mon Dec  8 14:03:20 2014) [sssd[be[lnx.e-bozo.com]]]
>>>> [sbus_message_handler] (0x4000): Received SBUS method [ping]
>>>> (Mon Dec  8 14:03:20 2014) [sssd[be[lnx.e-bozo.com]]]
>>>> [sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit
>>>> (Mon Dec  8 14:03:20 2014) [sssd[be[lnx.e-bozo.com]]]
>>>> [sbus_handler_got_caller_id] (0x4000): Received SBUS method [ping]
>>>> (Mon Dec  8 14:03:30 2014) [sssd[be[lnx.e-bozo.com]]] [sbus_dispatch]
>>>> (0x4000): dbus conn: 0x1e72ad0
>>>> (Mon Dec  8 14:03:30 2014) [sssd[be[lnx.e-bozo.com]]] [sbus_dispatch]
>>>> (0x4000): Dispatching.
>>>> (Mon Dec  8 14:03:30 2014) [sssd[be[lnx.e-bozo.com]]]
>>>> [sbus_message_handler] (0x4000): Received SBUS method [ping]
>>>> (Mon Dec  8 14:03:30 2014) [sssd[be[lnx.e-bozo.com]]]
>>>> [sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit
>>>> (Mon Dec  8 14:03:30 2014) [sssd[be[lnx.e-bozo.com]]]
>>>> [sbus_handler_got_caller_id] (0x4000): Received SBUS method [ping]
>>>> (Mon Dec  8 14:03:40 2014) [sssd[be[lnx.e-bozo.com]]] [sbus_dispatch]
>>>> (0x4000): dbus conn: 0x1e72ad0
>>>> (Mon Dec  8 14:03:40 2014) [sssd[be[lnx.e-bozo.com]]] [sbus_dispatch]
>>>> (0x4000): Dispatching.
>>>>
>>>>  [root at freeipa-poc-client02 sssd]# tail -f sssd_ssh.log
>>>> (Sun Dec  7 19:32:09 2014) [sssd[ssh]] [ssh_process_init] (0x0010):
>>>> sss_process_init() failed
>>>> (Sun Dec  7 19:32:09 2014) [sssd[ssh]] [sss_dp_init] (0x0010): Failed
>>>> to connect to monitor services.
>>>> (Sun Dec  7 19:32:09 2014) [sssd[ssh]] [sss_process_init] (0x0010):
>>>> fatal error setting up backend connector
>>>> (Sun Dec  7 19:32:09 2014) [sssd[ssh]] [ssh_process_init] (0x0010):
>>>> sss_process_init() failed
>>>> (Sun Dec  7 19:32:16 2014) [sssd[ssh]] [sss_dp_init] (0x0010): Failed
>>>> to connect to monitor services.
>>>> (Sun Dec  7 19:32:16 2014) [sssd[ssh]] [sss_process_init] (0x0010):
>>>> fatal error setting up backend connector
>>>> (Sun Dec  7 19:32:16 2014) [sssd[ssh]] [ssh_process_init] (0x0010):
>>>> sss_process_init() failed
>>>> (Sun Dec  7 19:32:16 2014) [sssd[ssh]] [sss_dp_init] (0x0010): Failed
>>>> to connect to monitor services.
>>>> (Sun Dec  7 19:32:16 2014) [sssd[ssh]] [sss_process_init] (0x0010):
>>>> fatal error setting up backend connector
>>>> (Sun Dec  7 19:32:16 2014) [sssd[ssh]] [ssh_process_init] (0x0010):
>>>> sss_process_init() failed
>>>>
>>>>
>>>> What is the version of the client?
>>>> Please add debug_level=9 to sssd.conf in different sections to rise the
>>>> verbosity of the log and see what is really going on there.
>>>> https://fedorahosted.org/sssd/wiki/FAQ#BasicsofTroubleshooting
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Mon, Dec 8, 2014 at 11:48 AM, Matthew Herzog <
>>>> matthew.herzog at gmail.com> wrote:
>>>>
>>>>> I have never seen my IPA servers produce a zone file nor has the
>>>>> install script ever mentioned the creation of such. In fact, I just ran
>>>>> ipa-server-install --uninstall && ipa-server-install and there was no
>>>>> mention of a zone file.
>>>>>
>>>>>  Where should I look in the file system to be sure? I see nothing in
>>>>> /var/named. I'm using 3.3.3 IPA on Oracle Linux from Oracle's yum repo.
>>>>> (Not my choice.)
>>>>>
>>>>>  dsee7 is *not *running Kerberos. dsee7 is *not *configured with SRV
>>>>> records. I guess I'll need to add SRV records for all my Linux hosts.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Dec 8, 2014 at 10:41 AM, Petr Spacek <pspacek at redhat.com>
>>>>> wrote:
>>>>>
>>>>>> On 8.12.2014 14:44, Matthew Herzog wrote:
>>>>>> > Petr said, "You can run ipa-server-install *without* --setup-dns
>>>>>> option and
>>>>>> > at the end of
>>>>>> > installation it will produce DNS records which you have to manually
>>>>>> add to
>>>>>> > your existing DNS database."
>>>>>> >
>>>>>> > I can't see how this would be useful or which machines I would need
>>>>>> to add
>>>>>> > to our DNS.
>>>>>> >
>>>>>> > Perhaps I should have explained that we are not going to set up a
>>>>>> new DNS
>>>>>> > domain for the ipa-managed servers.
>>>>>> Good.
>>>>>>
>>>>>> Now you should run ipa-server-install *without* --setup-dns, using
>>>>>> lnx.e-bozo.com as you IPA domain. It will install full IPA server
>>>>>> and spit out
>>>>>> DNS zone file.
>>>>>>
>>>>>> Then you *have to* take this zone file and import it to your existing
>>>>>> DNS
>>>>>> infrastructure - that will give you fully functional IPA domain
>>>>>> lnx.e-bozo.com.
>>>>>>
>>>>>> Caveat:
>>>>>> Preceding text assumes that 'dsee7' is nor using either Kerberos nor
>>>>>> DNS SRV
>>>>>> records for LDAP service in domain lnx.e-bozo.com, i.e. clients
>>>>>> connecting to
>>>>>> DSEE7 should be (most likely) statically configured with DSEE7 server
>>>>>> name.
>>>>>>
>>>>>> Petr^2 Spacek
>>>>>>
>>>>>> > We have an Oracle dsee7 server doing
>>>>>> > LDAP for our Linux servers and accounts. We want to migrate to IPA
>>>>>> so we
>>>>>> > don't have to maintain a Linux/LDAP account for every user who
>>>>>> needs access
>>>>>> > to Linux servers. All of our users start with an account in AD and
>>>>>> since
>>>>>> > none of my predecessors knew about Winbind, they set up dsee7.
>>>>>> >
>>>>>> > So I'm thinking we'll need to import all our dsee7 accounts AND
>>>>>> make it
>>>>>> > possible for AD users to access the Linux systems without needing
>>>>>> to create
>>>>>> > them in IPA.
>>>>>> >
>>>>>> > On Mon, Dec 8, 2014 at 2:56 AM, Petr Spacek <pspacek at redhat.com>
>>>>>> wrote:
>>>>>> >
>>>>>> >> On 8.12.2014 05:02, Dmitri Pal wrote:
>>>>>> >>> On 12/07/2014 10:10 PM, Matthew Herzog wrote:
>>>>>> >>>> So should the FreeIPA server be authoritative for the Kerb.
>>>>>> realm/DNS
>>>>>> >> domain
>>>>>> >>>> or can it/should it be a slave DNS server instead? Or caching
>>>>>> only?
>>>>>> >>>
>>>>>> >>> IPA DNS can't be a slave so you either delegate a whole zone to
>>>>>> it or
>>>>>> >> manage
>>>>>> >>> IPA DNS domain via your own DNS server.
>>>>>> >>
>>>>>> >> Generally, "slave" is not allowed to do any changes so it is
>>>>>> useless in
>>>>>> >> your
>>>>>> >> scenario.
>>>>>> >>
>>>>>> >> You can run ipa-server-install *without* --setup-dns option and at
>>>>>> the end
>>>>>> >> of
>>>>>> >> installation it will produce DNS records which you have to
>>>>>> manually add to
>>>>>> >> your existing DNS database.
>>>>>> >>
>>>>>> >> Did you try that?
>>>>>> >>
>>>>>> >> Petr^2 Spacek
>>>>>> >>
>>>>>> >>>> On Sun, Dec 7, 2014 at 9:57 PM, Dmitri Pal <dpal at redhat.com
>>>>>> >>>> <mailto:dpal at redhat.com>> wrote:
>>>>>> >>>>
>>>>>> >>>>     On 12/07/2014 09:51 PM, Matthew Herzog wrote:
>>>>>> >>>>>     What must be done in or on the ipa server with regard to
>>>>>> DNS, if
>>>>>> >>>>>     anything?
>>>>>> >>>>>
>>>>>> >>>>>     Our DNS works. It works well. We have four Linux DNS
>>>>>> servers and
>>>>>> >>>>>     two AD domain controllers that also do DNS.
>>>>>> >>>>>
>>>>>> >>>>>     So if we already have DNS working well in our domain, why
>>>>>> do we
>>>>>> >>>>>     want to manage DNS in IPA?
>>>>>> >>>>
>>>>>> >>>>     Let us keep the discussion on the list.
>>>>>> >>>>     IPA when used with AD trust presents itself as a separate
>>>>>> forest.
>>>>>> >>>>     AD thinks that it is working with another AD forest.
>>>>>> >>>>     For that to work we need to follow MSFT rules about
>>>>>> relationship
>>>>>> >>>>     between Kerberos realm and DNS domain.
>>>>>> >>>>     AD assumes that for every trusted forest Kerberos realm = DNS
>>>>>> >>>>     domain. IPA makes it easy to do because it has integrated
>>>>>> tools to
>>>>>> >>>>     manage IPA DNS domain.
>>>>>> >>>>     If you want to manage it yourself through your DNS you can
>>>>>> do it,
>>>>>> >>>>     just more manual operations for you.
>>>>>> >>>>
>>>>>> >>>>     HTH
>>>>>> >>>>
>>>>>> >>>>     Thanks
>>>>>> >>>>     Dmitri
>>>>>> >>>>
>>>>>> >>>>
>>>>>> >>>>>
>>>>>> >>>>>     On Sun, Dec 7, 2014 at 9:44 PM, Dmitri Pal <dpal at redhat.com
>>>>>> >>>>>     <mailto:dpal at redhat.com>> wrote:
>>>>>> >>>>>
>>>>>> >>>>>         On 12/07/2014 06:44 PM, Matthew Herzog wrote:
>>>>>> >>>>>>         Thanks guys. I'm sorry for my delay in responding.
>>>>>> >>>>>>
>>>>>> >>>>>>         Firstly, I was under the impression (from reading the
>>>>>> docs)
>>>>>> >>>>>>         that having named running on IPA server was critical.
>>>>>> >>>>>
>>>>>> >>>>>         Properly configured DNS is critical.
>>>>>> >>>>>         How you accomplish it is up to you.
>>>>>> >>>>>         IPA allows you to have a DNS server that would simplify
>>>>>> DNS
>>>>>> >>>>>         management but it can be done manually too. This is why
>>>>>> DNS
>>>>>> >>>>>         is optional.
>>>>>> >>>>>
>>>>>> >>>>>
>>>>>> >>>>>>         Also, the first question the ipa-server-install script
>>>>>> asks
>>>>>> >>>>>>         is, "Do you want to configure integrated DNS (BIND)? ."
>>>>>> >>>>>>         While it's true the default answer is no, it leads one
>>>>>> to
>>>>>> >>>>>>         believe that DNS is central to IPA. Also the
>>>>>> >>>>>>         ipa-client-install script says,
>>>>>> >>>>>>
>>>>>> >>>>>>         [root at freeipa-poc-client02 ~]# ipa-client-install
>>>>>> >>>>>>         DNS discovery failed to determine your DNS domain
>>>>>> >>>>>>         Provide the domain name of your IPA server (ex:
>>>>>> example.com
>>>>>> >>>>>>         <http://example.com>):
>>>>>> >>>>>>
>>>>>> >>>>>>         I can resolve -anything- from the machine using dig or
>>>>>> >> whatever.
>>>>>> >>>>>>
>>>>>> >>>>>>         Ultimately, the reason I started to be concerned about
>>>>>> my
>>>>>> >>>>>>         IPA server's DNS config was because I was not able to
>>>>>> >>>>>>         authenticate AD accounts to a client machine. I saw a
>>>>>> bunch
>>>>>> >>>>>>         of errors in the client's sssd logs which of course I
>>>>>> can't
>>>>>> >>>>>>         find now.
>>>>>> >>>>>>
>>>>>> >>>>>>         Perhaps it was these . . .
>>>>>> >>>>>>
>>>>>> >>>>>>         (Thu Dec  4 13:45:23 2014) [sssd] [ping_check]
>>>>>> (0x0100):
>>>>>> >>>>>>         Service nss replied to ping
>>>>>> >>>>>>         (Thu Dec  4 13:45:23 2014) [sssd] [ping_check]
>>>>>> (0x0100):
>>>>>> >>>>>>         Service sudo replied to ping
>>>>>> >>>>>>         (Thu Dec  4 13:45:23 2014) [sssd] [ping_check]
>>>>>> (0x0100):
>>>>>> >>>>>>         Service pam replied to ping
>>>>>> >>>>>>         (Thu Dec  4 13:45:23 2014) [sssd] [ping_check]
>>>>>> (0x0100):
>>>>>> >>>>>>         Service ssh replied to ping
>>>>>> >>>>>>         (Thu Dec  4 13:45:23 2014) [sssd] [ping_check]
>>>>>> (0x0100):
>>>>>> >>>>>>         Service pac replied to ping
>>>>>> >>>>>>         (Thu Dec  4 13:45:23 2014) [sssd] [ping_check]
>>>>>> (0x0100):
>>>>>> >>>>>>         Service bo3.e-bozo.com <http://bo3.e-bozo.com>
>>>>>> replied to
>>>>>> >> ping
>>>>>> >>>>>>
>>>>>> >>>>>>         I'm not allowed onto the AD domain controllers to
>>>>>> examine
>>>>>> >>>>>>         log files or I'd be checking those first.
>>>>>> >>>>>>
>>>>>> >>>>>>         So ultimately the goal is to authenticate AD users and
>>>>>> users
>>>>>> >>>>>>         that exist in our ldap schema. We need to set up
>>>>>> groups of
>>>>>> >>>>>>         users that can run sudo commands on specific groups of
>>>>>> hosts.
>>>>>> >>>>>
>>>>>> >>>>>         Did you setup trusts as explained on the following page?
>>>>>> >>>>>         http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup
>>>>>> >>>>>
>>>>>> >>>>>
>>>>>> >>>>>>
>>>>>> >>>>>>
>>>>>> >>>>>>
>>>>>> >>>>>>         On Wed, Dec 3, 2014 at 3:46 AM, Petr Spacek
>>>>>> >>>>>>         <pspacek at redhat.com <mailto:pspacek at redhat.com>>
>>>>>> wrote:
>>>>>> >>>>>>
>>>>>> >>>>>>             On 3.12.2014 04:35, Dmitri Pal wrote:
>>>>>> >>>>>>             > On 12/02/2014 08:54 PM, Matthew Herzog wrote:
>>>>>> >>>>>>             >> Any other ideas? I just spun up a new VM and
>>>>>> took the
>>>>>> >>>>>>             defaults on everything
>>>>>> >>>>>>             >> while running ipa-server-install (the defaults
>>>>>> did
>>>>>> >>>>>>             make sense) and my new VM
>>>>>> >>>>>>             >> can't resolve -anything- in the domain in which
>>>>>> it
>>>>>> >>>>>>             lives. The "old" VM
>>>>>> >>>>>>             >> (running the same versions of everything on the
>>>>>> same
>>>>>> >>>>>>             OS) can't even resolve
>>>>>> >>>>>>             >> the clients I have registered with it!
>>>>>> >>>>>>             >>
>>>>>> >>>>>>             >> So I'm pretty frustrated and am wondering, what
>>>>>> >>>>>>             _exactly_ is the role of
>>>>>> >>>>>>             >> bind in the IPA server and how is it expected
>>>>>> to know
>>>>>> >>>>>>             anything about the
>>>>>> >>>>>>             >> local DNS domain without becoming a bind slave
>>>>>> server?
>>>>>> >>>>>>             >
>>>>>> >>>>>>             > I am not sure I am 100% with you but...
>>>>>> >>>>>>             > If you use the defaults and nothing else you get
>>>>>> to
>>>>>> >>>>>>             the scenario when IPA has
>>>>>> >>>>>>             > its DNS but it is a self contained environment.
>>>>>> It
>>>>>> >>>>>>             seems that this is what you
>>>>>> >>>>>>             > observe.
>>>>>> >>>>>>             > It is expected that you decide in advance what
>>>>>> you
>>>>>> >>>>>>             want to do with DNS. There
>>>>>> >>>>>>             > are several options:
>>>>>> >>>>>>             > 1) You can delegate a zone to IPA to manage,
>>>>>> then you
>>>>>> >>>>>>             need to connect your IPA
>>>>>> >>>>>>             > DNS to your existing DNS during install or after.
>>>>>> >>>>>>             > In this case the systems joined to IPA will be a
>>>>>> part
>>>>>> >>>>>>             of IPA domain/zone and
>>>>>> >>>>>>             > would also be able to resolve other systems
>>>>>> around
>>>>>> >>>>>>             > 2) Not use IPA DNS if you do not want to take
>>>>>> >>>>>>             advantage of it
>>>>>> >>>>>>             > 3) Have a self contained demo/lab environment
>>>>>> that you
>>>>>> >>>>>>             currently observe.
>>>>>> >>>>>>             >
>>>>>> >>>>>>             > What is the intent?
>>>>>> >>>>>>
>>>>>> >>>>>>             I agree with Dmitri, we need more information from
>>>>>> you:
>>>>>> >>>>>>             - You said "my new VM can't resolve -anything- in
>>>>>> the
>>>>>> >>>>>>             domain in which it
>>>>>> >>>>>>             lives." - Which domain do you mean?
>>>>>> >>>>>>
>>>>>> >>>>>>             - Apparently you have configured FreeIPA to serve
>>>>>> zone
>>>>>> >>>>>>             e-bozo.com <http://e-bozo.com>. Do you have
>>>>>> >>>>>>             this zone configured on some other DNS server at
>>>>>> the
>>>>>> >>>>>>             same time?
>>>>>> >>>>>>
>>>>>> >>>>>>             Please keep in mind that authoritative servers
>>>>>> should
>>>>>> >>>>>>             share the database. You
>>>>>> >>>>>>             will get naming collisions if e-bozo.com
>>>>>> >>>>>>             <http://e-bozo.com> is served by FreeIPA DNS
>>>>>> servers and
>>>>>> >>>>>>             some other servers at the same time. Maybe that is
>>>>>> the
>>>>>> >>>>>>             problem you see right now.
>>>>>> >>>>>>
>>>>>> >>>>>>             As Dmitri said, the architecturally correct
>>>>>> solution is
>>>>>> >>>>>>             to decide if you want
>>>>>> >>>>>>             to use FreeIPA DNS or not. You have option to
>>>>>> either
>>>>>> >>>>>>             remove non-FreeIPA DNS
>>>>>> >>>>>>             servers and import data to FreeIPA or to add
>>>>>> >>>>>>             FreeIPA-specific DNS records to
>>>>>> >>>>>>             existing DNS servers and do not configure FreeIPA
>>>>>> to act
>>>>>> >>>>>>             as DNS server.
>>>>>> >>>>>>
>>>>>> >>>>>>             Petr^2 Spacek
>>>>>> >>>>>>
>>>>>> >>>>>>             >> Thanks.
>>>>>> >>>>>>             >>
>>>>>> >>>>>>             >> On Tue, Dec 2, 2014 at 11:58 AM, Petr Spacek
>>>>>> >>>>>>             <pspacek at redhat.com <mailto:pspacek at redhat.com>
>>>>>> >>>>>>             >> <mailto:pspacek at redhat.com
>>>>>> >>>>>>             <mailto:pspacek at redhat.com>>> wrote:
>>>>>> >>>>>>             >>
>>>>>> >>>>>>             >>     On 2.12.2014 17:36, Martin Basti wrote:
>>>>>> >>>>>>             >>     > On 02/12/14 17:28, Matthew Herzog wrote:
>>>>>> >>>>>>             >>     >> I just realized that my IPA servers
>>>>>> cannot
>>>>>> >>>>>>             resolve ANY servers
>>>>>> >>>>>>             >>     in my domain.
>>>>>> >>>>>>             >>     >> What do I need to do to fix this? Below
>>>>>> is my
>>>>>> >>>>>>             named.conf.
>>>>>> >>>>>>             >>     >>
>>>>>> >>>>>>             >>     >>
>>>>>> >>>>>>             >>     >> options {
>>>>>> >>>>>>             >>     >>  // turns on IPv6 for port 53, IPv4 is
>>>>>> on by
>>>>>> >>>>>>             default for
>>>>>> >>>>>>             >>     all ifaces
>>>>>> >>>>>>             >>     >>  listen-on-v6 {any;};
>>>>>> >>>>>>             >>     >>
>>>>>> >>>>>>             >>     >>  // Put files that named is allowed to
>>>>>> write
>>>>>> >>>>>>             in the
>>>>>> >>>>>>             >>     data/ directory:
>>>>>> >>>>>>             >>     >>  directory "/var/named"; // the default
>>>>>> >>>>>>             >>     >>  dump-file "data/cache_dump.db";
>>>>>> >>>>>>             >>     >>  statistics-file "data/named_stats.txt";
>>>>>> >>>>>>             >>     >>  memstatistics-file
>>>>>> "data/named_mem_stats.txt";
>>>>>> >>>>>>             >>     >>
>>>>>> >>>>>>             >>     >>  forward first;
>>>>>> >>>>>>             >>     >>  forwarders {
>>>>>> >>>>>>             >>     >>          10.100.8.41;
>>>>>> >>>>>>             >>     >>          10.100.8.40;
>>>>>> >>>>>>             >>     >>          10.100.4.13;
>>>>>> >>>>>>             >>     >>          10.100.4.14;
>>>>>> >>>>>>             >>     >>          10.100.4.19;
>>>>>> >>>>>>             >>     >>          10.100.4.44;
>>>>>> >>>>>>             >>     >>  };
>>>>>> >>>>>>             >>     >>
>>>>>> >>>>>>             >>     >>  // Any host is permitted to issue
>>>>>> recursive
>>>>>> >>>>>>             queries
>>>>>> >>>>>>             >>     >>  allow-recursion { any; };
>>>>>> >>>>>>             >>     >>
>>>>>> >>>>>>             >>     >>  tkey-gssapi-keytab "/etc/named.keytab";
>>>>>> >>>>>>             >>     >>  pid-file "/run/named/named.pid";
>>>>>> >>>>>>             >>     >> };
>>>>>> >>>>>>             >>     >>
>>>>>> >>>>>>             >>     >> /* If you want to enable debugging, eg.
>>>>>> using
>>>>>> >>>>>>             the 'rndc trace'
>>>>>> >>>>>>             >>     command,
>>>>>> >>>>>>             >>     >>  * By default, SELinux policy does not
>>>>>> allow
>>>>>> >>>>>>             named to modify
>>>>>> >>>>>>             >>     the /var/named
>>>>>> >>>>>>             >>     >> directory,
>>>>>> >>>>>>             >>     >>  * so put the default debug log file in
>>>>>> data/ :
>>>>>> >>>>>>             >>     >>  */
>>>>>> >>>>>>             >>     >> logging {
>>>>>> >>>>>>             >>     >>  channel default_debug {
>>>>>> >>>>>>             >>     >>          file "data/named.run";
>>>>>> >>>>>>             >>     >>          severity dynamic;
>>>>>> >>>>>>             >>     >>          print-time yes;
>>>>>> >>>>>>             >>     >>  };
>>>>>> >>>>>>             >>     >>  };
>>>>>> >>>>>>             >>     >> };
>>>>>> >>>>>>             >>     >>
>>>>>> >>>>>>             >>     >> zone "." IN {
>>>>>> >>>>>>             >>     >>  type hint;
>>>>>> >>>>>>             >>     >>  file "named.ca <http://named.ca>
>>>>>> >>>>>>             <http://named.ca> <http://named.ca>";
>>>>>> >>>>>>             >>     >> };
>>>>>> >>>>>>             >>     >>
>>>>>> >>>>>>             >>     >> include "/etc/named.rfc1912.zones";
>>>>>> >>>>>>             >>     >>
>>>>>> >>>>>>             >>     >> dynamic-db "ipa" {
>>>>>> >>>>>>             >>     >>  library "ldap.so";
>>>>>> >>>>>>             >>     >>  arg "uri
>>>>>> >>>>>>             >>
>>>>>> ldapi://%2fvar%2frun%2fslapd-BO3-E-BOZO-COM.socket";
>>>>>> >>>>>>             >>     >>  arg "base cn=dns,
>>>>>> dc=bo3,dc=e-bozo,dc=com";
>>>>>> >>>>>>             >>     >>  arg "fake_mname
>>>>>> freeipa-poc01.bo3.e-bozo.com
>>>>>> >>>>>>             <http://freeipa-poc01.bo3.e-bozo.com>
>>>>>> >>>>>>             >>     <http://freeipa-poc01.bo3.e-bozo.com>
>>>>>> >>>>>>             >>     >> <http://freeipa-poc01.bo3.e-bozo.com>.";
>>>>>> >>>>>>             >>     >>  arg "auth_method sasl";
>>>>>> >>>>>>             >>     >>  arg "sasl_mech GSSAPI";
>>>>>> >>>>>>             >>     >>  arg "sasl_user
>>>>>> >>>>>>             DNS/freeipa-poc01.bo3.e-bozo.com
>>>>>> >>>>>>             <http://freeipa-poc01.bo3.e-bozo.com>
>>>>>> >>>>>>             >>     <http://freeipa-poc01.bo3.e-bozo.com>
>>>>>> >>>>>>             >>     >> <http://freeipa-poc01.bo3.e-bozo.com>";
>>>>>> >>>>>>             >>     >>  arg "serial_autoincrement yes";
>>>>>> >>>>>>             >>     >> };
>>>>>> >>>>>>             >>     >>
>>>>>> >>>>>>             >>     >>
>>>>>> >>>>>>             >>     >>
>>>>>> >>>>>>             >>     >>
>>>>>> >>>>>>             >>     > Hello,
>>>>>> >>>>>>             >>     >
>>>>>> >>>>>>             >>     > which version ipa do you use? which
>>>>>> platform?
>>>>>> >>>>>>             Which version
>>>>>> >>>>>>             >>     bind-dyndb-ldap?
>>>>>> >>>>>>             >>     >
>>>>>> >>>>>>             >>     > Can you run these commands, and check if
>>>>>> there
>>>>>> >>>>>>             any errors?
>>>>>> >>>>>>             >>     > ipactl status
>>>>>> >>>>>>             >>     > systemctl status named  (respectively
>>>>>> >>>>>>             journalctl -u named)
>>>>>> >>>>>>             >>
>>>>>> >>>>>>             >>     We also may want to see information listed
>>>>>> on page
>>>>>> >>>>>>             >>
>>>>>> >>>>>>
>>>>>> >> https://fedorahosted.org/bind-dyndb-ldap/wiki/BugReporting
>>>>>>
>>>>>> --
>>>>>>  Petr^2 Spacek
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>   --
>>>>>  If life gives you melons, you may be dyslexic.
>>>>>
>>>>
>>>>
>>>>
>>>>  --
>>>>  If life gives you melons, you may be dyslexic.
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Thank you,
>>>> Dmitri Pal
>>>>
>>>> Sr. Engineering Manager IdM portfolio
>>>> Red Hat, Inc.
>>>>
>>>>
>>>> --
>>>> 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
>>>>
>>>
>>>
>>>
>>> --
>>> If life gives you melons, you may be dyslexic.
>>>
>>
>>
>>
>> --
>> If life gives you melons, you may be dyslexic.
>>
>
>
>
> --
> If life gives you melons, you may be dyslexic.
>



-- 
If life gives you melons, you may be dyslexic.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141208/262997c4/attachment.htm>

From dpal at redhat.com  Mon Dec  8 23:17:54 2014
From: dpal at redhat.com (Dmitri Pal)
Date: Mon, 08 Dec 2014 18:17:54 -0500
Subject: [Freeipa-users] DNS configuration
In-Reply-To: <CABhyZ36nxCA0OeeYt2pm8QbTKQE0XhaYtOHCz0uNnRqik6Kxbg@mail.gmail.com>
References: <CABhyZ34TCzUz+fNUSCvdZ38MS7rsLMMdb_jTdfKUsmYs86fn_Q@mail.gmail.com>	<547ECDDC.3090001@redhat.com>	<CABhyZ37XChaQF+4rRY-L=OU9pVNp7Mw_NQifTk3NhrewzJtyVQ@mail.gmail.com>	<5485108E.60409@redhat.com>	<CABhyZ36DDM6icM+haMbVErdVdDWonGqbPE+3Tpad4K=u9QHjAQ@mail.gmail.com>	<54851385.3050709@redhat.com>	<CABhyZ36D_SVLezC=wZ3tsYHn00tdBGsxpOxCtpVgWZo8EdH2hw@mail.gmail.com>	<548522B8.8040805@redhat.com>
	<5485599E.8030801@redhat.com>	<CABhyZ34Pbr4J6YDdLSmP=qPqAB7Pa=tWvw273aB-BNX4dRq-GQ@mail.gmail.com>	<5485C698.9000406@redhat.com>	<CABhyZ35qsCM0y8anFdqE7r60Fz8LAU8Yx3WWaF6zBhfg=dRUJA@mail.gmail.com>	<CABhyZ34exwjj4o8RRu651w2kik96wMS3Y6dvEk14MG1Y+LkY9w@mail.gmail.com>	<5485FB6D.8000005@redhat.com>	<CABhyZ34y-UKFpvRwuKsgPx=w+nQ3VTvwJWZ-M9v-XzUpoQ8v1w@mail.gmail.com>	<CABhyZ37DH2w8o22Bi49F0y5zXb97NNaKYyO40iHWFyeMCYNkVA@mail.gmail.com>	<CABhyZ367SZ9zK+s_49QR_DGXg3+PBqT0rr0jD-hGyJC+eGPMdQ@mail.gmail.com>
	<CABhyZ36nxCA0OeeYt2pm8QbTKQE0XhaYtOHCz0uNnRqik6Kxbg@mail.gmail.com>
Message-ID: <548631A2.90407@redhat.com>

On 12/08/2014 05:58 PM, Matthew Herzog wrote:
> Also, I just realized the AD I'm trying to connect to is of type 
> Windows 2000. Yay!

This one would not work...

>
> On Mon, Dec 8, 2014 at 5:54 PM, Matthew Herzog 
> <matthew.herzog at gmail.com <mailto:matthew.herzog at gmail.com>> wrote:
>
>     OK, I deserve a slap. I had forgotten to set up the two-way trust
>     again since the ipa-server-install --uninstall && reinstall.
>     That's back in place.
>
>     So I found Sumit Bose's
>     https://www.youtube.com/watch?v=infot4cmZgM and realized I could
>     not add groups to any new, external user group using the ipa
>     server's web interface.
>
>     Error in the GUI is, E-BOZO.COM <http://E-BOZO.COM>\Domain Users:
>     invalid 'truster domain object': no trusted domain matched the
>     specified flat name.
>
>
>
>     On Mon, Dec 8, 2014 at 2:49 PM, Matthew Herzog
>     <matthew.herzog at gmail.com <mailto:matthew.herzog at gmail.com>> wrote:
>
>         sssd_<hostname>.log
>         (Mon Dec  8 14:46:54 2014) [sssd[be[bo3.e-bozo.com
>         <http://bo3.e-bozo.com>]]] [sysdb_search_groups] (0x2000): No
>         such entry
>         (Mon Dec  8 14:46:54 2014) [sssd[be[bo3.e-bozo.com
>         <http://bo3.e-bozo.com>]]] [sysdb_delete_user] (0x0400):
>         Error: 2 (No such file or directory)
>         (Mon Dec  8 14:46:54 2014) [sssd[be[bo3.e-bozo.com
>         <http://bo3.e-bozo.com>]]] [acctinfo_callback] (0x0100):
>         Request processed. Returned 0,0,Success
>         (Mon Dec  8 14:46:54 2014) [sssd[be[bo3.e-bozo.com
>         <http://bo3.e-bozo.com>]]] [sdap_process_result] (0x2000):
>         Trace: sh[0x17b0030], connected[1], ops[(nil)], ldap[0x17ab240]
>         (Mon Dec  8 14:46:54 2014) [sssd[be[bo3.e-bozo.com
>         <http://bo3.e-bozo.com>]]] [sdap_process_result] (0x2000):
>         Trace: ldap_result found nothing!
>         (Mon Dec  8 14:46:57 2014) [sssd[be[bo3.e-bozo.com
>         <http://bo3.e-bozo.com>]]] [sbus_dispatch] (0x4000): dbus
>         conn: 0x178eb70
>         (Mon Dec  8 14:46:57 2014) [sssd[be[bo3.e-bozo.com
>         <http://bo3.e-bozo.com>]]] [sbus_dispatch] (0x4000): Dispatching.
>
>
>         On Mon, Dec 8, 2014 at 2:32 PM, Matthew Herzog
>         <matthew.herzog at gmail.com <mailto:matthew.herzog at gmail.com>>
>         wrote:
>
>             ipa-client-3.0.0-42.el6.x86_64 on OEL 6.5 (server has
>             3.3.3 IPA)
>
>
>             On Mon, Dec 8, 2014 at 2:26 PM, Dmitri Pal
>             <dpal at redhat.com <mailto:dpal at redhat.com>> wrote:
>
>                 On 12/08/2014 02:10 PM, Matthew Herzog wrote:
>>                 Here are some errors I'm seeing on the client.
>>
>>                 tail -f sssd_lnx.e-bozo.com.log
>>                 (Mon Dec  8 14:03:20 2014) [sssd[be[lnx.e-bozo.com
>>                 <http://lnx.e-bozo.com>]]] [sbus_dispatch] (0x4000):
>>                 dbus conn: 0x1e72ad0
>>                 (Mon Dec  8 14:03:20 2014) [sssd[be[lnx.e-bozo.com
>>                 <http://lnx.e-bozo.com>]]] [sbus_dispatch] (0x4000):
>>                 Dispatching.
>>                 (Mon Dec  8 14:03:20 2014) [sssd[be[lnx.e-bozo.com
>>                 <http://lnx.e-bozo.com>]]] [sbus_message_handler]
>>                 (0x4000): Received SBUS method [ping]
>>                 (Mon Dec  8 14:03:20 2014) [sssd[be[lnx.e-bozo.com
>>                 <http://lnx.e-bozo.com>]]] [sbus_get_sender_id_send]
>>                 (0x2000): Not a sysbus message, quit
>>                 (Mon Dec  8 14:03:20 2014) [sssd[be[lnx.e-bozo.com
>>                 <http://lnx.e-bozo.com>]]]
>>                 [sbus_handler_got_caller_id] (0x4000): Received SBUS
>>                 method [ping]
>>                 (Mon Dec  8 14:03:30 2014) [sssd[be[lnx.e-bozo.com
>>                 <http://lnx.e-bozo.com>]]] [sbus_dispatch] (0x4000):
>>                 dbus conn: 0x1e72ad0
>>                 (Mon Dec  8 14:03:30 2014) [sssd[be[lnx.e-bozo.com
>>                 <http://lnx.e-bozo.com>]]] [sbus_dispatch] (0x4000):
>>                 Dispatching.
>>                 (Mon Dec  8 14:03:30 2014) [sssd[be[lnx.e-bozo.com
>>                 <http://lnx.e-bozo.com>]]] [sbus_message_handler]
>>                 (0x4000): Received SBUS method [ping]
>>                 (Mon Dec  8 14:03:30 2014) [sssd[be[lnx.e-bozo.com
>>                 <http://lnx.e-bozo.com>]]] [sbus_get_sender_id_send]
>>                 (0x2000): Not a sysbus message, quit
>>                 (Mon Dec  8 14:03:30 2014) [sssd[be[lnx.e-bozo.com
>>                 <http://lnx.e-bozo.com>]]]
>>                 [sbus_handler_got_caller_id] (0x4000): Received SBUS
>>                 method [ping]
>>                 (Mon Dec  8 14:03:40 2014) [sssd[be[lnx.e-bozo.com
>>                 <http://lnx.e-bozo.com>]]] [sbus_dispatch] (0x4000):
>>                 dbus conn: 0x1e72ad0
>>                 (Mon Dec  8 14:03:40 2014) [sssd[be[lnx.e-bozo.com
>>                 <http://lnx.e-bozo.com>]]] [sbus_dispatch] (0x4000):
>>                 Dispatching.
>>
>>                 [root at freeipa-poc-client02 sssd]# tail -f sssd_ssh.log
>>                 (Sun Dec  7 19:32:09 2014) [sssd[ssh]]
>>                 [ssh_process_init] (0x0010): sss_process_init() failed
>>                 (Sun Dec  7 19:32:09 2014) [sssd[ssh]] [sss_dp_init]
>>                 (0x0010): Failed to connect to monitor services.
>>                 (Sun Dec  7 19:32:09 2014) [sssd[ssh]]
>>                 [sss_process_init] (0x0010): fatal error setting up
>>                 backend connector
>>                 (Sun Dec  7 19:32:09 2014) [sssd[ssh]]
>>                 [ssh_process_init] (0x0010): sss_process_init() failed
>>                 (Sun Dec  7 19:32:16 2014) [sssd[ssh]] [sss_dp_init]
>>                 (0x0010): Failed to connect to monitor services.
>>                 (Sun Dec  7 19:32:16 2014) [sssd[ssh]]
>>                 [sss_process_init] (0x0010): fatal error setting up
>>                 backend connector
>>                 (Sun Dec  7 19:32:16 2014) [sssd[ssh]]
>>                 [ssh_process_init] (0x0010): sss_process_init() failed
>>                 (Sun Dec  7 19:32:16 2014) [sssd[ssh]] [sss_dp_init]
>>                 (0x0010): Failed to connect to monitor services.
>>                 (Sun Dec  7 19:32:16 2014) [sssd[ssh]]
>>                 [sss_process_init] (0x0010): fatal error setting up
>>                 backend connector
>>                 (Sun Dec  7 19:32:16 2014) [sssd[ssh]]
>>                 [ssh_process_init] (0x0010): sss_process_init() failed
>
>                 What is the version of the client?
>                 Please add debug_level=9 to sssd.conf in different
>                 sections to rise the verbosity of the log and see what
>                 is really going on there.
>                 https://fedorahosted.org/sssd/wiki/FAQ#BasicsofTroubleshooting
>
>
>
>
>>
>>
>>                 On Mon, Dec 8, 2014 at 11:48 AM, Matthew Herzog
>>                 <matthew.herzog at gmail.com
>>                 <mailto:matthew.herzog at gmail.com>> wrote:
>>
>>                     I have never seen my IPA servers produce a zone
>>                     file nor has the install script ever mentioned
>>                     the creation of such. In fact, I just ran
>>                     ipa-server-install --uninstall
>>                     && ipa-server-install and there was no mention of
>>                     a zone file.
>>
>>                     Where should I look in the file system to be
>>                     sure? I see nothing in /var/named. I'm using
>>                     3.3.3 IPA on Oracle Linux from Oracle's yum repo.
>>                     (Not my choice.)
>>
>>                     dsee7 is /not /running Kerberos. dsee7 is /not
>>                     /configured with SRV records. I guess I'll need
>>                     to add SRV records for all my Linux hosts.
>>
>>
>>
>>
>>
>>
>>                     On Mon, Dec 8, 2014 at 10:41 AM, Petr Spacek
>>                     <pspacek at redhat.com <mailto:pspacek at redhat.com>>
>>                     wrote:
>>
>>                         On 8.12.2014 14:44, Matthew Herzog wrote:
>>                         > Petr said, "You can run ipa-server-install
>>                         *without* --setup-dns option and
>>                         > at the end of
>>                         > installation it will produce DNS records
>>                         which you have to manually add to
>>                         > your existing DNS database."
>>                         >
>>                         > I can't see how this would be useful or
>>                         which machines I would need to add
>>                         > to our DNS.
>>                         >
>>                         > Perhaps I should have explained that we are
>>                         not going to set up a new DNS
>>                         > domain for the ipa-managed servers.
>>                         Good.
>>
>>                         Now you should run ipa-server-install
>>                         *without* --setup-dns, using
>>                         lnx.e-bozo.com <http://lnx.e-bozo.com> as you
>>                         IPA domain. It will install full IPA server
>>                         and spit out
>>                         DNS zone file.
>>
>>                         Then you *have to* take this zone file and
>>                         import it to your existing DNS
>>                         infrastructure - that will give you fully
>>                         functional IPA domain lnx.e-bozo.com
>>                         <http://lnx.e-bozo.com>.
>>
>>                         Caveat:
>>                         Preceding text assumes that 'dsee7' is nor
>>                         using either Kerberos nor DNS SRV
>>                         records for LDAP service in domain
>>                         lnx.e-bozo.com <http://lnx.e-bozo.com>, i.e.
>>                         clients connecting to
>>                         DSEE7 should be (most likely) statically
>>                         configured with DSEE7 server name.
>>
>>                         Petr^2 Spacek
>>
>>                         > We have an Oracle dsee7 server doing
>>                         > LDAP for our Linux servers and accounts. We
>>                         want to migrate to IPA so we
>>                         > don't have to maintain a Linux/LDAP account
>>                         for every user who needs access
>>                         > to Linux servers. All of our users start
>>                         with an account in AD and since
>>                         > none of my predecessors knew about Winbind,
>>                         they set up dsee7.
>>                         >
>>                         > So I'm thinking we'll need to import all
>>                         our dsee7 accounts AND make it
>>                         > possible for AD users to access the Linux
>>                         systems without needing to create
>>                         > them in IPA.
>>                         >
>>                         > On Mon, Dec 8, 2014 at 2:56 AM, Petr Spacek
>>                         <pspacek at redhat.com
>>                         <mailto:pspacek at redhat.com>> wrote:
>>                         >
>>                         >> On 8.12.2014 05:02, Dmitri Pal wrote:
>>                         >>> On 12/07/2014 10:10 PM, Matthew Herzog wrote:
>>                         >>>> So should the FreeIPA server be
>>                         authoritative for the Kerb. realm/DNS
>>                         >> domain
>>                         >>>> or can it/should it be a slave DNS
>>                         server instead? Or caching only?
>>                         >>>
>>                         >>> IPA DNS can't be a slave so you either
>>                         delegate a whole zone to it or
>>                         >> manage
>>                         >>> IPA DNS domain via your own DNS server.
>>                         >>
>>                         >> Generally, "slave" is not allowed to do
>>                         any changes so it is useless in
>>                         >> your
>>                         >> scenario.
>>                         >>
>>                         >> You can run ipa-server-install *without*
>>                         --setup-dns option and at the end
>>                         >> of
>>                         >> installation it will produce DNS records
>>                         which you have to manually add to
>>                         >> your existing DNS database.
>>                         >>
>>                         >> Did you try that?
>>                         >>
>>                         >> Petr^2 Spacek
>>                         >>
>>                         >>>> On Sun, Dec 7, 2014 at 9:57 PM, Dmitri
>>                         Pal <dpal at redhat.com <mailto:dpal at redhat.com>
>>                         >>>> <mailto:dpal at redhat.com
>>                         <mailto:dpal at redhat.com>>> wrote:
>>                         >>>>
>>                         >>>>    On 12/07/2014 09:51 PM, Matthew
>>                         Herzog wrote:
>>                         >>>>>    What must be done in or on the ipa
>>                         server with regard to DNS, if
>>                         >>>>>    anything?
>>                         >>>>>
>>                         >>>>>    Our DNS works. It works well. We
>>                         have four Linux DNS servers and
>>                         >>>>>    two AD domain controllers that also
>>                         do DNS.
>>                         >>>>>
>>                         >>>>>    So if we already have DNS working
>>                         well in our domain, why do we
>>                         >>>>>    want to manage DNS in IPA?
>>                         >>>>
>>                         >>>>    Let us keep the discussion on the list.
>>                         >>>>    IPA when used with AD trust presents
>>                         itself as a separate forest.
>>                         >>>>    AD thinks that it is working with
>>                         another AD forest.
>>                         >>>>    For that to work we need to follow
>>                         MSFT rules about relationship
>>                         >>>>    between Kerberos realm and DNS domain.
>>                         >>>>    AD assumes that for every trusted
>>                         forest Kerberos realm = DNS
>>                         >>>>    domain. IPA makes it easy to do
>>                         because it has integrated tools to
>>                         >>>>    manage IPA DNS domain.
>>                         >>>>    If you want to manage it yourself
>>                         through your DNS you can do it,
>>                         >>>>    just more manual operations for you.
>>                         >>>>
>>                         >>>>    HTH
>>                         >>>>
>>                         >>>>    Thanks
>>                         >>>>    Dmitri
>>                         >>>>
>>                         >>>>
>>                         >>>>>
>>                         >>>>>    On Sun, Dec 7, 2014 at 9:44 PM,
>>                         Dmitri Pal <dpal at redhat.com
>>                         <mailto:dpal at redhat.com>
>>                         >>>>>    <mailto:dpal at redhat.com
>>                         <mailto:dpal at redhat.com>>> wrote:
>>                         >>>>>
>>                         >>>>>        On 12/07/2014 06:44 PM, Matthew
>>                         Herzog wrote:
>>                         >>>>>>        Thanks guys. I'm sorry for my
>>                         delay in responding.
>>                         >>>>>>
>>                         >>>>>>  Firstly, I was under the impression
>>                         (from reading the docs)
>>                         >>>>>>        that having named running on
>>                         IPA server was critical.
>>                         >>>>>
>>                         >>>>>  Properly configured DNS is critical.
>>                         >>>>>        How you accomplish it is up to you.
>>                         >>>>>        IPA allows you to have a DNS
>>                         server that would simplify DNS
>>                         >>>>>  management but it can be done manually
>>                         too. This is why DNS
>>                         >>>>>        is optional.
>>                         >>>>>
>>                         >>>>>
>>                         >>>>>>        Also, the first question the
>>                         ipa-server-install script asks
>>                         >>>>>>        is, "Do you want to configure
>>                         integrated DNS (BIND)? ."
>>                         >>>>>>        While it's true the default
>>                         answer is no, it leads one to
>>                         >>>>>>        believe that DNS is central to
>>                         IPA. Also the
>>                         >>>>>>  ipa-client-install script says,
>>                         >>>>>>
>>                         >>>>>>  [root at freeipa-poc-client02 ~]#
>>                         ipa-client-install
>>                         >>>>>>        DNS discovery failed to
>>                         determine your DNS domain
>>                         >>>>>>        Provide the domain name of your
>>                         IPA server (ex: example.com <http://example.com>
>>                         >>>>>>        <http://example.com>):
>>                         >>>>>>
>>                         >>>>>>        I can resolve -anything- from
>>                         the machine using dig or
>>                         >> whatever.
>>                         >>>>>>
>>                         >>>>>>  Ultimately, the reason I started to
>>                         be concerned about my
>>                         >>>>>>        IPA server's DNS config was
>>                         because I was not able to
>>                         >>>>>>  authenticate AD accounts to a client
>>                         machine. I saw a bunch
>>                         >>>>>>        of errors in the client's sssd
>>                         logs which of course I can't
>>                         >>>>>>        find now.
>>                         >>>>>>
>>                         >>>>>>        Perhaps it was these . . .
>>                         >>>>>>
>>                         >>>>>>        (Thu Dec  4 13:45:23 2014)
>>                         [sssd] [ping_check] (0x0100):
>>                         >>>>>>        Service nss replied to ping
>>                         >>>>>>        (Thu Dec  4 13:45:23 2014)
>>                         [sssd] [ping_check] (0x0100):
>>                         >>>>>>        Service sudo replied to ping
>>                         >>>>>>        (Thu Dec  4 13:45:23 2014)
>>                         [sssd] [ping_check] (0x0100):
>>                         >>>>>>        Service pam replied to ping
>>                         >>>>>>        (Thu Dec  4 13:45:23 2014)
>>                         [sssd] [ping_check] (0x0100):
>>                         >>>>>>        Service ssh replied to ping
>>                         >>>>>>        (Thu Dec  4 13:45:23 2014)
>>                         [sssd] [ping_check] (0x0100):
>>                         >>>>>>        Service pac replied to ping
>>                         >>>>>>        (Thu Dec  4 13:45:23 2014)
>>                         [sssd] [ping_check] (0x0100):
>>                         >>>>>>        Service bo3.e-bozo.com
>>                         <http://bo3.e-bozo.com>
>>                         <http://bo3.e-bozo.com> replied to
>>                         >> ping
>>                         >>>>>>
>>                         >>>>>>        I'm not allowed onto the AD
>>                         domain controllers to examine
>>                         >>>>>>        log files or I'd be checking
>>                         those first.
>>                         >>>>>>
>>                         >>>>>>        So ultimately the goal is to
>>                         authenticate AD users and users
>>                         >>>>>>        that exist in our ldap schema.
>>                         We need to set up groups of
>>                         >>>>>>        users that can run sudo
>>                         commands on specific groups of hosts.
>>                         >>>>>
>>                         >>>>>        Did you setup trusts as
>>                         explained on the following page?
>>                         >>>>>
>>                         http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup
>>                         >>>>>
>>                         >>>>>
>>                         >>>>>>
>>                         >>>>>>
>>                         >>>>>>
>>                         >>>>>>        On Wed, Dec 3, 2014 at 3:46 AM,
>>                         Petr Spacek
>>                         >>>>>>        <pspacek at redhat.com
>>                         <mailto:pspacek at redhat.com>
>>                         <mailto:pspacek at redhat.com
>>                         <mailto:pspacek at redhat.com>>> wrote:
>>                         >>>>>>
>>                         >>>>>>            On 3.12.2014 04:35, Dmitri
>>                         Pal wrote:
>>                         >>>>>>  > On 12/02/2014 08:54 PM, Matthew
>>                         Herzog wrote:
>>                         >>>>>>  >> Any other ideas? I just spun up a
>>                         new VM and took the
>>                         >>>>>>  defaults on everything
>>                         >>>>>>  >> while running ipa-server-install
>>                         (the defaults did
>>                         >>>>>>  make sense) and my new VM
>>                         >>>>>>  >> can't resolve -anything- in the
>>                         domain in which it
>>                         >>>>>>  lives. The "old" VM
>>                         >>>>>>  >> (running the same versions of
>>                         everything on the same
>>                         >>>>>>            OS) can't even resolve
>>                         >>>>>>  >> the clients I have registered with it!
>>                         >>>>>>  >>
>>                         >>>>>>  >> So I'm pretty frustrated and am
>>                         wondering, what
>>                         >>>>>>  _exactly_ is the role of
>>                         >>>>>>  >> bind in the IPA server and how is
>>                         it expected to know
>>                         >>>>>>  anything about the
>>                         >>>>>>  >> local DNS domain without becoming
>>                         a bind slave server?
>>                         >>>>>>  >
>>                         >>>>>>  > I am not sure I am 100% with you but...
>>                         >>>>>>  > If you use the defaults and nothing
>>                         else you get to
>>                         >>>>>>            the scenario when IPA has
>>                         >>>>>>  > its DNS but it is a self contained
>>                         environment. It
>>                         >>>>>>  seems that this is what you
>>                         >>>>>>  > observe.
>>                         >>>>>>  > It is expected that you decide in
>>                         advance what you
>>                         >>>>>>  want to do with DNS. There
>>                         >>>>>>  > are several options:
>>                         >>>>>>  > 1) You can delegate a zone to IPA
>>                         to manage, then you
>>                         >>>>>>  need to connect your IPA
>>                         >>>>>>  > DNS to your existing DNS during
>>                         install or after.
>>                         >>>>>>  > In this case the systems joined to
>>                         IPA will be a part
>>                         >>>>>>            of IPA domain/zone and
>>                         >>>>>>  > would also be able to resolve other
>>                         systems around
>>                         >>>>>>  > 2) Not use IPA DNS if you do not
>>                         want to take
>>                         >>>>>>  advantage of it
>>                         >>>>>>  > 3) Have a self contained demo/lab
>>                         environment that you
>>                         >>>>>>  currently observe.
>>                         >>>>>>  >
>>                         >>>>>>  > What is the intent?
>>                         >>>>>>
>>                         >>>>>>            I agree with Dmitri, we
>>                         need more information from you:
>>                         >>>>>>            - You said "my new VM can't
>>                         resolve -anything- in the
>>                         >>>>>>  domain in which it
>>                         >>>>>>  lives." - Which domain do you mean?
>>                         >>>>>>
>>                         >>>>>>            - Apparently you have
>>                         configured FreeIPA to serve zone
>>                         >>>>>> e-bozo.com <http://e-bozo.com>
>>                         <http://e-bozo.com>. Do you have
>>                         >>>>>>  this zone configured on some other
>>                         DNS server at the
>>                         >>>>>>  same time?
>>                         >>>>>>
>>                         >>>>>>  Please keep in mind that
>>                         authoritative servers should
>>                         >>>>>>  share the database. You
>>                         >>>>>>  will get naming collisions if
>>                         e-bozo.com <http://e-bozo.com>
>>                         >>>>>>  <http://e-bozo.com> is served by
>>                         FreeIPA DNS servers and
>>                         >>>>>>  some other servers at the same time.
>>                         Maybe that is the
>>                         >>>>>>  problem you see right now.
>>                         >>>>>>
>>                         >>>>>>            As Dmitri said, the
>>                         architecturally correct solution is
>>                         >>>>>>            to decide if you want
>>                         >>>>>>            to use FreeIPA DNS or not.
>>                         You have option to either
>>                         >>>>>>  remove non-FreeIPA DNS
>>                         >>>>>>  servers and import data to FreeIPA or
>>                         to add
>>                         >>>>>>  FreeIPA-specific DNS records to
>>                         >>>>>>  existing DNS servers and do not
>>                         configure FreeIPA to act
>>                         >>>>>>            as DNS server.
>>                         >>>>>>
>>                         >>>>>>  Petr^2 Spacek
>>                         >>>>>>
>>                         >>>>>>  >> Thanks.
>>                         >>>>>>  >>
>>                         >>>>>>  >> On Tue, Dec 2, 2014 at 11:58 AM,
>>                         Petr Spacek
>>                         >>>>>>  <pspacek at redhat.com
>>                         <mailto:pspacek at redhat.com>
>>                         <mailto:pspacek at redhat.com
>>                         <mailto:pspacek at redhat.com>>
>>                         >>>>>>  >> <mailto:pspacek at redhat.com
>>                         <mailto:pspacek at redhat.com>
>>                         >>>>>>  <mailto:pspacek at redhat.com
>>                         <mailto:pspacek at redhat.com>>>> wrote:
>>                         >>>>>>  >>
>>                         >>>>>>  >>  On 2.12.2014 17:36, Martin Basti
>>                         wrote:
>>                         >>>>>>  >>  > On 02/12/14 17:28, Matthew
>>                         Herzog wrote:
>>                         >>>>>>  >>  >> I just realized that my IPA
>>                         servers cannot
>>                         >>>>>>  resolve ANY servers
>>                         >>>>>>  >>  in my domain.
>>                         >>>>>>  >>  >> What do I need to do to fix
>>                         this? Below is my
>>                         >>>>>>  named.conf.
>>                         >>>>>>  >>  >>
>>                         >>>>>>  >>  >>
>>                         >>>>>>  >>  >> options {
>>                         >>>>>>  >>  >>  // turns on IPv6 for port 53,
>>                         IPv4 is on by
>>                         >>>>>>  default for
>>                         >>>>>>  >>  all ifaces
>>                         >>>>>>  >>  >> listen-on-v6 {any;};
>>                         >>>>>>  >>  >>
>>                         >>>>>>  >>  >>  // Put files that named is
>>                         allowed to write
>>                         >>>>>>            in the
>>                         >>>>>>  >>  data/ directory:
>>                         >>>>>>  >>  >> directory "/var/named"; // the
>>                         default
>>                         >>>>>>  >>  >> dump-file "data/cache_dump.db";
>>                         >>>>>>  >>  >> statistics-file
>>                         "data/named_stats.txt";
>>                         >>>>>>  >>  >> memstatistics-file
>>                         "data/named_mem_stats.txt";
>>                         >>>>>>  >>  >>
>>                         >>>>>>  >>  >> forward first;
>>                         >>>>>>  >>  >> forwarders {
>>                         >>>>>>  >>  >> 10.100.8.41;
>>                         >>>>>>  >>  >> 10.100.8.40;
>>                         >>>>>>  >>  >> 10.100.4.13;
>>                         >>>>>>  >>  >> 10.100.4.14;
>>                         >>>>>>  >>  >> 10.100.4.19;
>>                         >>>>>>  >>  >> 10.100.4.44;
>>                         >>>>>>  >>  >>  };
>>                         >>>>>>  >>  >>
>>                         >>>>>>  >>  >>  // Any host is permitted to
>>                         issue recursive
>>                         >>>>>>  queries
>>                         >>>>>>  >>  >> allow-recursion { any; };
>>                         >>>>>>  >>  >>
>>                         >>>>>>  >>  >> tkey-gssapi-keytab
>>                         "/etc/named.keytab";
>>                         >>>>>>  >>  >> pid-file "/run/named/named.pid";
>>                         >>>>>>  >>  >> };
>>                         >>>>>>  >>  >>
>>                         >>>>>>  >>  >> /* If you want to enable
>>                         debugging, eg. using
>>                         >>>>>>            the 'rndc trace'
>>                         >>>>>>  >>  command,
>>                         >>>>>>  >>  >>  * By default, SELinux policy
>>                         does not allow
>>                         >>>>>>  named to modify
>>                         >>>>>>  >>  the /var/named
>>                         >>>>>>  >>  >> directory,
>>                         >>>>>>  >>  >>  * so put the default debug
>>                         log file in data/ :
>>                         >>>>>>  >>  >>  */
>>                         >>>>>>  >>  >> logging {
>>                         >>>>>>  >>  >> channel default_debug {
>>                         >>>>>>  >>  >>     file "data/named.run";
>>                         >>>>>>  >>  >>     severity dynamic;
>>                         >>>>>>  >>  >>     print-time yes;
>>                         >>>>>>  >>  >>  };
>>                         >>>>>>  >>  >>  };
>>                         >>>>>>  >>  >> };
>>                         >>>>>>  >>  >>
>>                         >>>>>>  >>  >> zone "." IN {
>>                         >>>>>>  >>  >> type hint;
>>                         >>>>>>  >>  >> file "named.ca
>>                         <http://named.ca> <http://named.ca>
>>                         >>>>>>  <http://named.ca> <http://named.ca>";
>>                         >>>>>>  >>  >> };
>>                         >>>>>>  >>  >>
>>                         >>>>>>  >>  >> include
>>                         "/etc/named.rfc1912.zones";
>>                         >>>>>>  >>  >>
>>                         >>>>>>  >>  >> dynamic-db "ipa" {
>>                         >>>>>>  >>  >> library "ldap.so";
>>                         >>>>>>  >>  >>  arg "uri
>>                         >>>>>>  >>
>>                         ldapi://%2fvar%2frun%2fslapd-BO3-E-BOZO-COM.socket";
>>                         >>>>>>  >>  >>  arg "base cn=dns,
>>                         dc=bo3,dc=e-bozo,dc=com";
>>                         >>>>>>  >>  >>  arg "fake_mname
>>                         freeipa-poc01.bo3.e-bozo.com
>>                         <http://freeipa-poc01.bo3.e-bozo.com>
>>                         >>>>>>  <http://freeipa-poc01.bo3.e-bozo.com>
>>                         >>>>>>  >>  <http://freeipa-poc01.bo3.e-bozo.com>
>>                         >>>>>>  >>  >>
>>                         <http://freeipa-poc01.bo3.e-bozo.com>.";
>>                         >>>>>>  >>  >>  arg "auth_method sasl";
>>                         >>>>>>  >>  >>  arg "sasl_mech GSSAPI";
>>                         >>>>>>  >>  >>  arg "sasl_user
>>                         >>>>>>  DNS/freeipa-poc01.bo3.e-bozo.com
>>                         <http://freeipa-poc01.bo3.e-bozo.com>
>>                         >>>>>>  <http://freeipa-poc01.bo3.e-bozo.com>
>>                         >>>>>>  >>  <http://freeipa-poc01.bo3.e-bozo.com>
>>                         >>>>>>  >>  >>
>>                         <http://freeipa-poc01.bo3.e-bozo.com>";
>>                         >>>>>>  >>  >>  arg "serial_autoincrement yes";
>>                         >>>>>>  >>  >> };
>>                         >>>>>>  >>  >>
>>                         >>>>>>  >>  >>
>>                         >>>>>>  >>  >>
>>                         >>>>>>  >>  >>
>>                         >>>>>>  >>  > Hello,
>>                         >>>>>>  >>  >
>>                         >>>>>>  >>  > which version ipa do you use?
>>                         which platform?
>>                         >>>>>>  Which version
>>                         >>>>>>  >>  bind-dyndb-ldap?
>>                         >>>>>>  >>  >
>>                         >>>>>>  >>  > Can you run these commands, and
>>                         check if there
>>                         >>>>>>            any errors?
>>                         >>>>>>  >>  > ipactl status
>>                         >>>>>>  >>  > systemctl status named
>>                         (respectively
>>                         >>>>>>  journalctl -u named)
>>                         >>>>>>  >>
>>                         >>>>>>  >>  We also may want to see
>>                         information listed on page
>>                         >>>>>>  >>
>>                         >>>>>>
>>                         >>
>>                         https://fedorahosted.org/bind-dyndb-ldap/wiki/BugReporting
>>
>>                         --
>>                         Petr^2 Spacek
>>
>>
>>
>>
>>                     -- 
>>                     If life gives you melons, you may be dyslexic.
>>
>>
>>
>>
>>                 -- 
>>                 If life gives you melons, you may be dyslexic.
>>
>>
>
>
>                 -- 
>                 Thank you,
>                 Dmitri Pal
>
>                 Sr. Engineering Manager IdM portfolio
>                 Red Hat, Inc.
>
>
>                 --
>                 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
>
>
>
>
>             -- 
>             If life gives you melons, you may be dyslexic.
>
>
>
>
>         -- 
>         If life gives you melons, you may be dyslexic.
>
>
>
>
>     -- 
>     If life gives you melons, you may be dyslexic.
>
>
>
>
> -- 
> If life gives you melons, you may be dyslexic.
>
>


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141208/fa24c677/attachment.htm>

From gianluca.cecchi at gmail.com  Mon Dec  8 23:50:59 2014
From: gianluca.cecchi at gmail.com (Gianluca Cecchi)
Date: Tue, 9 Dec 2014 00:50:59 +0100
Subject: [Freeipa-users] vSphere 5.1 and FreeIPA 3.3 on CentOS 7 finally
 works! [How I did it...]
In-Reply-To: <CAG2kNCyWUhbVZUbpo0rgE_NAucs5S4x6_dj4JcCXTNWyLNSAFw@mail.gmail.com>
References: <CAG2kNCyXWXxMx0V96bYgMq--9zaBwhWMBENrOgSXnMMr9=F85Q@mail.gmail.com>
	<5485E119.10203@redhat.com>
	<CAG2kNCyWUhbVZUbpo0rgE_NAucs5S4x6_dj4JcCXTNWyLNSAFw@mail.gmail.com>
Message-ID: <CAG2kNCyj=b4c-5C59uvba37hoXwX8rHmtE9DC1vbKk+YM5p1ZQ@mail.gmail.com>

On Mon, Dec 8, 2014 at 7:17 PM, Gianluca Cecchi <gianluca.cecchi at gmail.com>
wrote:

> OK. I will check requirements to write into The wiki
>


When I try to login with my Fedora OpenID account and choose as nickname my
real name and press "login" actually it indefinitely remains on the blank
page
http://www.freeipa.org/page/Special:OpenIDLogin/ChooseName

without enabling me to log in and begin to write anything.
Tried from both Chrome and Fedora (on my Fedora 20 system)....
Similar problems when I used to use zanata to write oVirt Italian
translation, but in that case with some difficulty I finally was able then
to log in and begin to work... no way here

This OpenID thing doesn't seem very usable in my opinion...

Gianluca
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141209/93fe9032/attachment.htm>

From gianluca.cecchi at gmail.com  Mon Dec  8 23:51:56 2014
From: gianluca.cecchi at gmail.com (Gianluca Cecchi)
Date: Tue, 9 Dec 2014 00:51:56 +0100
Subject: [Freeipa-users] vSphere 5.1 and FreeIPA 3.3 on CentOS 7 finally
 works! [How I did it...]
In-Reply-To: <CAG2kNCyj=b4c-5C59uvba37hoXwX8rHmtE9DC1vbKk+YM5p1ZQ@mail.gmail.com>
References: <CAG2kNCyXWXxMx0V96bYgMq--9zaBwhWMBENrOgSXnMMr9=F85Q@mail.gmail.com>
	<5485E119.10203@redhat.com>
	<CAG2kNCyWUhbVZUbpo0rgE_NAucs5S4x6_dj4JcCXTNWyLNSAFw@mail.gmail.com>
	<CAG2kNCyj=b4c-5C59uvba37hoXwX8rHmtE9DC1vbKk+YM5p1ZQ@mail.gmail.com>
Message-ID: <CAG2kNCyUZJvnSbPirACcm9+iwrFdjx-7OZ+MdgMqbhLCpXX1Sg@mail.gmail.com>

On Tue, Dec 9, 2014 at 12:50 AM, Gianluca Cecchi <gianluca.cecchi at gmail.com>
wrote:

>
> Tried from both Chrome and Fedora (on my Fedora 20 system)....
>
>
Correct:
Tried from both Chrome and Firefox (on my Fedora 20 system)....
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141209/f1366959/attachment.htm>

From dpal at redhat.com  Tue Dec  9 01:43:03 2014
From: dpal at redhat.com (Dmitri Pal)
Date: Mon, 08 Dec 2014 20:43:03 -0500
Subject: [Freeipa-users] vSphere 5.1 and FreeIPA 3.3 on CentOS 7 finally
 works! [How I did it...]
In-Reply-To: <CAG2kNCyj=b4c-5C59uvba37hoXwX8rHmtE9DC1vbKk+YM5p1ZQ@mail.gmail.com>
References: <CAG2kNCyXWXxMx0V96bYgMq--9zaBwhWMBENrOgSXnMMr9=F85Q@mail.gmail.com>	<5485E119.10203@redhat.com>	<CAG2kNCyWUhbVZUbpo0rgE_NAucs5S4x6_dj4JcCXTNWyLNSAFw@mail.gmail.com>
	<CAG2kNCyj=b4c-5C59uvba37hoXwX8rHmtE9DC1vbKk+YM5p1ZQ@mail.gmail.com>
Message-ID: <548653A7.3070102@redhat.com>

On 12/08/2014 06:50 PM, Gianluca Cecchi wrote:
> On Mon, Dec 8, 2014 at 7:17 PM, Gianluca Cecchi 
> <gianluca.cecchi at gmail.com <mailto:gianluca.cecchi at gmail.com>> wrote:
>
>     OK. I will check requirements to write into The wiki
>
>
>
> When I try to login with my Fedora OpenID account and choose as 
> nickname my real name and press "login" actually it indefinitely 
> remains on the blank page
> http://www.freeipa.org/page/Special:OpenIDLogin/ChooseName
>
> without enabling me to log in and begin to write anything.
> Tried from both Chrome and Fedora (on my Fedora 20 system)....
> Similar problems when I used to use zanata to write oVirt Italian 
> translation, but in that case with some difficulty I finally was able 
> then to log in and begin to work... no way here
>
> This OpenID thing doesn't seem very usable in my opinion...
>
> Gianluca
>

Do you manage to pass the Fedora OpenID prompt?
Are you authenticating with  "giallu<https://giallu.fedorapeople.org>" 
login?
Is it on the redirect from fedora to wiki when you are stuck or it is 
some other point of the sequence?

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141208/70683ff7/attachment.htm>

From Less at imagine-sw.com  Tue Dec  9 04:04:41 2014
From: Less at imagine-sw.com (Les Stott)
Date: Tue, 9 Dec 2014 04:04:41 +0000
Subject: [Freeipa-users] CA Replication Installation Failing
In-Reply-To: <4ED173A868981548967B4FCA270722262803F3C5@AACMBXP04.exchserver.com>
References: <4ED173A868981548967B4FCA270722262803F3C5@AACMBXP04.exchserver.com>
Message-ID: <4ED173A868981548967B4FCA2707222628048DF6@AACMBXP04.exchserver.com>

Does anyone have any ideas on the below errors when trying to add CA replication to an existing replica?

Thanks in advance,

Les

From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Les Stott
Sent: Tuesday, 2 December 2014 6:17 PM
To: freeipa-users at redhat.com
Subject: [Freeipa-users] CA Replication Installation Failing

Hi All,

I have RHEL6 with ipa servers running standard ipa server 3.0.0-42. Pki components are also standard version 9.0.3-38.

Servera is the master
Serverb is the replica

Both have been running for many, many months. Serverb was initially setup as a replica, but not a CA replica.

I am now trying to add CA Replication to serverb but it is failing midway through and I cannot figure out why.

Annoyingly, I used the same method/command to setup a CA replica on test servers and it completed without issue.

Here is what I get....(for the sake of brevity, I am excluding the lines for connection check which were all OK)

=================
/usr/sbin/ipa-ca-install /var/lib/ipa/replica-info-serverb.mydomain.com.gpg
Directory Manager (existing master) password:
Get credentials to log in to remote master
admin at MYDOMAIN.COM<mailto:admin at MYDOMAIN.COM> password:
Execute check on remote master
Connection check OK
Configuring directory server for the CA (pkids): Estimated time 30 seconds
  [1/3]: creating directory server user
  [2/3]: creating directory server instance
  [3/3]: restarting directory server
Done configuring directory server for the CA (pkids).
Configuring certificate server (pki-cad): Estimated time 3 minutes 30 seconds
  [1/16]: creating certificate server user
  [2/16]: creating pki-ca instance
  [3/16]: configuring certificate server instance
ipa         : CRITICAL failed to configure ca instance Command '/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname serverb.mydomain.com -cs_port 9445 -client_certdb_dir /tmp/tmp-t3aHM7 -client_certdb_pwd XXXXXXXX -preop_pin exoyO2y7bawG5yjZMACM -domain_name IPA -admin_user admin -admin_email root at localhost -admin_password XXXXXXXX -agent_name ipa-ca-agent -agent_key_size 2048 -agent_key_type rsa -agent_cert_subject CN=ipa-ca-agent,O=MYDOMAIN.COM -ldap_host serverb.mydomain.com -ldap_port 7389 -bind_dn cn=Directory Manager -bind_password XXXXXXXX -base_dn o=ipaca -db_name ipaca -key_size 2048 -key_type rsa -key_algorithm SHA256withRSA -save_p12 true -backup_pwd XXXXXXXX -subsystem_name pki-cad -token_name internal -ca_subsystem_cert_subject_name CN=CA Subsystem,O=MYDOMAIN.COM -ca_subsystem_cert_subject_name CN=CA Subsystem,O=MYDOMAIN.COM -ca_ocsp_cert_subject_name CN=OCSP Subsystem,O=MYDOMAIN.COM -ca_server_cert_subject_name CN=serverb.mydomain.com,O=MYDOMAIN.COM -ca_audit_signing_cert_subject_name CN=CA Audit,O=MYDOMAIN.COM -ca_sign_cert_subject_name CN=Certificate Authority,O=MYDOMAIN.COM -external false -clone true -clone_p12_file ca.p12 -clone_p12_password XXXXXXXX -sd_hostname servera.mydomain.com -sd_admin_port 443 -sd_admin_name admin -sd_admin_password XXXXXXXX -clone_start_tls true -clone_uri https://servera.mydomain.com:443' returned non-zero exit status 255

Your system may be partly configured.
Run /usr/sbin/ipa-server-install --uninstall to clean up.

Configuration of CA failed
=================

Additional excerpt from the log file /var/log/ipareplica-ca-install.log at the point of failure....

=================

#############################################
Attempting to connect to: serverb.mydomain.com:9445
Connected.
Posting Query = https://serverb.mydomain.com:9445//ca/admin/console/config/wizard?p=7&op=next&xml=true&__password=XXXXXXXX&path=ca.p12<https://serverb.mydomain.com:9445/ca/admin/console/config/wizard?p=7&op=next&xml=true&__password=XXXXXXXX&path=ca.p12>
RESPONSE STATUS:  HTTP/1.1 200 OK
RESPONSE HEADER:  Server: Apache-Coyote/1.1
RESPONSE HEADER:  Content-Type: application/xml;charset=UTF-8
RESPONSE HEADER:  Date: Tue, 02 Dec 2014 05:44:19 GMT
RESPONSE HEADER:  Connection: close
<?xml version="1.0" encoding="UTF-8"?>
<!-- BEGIN COPYRIGHT BLOCK
     This program is free software; you can redistribute it and/or modify
     it under the terms of the GNU General Public License as published by
     the Free Software Foundation; version 2 of the License.

     This program is distributed in the hope that it will be useful,
     but WITHOUT ANY WARRANTY; without even the implied warranty of
     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
     GNU General Public License for more details.

     You should have received a copy of the GNU General Public License along
     with this program; if not, write to the Free Software Foundation, Inc.,
     51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.

     Copyright (C) 2007 Red Hat, Inc.
     All rights reserved.
     END COPYRIGHT BLOCK -->
<response>
  <panel>admin/console/config/restorekeycertpanel.vm</panel>
  <res/>
  <updateStatus>failure</updateStatus>
  <password/>
  <errorString>The pkcs12 file is not correct.</errorString>
  <size>19</size>
  <title>Import Keys and Certificates</title>
  <panels>
    <Vector>
      <Panel>
        <Id>welcome</Id>
        <Name>Welcome</Name>
      </Panel>
      <Panel>
        <Id>module</Id>
        <Name>Key Store</Name>
      </Panel>
      <Panel>
        <Id>confighsmlogin</Id>
        <Name>ConfigHSMLogin</Name>
      </Panel>
      <Panel>
        <Id>securitydomain</Id>
        <Name>Security Domain</Name>
      </Panel>
      <Panel>
        <Id>securitydomain</Id>
        <Name>Display Certificate Chain</Name>
      </Panel>
      <Panel>
        <Id>subsystem</Id>
        <Name>Subsystem Type</Name>
      </Panel>
      <Panel>
        <Id>clone</Id>
        <Name>Display Certificate Chain</Name>
      </Panel>
      <Panel>
        <Id>restorekeys</Id>
        <Name>Import Keys and Certificates</Name>
      </Panel>
      <Panel>
        <Id>cahierarchy</Id>
        <Name>PKI Hierarchy</Name>
      </Panel>
      <Panel>
        <Id>database</Id>
        <Name>Internal Database</Name>
      </Panel>
      <Panel>
        <Id>size</Id>
        <Name>Key Pairs</Name>
      </Panel>
      <Panel>
        <Id>subjectname</Id>
        <Name>Subject Names</Name>
      </Panel>
      <Panel>
        <Id>certrequest</Id>
        <Name>Requests and Certificates</Name>
      </Panel>
      <Panel>
        <Id>backupkeys</Id>
        <Name>Export Keys and Certificates</Name>
      </Panel>
      <Panel>
        <Id>savepk12</Id>
        <Name>Save Keys and Certificates</Name>
      </Panel>
      <Panel>
        <Id>importcachain</Id>
        <Name>Import CA's Certificate Chain</Name>
      </Panel>
      <Panel>
        <Id>admin</Id>
        <Name>Administrator</Name>
      </Panel>
      <Panel>
        <Id>importadmincert</Id>
        <Name>Import Administrator's Certificate</Name>
      </Panel>
      <Panel>
        <Id>done</Id>
        <Name>Done</Name>
      </Panel>
    </Vector>
  </panels>
  <name>CA Setup Wizard</name>
  <p>7</p>
  <path/>
  <req/>
  <panelname>restorekeys</panelname>
</response>
Error in RestoreKeyCertPanel(): updateStatus returns failure
ERROR: ConfigureCA: RestoreKeyCertPanel() failure
ERROR: unable to create CA

#######################################################################
2014-12-02T05:44:19Z DEBUG stderr=
2014-12-02T05:44:19Z CRITICAL failed to configure ca instance Command '/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname serverb.mydomain.com -cs_port 9445 -client_certdb_dir /tmp/tmp-1Tqws5 -client_certdb_pwd XXXXXXXX -preop_pin rdkE0y2CiGMKNcRRPKKc -domain_name IPA -admin_user admin -admin_email root at localhost -admin_password XXXXXXXX -agent_name ipa-ca-agent -agent_key_size 2048 -agent_key_type rsa -agent_cert_subject CN=ipa-ca-agent,O=MYDOMAIN.COM -ldap_host serverb.mydomain.com -ldap_port 7389 -bind_dn cn=Directory Manager -bind_password XXXXXXXX -base_dn o=ipaca -db_name ipaca -key_size 2048 -key_type rsa -key_algorithm SHA256withRSA -save_p12 true -backup_pwd XXXXXXXX -subsystem_name pki-cad -token_name internal -ca_subsystem_cert_subject_name CN=CA Subsystem,O=MYDOMAIN.COM -ca_subsystem_cert_subject_name CN=CA Subsystem,O=MYDOMAIN.COM -ca_ocsp_cert_subject_name CN=OCSP Subsystem,O=MYDOMAIN.COM -ca_server_cert_subject_name CN=serverb.mydomain.com,O=MYDOMAIN.COM -ca_audit_signing_cert_subject_name CN=CA Audit,O=MYDOMAIN.COM -ca_sign_cert_subject_name CN=Certificate Authority,O=MYDOMAIN.COM -external false -clone true -clone_p12_file ca.p12 -clone_p12_password XXXXXXXX -sd_hostname servera.mydomain.com -sd_admin_port 443 -sd_admin_name admin -sd_admin_password XXXXXXXX -clone_start_tls true -clone_uri https://servera.mydomain.com:443' returned non-zero exit status 255
2014-12-02T05:44:19Z INFO   File "/usr/lib/python2.6/site-packages/ipaserver/install/installutils.py", line 614, in run_script
    return_value = main_function()

  File "/usr/sbin/ipa-ca-install", line 149, in main
    (CA, cs) = cainstance.install_replica_ca(config, postinstall=True)

  File "/usr/lib/python2.6/site-packages/ipaserver/install/cainstance.py", line 1626, in install_replica_ca
    subject_base=config.subject_base)

  File "/usr/lib/python2.6/site-packages/ipaserver/install/cainstance.py", line 626, in configure_instance
    self.start_creation(runtime=210)

  File "/usr/lib/python2.6/site-packages/ipaserver/install/service.py", line 358, in start_creation
    method()

  File "/usr/lib/python2.6/site-packages/ipaserver/install/cainstance.py", line 888, in __configure_instance
    raise RuntimeError('Configuration of CA failed')

2014-12-02T05:44:19Z INFO The ipa-ca-install command failed, exception: RuntimeError: Configuration of CA failed

=================

I am not sure why this is happening.

Certutil shows that the setup isn't complete on serverb when comparing against the CA replica in my test servers which were successful.

# certutil -L -d /var/lib/pki-ca/alias

Certificate Nickname                                         Trust Attributes
                                                             SSL,S/MIME,JAR/XPI

Certificate Authority - MYDOMAIN.COM                      CT,c,
Server-Cert cert-pki-ca                                      CTu,Cu,Cu

# certutil -K -d /var/lib/pki-ca/alias
certutil: Checking token "NSS Certificate DB" in slot "NSS User Private Key and Certificate Services"
Enter Password or Pin for "NSS Certificate DB":
< 0> rsa      ef25de4fb656a27e297899509bc3dad582bcd643   NSS Certificate DB:Server-Cert cert-pki-ca


As yet, I have not tried "/usr/sbin/ipa-server-install -uninstall" in an attempt to cleanup as this is a production server and apart from CA replication, it is running fine. I have tried multiple times manually removing pki instances and reinstalling but it still won't get past the above error.

Can anyone shed any light on this?

Thanks in advance,

Les




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141209/1d9307bf/attachment.htm>

From dpal at redhat.com  Tue Dec  9 04:49:21 2014
From: dpal at redhat.com (Dmitri Pal)
Date: Mon, 08 Dec 2014 23:49:21 -0500
Subject: [Freeipa-users] CA Replication Installation Failing
In-Reply-To: <4ED173A868981548967B4FCA2707222628048DF6@AACMBXP04.exchserver.com>
References: <4ED173A868981548967B4FCA270722262803F3C5@AACMBXP04.exchserver.com>
	<4ED173A868981548967B4FCA2707222628048DF6@AACMBXP04.exchserver.com>
Message-ID: <54867F51.1030603@redhat.com>

On 12/08/2014 11:04 PM, Les Stott wrote:
>
> Does anyone have any ideas on the below errors when trying to add CA 
> replication to an existing replica?
>

People who might be able to help are or PTO right now.

Is your installation older than 2 years?
Did you generate a new replica package or use the original one?
May be the problem is that the cert that is in that package already expired?
Just a thought...

The simplest workaround IMO would be to prepare Server C, install it 
with CA and then decommission replica B.
Do not forget to clean replication agreements on master.

But that would be work around, would not solve this specific problem, it 
will kill it.

> Thanks in advance,
>
> Les
>
> *From:*freeipa-users-bounces at redhat.com 
> [mailto:freeipa-users-bounces at redhat.com] *On Behalf Of *Les Stott
> *Sent:* Tuesday, 2 December 2014 6:17 PM
> *To:* freeipa-users at redhat.com
> *Subject:* [Freeipa-users] CA Replication Installation Failing
>
> Hi All,
>
> I have RHEL6 with ipa servers running standard ipa server 3.0.0-42. 
> Pki components are also standard version 9.0.3-38.
>
> Servera is the master
>
> Serverb is the replica
>
> Both have been running for many, many months. Serverb was initially 
> setup as a replica, but not a CA replica.
>
> I am now trying to add CA Replication to serverb but it is failing 
> midway through and I cannot figure out why.
>
> Annoyingly, I used the same method/command to setup a CA replica on 
> test servers and it completed without issue.
>
> Here is what I get....(for the sake of brevity, I am excluding the 
> lines for connection check which were all OK)
>
> =================
>
> /usr/sbin/ipa-ca-install 
> /var/lib/ipa/replica-info-serverb.mydomain.com.gpg
>
> Directory Manager (existing master) password:
>
> Get credentials to log in to remote master
>
> admin at MYDOMAIN.COM <mailto:admin at MYDOMAIN.COM> password:
>
> Execute check on remote master
>
> Connection check OK
>
> Configuring directory server for the CA (pkids): Estimated time 30 seconds
>
>   [1/3]: creating directory server user
>
>   [2/3]: creating directory server instance
>
>   [3/3]: restarting directory server
>
> Done configuring directory server for the CA (pkids).
>
> Configuring certificate server (pki-cad): Estimated time 3 minutes 30 
> seconds
>
>   [1/16]: creating certificate server user
>
>   [2/16]: creating pki-ca instance
>
>   [3/16]: configuring certificate server instance
>
> ipa         : CRITICAL failed to configure ca instance Command 
> '/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname 
> serverb.mydomain.com -cs_port 9445 -client_certdb_dir /tmp/tmp-t3aHM7 
> -client_certdb_pwd XXXXXXXX -preop_pin exoyO2y7bawG5yjZMACM 
> -domain_name IPA -admin_user admin -admin_email root at localhost 
> -admin_password XXXXXXXX -agent_name ipa-ca-agent -agent_key_size 2048 
> -agent_key_type rsa -agent_cert_subject CN=ipa-ca-agent,O=MYDOMAIN.COM 
> -ldap_host serverb.mydomain.com -ldap_port 7389 -bind_dn cn=Directory 
> Manager -bind_password XXXXXXXX -base_dn o=ipaca -db_name ipaca 
> -key_size 2048 -key_type rsa -key_algorithm SHA256withRSA -save_p12 
> true -backup_pwd XXXXXXXX -subsystem_name pki-cad -token_name internal 
> -ca_subsystem_cert_subject_name CN=CA Subsystem,O=MYDOMAIN.COM 
> -ca_subsystem_cert_subject_name CN=CA Subsystem,O=MYDOMAIN.COM 
> -ca_ocsp_cert_subject_name CN=OCSP Subsystem,O=MYDOMAIN.COM 
> -ca_server_cert_subject_name CN=serverb.mydomain.com,O=MYDOMAIN.COM 
> -ca_audit_signing_cert_subject_name CN=CA Audit,O=MYDOMAIN.COM 
> -ca_sign_cert_subject_name CN=Certificate Authority,O=MYDOMAIN.COM 
> -external false -clone true -clone_p12_file ca.p12 -clone_p12_password 
> XXXXXXXX -sd_hostname servera.mydomain.com -sd_admin_port 443 
> -sd_admin_name admin -sd_admin_password XXXXXXXX -clone_start_tls true 
> -clone_uri https://servera.mydomain.com:443' returned non-zero exit 
> status 255
>
> Your system may be partly configured.
>
> Run /usr/sbin/ipa-server-install --uninstall to clean up.
>
> Configuration of CA failed
>
> =================
>
> Additional excerpt from the log file 
> /var/log/ipareplica-ca-install.log at the point of failure....
>
> =================
>
> #############################################
>
> Attempting to connect to: serverb.mydomain.com:9445
>
> Connected.
>
> Posting Query = 
> https://serverb.mydomain.com:9445//ca/admin/console/config/wizard?p=7&op=next&xml=true&__password=XXXXXXXX&path=ca.p12 
> <https://serverb.mydomain.com:9445/ca/admin/console/config/wizard?p=7&op=next&xml=true&__password=XXXXXXXX&path=ca.p12>
>
> RESPONSE STATUS:  HTTP/1.1 200 OK
>
> RESPONSE HEADER:  Server: Apache-Coyote/1.1
>
> RESPONSE HEADER:  Content-Type: application/xml;charset=UTF-8
>
> RESPONSE HEADER:  Date: Tue, 02 Dec 2014 05:44:19 GMT
>
> RESPONSE HEADER:  Connection: close
>
> <?xml version="1.0" encoding="UTF-8"?>
>
> <!-- BEGIN COPYRIGHT BLOCK
>
>      This program is free software; you can redistribute it and/or modify
>
>      it under the terms of the GNU General Public License as published by
>
>      the Free Software Foundation; version 2 of the License.
>
>      This program is distributed in the hope that it will be useful,
>
>      but WITHOUT ANY WARRANTY; without even the implied warranty of
>
>      MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>
>      GNU General Public License for more details.
>
>      You should have received a copy of the GNU General Public License 
> along
>
>      with this program; if not, write to the Free Software Foundation, 
> Inc.,
>
>      51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
>
>      Copyright (C) 2007 Red Hat, Inc.
>
>      All rights reserved.
>
>      END COPYRIGHT BLOCK -->
>
> <response>
>
> <panel>admin/console/config/restorekeycertpanel.vm</panel>
>
>   <res/>
>
> <updateStatus>failure</updateStatus>
>
>   <password/>
>
>   <errorString>The pkcs12 file is not correct.</errorString>
>
>   <size>19</size>
>
>   <title>Import Keys and Certificates</title>
>
>   <panels>
>
>     <Vector>
>
>       <Panel>
>
>         <Id>welcome</Id>
>
>         <Name>Welcome</Name>
>
>       </Panel>
>
>       <Panel>
>
>         <Id>module</Id>
>
>         <Name>Key Store</Name>
>
>       </Panel>
>
>       <Panel>
>
> <Id>confighsmlogin</Id>
>
> <Name>ConfigHSMLogin</Name>
>
>       </Panel>
>
>       <Panel>
>
> <Id>securitydomain</Id>
>
>         <Name>Security Domain</Name>
>
>       </Panel>
>
>       <Panel>
>
> <Id>securitydomain</Id>
>
>         <Name>Display Certificate Chain</Name>
>
>       </Panel>
>
>       <Panel>
>
>         <Id>subsystem</Id>
>
>         <Name>Subsystem Type</Name>
>
>       </Panel>
>
>       <Panel>
>
>         <Id>clone</Id>
>
>         <Name>Display Certificate Chain</Name>
>
>       </Panel>
>
>       <Panel>
>
>         <Id>restorekeys</Id>
>
>         <Name>Import Keys and Certificates</Name>
>
>       </Panel>
>
>       <Panel>
>
>         <Id>cahierarchy</Id>
>
>         <Name>PKI Hierarchy</Name>
>
>       </Panel>
>
>       <Panel>
>
>         <Id>database</Id>
>
>         <Name>Internal Database</Name>
>
>       </Panel>
>
>       <Panel>
>
>         <Id>size</Id>
>
>         <Name>Key Pairs</Name>
>
>       </Panel>
>
>       <Panel>
>
>         <Id>subjectname</Id>
>
>         <Name>Subject Names</Name>
>
>       </Panel>
>
>       <Panel>
>
>         <Id>certrequest</Id>
>
>         <Name>Requests and Certificates</Name>
>
>       </Panel>
>
>       <Panel>
>
>         <Id>backupkeys</Id>
>
>         <Name>Export Keys and Certificates</Name>
>
>       </Panel>
>
>       <Panel>
>
>         <Id>savepk12</Id>
>
>         <Name>Save Keys and Certificates</Name>
>
>       </Panel>
>
>       <Panel>
>
> <Id>importcachain</Id>
>
>         <Name>Import CA's Certificate Chain</Name>
>
>       </Panel>
>
>       <Panel>
>
>         <Id>admin</Id>
>
> <Name>Administrator</Name>
>
>       </Panel>
>
>       <Panel>
>
> <Id>importadmincert</Id>
>
>         <Name>Import Administrator's Certificate</Name>
>
>       </Panel>
>
>       <Panel>
>
>         <Id>done</Id>
>
>         <Name>Done</Name>
>
>       </Panel>
>
>     </Vector>
>
>   </panels>
>
>   <name>CA Setup Wizard</name>
>
>   <p>7</p>
>
>   <path/>
>
>   <req/>
>
> <panelname>restorekeys</panelname>
>
> </response>
>
> Error in RestoreKeyCertPanel(): updateStatus returns failure
>
> ERROR: ConfigureCA: RestoreKeyCertPanel() failure
>
> ERROR: unable to create CA
>
> #######################################################################
>
> 2014-12-02T05:44:19Z DEBUG stderr=
>
> 2014-12-02T05:44:19Z CRITICAL failed to configure ca instance Command 
> '/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname 
> serverb.mydomain.com -cs_port 9445 -client_certdb_dir /tmp/tmp-1Tqws5 
> -client_certdb_pwd XXXXXXXX -preop_pin rdkE0y2CiGMKNcRRPKKc 
> -domain_name IPA -admin_user admin -admin_email root at localhost 
> -admin_password XXXXXXXX -agent_name ipa-ca-agent -agent_key_size 2048 
> -agent_key_type rsa -agent_cert_subject CN=ipa-ca-agent,O=MYDOMAIN.COM 
> -ldap_host serverb.mydomain.com -ldap_port 7389 -bind_dn cn=Directory 
> Manager -bind_password XXXXXXXX -base_dn o=ipaca -db_name ipaca 
> -key_size 2048 -key_type rsa -key_algorithm SHA256withRSA -save_p12 
> true -backup_pwd XXXXXXXX -subsystem_name pki-cad -token_name internal 
> -ca_subsystem_cert_subject_name CN=CA Subsystem,O=MYDOMAIN.COM 
> -ca_subsystem_cert_subject_name CN=CA Subsystem,O=MYDOMAIN.COM 
> -ca_ocsp_cert_subject_name CN=OCSP Subsystem,O=MYDOMAIN.COM 
> -ca_server_cert_subject_name CN=serverb.mydomain.com,O=MYDOMAIN.COM 
> -ca_audit_signing_cert_subject_name CN=CA Audit,O=MYDOMAIN.COM 
> -ca_sign_cert_subject_name CN=Certificate Authority,O=MYDOMAIN.COM 
> -external false -clone true -clone_p12_file ca.p12 -clone_p12_password 
> XXXXXXXX -sd_hostname servera.mydomain.com -sd_admin_port 443 
> -sd_admin_name admin -sd_admin_password XXXXXXXX -clone_start_tls true 
> -clone_uri https://servera.mydomain.com:443 
> <https://servera.mydomain.com:443>' returned non-zero exit status 255
>
> 2014-12-02T05:44:19Z INFO   File 
> "/usr/lib/python2.6/site-packages/ipaserver/install/installutils.py", 
> line 614, in run_script
>
>     return_value = main_function()
>
>   File "/usr/sbin/ipa-ca-install", line 149, in main
>
>     (CA, cs) = cainstance.install_replica_ca(config, postinstall=True)
>
>   File 
> "/usr/lib/python2.6/site-packages/ipaserver/install/cainstance.py", 
> line 1626, in install_replica_ca
>
>     subject_base=config.subject_base)
>
>   File 
> "/usr/lib/python2.6/site-packages/ipaserver/install/cainstance.py", 
> line 626, in configure_instance
>
>     self.start_creation(runtime=210)
>
>   File 
> "/usr/lib/python2.6/site-packages/ipaserver/install/service.py", line 
> 358, in start_creation
>
>     method()
>
>   File 
> "/usr/lib/python2.6/site-packages/ipaserver/install/cainstance.py", 
> line 888, in __configure_instance
>
>     raise RuntimeError('Configuration of CA failed')
>
> 2014-12-02T05:44:19Z INFO The ipa-ca-install command failed, 
> exception: RuntimeError: Configuration of CA failed
>
> =================
>
> I am not sure why this is happening.
>
> Certutil shows that the setup isn't complete on serverb when comparing 
> against the CA replica in my test servers which were successful.
>
> # certutil -L -d /var/lib/pki-ca/alias
>
> Certificate Nickname                                         Trust 
> Attributes
>
> SSL,S/MIME,JAR/XPI
>
> Certificate Authority - MYDOMAIN.COM                      CT,c,
>
> Server-Cert cert-pki-ca                                      CTu,Cu,Cu
>
> # certutil -K -d /var/lib/pki-ca/alias
>
> certutil: Checking token "NSS Certificate DB" in slot "NSS User 
> Private Key and Certificate Services"
>
> Enter Password or Pin for "NSS Certificate DB":
>
> < 0> rsa ef25de4fb656a27e297899509bc3dad582bcd643   NSS Certificate 
> DB:Server-Cert cert-pki-ca
>
> As yet, I have not tried "/usr/sbin/ipa-server-install --uninstall" in 
> an attempt to cleanup as this is a production server and apart from CA 
> replication, it is running fine. I have tried multiple times manually 
> removing pki instances and reinstalling but it still won't get past 
> the above error.
>
> Can anyone shed any light on this?
>
> Thanks in advance,
>
> Les
>
>
>


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141208/7b8e103f/attachment.htm>

From Less at imagine-sw.com  Tue Dec  9 07:48:30 2014
From: Less at imagine-sw.com (Les Stott)
Date: Tue, 9 Dec 2014 07:48:30 +0000
Subject: [Freeipa-users] CA Replication Installation Failing
In-Reply-To: <54867F51.1030603@redhat.com>
References: <4ED173A868981548967B4FCA270722262803F3C5@AACMBXP04.exchserver.com>
	<4ED173A868981548967B4FCA2707222628048DF6@AACMBXP04.exchserver.com>,
	<54867F51.1030603@redhat.com>
Message-ID: <4ED173A868981548967B4FCA2707222628049113@AACMBXP04.exchserver.com>


________________________________
From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Dmitri Pal [dpal at redhat.com]
Sent: Tuesday, December 09, 2014 3:49 PM
To: freeipa-users at redhat.com
Subject: Re: [Freeipa-users] CA Replication Installation Failing

On 12/08/2014 11:04 PM, Les Stott wrote:
Does anyone have any ideas on the below errors when trying to add CA replication to an existing replica?

> People who might be able to help are or PTO right now.
>
> Is your installation older than 2 years?

No, December 2013 was when it was originally built.

> Did you generate a new replica package or use the original one?

I used the original replica file for serverb, based on instructions i came across. I can try regenerating the replica file.

Interestingly, now that you mention it, servera had to be restored a couple of months back. Perhaps this is an issue and regenerating the replica file for serverb will be required.

I will try this.

> May be the problem is that the cert that is in that package already expired?

original replica file was created on Dec 16 2013. Cert is not set to expire until 2015-12-17.

> Just a thought...
>
> The simplest workaround IMO would be to prepare Server C, install it with CA and then decommission replica B.
> Do not forget to clean replication agreements on master.
>
> But that would be work around, would not solve this specific problem, it will kill it.

I actually do have serverc and serverd. I planned to have CA replication on at least 2 other servers, but held off on trying on serverc due to issues with serverb.

I'll report back what i find after regenerating the replica file and re-trying to setup CA replication.

Thanks,

Les


Thanks in advance,

Les

From: freeipa-users-bounces at redhat.com<mailto:freeipa-users-bounces at redhat.com> [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Les Stott
Sent: Tuesday, 2 December 2014 6:17 PM
To: freeipa-users at redhat.com<mailto:freeipa-users at redhat.com>
Subject: [Freeipa-users] CA Replication Installation Failing

Hi All,

I have RHEL6 with ipa servers running standard ipa server 3.0.0-42. Pki components are also standard version 9.0.3-38.

Servera is the master
Serverb is the replica

Both have been running for many, many months. Serverb was initially setup as a replica, but not a CA replica.

I am now trying to add CA Replication to serverb but it is failing midway through and I cannot figure out why.

Annoyingly, I used the same method/command to setup a CA replica on test servers and it completed without issue.

Here is what I get?.(for the sake of brevity, I am excluding the lines for connection check which were all OK)

=================
/usr/sbin/ipa-ca-install /var/lib/ipa/replica-info-serverb.mydomain.com.gpg
Directory Manager (existing master) password:
Get credentials to log in to remote master
admin at MYDOMAIN.COM<mailto:admin at MYDOMAIN.COM> password:
Execute check on remote master
Connection check OK
Configuring directory server for the CA (pkids): Estimated time 30 seconds
  [1/3]: creating directory server user
  [2/3]: creating directory server instance
  [3/3]: restarting directory server
Done configuring directory server for the CA (pkids).
Configuring certificate server (pki-cad): Estimated time 3 minutes 30 seconds
  [1/16]: creating certificate server user
  [2/16]: creating pki-ca instance
  [3/16]: configuring certificate server instance
ipa         : CRITICAL failed to configure ca instance Command '/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname serverb.mydomain.com -cs_port 9445 -client_certdb_dir /tmp/tmp-t3aHM7 -client_certdb_pwd XXXXXXXX -preop_pin exoyO2y7bawG5yjZMACM -domain_name IPA -admin_user admin -admin_email root at localhost -admin_password XXXXXXXX -agent_name ipa-ca-agent -agent_key_size 2048 -agent_key_type rsa -agent_cert_subject CN=ipa-ca-agent,O=MYDOMAIN.COM -ldap_host serverb.mydomain.com -ldap_port 7389 -bind_dn cn=Directory Manager -bind_password XXXXXXXX -base_dn o=ipaca -db_name ipaca -key_size 2048 -key_type rsa -key_algorithm SHA256withRSA -save_p12 true -backup_pwd XXXXXXXX -subsystem_name pki-cad -token_name internal -ca_subsystem_cert_subject_name CN=CA Subsystem,O=MYDOMAIN.COM -ca_subsystem_cert_subject_name CN=CA Subsystem,O=MYDOMAIN.COM -ca_ocsp_cert_subject_name CN=OCSP Subsystem,O=MYDOMAIN.COM -ca_server_cert_subject_name CN=serverb.mydomain.com,O=MYDOMAIN.COM -ca_audit_signing_cert_subject_name CN=CA Audit,O=MYDOMAIN.COM -ca_sign_cert_subject_name CN=Certificate Authority,O=MYDOMAIN.COM -external false -clone true -clone_p12_file ca.p12 -clone_p12_password XXXXXXXX -sd_hostname servera.mydomain.com -sd_admin_port 443 -sd_admin_name admin -sd_admin_password XXXXXXXX -clone_start_tls true -clone_uri https://servera.mydomain.com:443' returned non-zero exit status 255

Your system may be partly configured.
Run /usr/sbin/ipa-server-install --uninstall to clean up.

Configuration of CA failed
=================

Additional excerpt from the log file /var/log/ipareplica-ca-install.log at the point of failure?.

=================

#############################################
Attempting to connect to: serverb.mydomain.com:9445
Connected.
Posting Query = https://serverb.mydomain.com:9445//ca/admin/console/config/wizard?p=7&op=next&xml=true&__password=XXXXXXXX&path=ca.p12<https://serverb.mydomain.com:9445/ca/admin/console/config/wizard?p=7&op=next&xml=true&__password=XXXXXXXX&path=ca.p12>
RESPONSE STATUS:  HTTP/1.1 200 OK
RESPONSE HEADER:  Server: Apache-Coyote/1.1
RESPONSE HEADER:  Content-Type: application/xml;charset=UTF-8
RESPONSE HEADER:  Date: Tue, 02 Dec 2014 05:44:19 GMT
RESPONSE HEADER:  Connection: close
<?xml version="1.0" encoding="UTF-8"?>
<!-- BEGIN COPYRIGHT BLOCK
     This program is free software; you can redistribute it and/or modify
     it under the terms of the GNU General Public License as published by
     the Free Software Foundation; version 2 of the License.

     This program is distributed in the hope that it will be useful,
     but WITHOUT ANY WARRANTY; without even the implied warranty of
     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
     GNU General Public License for more details.

     You should have received a copy of the GNU General Public License along
     with this program; if not, write to the Free Software Foundation, Inc.,
     51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.

     Copyright (C) 2007 Red Hat, Inc.
     All rights reserved.
     END COPYRIGHT BLOCK -->
<response>
  <panel>admin/console/config/restorekeycertpanel.vm</panel>
  <res/>
  <updateStatus>failure</updateStatus>
  <password/>
  <errorString>The pkcs12 file is not correct.</errorString>
  <size>19</size>
  <title>Import Keys and Certificates</title>
  <panels>
    <Vector>
      <Panel>
        <Id>welcome</Id>
        <Name>Welcome</Name>
      </Panel>
      <Panel>
        <Id>module</Id>
        <Name>Key Store</Name>
      </Panel>
      <Panel>
        <Id>confighsmlogin</Id>
        <Name>ConfigHSMLogin</Name>
      </Panel>
      <Panel>
        <Id>securitydomain</Id>
        <Name>Security Domain</Name>
      </Panel>
      <Panel>
        <Id>securitydomain</Id>
        <Name>Display Certificate Chain</Name>
      </Panel>
      <Panel>
        <Id>subsystem</Id>
        <Name>Subsystem Type</Name>
      </Panel>
      <Panel>
        <Id>clone</Id>
        <Name>Display Certificate Chain</Name>
      </Panel>
      <Panel>
        <Id>restorekeys</Id>
        <Name>Import Keys and Certificates</Name>
      </Panel>
      <Panel>
        <Id>cahierarchy</Id>
        <Name>PKI Hierarchy</Name>
      </Panel>
      <Panel>
        <Id>database</Id>
        <Name>Internal Database</Name>
      </Panel>
      <Panel>
        <Id>size</Id>
        <Name>Key Pairs</Name>
      </Panel>
      <Panel>
        <Id>subjectname</Id>
        <Name>Subject Names</Name>
      </Panel>
      <Panel>
        <Id>certrequest</Id>
        <Name>Requests and Certificates</Name>
      </Panel>
      <Panel>
        <Id>backupkeys</Id>
        <Name>Export Keys and Certificates</Name>
      </Panel>
      <Panel>
        <Id>savepk12</Id>
        <Name>Save Keys and Certificates</Name>
      </Panel>
      <Panel>
        <Id>importcachain</Id>
        <Name>Import CA's Certificate Chain</Name>
      </Panel>
      <Panel>
        <Id>admin</Id>
        <Name>Administrator</Name>
      </Panel>
      <Panel>
        <Id>importadmincert</Id>
        <Name>Import Administrator's Certificate</Name>
      </Panel>
      <Panel>
        <Id>done</Id>
        <Name>Done</Name>
      </Panel>
    </Vector>
  </panels>
  <name>CA Setup Wizard</name>
  <p>7</p>
  <path/>
  <req/>
  <panelname>restorekeys</panelname>
</response>
Error in RestoreKeyCertPanel(): updateStatus returns failure
ERROR: ConfigureCA: RestoreKeyCertPanel() failure
ERROR: unable to create CA

#######################################################################
2014-12-02T05:44:19Z DEBUG stderr=
2014-12-02T05:44:19Z CRITICAL failed to configure ca instance Command '/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname serverb.mydomain.com -cs_port 9445 -client_certdb_dir /tmp/tmp-1Tqws5 -client_certdb_pwd XXXXXXXX -preop_pin rdkE0y2CiGMKNcRRPKKc -domain_name IPA -admin_user admin -admin_email root at localhost -admin_password XXXXXXXX -agent_name ipa-ca-agent -agent_key_size 2048 -agent_key_type rsa -agent_cert_subject CN=ipa-ca-agent,O=MYDOMAIN.COM -ldap_host serverb.mydomain.com -ldap_port 7389 -bind_dn cn=Directory Manager -bind_password XXXXXXXX -base_dn o=ipaca -db_name ipaca -key_size 2048 -key_type rsa -key_algorithm SHA256withRSA -save_p12 true -backup_pwd XXXXXXXX -subsystem_name pki-cad -token_name internal -ca_subsystem_cert_subject_name CN=CA Subsystem,O=MYDOMAIN.COM -ca_subsystem_cert_subject_name CN=CA Subsystem,O=MYDOMAIN.COM -ca_ocsp_cert_subject_name CN=OCSP Subsystem,O=MYDOMAIN.COM -ca_server_cert_subject_name CN=serverb.mydomain.com,O=MYDOMAIN.COM -ca_audit_signing_cert_subject_name CN=CA Audit,O=MYDOMAIN.COM -ca_sign_cert_subject_name CN=Certificate Authority,O=MYDOMAIN.COM -external false -clone true -clone_p12_file ca.p12 -clone_p12_password XXXXXXXX -sd_hostname servera.mydomain.com -sd_admin_port 443 -sd_admin_name admin -sd_admin_password XXXXXXXX -clone_start_tls true -clone_uri https://servera.mydomain.com:443' returned non-zero exit status 255
2014-12-02T05:44:19Z INFO   File "/usr/lib/python2.6/site-packages/ipaserver/install/installutils.py", line 614, in run_script
    return_value = main_function()

  File "/usr/sbin/ipa-ca-install", line 149, in main
    (CA, cs) = cainstance.install_replica_ca(config, postinstall=True)

  File "/usr/lib/python2.6/site-packages/ipaserver/install/cainstance.py", line 1626, in install_replica_ca
    subject_base=config.subject_base)

  File "/usr/lib/python2.6/site-packages/ipaserver/install/cainstance.py", line 626, in configure_instance
    self.start_creation(runtime=210)

  File "/usr/lib/python2.6/site-packages/ipaserver/install/service.py", line 358, in start_creation
    method()

  File "/usr/lib/python2.6/site-packages/ipaserver/install/cainstance.py", line 888, in __configure_instance
    raise RuntimeError('Configuration of CA failed')

2014-12-02T05:44:19Z INFO The ipa-ca-install command failed, exception: RuntimeError: Configuration of CA failed

=================

I am not sure why this is happening.

Certutil shows that the setup isn?t complete on serverb when comparing against the CA replica in my test servers which were successful.

# certutil -L -d /var/lib/pki-ca/alias

Certificate Nickname                                         Trust Attributes
                                                             SSL,S/MIME,JAR/XPI

Certificate Authority - MYDOMAIN.COM                      CT,c,
Server-Cert cert-pki-ca                                      CTu,Cu,Cu

# certutil -K -d /var/lib/pki-ca/alias
certutil: Checking token "NSS Certificate DB" in slot "NSS User Private Key and Certificate Services"
Enter Password or Pin for "NSS Certificate DB":
< 0> rsa      ef25de4fb656a27e297899509bc3dad582bcd643   NSS Certificate DB:Server-Cert cert-pki-ca


As yet, I have not tried ?/usr/sbin/ipa-server-install ?uninstall? in an attempt to cleanup as this is a production server and apart from CA replication, it is running fine. I have tried multiple times manually removing pki instances and reinstalling but it still won?t get past the above error.

Can anyone shed any light on this?

Thanks in advance,

Les









--
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141209/4382b937/attachment.htm>

From pspacek at redhat.com  Tue Dec  9 08:50:34 2014
From: pspacek at redhat.com (Petr Spacek)
Date: Tue, 09 Dec 2014 09:50:34 +0100
Subject: [Freeipa-users] DNS configuration
In-Reply-To: <CABhyZ35Mi1P8J9pzF-q1Uh_dRES52xqBuQggDw5-m70XxaZN-Q@mail.gmail.com>
References: <CABhyZ34TCzUz+fNUSCvdZ38MS7rsLMMdb_jTdfKUsmYs86fn_Q@mail.gmail.com>	<547DEA9E.2030203@redhat.com>
	<547DEFB5.1020205@redhat.com>	<CABhyZ347EU+Q85jQJGU30yx4njC3OtL_QsJZi1MMu1ZR2Lfd2Q@mail.gmail.com>	<547E851C.1020407@redhat.com>
	<547ECDDC.3090001@redhat.com>	<CABhyZ37XChaQF+4rRY-L=OU9pVNp7Mw_NQifTk3NhrewzJtyVQ@mail.gmail.com>	<5485108E.60409@redhat.com>	<CABhyZ36DDM6icM+haMbVErdVdDWonGqbPE+3Tpad4K=u9QHjAQ@mail.gmail.com>	<54851385.3050709@redhat.com>	<CABhyZ36D_SVLezC=wZ3tsYHn00tdBGsxpOxCtpVgWZo8EdH2hw@mail.gmail.com>	<548522B8.8040805@redhat.com>
	<5485599E.8030801@redhat.com>	<CABhyZ34Pbr4J6YDdLSmP=qPqAB7Pa=tWvw273aB-BNX4dRq-GQ@mail.gmail.com>	<5485C698.9000406@redhat.com>	<CABhyZ35qsCM0y8anFdqE7r60Fz8LAU8Yx3WWaF6zBhfg=dRUJA@mail.gmail.com>	<CABhyZ34exwjj4o8RRu651w2kik96wMS3Y6dvEk14MG1Y+LkY9w@mail.gmail.com>
	<CABhyZ35Mi1P8J9pzF-q1Uh_dRES52xqBuQggDw5-m70XxaZN-Q@mail.gmail.com>
Message-ID: <5486B7DA.7050909@redhat.com>

On 8.12.2014 20:27, Matthew Herzog wrote:
> OK, I found the generated zoe file in /tmp and it looks sane.
> Should I add those lines of config to our DNS servers?

Yes, exactly. After that you can proceed with AD trust establishment.

BTW ipa-server-install tells you where the file with message:
"Sample zone file for bind has been created in ..."

I just checked IPA 3.3.x and the message is really there :-)

Have a nice day!

Petr^2 Spacek

> 
> On Mon, Dec 8, 2014 at 2:10 PM, Matthew Herzog <matthew.herzog at gmail.com>
> wrote:
> 
>> Here are some errors I'm seeing on the client.
>>
>> tail -f sssd_lnx.e-bozo.com.log
>> (Mon Dec  8 14:03:20 2014) [sssd[be[lnx.e-bozo.com]]] [sbus_dispatch]
>> (0x4000): dbus conn: 0x1e72ad0
>> (Mon Dec  8 14:03:20 2014) [sssd[be[lnx.e-bozo.com]]] [sbus_dispatch]
>> (0x4000): Dispatching.
>> (Mon Dec  8 14:03:20 2014) [sssd[be[lnx.e-bozo.com]]]
>> [sbus_message_handler] (0x4000): Received SBUS method [ping]
>> (Mon Dec  8 14:03:20 2014) [sssd[be[lnx.e-bozo.com]]]
>> [sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit
>> (Mon Dec  8 14:03:20 2014) [sssd[be[lnx.e-bozo.com]]]
>> [sbus_handler_got_caller_id] (0x4000): Received SBUS method [ping]
>> (Mon Dec  8 14:03:30 2014) [sssd[be[lnx.e-bozo.com]]] [sbus_dispatch]
>> (0x4000): dbus conn: 0x1e72ad0
>> (Mon Dec  8 14:03:30 2014) [sssd[be[lnx.e-bozo.com]]] [sbus_dispatch]
>> (0x4000): Dispatching.
>> (Mon Dec  8 14:03:30 2014) [sssd[be[lnx.e-bozo.com]]]
>> [sbus_message_handler] (0x4000): Received SBUS method [ping]
>> (Mon Dec  8 14:03:30 2014) [sssd[be[lnx.e-bozo.com]]]
>> [sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit
>> (Mon Dec  8 14:03:30 2014) [sssd[be[lnx.e-bozo.com]]]
>> [sbus_handler_got_caller_id] (0x4000): Received SBUS method [ping]
>> (Mon Dec  8 14:03:40 2014) [sssd[be[lnx.e-bozo.com]]] [sbus_dispatch]
>> (0x4000): dbus conn: 0x1e72ad0
>> (Mon Dec  8 14:03:40 2014) [sssd[be[lnx.e-bozo.com]]] [sbus_dispatch]
>> (0x4000): Dispatching.
>>
>> [root at freeipa-poc-client02 sssd]# tail -f sssd_ssh.log
>> (Sun Dec  7 19:32:09 2014) [sssd[ssh]] [ssh_process_init] (0x0010):
>> sss_process_init() failed
>> (Sun Dec  7 19:32:09 2014) [sssd[ssh]] [sss_dp_init] (0x0010): Failed to
>> connect to monitor services.
>> (Sun Dec  7 19:32:09 2014) [sssd[ssh]] [sss_process_init] (0x0010): fatal
>> error setting up backend connector
>> (Sun Dec  7 19:32:09 2014) [sssd[ssh]] [ssh_process_init] (0x0010):
>> sss_process_init() failed
>> (Sun Dec  7 19:32:16 2014) [sssd[ssh]] [sss_dp_init] (0x0010): Failed to
>> connect to monitor services.
>> (Sun Dec  7 19:32:16 2014) [sssd[ssh]] [sss_process_init] (0x0010): fatal
>> error setting up backend connector
>> (Sun Dec  7 19:32:16 2014) [sssd[ssh]] [ssh_process_init] (0x0010):
>> sss_process_init() failed
>> (Sun Dec  7 19:32:16 2014) [sssd[ssh]] [sss_dp_init] (0x0010): Failed to
>> connect to monitor services.
>> (Sun Dec  7 19:32:16 2014) [sssd[ssh]] [sss_process_init] (0x0010): fatal
>> error setting up backend connector
>> (Sun Dec  7 19:32:16 2014) [sssd[ssh]] [ssh_process_init] (0x0010):
>> sss_process_init() failed
>>
>>
>> On Mon, Dec 8, 2014 at 11:48 AM, Matthew Herzog <matthew.herzog at gmail.com>
>> wrote:
>>
>>> I have never seen my IPA servers produce a zone file nor has the install
>>> script ever mentioned the creation of such. In fact, I just ran
>>> ipa-server-install --uninstall && ipa-server-install and there was no
>>> mention of a zone file.
>>>
>>> Where should I look in the file system to be sure? I see nothing in
>>> /var/named. I'm using 3.3.3 IPA on Oracle Linux from Oracle's yum repo.
>>> (Not my choice.)
>>>
>>> dsee7 is *not *running Kerberos. dsee7 is *not *configured with SRV
>>> records. I guess I'll need to add SRV records for all my Linux hosts.
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Mon, Dec 8, 2014 at 10:41 AM, Petr Spacek <pspacek at redhat.com> wrote:
>>>
>>>> On 8.12.2014 14:44, Matthew Herzog wrote:
>>>>> Petr said, "You can run ipa-server-install *without* --setup-dns
>>>> option and
>>>>> at the end of
>>>>> installation it will produce DNS records which you have to manually
>>>> add to
>>>>> your existing DNS database."
>>>>>
>>>>> I can't see how this would be useful or which machines I would need to
>>>> add
>>>>> to our DNS.
>>>>>
>>>>> Perhaps I should have explained that we are not going to set up a new
>>>> DNS
>>>>> domain for the ipa-managed servers.
>>>> Good.
>>>>
>>>> Now you should run ipa-server-install *without* --setup-dns, using
>>>> lnx.e-bozo.com as you IPA domain. It will install full IPA server and
>>>> spit out
>>>> DNS zone file.
>>>>
>>>> Then you *have to* take this zone file and import it to your existing DNS
>>>> infrastructure - that will give you fully functional IPA domain
>>>> lnx.e-bozo.com.
>>>>
>>>> Caveat:
>>>> Preceding text assumes that 'dsee7' is nor using either Kerberos nor DNS
>>>> SRV
>>>> records for LDAP service in domain lnx.e-bozo.com, i.e. clients
>>>> connecting to
>>>> DSEE7 should be (most likely) statically configured with DSEE7 server
>>>> name.
>>>>
>>>> Petr^2 Spacek
>>>>
>>>>> We have an Oracle dsee7 server doing
>>>>> LDAP for our Linux servers and accounts. We want to migrate to IPA so
>>>> we
>>>>> don't have to maintain a Linux/LDAP account for every user who needs
>>>> access
>>>>> to Linux servers. All of our users start with an account in AD and
>>>> since
>>>>> none of my predecessors knew about Winbind, they set up dsee7.
>>>>>
>>>>> So I'm thinking we'll need to import all our dsee7 accounts AND make it
>>>>> possible for AD users to access the Linux systems without needing to
>>>> create
>>>>> them in IPA.
>>>>>
>>>>> On Mon, Dec 8, 2014 at 2:56 AM, Petr Spacek <pspacek at redhat.com>
>>>> wrote:
>>>>>
>>>>>> On 8.12.2014 05:02, Dmitri Pal wrote:
>>>>>>> On 12/07/2014 10:10 PM, Matthew Herzog wrote:
>>>>>>>> So should the FreeIPA server be authoritative for the Kerb.
>>>> realm/DNS
>>>>>> domain
>>>>>>>> or can it/should it be a slave DNS server instead? Or caching only?
>>>>>>>
>>>>>>> IPA DNS can't be a slave so you either delegate a whole zone to it or
>>>>>> manage
>>>>>>> IPA DNS domain via your own DNS server.
>>>>>>
>>>>>> Generally, "slave" is not allowed to do any changes so it is useless
>>>> in
>>>>>> your
>>>>>> scenario.
>>>>>>
>>>>>> You can run ipa-server-install *without* --setup-dns option and at
>>>> the end
>>>>>> of
>>>>>> installation it will produce DNS records which you have to manually
>>>> add to
>>>>>> your existing DNS database.
>>>>>>
>>>>>> Did you try that?
>>>>>>
>>>>>> Petr^2 Spacek
>>>>>>
>>>>>>>> On Sun, Dec 7, 2014 at 9:57 PM, Dmitri Pal <dpal at redhat.com
>>>>>>>> <mailto:dpal at redhat.com>> wrote:
>>>>>>>>
>>>>>>>>     On 12/07/2014 09:51 PM, Matthew Herzog wrote:
>>>>>>>>>     What must be done in or on the ipa server with regard to DNS,
>>>> if
>>>>>>>>>     anything?
>>>>>>>>>
>>>>>>>>>     Our DNS works. It works well. We have four Linux DNS servers
>>>> and
>>>>>>>>>     two AD domain controllers that also do DNS.
>>>>>>>>>
>>>>>>>>>     So if we already have DNS working well in our domain, why do we
>>>>>>>>>     want to manage DNS in IPA?
>>>>>>>>
>>>>>>>>     Let us keep the discussion on the list.
>>>>>>>>     IPA when used with AD trust presents itself as a separate
>>>> forest.
>>>>>>>>     AD thinks that it is working with another AD forest.
>>>>>>>>     For that to work we need to follow MSFT rules about relationship
>>>>>>>>     between Kerberos realm and DNS domain.
>>>>>>>>     AD assumes that for every trusted forest Kerberos realm = DNS
>>>>>>>>     domain. IPA makes it easy to do because it has integrated tools
>>>> to
>>>>>>>>     manage IPA DNS domain.
>>>>>>>>     If you want to manage it yourself through your DNS you can do
>>>> it,
>>>>>>>>     just more manual operations for you.
>>>>>>>>
>>>>>>>>     HTH
>>>>>>>>
>>>>>>>>     Thanks
>>>>>>>>     Dmitri
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>     On Sun, Dec 7, 2014 at 9:44 PM, Dmitri Pal <dpal at redhat.com
>>>>>>>>>     <mailto:dpal at redhat.com>> wrote:
>>>>>>>>>
>>>>>>>>>         On 12/07/2014 06:44 PM, Matthew Herzog wrote:
>>>>>>>>>>         Thanks guys. I'm sorry for my delay in responding.
>>>>>>>>>>
>>>>>>>>>>         Firstly, I was under the impression (from reading the
>>>> docs)
>>>>>>>>>>         that having named running on IPA server was critical.
>>>>>>>>>
>>>>>>>>>         Properly configured DNS is critical.
>>>>>>>>>         How you accomplish it is up to you.
>>>>>>>>>         IPA allows you to have a DNS server that would simplify DNS
>>>>>>>>>         management but it can be done manually too. This is why DNS
>>>>>>>>>         is optional.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>         Also, the first question the ipa-server-install script
>>>> asks
>>>>>>>>>>         is, "Do you want to configure integrated DNS (BIND)? ."
>>>>>>>>>>         While it's true the default answer is no, it leads one to
>>>>>>>>>>         believe that DNS is central to IPA. Also the
>>>>>>>>>>         ipa-client-install script says,
>>>>>>>>>>
>>>>>>>>>>         [root at freeipa-poc-client02 ~]# ipa-client-install
>>>>>>>>>>         DNS discovery failed to determine your DNS domain
>>>>>>>>>>         Provide the domain name of your IPA server (ex:
>>>> example.com
>>>>>>>>>>         <http://example.com>):
>>>>>>>>>>
>>>>>>>>>>         I can resolve -anything- from the machine using dig or
>>>>>> whatever.
>>>>>>>>>>
>>>>>>>>>>         Ultimately, the reason I started to be concerned about my
>>>>>>>>>>         IPA server's DNS config was because I was not able to
>>>>>>>>>>         authenticate AD accounts to a client machine. I saw a
>>>> bunch
>>>>>>>>>>         of errors in the client's sssd logs which of course I
>>>> can't
>>>>>>>>>>         find now.
>>>>>>>>>>
>>>>>>>>>>         Perhaps it was these . . .
>>>>>>>>>>
>>>>>>>>>>         (Thu Dec  4 13:45:23 2014) [sssd] [ping_check] (0x0100):
>>>>>>>>>>         Service nss replied to ping
>>>>>>>>>>         (Thu Dec  4 13:45:23 2014) [sssd] [ping_check] (0x0100):
>>>>>>>>>>         Service sudo replied to ping
>>>>>>>>>>         (Thu Dec  4 13:45:23 2014) [sssd] [ping_check] (0x0100):
>>>>>>>>>>         Service pam replied to ping
>>>>>>>>>>         (Thu Dec  4 13:45:23 2014) [sssd] [ping_check] (0x0100):
>>>>>>>>>>         Service ssh replied to ping
>>>>>>>>>>         (Thu Dec  4 13:45:23 2014) [sssd] [ping_check] (0x0100):
>>>>>>>>>>         Service pac replied to ping
>>>>>>>>>>         (Thu Dec  4 13:45:23 2014) [sssd] [ping_check] (0x0100):
>>>>>>>>>>         Service bo3.e-bozo.com <http://bo3.e-bozo.com> replied to
>>>>>> ping
>>>>>>>>>>
>>>>>>>>>>         I'm not allowed onto the AD domain controllers to examine
>>>>>>>>>>         log files or I'd be checking those first.
>>>>>>>>>>
>>>>>>>>>>         So ultimately the goal is to authenticate AD users and
>>>> users
>>>>>>>>>>         that exist in our ldap schema. We need to set up groups of
>>>>>>>>>>         users that can run sudo commands on specific groups of
>>>> hosts.
>>>>>>>>>
>>>>>>>>>         Did you setup trusts as explained on the following page?
>>>>>>>>>         http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>         On Wed, Dec 3, 2014 at 3:46 AM, Petr Spacek
>>>>>>>>>>         <pspacek at redhat.com <mailto:pspacek at redhat.com>> wrote:
>>>>>>>>>>
>>>>>>>>>>             On 3.12.2014 04:35, Dmitri Pal wrote:
>>>>>>>>>>             > On 12/02/2014 08:54 PM, Matthew Herzog wrote:
>>>>>>>>>>             >> Any other ideas? I just spun up a new VM and took
>>>> the
>>>>>>>>>>             defaults on everything
>>>>>>>>>>             >> while running ipa-server-install (the defaults did
>>>>>>>>>>             make sense) and my new VM
>>>>>>>>>>             >> can't resolve -anything- in the domain in which it
>>>>>>>>>>             lives. The "old" VM
>>>>>>>>>>             >> (running the same versions of everything on the
>>>> same
>>>>>>>>>>             OS) can't even resolve
>>>>>>>>>>             >> the clients I have registered with it!
>>>>>>>>>>             >>
>>>>>>>>>>             >> So I'm pretty frustrated and am wondering, what
>>>>>>>>>>             _exactly_ is the role of
>>>>>>>>>>             >> bind in the IPA server and how is it expected to
>>>> know
>>>>>>>>>>             anything about the
>>>>>>>>>>             >> local DNS domain without becoming a bind slave
>>>> server?
>>>>>>>>>>             >
>>>>>>>>>>             > I am not sure I am 100% with you but...
>>>>>>>>>>             > If you use the defaults and nothing else you get to
>>>>>>>>>>             the scenario when IPA has
>>>>>>>>>>             > its DNS but it is a self contained environment. It
>>>>>>>>>>             seems that this is what you
>>>>>>>>>>             > observe.
>>>>>>>>>>             > It is expected that you decide in advance what you
>>>>>>>>>>             want to do with DNS. There
>>>>>>>>>>             > are several options:
>>>>>>>>>>             > 1) You can delegate a zone to IPA to manage, then
>>>> you
>>>>>>>>>>             need to connect your IPA
>>>>>>>>>>             > DNS to your existing DNS during install or after.
>>>>>>>>>>             > In this case the systems joined to IPA will be a
>>>> part
>>>>>>>>>>             of IPA domain/zone and
>>>>>>>>>>             > would also be able to resolve other systems around
>>>>>>>>>>             > 2) Not use IPA DNS if you do not want to take
>>>>>>>>>>             advantage of it
>>>>>>>>>>             > 3) Have a self contained demo/lab environment that
>>>> you
>>>>>>>>>>             currently observe.
>>>>>>>>>>             >
>>>>>>>>>>             > What is the intent?
>>>>>>>>>>
>>>>>>>>>>             I agree with Dmitri, we need more information from
>>>> you:
>>>>>>>>>>             - You said "my new VM can't resolve -anything- in the
>>>>>>>>>>             domain in which it
>>>>>>>>>>             lives." - Which domain do you mean?
>>>>>>>>>>
>>>>>>>>>>             - Apparently you have configured FreeIPA to serve zone
>>>>>>>>>>             e-bozo.com <http://e-bozo.com>. Do you have
>>>>>>>>>>             this zone configured on some other DNS server at the
>>>>>>>>>>             same time?
>>>>>>>>>>
>>>>>>>>>>             Please keep in mind that authoritative servers should
>>>>>>>>>>             share the database. You
>>>>>>>>>>             will get naming collisions if e-bozo.com
>>>>>>>>>>             <http://e-bozo.com> is served by FreeIPA DNS servers
>>>> and
>>>>>>>>>>             some other servers at the same time. Maybe that is the
>>>>>>>>>>             problem you see right now.
>>>>>>>>>>
>>>>>>>>>>             As Dmitri said, the architecturally correct solution
>>>> is
>>>>>>>>>>             to decide if you want
>>>>>>>>>>             to use FreeIPA DNS or not. You have option to either
>>>>>>>>>>             remove non-FreeIPA DNS
>>>>>>>>>>             servers and import data to FreeIPA or to add
>>>>>>>>>>             FreeIPA-specific DNS records to
>>>>>>>>>>             existing DNS servers and do not configure FreeIPA to
>>>> act
>>>>>>>>>>             as DNS server.
>>>>>>>>>>
>>>>>>>>>>             Petr^2 Spacek
>>>>>>>>>>
>>>>>>>>>>             >> Thanks.
>>>>>>>>>>             >>
>>>>>>>>>>             >> On Tue, Dec 2, 2014 at 11:58 AM, Petr Spacek
>>>>>>>>>>             <pspacek at redhat.com <mailto:pspacek at redhat.com>
>>>>>>>>>>             >> <mailto:pspacek at redhat.com
>>>>>>>>>>             <mailto:pspacek at redhat.com>>> wrote:
>>>>>>>>>>             >>
>>>>>>>>>>             >>     On 2.12.2014 17:36, Martin Basti wrote:
>>>>>>>>>>             >>     > On 02/12/14 17:28, Matthew Herzog wrote:
>>>>>>>>>>             >>     >> I just realized that my IPA servers cannot
>>>>>>>>>>             resolve ANY servers
>>>>>>>>>>             >>     in my domain.
>>>>>>>>>>             >>     >> What do I need to do to fix this? Below is
>>>> my
>>>>>>>>>>             named.conf.
>>>>>>>>>>             >>     >>
>>>>>>>>>>             >>     >>
>>>>>>>>>>             >>     >> options {
>>>>>>>>>>             >>     >>  // turns on IPv6 for port 53, IPv4 is on by
>>>>>>>>>>             default for
>>>>>>>>>>             >>     all ifaces
>>>>>>>>>>             >>     >>  listen-on-v6 {any;};
>>>>>>>>>>             >>     >>
>>>>>>>>>>             >>     >>  // Put files that named is allowed to write
>>>>>>>>>>             in the
>>>>>>>>>>             >>     data/ directory:
>>>>>>>>>>             >>     >>  directory "/var/named"; // the default
>>>>>>>>>>             >>     >>  dump-file "data/cache_dump.db";
>>>>>>>>>>             >>     >>  statistics-file "data/named_stats.txt";
>>>>>>>>>>             >>     >>  memstatistics-file
>>>> "data/named_mem_stats.txt";
>>>>>>>>>>             >>     >>
>>>>>>>>>>             >>     >>  forward first;
>>>>>>>>>>             >>     >>  forwarders {
>>>>>>>>>>             >>     >>          10.100.8.41;
>>>>>>>>>>             >>     >>          10.100.8.40;
>>>>>>>>>>             >>     >>          10.100.4.13;
>>>>>>>>>>             >>     >>          10.100.4.14;
>>>>>>>>>>             >>     >>          10.100.4.19;
>>>>>>>>>>             >>     >>          10.100.4.44;
>>>>>>>>>>             >>     >>  };
>>>>>>>>>>             >>     >>
>>>>>>>>>>             >>     >>  // Any host is permitted to issue recursive
>>>>>>>>>>             queries
>>>>>>>>>>             >>     >>  allow-recursion { any; };
>>>>>>>>>>             >>     >>
>>>>>>>>>>             >>     >>  tkey-gssapi-keytab "/etc/named.keytab";
>>>>>>>>>>             >>     >>  pid-file "/run/named/named.pid";
>>>>>>>>>>             >>     >> };
>>>>>>>>>>             >>     >>
>>>>>>>>>>             >>     >> /* If you want to enable debugging, eg.
>>>> using
>>>>>>>>>>             the 'rndc trace'
>>>>>>>>>>             >>     command,
>>>>>>>>>>             >>     >>  * By default, SELinux policy does not allow
>>>>>>>>>>             named to modify
>>>>>>>>>>             >>     the /var/named
>>>>>>>>>>             >>     >> directory,
>>>>>>>>>>             >>     >>  * so put the default debug log file in
>>>> data/ :
>>>>>>>>>>             >>     >>  */
>>>>>>>>>>             >>     >> logging {
>>>>>>>>>>             >>     >>  channel default_debug {
>>>>>>>>>>             >>     >>          file "data/named.run";
>>>>>>>>>>             >>     >>          severity dynamic;
>>>>>>>>>>             >>     >>          print-time yes;
>>>>>>>>>>             >>     >>  };
>>>>>>>>>>             >>     >>  };
>>>>>>>>>>             >>     >> };
>>>>>>>>>>             >>     >>
>>>>>>>>>>             >>     >> zone "." IN {
>>>>>>>>>>             >>     >>  type hint;
>>>>>>>>>>             >>     >>  file "named.ca <http://named.ca>
>>>>>>>>>>             <http://named.ca> <http://named.ca>";
>>>>>>>>>>             >>     >> };
>>>>>>>>>>             >>     >>
>>>>>>>>>>             >>     >> include "/etc/named.rfc1912.zones";
>>>>>>>>>>             >>     >>
>>>>>>>>>>             >>     >> dynamic-db "ipa" {
>>>>>>>>>>             >>     >>  library "ldap.so";
>>>>>>>>>>             >>     >>  arg "uri
>>>>>>>>>>             >>
>>>> ldapi://%2fvar%2frun%2fslapd-BO3-E-BOZO-COM.socket";
>>>>>>>>>>             >>     >>  arg "base cn=dns, dc=bo3,dc=e-bozo,dc=com";
>>>>>>>>>>             >>     >>  arg "fake_mname
>>>> freeipa-poc01.bo3.e-bozo.com
>>>>>>>>>>             <http://freeipa-poc01.bo3.e-bozo.com>
>>>>>>>>>>             >>     <http://freeipa-poc01.bo3.e-bozo.com>
>>>>>>>>>>             >>     >> <http://freeipa-poc01.bo3.e-bozo.com>.";
>>>>>>>>>>             >>     >>  arg "auth_method sasl";
>>>>>>>>>>             >>     >>  arg "sasl_mech GSSAPI";
>>>>>>>>>>             >>     >>  arg "sasl_user
>>>>>>>>>>             DNS/freeipa-poc01.bo3.e-bozo.com
>>>>>>>>>>             <http://freeipa-poc01.bo3.e-bozo.com>
>>>>>>>>>>             >>     <http://freeipa-poc01.bo3.e-bozo.com>
>>>>>>>>>>             >>     >> <http://freeipa-poc01.bo3.e-bozo.com>";
>>>>>>>>>>             >>     >>  arg "serial_autoincrement yes";
>>>>>>>>>>             >>     >> };
>>>>>>>>>>             >>     >>
>>>>>>>>>>             >>     >>
>>>>>>>>>>             >>     >>
>>>>>>>>>>             >>     >>
>>>>>>>>>>             >>     > Hello,
>>>>>>>>>>             >>     >
>>>>>>>>>>             >>     > which version ipa do you use? which platform?
>>>>>>>>>>             Which version
>>>>>>>>>>             >>     bind-dyndb-ldap?
>>>>>>>>>>             >>     >
>>>>>>>>>>             >>     > Can you run these commands, and check if
>>>> there
>>>>>>>>>>             any errors?
>>>>>>>>>>             >>     > ipactl status
>>>>>>>>>>             >>     > systemctl status named  (respectively
>>>>>>>>>>             journalctl -u named)
>>>>>>>>>>             >>
>>>>>>>>>>             >>     We also may want to see information listed on
>>>> page
>>>>>>>>>>             >>
>>>>>>>>>>
>>>>>> https://fedorahosted.org/bind-dyndb-ldap/wiki/BugReporting


-- 
Petr^2 Spacek



From pspacek at redhat.com  Tue Dec  9 08:56:17 2014
From: pspacek at redhat.com (Petr Spacek)
Date: Tue, 09 Dec 2014 09:56:17 +0100
Subject: [Freeipa-users] vSphere 5.1 and FreeIPA 3.3 on CentOS 7 finally
 works! [How I did it...]
In-Reply-To: <548653A7.3070102@redhat.com>
References: <CAG2kNCyXWXxMx0V96bYgMq--9zaBwhWMBENrOgSXnMMr9=F85Q@mail.gmail.com>	<5485E119.10203@redhat.com>	<CAG2kNCyWUhbVZUbpo0rgE_NAucs5S4x6_dj4JcCXTNWyLNSAFw@mail.gmail.com>	<CAG2kNCyj=b4c-5C59uvba37hoXwX8rHmtE9DC1vbKk+YM5p1ZQ@mail.gmail.com>
	<548653A7.3070102@redhat.com>
Message-ID: <5486B931.4030001@redhat.com>

On 9.12.2014 02:43, Dmitri Pal wrote:
> On 12/08/2014 06:50 PM, Gianluca Cecchi wrote:
>> On Mon, Dec 8, 2014 at 7:17 PM, Gianluca Cecchi <gianluca.cecchi at gmail.com
>> <mailto:gianluca.cecchi at gmail.com>> wrote:
>>
>>     OK. I will check requirements to write into The wiki
>>
>>
>>
>> When I try to login with my Fedora OpenID account and choose as nickname my
>> real name and press "login" actually it indefinitely remains on the blank page
>> http://www.freeipa.org/page/Special:OpenIDLogin/ChooseName
>>
>> without enabling me to log in and begin to write anything.
>> Tried from both Chrome and Fedora (on my Fedora 20 system)....
>> Similar problems when I used to use zanata to write oVirt Italian
>> translation, but in that case with some difficulty I finally was able then
>> to log in and begin to work... no way here
>>
>> This OpenID thing doesn't seem very usable in my opinion...
>>
>> Gianluca
>>
> 
> Do you manage to pass the Fedora OpenID prompt?
> Are you authenticating with  "giallu<https://giallu.fedorapeople.org>" login?
> Is it on the redirect from fedora to wiki when you are stuck or it is some
> other point of the sequence?

You can try to log-in into Fedora Notifications for example, just to make sure
that your account works:
https://apps.fedoraproject.org/notifications/

-- 
Petr^2 Spacek



From mkosek at redhat.com  Tue Dec  9 09:01:50 2014
From: mkosek at redhat.com (Martin Kosek)
Date: Tue, 09 Dec 2014 10:01:50 +0100
Subject: [Freeipa-users] [Freeipa-interest] Announcing FreeIPA 4.1.2 -
 NEED HELP WITH 2FA/OTP!!!
In-Reply-To: <54845DA3.3070104@redhat.com>
References: <54775877.6060102@redhat.com>	<176433463.23902008.1417805679430.JavaMail.zimbra@redhat.com>
	<54845DA3.3070104@redhat.com>
Message-ID: <5486BA7E.90100@redhat.com>

On 12/07/2014 03:01 PM, Niranjan M.R wrote:
> On 12/06/2014 12:24 AM, Dmitri Pal wrote:
>> Hello,
> 
>> WE NEED HELP!
> 
>> The biggest and the most interesting feature of FreeIPA 4.1.2 is support for the two factor authentication using HOTP/TOTP compatible software tokens like FreeOTP (open source compatible alternative to Google Authenticator) and hardware tokens like Yubikeys. This feature allows Kerberos and LDAP clients of a FreeIPA server to authenticate using the normal account password as the first factor and an OTP token as a second factor. For those environments where a 2FA solution is already in place, FreeIPA can act as a proxy via RADIUS. More about this feature can be read here.
>> http://www.freeipa.org/page/V4/OTP
> 
>> If you want to see this feature in downstream distros sooner rather than later we need your help!
>> Please give it a try and provide feedback. We really, really need it!
> I am unable to configure ipa-server with freeipa-server-4.1.2-1.fc20.x86_64,  ipa-server-install fails with below error:
> 
> Done configuring certificate server (pki-tomcatd).
> Configuring directory server (dirsrv): Estimated time 10 seconds
>   [1/3]: configuring ssl for ds instance
>   [2/3]: restarting directory server
> ipa         : CRITICAL Failed to restart the directory server ([Errno 2] No such file or directory:
> '/etc/systemd/system/dirsrv.target.wants/dirsrv at EXAMPLE-ORG.service'). See the installation log for details.
>   [3/3]: adding CA certificate entry
> Done configuring directory server (dirsrv).
> CA did not start in 300.0s
> 
> 
> Versions used:
> ==============
> freeipa-client-4.1.2-1.fc20.x86_64
> freeipa-server-4.1.2-1.fc20.x86_64
> libipa_hbac-1.12.2-2.fc20.x86_64
> libipa_hbac-python-1.12.2-2.fc20.x86_64
> sssd-ipa-1.12.2-2.fc20.x86_64
> device-mapper-multipath-0.4.9-56.fc20.x86_64
> python-iniparse-0.4-9.fc20.noarch
> freeipa-admintools-4.1.2-1.fc20.x86_64
> freeipa-python-4.1.2-1.fc20.x86_64
> 389-ds-base-libs-1.3.3.5-1.fc20.x86_64
> 389-ds-base-1.3.3.5-1.fc20.x86_64
> 
> BaseOS:Fedora release 20 (Heisenbug)
> 
> 
> Steps to reproduce:
> ---------------
> 
> 1. On Fedora-20 system, Used mkosek freeipa repo:
> [mkosek-freeipa]
> name=Copr repo for freeipa owned by mkosek
> baseurl=http://copr-be.cloud.fedoraproject.org/results/mkosek/freeipa/fedora-$releasever-$basearch/
> skip_if_unavailable=True
> gpgcheck=0
> enabled=1
> 
> 2. Install freeipa-server packages from the above repo
> 
> 3. Issue ipa-server-install
> 
> [root at pkiserver1 ~]# ipa-server-install
> 
> The log file for this installation can be found in /var/log/ipaserver-install.log
> ==============================================================================
> This program will set up the FreeIPA Server.
> 
> This includes:
>   * Configure a stand-alone CA (dogtag) for certificate management
>   * Configure the Network Time Daemon (ntpd)
>   * Create and configure an instance of Directory Server
>   * Create and configure a Kerberos Key Distribution Center (KDC)
>   * Configure Apache (httpd)
> 
> To accept the default shown in brackets, press the Enter key.
> 
> WARNING: conflicting time&date synchronization service 'chronyd' will be disabled
> in favor of ntpd
> 
> Do you want to configure integrated DNS (BIND)? [no]: yes
> 
> Existing BIND configuration detected, overwrite? [no]: yes
> Enter the fully qualified domain name of the computer
> on which you're setting up server software. Using the form
> <hostname>.<domainname>
> Example: master.example.com.
> 
> 
> Server host name [pkiserver1.example.org]:
> 
> Warning: skipping DNS resolution of host pkiserver1.example.org
> The domain name has been determined based on the host name.
> 
> Please confirm the domain name [example.org]:
> 
> The kerberos protocol requires a Realm name to be defined.
> This is typically the domain name converted to uppercase.
> 
> Please provide a realm name [EXAMPLE.ORG]:
> Certain directory server operations require an administrative user.
> This user is referred to as the Directory Manager and has full access
> to the Directory for system management tasks and will be added to the
> 
> The IPA server requires an administrative user, named 'admin'.
> This user is a regular system account used for IPA server administration.
> 
> IPA admin password:
> Password (confirm):
> 
> Do you want to configure DNS forwarders? [yes]: no
> No DNS forwarders configured
> Do you want to configure the reverse zone? [yes]:
> Please specify the reverse zone name [122.168.192.in-addr.arpa.]:
> Using reverse zone(s) 122.168.192.in-addr.arpa.
> 
> The IPA Master Server will be configured with:
> Hostname:       pkiserver1.example.org
> IP address(es): 192.168.122.246
> Domain name:    example.org
> Realm name:     EXAMPLE.ORG
> 
> BIND DNS server will be configured to serve IPA domain with:
> Forwarders:    No forwarders
> Reverse zone(s):  122.168.192.in-addr.arpa.
> 
> Continue to configure the system with these values? [no]: yes
> 
> The following operations may take some minutes to complete.
> Please wait until the prompt is returned.
> 
> 
> instance of directory server created for IPA.
> The password must be at least 8 characters long.
> 
> Directory Manager password:
> Password (confirm):
> Configuring NTP daemon (ntpd)
>   [1/4]: stopping ntpd
>   [2/4]: writing configuration
>   [3/4]: configuring ntpd to start on boot
>   [4/4]: starting ntpd
> Done configuring NTP daemon (ntpd).
> Configuring directory server (dirsrv): Estimated time 1 minute
>   [1/38]: creating directory server user
>   [2/38]: creating directory server instance
>   [3/38]: adding default schema
>   [4/38]: enabling memberof plugin
>   [5/38]: enabling winsync plugin
>   [6/38]: configuring replication version plugin
>   [7/38]: enabling IPA enrollment plugin
>   [8/38]: enabling ldapi
>   [9/38]: configuring uniqueness plugin
>   [10/38]: configuring uuid plugin
>   [11/38]: configuring modrdn plugin
>   [12/38]: configuring DNS plugin
>   [13/38]: enabling entryUSN plugin
>   [14/38]: configuring lockout plugin
>   [15/38]: creating indices
>   [16/38]: enabling referential integrity plugin
>   [17/38]: configuring certmap.conf
>   [18/38]: configure autobind for root
>   [19/38]: configure new location for managed entries
>   [20/38]: configure dirsrv ccache
>   [21/38]: enable SASL mapping fallback
>   [22/38]: restarting directory server
>   [23/38]: adding default layout
>   [24/38]: adding delegation layout
>   [25/38]: creating container for managed entries
>   [26/38]: configuring user private groups
>   [27/38]: configuring netgroups from hostgroups
>   [28/38]: creating default Sudo bind user
>   [29/38]: creating default Auto Member layout
>   [30/38]: adding range check plugin
>   [31/38]: creating default HBAC rule allow_all
>   [32/38]: initializing group membership
>   [33/38]: adding master entry
>   [34/38]: configuring Posix uid/gid generation
>   [35/38]: adding replication acis
>   [36/38]: enabling compatibility plugin
>   [37/38]: tuning directory server
>   [38/38]: configuring directory to start on boot
> Done configuring directory server (dirsrv).
> Configuring certificate server (pki-tomcatd): Estimated time 3 minutes 30 seconds
>   [1/27]: creating certificate server user
>   [2/27]: configuring certificate server instance
>   [3/27]: stopping certificate server instance to update CS.cfg
>   [4/27]: backing up CS.cfg
>   [5/27]: disabling nonces
>   [6/27]: set up CRL publishing
>   [7/27]: enable PKIX certificate path discovery and validation
>   [8/27]: starting certificate server instance
>   [9/27]: creating RA agent certificate database
>   [10/27]: importing CA chain to RA certificate database
>   [11/27]: fixing RA database permissions
>   [12/27]: setting up signing cert profile
>   [13/27]: set certificate subject base
>   [14/27]: enabling Subject Key Identifier
>   [15/27]: enabling Subject Alternative Name
>   [16/27]: enabling CRL and OCSP extensions for certificates
>   [17/27]: setting audit signing renewal to 2 years
>   [18/27]: configuring certificate server to start on boot
>   [19/27]: restarting certificate server
>   [20/27]: requesting RA certificate from CA
>   [21/27]: issuing RA agent certificate
>   [22/27]: adding RA agent as a trusted user
>   [23/27]: configure certmonger for renewals
>   [24/27]: configure certificate renewals
>   [25/27]: configure RA certificate renewal
>   [26/27]: configure Server-Cert certificate renewal
>   [27/27]: Configure HTTP to proxy connections
> Done configuring certificate server (pki-tomcatd).
> Configuring directory server (dirsrv): Estimated time 10 seconds
>   [1/3]: configuring ssl for ds instance
>   [2/3]: restarting directory server
> ipa         : CRITICAL Failed to restart the directory server ([Errno 2] No such file or directory:
> '/etc/systemd/system/dirsrv.target.wants/dirsrv at EXAMPLE-ORG.service'). See the installation log for details.
>   [3/3]: adding CA certificate entry
> Done configuring directory server (dirsrv).
> 
> CA did not start in 300.0s
> 
> Attaching ipaserver-install.log, pkispawn logs
> 
> Any hints on how to overcome the above error.

The error is obviously in Directory Server restart. I am not sure what causes

2014-12-07T11:16:25Z DEBUG   [2/3]: restarting directory server
2014-12-07T11:16:25Z CRITICAL Failed to restart the directory server ([Errno 2]
No such file or directory:
'/etc/systemd/system/dirsrv.target.wants/dirsrv at EXAMPLE-ORG.service'). See the
installation log for details.

The first restart worked and it uses the same call, AFAIK. It would be
interesting to see the latest logs of the instance after ipa-server-install
crashes:

# systemctl status dirsrv at EXAMPLE-ORG.service

It may have some useful logs that would reveal what happened.

Martin



From mkosek at redhat.com  Tue Dec  9 09:05:51 2014
From: mkosek at redhat.com (Martin Kosek)
Date: Tue, 09 Dec 2014 10:05:51 +0100
Subject: [Freeipa-users] one step away from having freeipa work with
 vsphere ldap
In-Reply-To: <CAG2kNCwBXz-58cDnSuYqyF9fvkrd-T7-CdjR9GsLtc5_L_X-uA@mail.gmail.com>
References: <CAG2kNCyKOiD69pfiu9ZqAifjBKeUoCJTpK9C_H=hDURdbAcn9w@mail.gmail.com>
	<CAG2kNCwBXz-58cDnSuYqyF9fvkrd-T7-CdjR9GsLtc5_L_X-uA@mail.gmail.com>
Message-ID: <5486BB6F.2030601@redhat.com>

On 12/07/2014 07:29 PM, Gianluca Cecchi wrote:
> On Sun, Dec 7, 2014 at 3:44 PM, Gianluca Cecchi <gianluca.cecchi at gmail.com>
> wrote:
> 
>> Hello,
>> I'm quite near to have users and groups working using ipa 3.3 as in CentOS
>> 7 as this gives ability to do binds against compat tree.
>> This is with the use of schema compatibility
>>
>> The last step I need is getting components of groups so that vSphere con
>> enforce group membership permission over user set.
>>
>> The query from vsphere after my modifications when it searches for users
>> belonging to groups is sort of
>>
>> ldapsearch -x -b "cn=groups,cn=compat,dc=localdomain,dc=local"
>> "(&(objectClass=groupOfUniqueNames)(uniqueMember=uid=gcecchi,cn=users,cn=compat,dc=localdomain,dc=local))"
>>
>> so I provided ldif modification for cn=groups, cn=compat this way
>>
>> schema-compat-entry-attribute: uniqueMember=%{member}
>>
>> but this produces somthing like this when I query for example a created
>> group named esxpower to be used for power users
>>
>> # esxpower, groups, compat, localdomain.local
>> dn: cn=esxpower,cn=groups,cn=compat,dc=localdomain,dc=local
>> objectClass: posixGroup
>> objectClass: groupOfUniqueNames
>> objectClass: top
>> gidNumber: 1639600006
>> memberUid: gcecchi
>> memberUid: vadmin
>> uniqueMember: uid=gcecchi,cn=users,cn=accounts,dc=localdomain,dc=local
>> uniqueMember: uid=vadmin,cn=users,cn=accounts,dc=localdomain,dc=local
>> cn: esxpower
>>
>> so the problem is I have to change the entry
>> schema-compat-entry-attribute: uniqueMember=%{member}
>>
>> with a sort of function that gives cn=compat instead of cn=accounts in the
>> line
>> uniqueMember: uid=gcecchi,cn=users,cn=accounts,dc=localdomain,dc=local
>>
>> I read also /usr/share/doc/slapi-nis-0.52/format-specifiers.txt
>> but I didn't come to a sort of "substitute" function so that I can change
>> %{member} with the same but with "compat" word instead of "accounts"
>>
>> I plan to detail all my steps once I can accomplish this.
>>
>> Thanks in advance,
>>
>> Gianluca
>>
>>
> 
> Tried with
> schema-compat-entry-attribute:
> uniqueMember=%regsub("%{member}","^(.*)accounts(.*)","%1compat%2")
> 
> but it seems it works with some groups (the system groups) but not with the
> other ones I have created...
> 
> ldapsearch -x -b "cn=groups,cn=compat,dc=localdomain,dc=local"
> 
> gives
> 
> # admins, groups, compat, localdomain.local
> dn: cn=admins,cn=groups,cn=compat,dc=localdomain,dc=local
> objectClass: posixGroup
> objectClass: groupOfUniqueNames
> objectClass: top
> gidNumber: 1639600000
> memberUid: admin
> uniqueMember: uid=admin,cn=users,cn=compat,dc=localdomain,dc=local
> cn: admins
> 
> 
> but in esxpower group I see only the memberUid entry and not the
> uniqueMember entry
> 
> # esxpower, groups, compat, localdomain.local
> dn: cn=esxpower,cn=groups,cn=compat,dc=localdomain,dc=local
> objectClass: posixGroup
> objectClass: groupOfUniqueNames
> objectClass: top
> gidNumber: 1639600006
> memberUid: gcecchi
> memberUid: vadmin
> cn: esxpower
> 
> Gianluca

CCing Ludwig and Thierry, in case they have some idea.

BTW, if we manage to resolve the issue, it would be nice if you could
contribute a howto with the configuration changes to

http://www.freeipa.org/page/HowTos

:-)

Martin



From mkosek at redhat.com  Tue Dec  9 09:09:15 2014
From: mkosek at redhat.com (Martin Kosek)
Date: Tue, 09 Dec 2014 10:09:15 +0100
Subject: [Freeipa-users] Problem adding group after update IPA from
 CentOS 6.6 to 7.0
In-Reply-To: <CAG2kNCz9yRkEeKiR2EYSEL3AbBhyQUo6CYw61chs3h9Rm-tBEw@mail.gmail.com>
References: <CAG2kNCzuj7goy+gHh0kvM7mrqn9o77rMvewJKRq6KeXqqZCYKw@mail.gmail.com>
	<CAG2kNCz9yRkEeKiR2EYSEL3AbBhyQUo6CYw61chs3h9Rm-tBEw@mail.gmail.com>
Message-ID: <5486BC3B.9070101@redhat.com>

On 12/08/2014 04:17 PM, Gianluca Cecchi wrote:
> On Mon, Dec 8, 2014 at 3:47 PM, Gianluca Cecchi <gianluca.cecchi at gmail.com>
> wrote:
> 
>> Hello,
>> I followed the guide here to migrate IPA from CentOS 6.6 to CentOS 7.0:
>>
>> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/upgrading.html
>>
>> Now, adding a group from console with command
>> ipa group-add
>> I get this kind of error:
>> ipa: ERROR: Operations error: Allocation of a new value for range cn=posix
>> ids,cn=distributed numeric assignment plugin,cn=plugins,cn=config failed!
>> Unable to proceed.
>>
>>
>>
> Based on info on og of CentOS 6.5 system, at the moment I solved the
> probelm this way and it seems it works.
> Let me know if you think I misunderstood anything.
> 
> created /root/dna_addrange.ldif
> dn: cn=POSIX IDs,cn=Distributed Numeric Assignment
> Plugin,cn=plugins,cn=config
> changetype: modify
> add: dnaNextRange
> dnaNextRange: 1639600001-1639799999
> -
> 
> [root at c7server slapd-LOCALDOMAIN-LOCAL]# ldapmodify -x -D "cn=Directory
> Manager" -f /root/dna_addrange.ldif -W
> Enter LDAP Password:
> modifying entry "cn=POSIX IDs,cn=Distributed Numeric Assignment
> Plugin,cn=plugins,cn=config"
> 
> Now the group create command automatically insert an unallocated GID
> 1639600005:
> [root at c7server slapd-LOCALDOMAIN-LOCAL]# ipa group-add
> Group name: testgroup
> Description: test group per generazione gid
> -----------------------
> Added group "testgroup"
> -----------------------
>   Group name: testgroup
>   Description: test group per generazione gid
>   GID: 1639600005
> 
> Gianluca

Normally, the replica should be able to request a DNA range from the other
replica it connects with, CentOS 6.6 in your case.

Given that it was unable to do it (thus the "Operations error: Allocation of a
new value" error), it seems the call was not successful. I would recommend
checking that replication between 6.6 and 7.0 indeed works and you are not for
example hitting the infamous SASL problem
(https://bugzilla.redhat.com/show_bug.cgi?id=1136882) preventing from
replication & DNA allocation.

Martin



From mkosek at redhat.com  Tue Dec  9 09:18:42 2014
From: mkosek at redhat.com (Martin Kosek)
Date: Tue, 09 Dec 2014 10:18:42 +0100
Subject: [Freeipa-users] can't register new clients
In-Reply-To: <CACMA5-wY7+ceQm8GOT11=8MttRgNcZfsS8sg8X25AOMfo+22Jg@mail.gmail.com>
References: <CACMA5-xsgZ2RcF7rx9MS+jtxpyMOofhpU0MnPn+1mcmHGOxNkg@mail.gmail.com>	<54821AA7.1000007@redhat.com>
	<54821D9B.80502@redhat.com>	<CACMA5-xs3gOMAdjg3o5aG6d58d-CvqPh5k9yo23pLSD9uXAq9Q@mail.gmail.com>	<548225F9.7010001@redhat.com>	<CACMA5-w=BmD+=9Gj7Q=U0oheEQOb40zfdzST_ASixiuKs5TqHA@mail.gmail.com>	<54822D6D.1050807@redhat.com>	<CACMA5-z+rt0e7tkf_UY5L_YzbQNcmRrNbNDQv3H01a=O9sXmxg@mail.gmail.com>
	<CACMA5-wY7+ceQm8GOT11=8MttRgNcZfsS8sg8X25AOMfo+22Jg@mail.gmail.com>
Message-ID: <5486BE72.5020506@redhat.com>

On 12/08/2014 08:00 PM, Megan . wrote:
> I looked through the logs on the server and i see the below error in
> the apache error log when i try to register a client:
> 
> [Mon Dec 08 12:20:38 2014] [error] SSL Library Error: -12195 Peer does
> not recognize and trust the CA that issued your certificate
> 
> 
> I ran ipa-getcert list and everything seems ok (nothing expired) but
> i'm not sure where to troubleshoot from here.

The next step would be to check the actual HTTP certificate (on the client
machine) and see what's wrong. I did a simple test you can follow:

# wget http://ipa.mkosek-f21.test/ipa/config/ca.crt -O /tmp/ipa.crt
# openssl s_client -host ipa.mkosek-f21.test -port 443 -CAfile /tmp/ipa.crt
CONNECTED(00000003)
depth=1 O = MKOSEK-F21.TEST, CN = Certificate Authority
verify return:1
depth=0 O = MKOSEK-F21.TEST, CN = ipa.mkosek-f21.test
verify return:1
---
Certificate chain
 0 s:/O=MKOSEK-F21.TEST/CN=ipa.mkosek-f21.test
   i:/O=MKOSEK-F21.TEST/CN=Certificate Authority
 1 s:/O=MKOSEK-F21.TEST/CN=Certificate Authority
   i:/O=MKOSEK-F21.TEST/CN=Certificate Authority
---
Server certificate
...
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : AES128-SHA
    Session-ID: 5A4B326D2E8FB80408D628D1975C49C4F78D3E65F31E475F9E7B9BBBE11F576E
    Session-ID-ctx:
    Master-Key:
D5C31E9E36503ADC9F162439B41A7A608260D7DF5EB357FB3D79C9CFAE700912526893E7DD9AA56F5B6CD320FBA98C49
    Key-Arg   : None
    Krb5 Principal: None
    PSK identity: None
    PSK identity hint: None
    Start Time: 1418073191
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---

> 
> 
> 
> On Fri, Dec 5, 2014 at 7:51 PM, Megan . <nagemnna at gmail.com> wrote:
>> It failed again.
>>
>>
>> [root at cache2-uat ~]# certutil -L -d sql:/etc/pki/nssdb
>>
>> Certificate Nickname                                         Trust Attributes
>>                                                              SSL,S/MIME,JAR/XPI
>> [root at cache2-uat ~]#
>>
>> Not sure if its related, but on the directory server in the apache
>> error.log I see the below every time a client tries to register:
>>
>> [Sat Dec 06 00:48:35 2014] [error] SSL Library Error: -12271 SSL
>> client cannot verify your certificate
>>
>> On the directory server i ran ipa-getcert list and the certs seem ok.
>>
>>
>>
>> On Fri, Dec 5, 2014 at 5:10 PM, Rob Crittenden <rcritten at redhat.com> wrote:
>>> Megan . wrote:
>>>> Sorry for being unclear. It still fails.  Same error.
>>>
>>> Hmm, strange. Try being explicit about sql:
>>>
>>> # certutil -L -d sql:/etc/pki/nssdb
>>>
>>> And if there is a CA cert there, delete it.
>>>
>>> rob
>>>
>>>>
>>>> On Dec 5, 2014 4:39 PM, "Rob Crittenden" <rcritten at redhat.com
>>>> <mailto:rcritten at redhat.com>> wrote:
>>>>
>>>>     Megan . wrote:
>>>>     > Thanks.
>>>>     >
>>>>     > I did have an issue last week where i tried to do the client install
>>>>     > and it failed because of a firewall issue.  Networks has it opened
>>>>     > now.  I deleted ca.crt before trying again.  There doesn't seem to be
>>>>     > a certificate in /etc/pki/nssdb for it.
>>>>     >
>>>>     >
>>>>     >
>>>>     > [root at data2-uat ipa]# certutil -L -d /etc/pki/nssdb
>>>>     >
>>>>     >
>>>>     > Certificate Nickname                                         Trust
>>>>     Attributes
>>>>     >
>>>>     >
>>>>     SSL,S/MIME,JAR/XPI
>>>>     >
>>>>     >
>>>>     > [root at data2-uat ipa]# certutil -D -n 'IPA CA' -d /etc/pki/nssdb
>>>>     >
>>>>     > certutil: could not find certificate named "IPA CA":
>>>>     > SEC_ERROR_BAD_DATABASE: security library: bad database.
>>>>     >
>>>>     > [root at data2-uat ipa]# ls
>>>>     >
>>>>     > [root at data2-uat ipa]# pwd
>>>>     >
>>>>     > /etc/ipa
>>>>     >
>>>>     > [root at data2-uat ipa]# ls -al
>>>>     >
>>>>     > total 16
>>>>     >
>>>>     > drwxr-xr-x.  2 root root  4096 Dec  5 21:16 .
>>>>     >
>>>>     > drwxr-xr-x. 82 root root 12288 Dec  5 21:16 ..
>>>>     >
>>>>     > [root at data2-uat ipa]#
>>>>
>>>>     So trying to install the client again fails or succeeds now?
>>>>
>>>>     rob
>>>>
>>>>     >
>>>>     > On Fri, Dec 5, 2014 at 4:03 PM, Rob Crittenden
>>>>     <rcritten at redhat.com <mailto:rcritten at redhat.com>> wrote:
>>>>     >> Rob Crittenden wrote:
>>>>     >>> Megan . wrote:
>>>>     >>>> Good Day!
>>>>     >>>>
>>>>     >>>> I am getting an error when i register new clients.
>>>>     >>>>
>>>>     >>>> libcurl failed to execute the HTTP POST transaction.  SSL
>>>>     connect error
>>>>     >>>>
>>>>     >>>> I can't find anything useful not the internet about the error.  Can
>>>>     >>>> someone help me troubleshoot?
>>>>     >>>>
>>>>     >>>> CentOS 6.6  x64
>>>>     >>>> ipa-client-3.0.0-42.el6.centos.x86_64
>>>>     >>>> ipa-server-3.0.0-42.el6.centos.x86_64
>>>>     >>>> curl-7.19.7-40.el6_6.1.x86_64
>>>>     >>>
>>>>     >>> Do you have NSS_DEFAULT_DB_TYPE set to sql? I don't know that
>>>>     we've done
>>>>     >>> any testing on the client with this set.
>>>>     >>
>>>>     >> Never mind, that's not it. The problem is:
>>>>     >>
>>>>     >> * NSS error -8054
>>>>     >>
>>>>     >> Which is SEC_ERROR_REUSED_ISSUER_AND_SERIAL
>>>>     >>
>>>>     >> So I'd do this:
>>>>     >>
>>>>     >> # rm /etc/ipa/ca.crt
>>>>     >>
>>>>     >> You may also want to ensure that the IPA CA certificate isn't in
>>>>     >> /etc/pki/nssdb:
>>>>     >>
>>>>     >> # certutil -L -d /etc/pki/nssdb
>>>>     >>
>>>>     >> And then perhaps
>>>>     >>
>>>>     >> # certutil -D -n 'IPA CA' -d /etc/pki/nssdb
>>>>     >>
>>>>     >> rob
>>>>     >>
>>>>
>>>
> 



From mkosek at redhat.com  Tue Dec  9 09:22:12 2014
From: mkosek at redhat.com (Martin Kosek)
Date: Tue, 09 Dec 2014 10:22:12 +0100
Subject: [Freeipa-users] one step away from having freeipa work with
 vsphere ldap
In-Reply-To: <5486BB6F.2030601@redhat.com>
References: <CAG2kNCyKOiD69pfiu9ZqAifjBKeUoCJTpK9C_H=hDURdbAcn9w@mail.gmail.com>	<CAG2kNCwBXz-58cDnSuYqyF9fvkrd-T7-CdjR9GsLtc5_L_X-uA@mail.gmail.com>
	<5486BB6F.2030601@redhat.com>
Message-ID: <5486BF44.2050506@redhat.com>

On 12/09/2014 10:05 AM, Martin Kosek wrote:
> On 12/07/2014 07:29 PM, Gianluca Cecchi wrote:
>> On Sun, Dec 7, 2014 at 3:44 PM, Gianluca Cecchi <gianluca.cecchi at gmail.com>
>> wrote:
>>
>>> Hello,
>>> I'm quite near to have users and groups working using ipa 3.3 as in CentOS
>>> 7 as this gives ability to do binds against compat tree.
>>> This is with the use of schema compatibility
>>>
>>> The last step I need is getting components of groups so that vSphere con
>>> enforce group membership permission over user set.
>>>
>>> The query from vsphere after my modifications when it searches for users
>>> belonging to groups is sort of
>>>
>>> ldapsearch -x -b "cn=groups,cn=compat,dc=localdomain,dc=local"
>>> "(&(objectClass=groupOfUniqueNames)(uniqueMember=uid=gcecchi,cn=users,cn=compat,dc=localdomain,dc=local))"
>>>
>>> so I provided ldif modification for cn=groups, cn=compat this way
>>>
>>> schema-compat-entry-attribute: uniqueMember=%{member}
>>>
>>> but this produces somthing like this when I query for example a created
>>> group named esxpower to be used for power users
>>>
>>> # esxpower, groups, compat, localdomain.local
>>> dn: cn=esxpower,cn=groups,cn=compat,dc=localdomain,dc=local
>>> objectClass: posixGroup
>>> objectClass: groupOfUniqueNames
>>> objectClass: top
>>> gidNumber: 1639600006
>>> memberUid: gcecchi
>>> memberUid: vadmin
>>> uniqueMember: uid=gcecchi,cn=users,cn=accounts,dc=localdomain,dc=local
>>> uniqueMember: uid=vadmin,cn=users,cn=accounts,dc=localdomain,dc=local
>>> cn: esxpower
>>>
>>> so the problem is I have to change the entry
>>> schema-compat-entry-attribute: uniqueMember=%{member}
>>>
>>> with a sort of function that gives cn=compat instead of cn=accounts in the
>>> line
>>> uniqueMember: uid=gcecchi,cn=users,cn=accounts,dc=localdomain,dc=local
>>>
>>> I read also /usr/share/doc/slapi-nis-0.52/format-specifiers.txt
>>> but I didn't come to a sort of "substitute" function so that I can change
>>> %{member} with the same but with "compat" word instead of "accounts"
>>>
>>> I plan to detail all my steps once I can accomplish this.
>>>
>>> Thanks in advance,
>>>
>>> Gianluca
>>>
>>>
>>
>> Tried with
>> schema-compat-entry-attribute:
>> uniqueMember=%regsub("%{member}","^(.*)accounts(.*)","%1compat%2")
>>
>> but it seems it works with some groups (the system groups) but not with the
>> other ones I have created...
>>
>> ldapsearch -x -b "cn=groups,cn=compat,dc=localdomain,dc=local"
>>
>> gives
>>
>> # admins, groups, compat, localdomain.local
>> dn: cn=admins,cn=groups,cn=compat,dc=localdomain,dc=local
>> objectClass: posixGroup
>> objectClass: groupOfUniqueNames
>> objectClass: top
>> gidNumber: 1639600000
>> memberUid: admin
>> uniqueMember: uid=admin,cn=users,cn=compat,dc=localdomain,dc=local
>> cn: admins
>>
>>
>> but in esxpower group I see only the memberUid entry and not the
>> uniqueMember entry
>>
>> # esxpower, groups, compat, localdomain.local
>> dn: cn=esxpower,cn=groups,cn=compat,dc=localdomain,dc=local
>> objectClass: posixGroup
>> objectClass: groupOfUniqueNames
>> objectClass: top
>> gidNumber: 1639600006
>> memberUid: gcecchi
>> memberUid: vadmin
>> cn: esxpower
>>
>> Gianluca
> 
> CCing Ludwig and Thierry, in case they have some idea.
> 
> BTW, if we manage to resolve the issue, it would be nice if you could
> contribute a howto with the configuration changes to
> 
> http://www.freeipa.org/page/HowTos
> 
> :-)
> 
> Martin
> 

Please ignore my mail above, I see Gianluca informed about resolving the issue
in another thread, "[Freeipa-users] vSphere 5.1 and FreeIPA 3.3 on CentOS 7
finally works! [How I did it...]".

Martin



From tbordaz at redhat.com  Tue Dec  9 09:27:54 2014
From: tbordaz at redhat.com (thierry bordaz)
Date: Tue, 09 Dec 2014 10:27:54 +0100
Subject: [Freeipa-users] [Freeipa-interest] Announcing FreeIPA 4.1.2 -
 NEED HELP WITH 2FA/OTP!!!
In-Reply-To: <5486BA7E.90100@redhat.com>
References: <54775877.6060102@redhat.com>	<176433463.23902008.1417805679430.JavaMail.zimbra@redhat.com>
	<54845DA3.3070104@redhat.com> <5486BA7E.90100@redhat.com>
Message-ID: <5486C09A.5060902@redhat.com>

Hello,

Niranjan, may I have access to your test machine.

thanks
theirry


On 12/09/2014 10:01 AM, Martin Kosek wrote:
> On 12/07/2014 03:01 PM, Niranjan M.R wrote:
>> On 12/06/2014 12:24 AM, Dmitri Pal wrote:
>>> Hello,
>>> WE NEED HELP!
>>> The biggest and the most interesting feature of FreeIPA 4.1.2 is support for the two factor authentication using HOTP/TOTP compatible software tokens like FreeOTP (open source compatible alternative to Google Authenticator) and hardware tokens like Yubikeys. This feature allows Kerberos and LDAP clients of a FreeIPA server to authenticate using the normal account password as the first factor and an OTP token as a second factor. For those environments where a 2FA solution is already in place, FreeIPA can act as a proxy via RADIUS. More about this feature can be read here.
>>> http://www.freeipa.org/page/V4/OTP
>>> If you want to see this feature in downstream distros sooner rather than later we need your help!
>>> Please give it a try and provide feedback. We really, really need it!
>> I am unable to configure ipa-server with freeipa-server-4.1.2-1.fc20.x86_64,  ipa-server-install fails with below error:
>>
>> Done configuring certificate server (pki-tomcatd).
>> Configuring directory server (dirsrv): Estimated time 10 seconds
>>    [1/3]: configuring ssl for ds instance
>>    [2/3]: restarting directory server
>> ipa         : CRITICAL Failed to restart the directory server ([Errno 2] No such file or directory:
>> '/etc/systemd/system/dirsrv.target.wants/dirsrv at EXAMPLE-ORG.service'). See the installation log for details.
>>    [3/3]: adding CA certificate entry
>> Done configuring directory server (dirsrv).
>> CA did not start in 300.0s
>>
>>
>> Versions used:
>> ==============
>> freeipa-client-4.1.2-1.fc20.x86_64
>> freeipa-server-4.1.2-1.fc20.x86_64
>> libipa_hbac-1.12.2-2.fc20.x86_64
>> libipa_hbac-python-1.12.2-2.fc20.x86_64
>> sssd-ipa-1.12.2-2.fc20.x86_64
>> device-mapper-multipath-0.4.9-56.fc20.x86_64
>> python-iniparse-0.4-9.fc20.noarch
>> freeipa-admintools-4.1.2-1.fc20.x86_64
>> freeipa-python-4.1.2-1.fc20.x86_64
>> 389-ds-base-libs-1.3.3.5-1.fc20.x86_64
>> 389-ds-base-1.3.3.5-1.fc20.x86_64
>>
>> BaseOS:Fedora release 20 (Heisenbug)
>>
>>
>> Steps to reproduce:
>> ---------------
>>
>> 1. On Fedora-20 system, Used mkosek freeipa repo:
>> [mkosek-freeipa]
>> name=Copr repo for freeipa owned by mkosek
>> baseurl=http://copr-be.cloud.fedoraproject.org/results/mkosek/freeipa/fedora-$releasever-$basearch/
>> skip_if_unavailable=True
>> gpgcheck=0
>> enabled=1
>>
>> 2. Install freeipa-server packages from the above repo
>>
>> 3. Issue ipa-server-install
>>
>> [root at pkiserver1 ~]# ipa-server-install
>>
>> The log file for this installation can be found in /var/log/ipaserver-install.log
>> ==============================================================================
>> This program will set up the FreeIPA Server.
>>
>> This includes:
>>    * Configure a stand-alone CA (dogtag) for certificate management
>>    * Configure the Network Time Daemon (ntpd)
>>    * Create and configure an instance of Directory Server
>>    * Create and configure a Kerberos Key Distribution Center (KDC)
>>    * Configure Apache (httpd)
>>
>> To accept the default shown in brackets, press the Enter key.
>>
>> WARNING: conflicting time&date synchronization service 'chronyd' will be disabled
>> in favor of ntpd
>>
>> Do you want to configure integrated DNS (BIND)? [no]: yes
>>
>> Existing BIND configuration detected, overwrite? [no]: yes
>> Enter the fully qualified domain name of the computer
>> on which you're setting up server software. Using the form
>> <hostname>.<domainname>
>> Example: master.example.com.
>>
>>
>> Server host name [pkiserver1.example.org]:
>>
>> Warning: skipping DNS resolution of host pkiserver1.example.org
>> The domain name has been determined based on the host name.
>>
>> Please confirm the domain name [example.org]:
>>
>> The kerberos protocol requires a Realm name to be defined.
>> This is typically the domain name converted to uppercase.
>>
>> Please provide a realm name [EXAMPLE.ORG]:
>> Certain directory server operations require an administrative user.
>> This user is referred to as the Directory Manager and has full access
>> to the Directory for system management tasks and will be added to the
>>
>> The IPA server requires an administrative user, named 'admin'.
>> This user is a regular system account used for IPA server administration.
>>
>> IPA admin password:
>> Password (confirm):
>>
>> Do you want to configure DNS forwarders? [yes]: no
>> No DNS forwarders configured
>> Do you want to configure the reverse zone? [yes]:
>> Please specify the reverse zone name [122.168.192.in-addr.arpa.]:
>> Using reverse zone(s) 122.168.192.in-addr.arpa.
>>
>> The IPA Master Server will be configured with:
>> Hostname:       pkiserver1.example.org
>> IP address(es): 192.168.122.246
>> Domain name:    example.org
>> Realm name:     EXAMPLE.ORG
>>
>> BIND DNS server will be configured to serve IPA domain with:
>> Forwarders:    No forwarders
>> Reverse zone(s):  122.168.192.in-addr.arpa.
>>
>> Continue to configure the system with these values? [no]: yes
>>
>> The following operations may take some minutes to complete.
>> Please wait until the prompt is returned.
>>
>>
>> instance of directory server created for IPA.
>> The password must be at least 8 characters long.
>>
>> Directory Manager password:
>> Password (confirm):
>> Configuring NTP daemon (ntpd)
>>    [1/4]: stopping ntpd
>>    [2/4]: writing configuration
>>    [3/4]: configuring ntpd to start on boot
>>    [4/4]: starting ntpd
>> Done configuring NTP daemon (ntpd).
>> Configuring directory server (dirsrv): Estimated time 1 minute
>>    [1/38]: creating directory server user
>>    [2/38]: creating directory server instance
>>    [3/38]: adding default schema
>>    [4/38]: enabling memberof plugin
>>    [5/38]: enabling winsync plugin
>>    [6/38]: configuring replication version plugin
>>    [7/38]: enabling IPA enrollment plugin
>>    [8/38]: enabling ldapi
>>    [9/38]: configuring uniqueness plugin
>>    [10/38]: configuring uuid plugin
>>    [11/38]: configuring modrdn plugin
>>    [12/38]: configuring DNS plugin
>>    [13/38]: enabling entryUSN plugin
>>    [14/38]: configuring lockout plugin
>>    [15/38]: creating indices
>>    [16/38]: enabling referential integrity plugin
>>    [17/38]: configuring certmap.conf
>>    [18/38]: configure autobind for root
>>    [19/38]: configure new location for managed entries
>>    [20/38]: configure dirsrv ccache
>>    [21/38]: enable SASL mapping fallback
>>    [22/38]: restarting directory server
>>    [23/38]: adding default layout
>>    [24/38]: adding delegation layout
>>    [25/38]: creating container for managed entries
>>    [26/38]: configuring user private groups
>>    [27/38]: configuring netgroups from hostgroups
>>    [28/38]: creating default Sudo bind user
>>    [29/38]: creating default Auto Member layout
>>    [30/38]: adding range check plugin
>>    [31/38]: creating default HBAC rule allow_all
>>    [32/38]: initializing group membership
>>    [33/38]: adding master entry
>>    [34/38]: configuring Posix uid/gid generation
>>    [35/38]: adding replication acis
>>    [36/38]: enabling compatibility plugin
>>    [37/38]: tuning directory server
>>    [38/38]: configuring directory to start on boot
>> Done configuring directory server (dirsrv).
>> Configuring certificate server (pki-tomcatd): Estimated time 3 minutes 30 seconds
>>    [1/27]: creating certificate server user
>>    [2/27]: configuring certificate server instance
>>    [3/27]: stopping certificate server instance to update CS.cfg
>>    [4/27]: backing up CS.cfg
>>    [5/27]: disabling nonces
>>    [6/27]: set up CRL publishing
>>    [7/27]: enable PKIX certificate path discovery and validation
>>    [8/27]: starting certificate server instance
>>    [9/27]: creating RA agent certificate database
>>    [10/27]: importing CA chain to RA certificate database
>>    [11/27]: fixing RA database permissions
>>    [12/27]: setting up signing cert profile
>>    [13/27]: set certificate subject base
>>    [14/27]: enabling Subject Key Identifier
>>    [15/27]: enabling Subject Alternative Name
>>    [16/27]: enabling CRL and OCSP extensions for certificates
>>    [17/27]: setting audit signing renewal to 2 years
>>    [18/27]: configuring certificate server to start on boot
>>    [19/27]: restarting certificate server
>>    [20/27]: requesting RA certificate from CA
>>    [21/27]: issuing RA agent certificate
>>    [22/27]: adding RA agent as a trusted user
>>    [23/27]: configure certmonger for renewals
>>    [24/27]: configure certificate renewals
>>    [25/27]: configure RA certificate renewal
>>    [26/27]: configure Server-Cert certificate renewal
>>    [27/27]: Configure HTTP to proxy connections
>> Done configuring certificate server (pki-tomcatd).
>> Configuring directory server (dirsrv): Estimated time 10 seconds
>>    [1/3]: configuring ssl for ds instance
>>    [2/3]: restarting directory server
>> ipa         : CRITICAL Failed to restart the directory server ([Errno 2] No such file or directory:
>> '/etc/systemd/system/dirsrv.target.wants/dirsrv at EXAMPLE-ORG.service'). See the installation log for details.
>>    [3/3]: adding CA certificate entry
>> Done configuring directory server (dirsrv).
>>
>> CA did not start in 300.0s
>>
>> Attaching ipaserver-install.log, pkispawn logs
>>
>> Any hints on how to overcome the above error.
> The error is obviously in Directory Server restart. I am not sure what causes
>
> 2014-12-07T11:16:25Z DEBUG   [2/3]: restarting directory server
> 2014-12-07T11:16:25Z CRITICAL Failed to restart the directory server ([Errno 2]
> No such file or directory:
> '/etc/systemd/system/dirsrv.target.wants/dirsrv at EXAMPLE-ORG.service'). See the
> installation log for details.
>
> The first restart worked and it uses the same call, AFAIK. It would be
> interesting to see the latest logs of the instance after ipa-server-install
> crashes:
>
> # systemctl status dirsrv at EXAMPLE-ORG.service
>
> It may have some useful logs that would reveal what happened.
>
> Martin



From lslebodn at redhat.com  Tue Dec  9 09:36:42 2014
From: lslebodn at redhat.com (Lukas Slebodnik)
Date: Tue, 9 Dec 2014 10:36:42 +0100
Subject: [Freeipa-users] DNS configuration
In-Reply-To: <5485FB6D.8000005@redhat.com>
References: <CABhyZ36DDM6icM+haMbVErdVdDWonGqbPE+3Tpad4K=u9QHjAQ@mail.gmail.com>
	<54851385.3050709@redhat.com>
	<CABhyZ36D_SVLezC=wZ3tsYHn00tdBGsxpOxCtpVgWZo8EdH2hw@mail.gmail.com>
	<548522B8.8040805@redhat.com> <5485599E.8030801@redhat.com>
	<CABhyZ34Pbr4J6YDdLSmP=qPqAB7Pa=tWvw273aB-BNX4dRq-GQ@mail.gmail.com>
	<5485C698.9000406@redhat.com>
	<CABhyZ35qsCM0y8anFdqE7r60Fz8LAU8Yx3WWaF6zBhfg=dRUJA@mail.gmail.com>
	<CABhyZ34exwjj4o8RRu651w2kik96wMS3Y6dvEk14MG1Y+LkY9w@mail.gmail.com>
	<5485FB6D.8000005@redhat.com>
Message-ID: <20141209093641.GA12384@mail.corp.redhat.com>

On (08/12/14 14:26), Dmitri Pal wrote:
>On 12/08/2014 02:10 PM, Matthew Herzog wrote:
>>Here are some errors I'm seeing on the client.
>>
>>tail -f sssd_lnx.e-bozo.com.log
>>(Mon Dec  8 14:03:20 2014) [sssd[be[lnx.e-bozo.com
>><http://lnx.e-bozo.com>]]] [sbus_dispatch] (0x4000): dbus conn: 0x1e72ad0
>>(Mon Dec  8 14:03:20 2014) [sssd[be[lnx.e-bozo.com
>><http://lnx.e-bozo.com>]]] [sbus_dispatch] (0x4000): Dispatching.
>>(Mon Dec  8 14:03:20 2014) [sssd[be[lnx.e-bozo.com
>><http://lnx.e-bozo.com>]]] [sbus_message_handler] (0x4000): Received SBUS
>>method [ping]
>>(Mon Dec  8 14:03:20 2014) [sssd[be[lnx.e-bozo.com
>><http://lnx.e-bozo.com>]]] [sbus_get_sender_id_send] (0x2000): Not a sysbus
>>message, quit
>>(Mon Dec  8 14:03:20 2014) [sssd[be[lnx.e-bozo.com
>><http://lnx.e-bozo.com>]]] [sbus_handler_got_caller_id] (0x4000): Received
>>SBUS method [ping]
>>(Mon Dec  8 14:03:30 2014) [sssd[be[lnx.e-bozo.com
>><http://lnx.e-bozo.com>]]] [sbus_dispatch] (0x4000): dbus conn: 0x1e72ad0
>>(Mon Dec  8 14:03:30 2014) [sssd[be[lnx.e-bozo.com
>><http://lnx.e-bozo.com>]]] [sbus_dispatch] (0x4000): Dispatching.
>>(Mon Dec  8 14:03:30 2014) [sssd[be[lnx.e-bozo.com
>><http://lnx.e-bozo.com>]]] [sbus_message_handler] (0x4000): Received SBUS
>>method [ping]
>>(Mon Dec  8 14:03:30 2014) [sssd[be[lnx.e-bozo.com
>><http://lnx.e-bozo.com>]]] [sbus_get_sender_id_send] (0x2000): Not a sysbus
>>message, quit
>>(Mon Dec  8 14:03:30 2014) [sssd[be[lnx.e-bozo.com
>><http://lnx.e-bozo.com>]]] [sbus_handler_got_caller_id] (0x4000): Received
>>SBUS method [ping]
>>(Mon Dec  8 14:03:40 2014) [sssd[be[lnx.e-bozo.com
>><http://lnx.e-bozo.com>]]] [sbus_dispatch] (0x4000): dbus conn: 0x1e72ad0
>>(Mon Dec  8 14:03:40 2014) [sssd[be[lnx.e-bozo.com
>><http://lnx.e-bozo.com>]]] [sbus_dispatch] (0x4000): Dispatching.
>>
>>[root at freeipa-poc-client02 sssd]# tail -f sssd_ssh.log
>>(Sun Dec  7 19:32:09 2014) [sssd[ssh]] [ssh_process_init] (0x0010):
>>sss_process_init() failed
>>(Sun Dec  7 19:32:09 2014) [sssd[ssh]] [sss_dp_init] (0x0010): Failed to
>>connect to monitor services.
>>(Sun Dec  7 19:32:09 2014) [sssd[ssh]] [sss_process_init] (0x0010): fatal
>>error setting up backend connector
>>(Sun Dec  7 19:32:09 2014) [sssd[ssh]] [ssh_process_init] (0x0010):
>>sss_process_init() failed
>>(Sun Dec  7 19:32:16 2014) [sssd[ssh]] [sss_dp_init] (0x0010): Failed to
>>connect to monitor services.
>>(Sun Dec  7 19:32:16 2014) [sssd[ssh]] [sss_process_init] (0x0010): fatal
>>error setting up backend connector
>>(Sun Dec  7 19:32:16 2014) [sssd[ssh]] [ssh_process_init] (0x0010):
>>sss_process_init() failed
>>(Sun Dec  7 19:32:16 2014) [sssd[ssh]] [sss_dp_init] (0x0010): Failed to
>>connect to monitor services.
>>(Sun Dec  7 19:32:16 2014) [sssd[ssh]] [sss_process_init] (0x0010): fatal
>>error setting up backend connector
>>(Sun Dec  7 19:32:16 2014) [sssd[ssh]] [ssh_process_init] (0x0010):
>>sss_process_init() failed
>
>What is the version of the client?
>Please add debug_level=9 to sssd.conf in different sections to rise the
>verbosity of the log and see what is really going on there.
>https://fedorahosted.org/sssd/wiki/FAQ#BasicsofTroubleshooting
>
I agree with Dimitri. This part of log file is not sufficient.
The debug_level = 9. It will generate log files with all debug messages.
You can filter the most critical part with
    grep -E "(0x00[1-9]0)" sssd_lnx.e-bozo.com.log

If you will not able to find problem in log files please send them to the list
(You can send private message to me if you don't want to send big log files to
 public mailing list.

LS



From mkosek at redhat.com  Tue Dec  9 09:50:58 2014
From: mkosek at redhat.com (Martin Kosek)
Date: Tue, 09 Dec 2014 10:50:58 +0100
Subject: [Freeipa-users] vSphere 5.1 and FreeIPA 3.3 on CentOS 7 finally
 works! [How I did it...]
In-Reply-To: <CAG2kNCyj=b4c-5C59uvba37hoXwX8rHmtE9DC1vbKk+YM5p1ZQ@mail.gmail.com>
References: <CAG2kNCyXWXxMx0V96bYgMq--9zaBwhWMBENrOgSXnMMr9=F85Q@mail.gmail.com>	<5485E119.10203@redhat.com>	<CAG2kNCyWUhbVZUbpo0rgE_NAucs5S4x6_dj4JcCXTNWyLNSAFw@mail.gmail.com>
	<CAG2kNCyj=b4c-5C59uvba37hoXwX8rHmtE9DC1vbKk+YM5p1ZQ@mail.gmail.com>
Message-ID: <5486C602.80106@redhat.com>

On 12/09/2014 12:50 AM, Gianluca Cecchi wrote:
> On Mon, Dec 8, 2014 at 7:17 PM, Gianluca Cecchi <gianluca.cecchi at gmail.com>
> wrote:
> 
>> OK. I will check requirements to write into The wiki
>>
> 
> 
> When I try to login with my Fedora OpenID account and choose as nickname my
> real name and press "login" actually it indefinitely remains on the blank
> page
> http://www.freeipa.org/page/Special:OpenIDLogin/ChooseName
> 
> without enabling me to log in and begin to write anything.
> Tried from both Chrome and Fedora (on my Fedora 20 system)....
> Similar problems when I used to use zanata to write oVirt Italian
> translation, but in that case with some difficulty I finally was able then
> to log in and begin to work... no way here

I updated the OpenID plugin on the FreeIPA.org wiki to the latest version. Can
you please try the login now? I wonder of it is related to the latest upgrade I
performed [1]...

> This OpenID thing doesn't seem very usable in my opinion...

So far, the OpenID log in&account creation this was the only convenience method
we came with to avoid manual account creation by the wiki administrators.
Simple wiki registration method did not work as then we got attacked by spam bots.

[1] https://www.redhat.com/archives/freeipa-devel/2014-November/msg00531.html



From mkosek at redhat.com  Tue Dec  9 09:52:53 2014
From: mkosek at redhat.com (Martin Kosek)
Date: Tue, 09 Dec 2014 10:52:53 +0100
Subject: [Freeipa-users] [Freeipa-interest] Announcing FreeIPA 4.1.2 -
 NEED HELP WITH 2FA/OTP!!!
In-Reply-To: <5486C581.9020209@redhat.com>
References: <54775877.6060102@redhat.com>	<176433463.23902008.1417805679430.JavaMail.zimbra@redhat.com>	<54845DA3.3070104@redhat.com>
	<5486BA7E.90100@redhat.com> <5486C09A.5060902@redhat.com>
	<5486C581.9020209@redhat.com>
Message-ID: <5486C675.4040003@redhat.com>

On 12/09/2014 10:48 AM, Niranjan M.R wrote:
> On 12/09/2014 02:57 PM, thierry bordaz wrote:
>> Hello,
> 
>> Niranjan, may I have access to your test machine.
> 
> It's a vm on my laptop. I am trying to reproduce on another VM
> to which i can give access. I will provide the details of this VM as soon
> as possible.
> 
> Mean while i am providing ns-slapd access logs, ipa-logs and pkispawn logs.

Thanks. I see no related errors in the DS errors log, I wonder if the suggested

# systemctl status dirsrv at EXAMPLE-ORG.service

would show anything interesting.

> 
> 
> 
>> thanks
>> theirry
> 
> 
>> On 12/09/2014 10:01 AM, Martin Kosek wrote:
>>> On 12/07/2014 03:01 PM, Niranjan M.R wrote:
>>>> On 12/06/2014 12:24 AM, Dmitri Pal wrote:
>>>>> Hello,
>>>>> WE NEED HELP!
>>>>> The biggest and the most interesting feature of FreeIPA 4.1.2 is support for the two factor authentication using HOTP/TOTP compatible software tokens like FreeOTP (open source compatible alternative to Google Authenticator) and hardware tokens like Yubikeys. This feature allows Kerberos and LDAP clients of a FreeIPA server to authenticate using the normal account password as the first factor and an OTP token as a second factor. For those environments where a 2FA solution is already in place, FreeIPA can act as a proxy via RADIUS. More about this feature can be read here.
>>>>> http://www.freeipa.org/page/V4/OTP
>>>>> If you want to see this feature in downstream distros sooner rather than later we need your help!
>>>>> Please give it a try and provide feedback. We really, really need it!
>>>> I am unable to configure ipa-server with freeipa-server-4.1.2-1.fc20.x86_64,  ipa-server-install fails with below error:
>>>>
>>>> Done configuring certificate server (pki-tomcatd).
>>>> Configuring directory server (dirsrv): Estimated time 10 seconds
>>>>    [1/3]: configuring ssl for ds instance
>>>>    [2/3]: restarting directory server
>>>> ipa         : CRITICAL Failed to restart the directory server ([Errno 2] No such file or directory:
>>>> '/etc/systemd/system/dirsrv.target.wants/dirsrv at EXAMPLE-ORG.service'). See the installation log for details.
>>>>    [3/3]: adding CA certificate entry
>>>> Done configuring directory server (dirsrv).
>>>> CA did not start in 300.0s
>>>>
>>>>
>>>> Versions used:
>>>> ==============
>>>> freeipa-client-4.1.2-1.fc20.x86_64
>>>> freeipa-server-4.1.2-1.fc20.x86_64
>>>> libipa_hbac-1.12.2-2.fc20.x86_64
>>>> libipa_hbac-python-1.12.2-2.fc20.x86_64
>>>> sssd-ipa-1.12.2-2.fc20.x86_64
>>>> device-mapper-multipath-0.4.9-56.fc20.x86_64
>>>> python-iniparse-0.4-9.fc20.noarch
>>>> freeipa-admintools-4.1.2-1.fc20.x86_64
>>>> freeipa-python-4.1.2-1.fc20.x86_64
>>>> 389-ds-base-libs-1.3.3.5-1.fc20.x86_64
>>>> 389-ds-base-1.3.3.5-1.fc20.x86_64
>>>>
>>>> BaseOS:Fedora release 20 (Heisenbug)
>>>>
>>>>
>>>> Steps to reproduce:
>>>> ---------------
>>>>
>>>> 1. On Fedora-20 system, Used mkosek freeipa repo:
>>>> [mkosek-freeipa]
>>>> name=Copr repo for freeipa owned by mkosek
>>>> baseurl=http://copr-be.cloud.fedoraproject.org/results/mkosek/freeipa/fedora-$releasever-$basearch/
>>>> skip_if_unavailable=True
>>>> gpgcheck=0
>>>> enabled=1
>>>>
>>>> 2. Install freeipa-server packages from the above repo
>>>>
>>>> 3. Issue ipa-server-install
>>>>
>>>> [root at pkiserver1 ~]# ipa-server-install
>>>>
>>>> The log file for this installation can be found in /var/log/ipaserver-install.log
>>>> ==============================================================================
>>>> This program will set up the FreeIPA Server.
>>>>
>>>> This includes:
>>>>    * Configure a stand-alone CA (dogtag) for certificate management
>>>>    * Configure the Network Time Daemon (ntpd)
>>>>    * Create and configure an instance of Directory Server
>>>>    * Create and configure a Kerberos Key Distribution Center (KDC)
>>>>    * Configure Apache (httpd)
>>>>
>>>> To accept the default shown in brackets, press the Enter key.
>>>>
>>>> WARNING: conflicting time&date synchronization service 'chronyd' will be disabled
>>>> in favor of ntpd
>>>>
>>>> Do you want to configure integrated DNS (BIND)? [no]: yes
>>>>
>>>> Existing BIND configuration detected, overwrite? [no]: yes
>>>> Enter the fully qualified domain name of the computer
>>>> on which you're setting up server software. Using the form
>>>> <hostname>.<domainname>
>>>> Example: master.example.com.
>>>>
>>>>
>>>> Server host name [pkiserver1.example.org]:
>>>>
>>>> Warning: skipping DNS resolution of host pkiserver1.example.org
>>>> The domain name has been determined based on the host name.
>>>>
>>>> Please confirm the domain name [example.org]:
>>>>
>>>> The kerberos protocol requires a Realm name to be defined.
>>>> This is typically the domain name converted to uppercase.
>>>>
>>>> Please provide a realm name [EXAMPLE.ORG]:
>>>> Certain directory server operations require an administrative user.
>>>> This user is referred to as the Directory Manager and has full access
>>>> to the Directory for system management tasks and will be added to the
>>>>
>>>> The IPA server requires an administrative user, named 'admin'.
>>>> This user is a regular system account used for IPA server administration.
>>>>
>>>> IPA admin password:
>>>> Password (confirm):
>>>>
>>>> Do you want to configure DNS forwarders? [yes]: no
>>>> No DNS forwarders configured
>>>> Do you want to configure the reverse zone? [yes]:
>>>> Please specify the reverse zone name [122.168.192.in-addr.arpa.]:
>>>> Using reverse zone(s) 122.168.192.in-addr.arpa.
>>>>
>>>> The IPA Master Server will be configured with:
>>>> Hostname:       pkiserver1.example.org
>>>> IP address(es): 192.168.122.246
>>>> Domain name:    example.org
>>>> Realm name:     EXAMPLE.ORG
>>>>
>>>> BIND DNS server will be configured to serve IPA domain with:
>>>> Forwarders:    No forwarders
>>>> Reverse zone(s):  122.168.192.in-addr.arpa.
>>>>
>>>> Continue to configure the system with these values? [no]: yes
>>>>
>>>> The following operations may take some minutes to complete.
>>>> Please wait until the prompt is returned.
>>>>
>>>>
>>>> instance of directory server created for IPA.
>>>> The password must be at least 8 characters long.
>>>>
>>>> Directory Manager password:
>>>> Password (confirm):
>>>> Configuring NTP daemon (ntpd)
>>>>    [1/4]: stopping ntpd
>>>>    [2/4]: writing configuration
>>>>    [3/4]: configuring ntpd to start on boot
>>>>    [4/4]: starting ntpd
>>>> Done configuring NTP daemon (ntpd).
>>>> Configuring directory server (dirsrv): Estimated time 1 minute
>>>>    [1/38]: creating directory server user
>>>>    [2/38]: creating directory server instance
>>>>    [3/38]: adding default schema
>>>>    [4/38]: enabling memberof plugin
>>>>    [5/38]: enabling winsync plugin
>>>>    [6/38]: configuring replication version plugin
>>>>    [7/38]: enabling IPA enrollment plugin
>>>>    [8/38]: enabling ldapi
>>>>    [9/38]: configuring uniqueness plugin
>>>>    [10/38]: configuring uuid plugin
>>>>    [11/38]: configuring modrdn plugin
>>>>    [12/38]: configuring DNS plugin
>>>>    [13/38]: enabling entryUSN plugin
>>>>    [14/38]: configuring lockout plugin
>>>>    [15/38]: creating indices
>>>>    [16/38]: enabling referential integrity plugin
>>>>    [17/38]: configuring certmap.conf
>>>>    [18/38]: configure autobind for root
>>>>    [19/38]: configure new location for managed entries
>>>>    [20/38]: configure dirsrv ccache
>>>>    [21/38]: enable SASL mapping fallback
>>>>    [22/38]: restarting directory server
>>>>    [23/38]: adding default layout
>>>>    [24/38]: adding delegation layout
>>>>    [25/38]: creating container for managed entries
>>>>    [26/38]: configuring user private groups
>>>>    [27/38]: configuring netgroups from hostgroups
>>>>    [28/38]: creating default Sudo bind user
>>>>    [29/38]: creating default Auto Member layout
>>>>    [30/38]: adding range check plugin
>>>>    [31/38]: creating default HBAC rule allow_all
>>>>    [32/38]: initializing group membership
>>>>    [33/38]: adding master entry
>>>>    [34/38]: configuring Posix uid/gid generation
>>>>    [35/38]: adding replication acis
>>>>    [36/38]: enabling compatibility plugin
>>>>    [37/38]: tuning directory server
>>>>    [38/38]: configuring directory to start on boot
>>>> Done configuring directory server (dirsrv).
>>>> Configuring certificate server (pki-tomcatd): Estimated time 3 minutes 30 seconds
>>>>    [1/27]: creating certificate server user
>>>>    [2/27]: configuring certificate server instance
>>>>    [3/27]: stopping certificate server instance to update CS.cfg
>>>>    [4/27]: backing up CS.cfg
>>>>    [5/27]: disabling nonces
>>>>    [6/27]: set up CRL publishing
>>>>    [7/27]: enable PKIX certificate path discovery and validation
>>>>    [8/27]: starting certificate server instance
>>>>    [9/27]: creating RA agent certificate database
>>>>    [10/27]: importing CA chain to RA certificate database
>>>>    [11/27]: fixing RA database permissions
>>>>    [12/27]: setting up signing cert profile
>>>>    [13/27]: set certificate subject base
>>>>    [14/27]: enabling Subject Key Identifier
>>>>    [15/27]: enabling Subject Alternative Name
>>>>    [16/27]: enabling CRL and OCSP extensions for certificates
>>>>    [17/27]: setting audit signing renewal to 2 years
>>>>    [18/27]: configuring certificate server to start on boot
>>>>    [19/27]: restarting certificate server
>>>>    [20/27]: requesting RA certificate from CA
>>>>    [21/27]: issuing RA agent certificate
>>>>    [22/27]: adding RA agent as a trusted user
>>>>    [23/27]: configure certmonger for renewals
>>>>    [24/27]: configure certificate renewals
>>>>    [25/27]: configure RA certificate renewal
>>>>    [26/27]: configure Server-Cert certificate renewal
>>>>    [27/27]: Configure HTTP to proxy connections
>>>> Done configuring certificate server (pki-tomcatd).
>>>> Configuring directory server (dirsrv): Estimated time 10 seconds
>>>>    [1/3]: configuring ssl for ds instance
>>>>    [2/3]: restarting directory server
>>>> ipa         : CRITICAL Failed to restart the directory server ([Errno 2] No such file or directory:
>>>> '/etc/systemd/system/dirsrv.target.wants/dirsrv at EXAMPLE-ORG.service'). See the installation log for details.
>>>>    [3/3]: adding CA certificate entry
>>>> Done configuring directory server (dirsrv).
>>>>
>>>> CA did not start in 300.0s
>>>>
>>>> Attaching ipaserver-install.log, pkispawn logs
>>>>
>>>> Any hints on how to overcome the above error.
>>> The error is obviously in Directory Server restart. I am not sure what causes
>>>
>>> 2014-12-07T11:16:25Z DEBUG   [2/3]: restarting directory server
>>> 2014-12-07T11:16:25Z CRITICAL Failed to restart the directory server ([Errno 2]
>>> No such file or directory:
>>> '/etc/systemd/system/dirsrv.target.wants/dirsrv at EXAMPLE-ORG.service'). See the
>>> installation log for details.
>>>
>>> The first restart worked and it uses the same call, AFAIK. It would be
>>> interesting to see the latest logs of the instance after ipa-server-install
>>> crashes:
>>>
>>> # systemctl status dirsrv at EXAMPLE-ORG.service
>>>
>>> It may have some useful logs that would reveal what happened.
>>>
>>> Martin
> 
> 
> 
> 



From tbordaz at redhat.com  Tue Dec  9 10:15:59 2014
From: tbordaz at redhat.com (thierry bordaz)
Date: Tue, 09 Dec 2014 11:15:59 +0100
Subject: [Freeipa-users] [Freeipa-interest] Announcing FreeIPA 4.1.2 -
 NEED HELP WITH 2FA/OTP!!!
In-Reply-To: <5486C581.9020209@redhat.com>
References: <54775877.6060102@redhat.com>	<176433463.23902008.1417805679430.JavaMail.zimbra@redhat.com>	<54845DA3.3070104@redhat.com>
	<5486BA7E.90100@redhat.com> <5486C09A.5060902@redhat.com>
	<5486C581.9020209@redhat.com>
Message-ID: <5486CBDF.7050606@redhat.com>

On 12/09/2014 10:48 AM, Niranjan M.R wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 12/09/2014 02:57 PM, thierry bordaz wrote:
>> Hello,
>>
>> Niranjan, may I have access to your test machine.
>>
> It's a vm on my laptop. I am trying to reproduce on another VM
> to which i can give access. I will provide the details of this VM as soon
> as possible.
>
> Mean while i am providing ns-slapd access logs, ipa-logs and pkispawn logs.

Something curious is that the installer is waiting for DS to restart but 
it is looking like DS has not received the terminaison signal.

2014-12-09T09:37:49Z DEBUG Waiting for CA to start...
...
2014-12-09T09:42:45Z DEBUG Waiting for CA to start...


[09/Dec/2014:04:37:41 -0500] - Warning: Adding configuration attribute 
"nsslapd-security"

<< here we should expect a restart of DS >>

First why DS did not receive the restart order and then as it is still 
running (DS looks idle) what does the install is waiting for.



>
>
>> thanks
>> theirry
>>
>>
>> On 12/09/2014 10:01 AM, Martin Kosek wrote:
>>> On 12/07/2014 03:01 PM, Niranjan M.R wrote:
>>>> On 12/06/2014 12:24 AM, Dmitri Pal wrote:
>>>>> Hello,
>>>>> WE NEED HELP!
>>>>> The biggest and the most interesting feature of FreeIPA 4.1.2 is support for the two factor authentication using HOTP/TOTP compatible software tokens like FreeOTP (open source compatible alternative to Google Authenticator) and hardware tokens like Yubikeys. This feature allows Kerberos and LDAP clients of a FreeIPA server to authenticate using the normal account password as the first factor and an OTP token as a second factor. For those environments where a 2FA solution is already in place, FreeIPA can act as a proxy via RADIUS. More about this feature can be read here.
>>>>> http://www.freeipa.org/page/V4/OTP
>>>>> If you want to see this feature in downstream distros sooner rather than later we need your help!
>>>>> Please give it a try and provide feedback. We really, really need it!
>>>> I am unable to configure ipa-server with freeipa-server-4.1.2-1.fc20.x86_64,  ipa-server-install fails with below error:
>>>>
>>>> Done configuring certificate server (pki-tomcatd).
>>>> Configuring directory server (dirsrv): Estimated time 10 seconds
>>>>     [1/3]: configuring ssl for ds instance
>>>>     [2/3]: restarting directory server
>>>> ipa         : CRITICAL Failed to restart the directory server ([Errno 2] No such file or directory:
>>>> '/etc/systemd/system/dirsrv.target.wants/dirsrv at EXAMPLE-ORG.service'). See the installation log for details.
>>>>     [3/3]: adding CA certificate entry
>>>> Done configuring directory server (dirsrv).
>>>> CA did not start in 300.0s
>>>>
>>>>
>>>> Versions used:
>>>> ==============
>>>> freeipa-client-4.1.2-1.fc20.x86_64
>>>> freeipa-server-4.1.2-1.fc20.x86_64
>>>> libipa_hbac-1.12.2-2.fc20.x86_64
>>>> libipa_hbac-python-1.12.2-2.fc20.x86_64
>>>> sssd-ipa-1.12.2-2.fc20.x86_64
>>>> device-mapper-multipath-0.4.9-56.fc20.x86_64
>>>> python-iniparse-0.4-9.fc20.noarch
>>>> freeipa-admintools-4.1.2-1.fc20.x86_64
>>>> freeipa-python-4.1.2-1.fc20.x86_64
>>>> 389-ds-base-libs-1.3.3.5-1.fc20.x86_64
>>>> 389-ds-base-1.3.3.5-1.fc20.x86_64
>>>>
>>>> BaseOS:Fedora release 20 (Heisenbug)
>>>>
>>>>
>>>> Steps to reproduce:
>>>> ---------------
>>>>
>>>> 1. On Fedora-20 system, Used mkosek freeipa repo:
>>>> [mkosek-freeipa]
>>>> name=Copr repo for freeipa owned by mkosek
>>>> baseurl=http://copr-be.cloud.fedoraproject.org/results/mkosek/freeipa/fedora-$releasever-$basearch/
>>>> skip_if_unavailable=True
>>>> gpgcheck=0
>>>> enabled=1
>>>>
>>>> 2. Install freeipa-server packages from the above repo
>>>>
>>>> 3. Issue ipa-server-install
>>>>
>>>> [root at pkiserver1 ~]# ipa-server-install
>>>>
>>>> The log file for this installation can be found in /var/log/ipaserver-install.log
>>>> ==============================================================================
>>>> This program will set up the FreeIPA Server.
>>>>
>>>> This includes:
>>>>     * Configure a stand-alone CA (dogtag) for certificate management
>>>>     * Configure the Network Time Daemon (ntpd)
>>>>     * Create and configure an instance of Directory Server
>>>>     * Create and configure a Kerberos Key Distribution Center (KDC)
>>>>     * Configure Apache (httpd)
>>>>
>>>> To accept the default shown in brackets, press the Enter key.
>>>>
>>>> WARNING: conflicting time&date synchronization service 'chronyd' will be disabled
>>>> in favor of ntpd
>>>>
>>>> Do you want to configure integrated DNS (BIND)? [no]: yes
>>>>
>>>> Existing BIND configuration detected, overwrite? [no]: yes
>>>> Enter the fully qualified domain name of the computer
>>>> on which you're setting up server software. Using the form
>>>> <hostname>.<domainname>
>>>> Example: master.example.com.
>>>>
>>>>
>>>> Server host name [pkiserver1.example.org]:
>>>>
>>>> Warning: skipping DNS resolution of host pkiserver1.example.org
>>>> The domain name has been determined based on the host name.
>>>>
>>>> Please confirm the domain name [example.org]:
>>>>
>>>> The kerberos protocol requires a Realm name to be defined.
>>>> This is typically the domain name converted to uppercase.
>>>>
>>>> Please provide a realm name [EXAMPLE.ORG]:
>>>> Certain directory server operations require an administrative user.
>>>> This user is referred to as the Directory Manager and has full access
>>>> to the Directory for system management tasks and will be added to the
>>>>
>>>> The IPA server requires an administrative user, named 'admin'.
>>>> This user is a regular system account used for IPA server administration.
>>>>
>>>> IPA admin password:
>>>> Password (confirm):
>>>>
>>>> Do you want to configure DNS forwarders? [yes]: no
>>>> No DNS forwarders configured
>>>> Do you want to configure the reverse zone? [yes]:
>>>> Please specify the reverse zone name [122.168.192.in-addr.arpa.]:
>>>> Using reverse zone(s) 122.168.192.in-addr.arpa.
>>>>
>>>> The IPA Master Server will be configured with:
>>>> Hostname:       pkiserver1.example.org
>>>> IP address(es): 192.168.122.246
>>>> Domain name:    example.org
>>>> Realm name:     EXAMPLE.ORG
>>>>
>>>> BIND DNS server will be configured to serve IPA domain with:
>>>> Forwarders:    No forwarders
>>>> Reverse zone(s):  122.168.192.in-addr.arpa.
>>>>
>>>> Continue to configure the system with these values? [no]: yes
>>>>
>>>> The following operations may take some minutes to complete.
>>>> Please wait until the prompt is returned.
>>>>
>>>>
>>>> instance of directory server created for IPA.
>>>> The password must be at least 8 characters long.
>>>>
>>>> Directory Manager password:
>>>> Password (confirm):
>>>> Configuring NTP daemon (ntpd)
>>>>     [1/4]: stopping ntpd
>>>>     [2/4]: writing configuration
>>>>     [3/4]: configuring ntpd to start on boot
>>>>     [4/4]: starting ntpd
>>>> Done configuring NTP daemon (ntpd).
>>>> Configuring directory server (dirsrv): Estimated time 1 minute
>>>>     [1/38]: creating directory server user
>>>>     [2/38]: creating directory server instance
>>>>     [3/38]: adding default schema
>>>>     [4/38]: enabling memberof plugin
>>>>     [5/38]: enabling winsync plugin
>>>>     [6/38]: configuring replication version plugin
>>>>     [7/38]: enabling IPA enrollment plugin
>>>>     [8/38]: enabling ldapi
>>>>     [9/38]: configuring uniqueness plugin
>>>>     [10/38]: configuring uuid plugin
>>>>     [11/38]: configuring modrdn plugin
>>>>     [12/38]: configuring DNS plugin
>>>>     [13/38]: enabling entryUSN plugin
>>>>     [14/38]: configuring lockout plugin
>>>>     [15/38]: creating indices
>>>>     [16/38]: enabling referential integrity plugin
>>>>     [17/38]: configuring certmap.conf
>>>>     [18/38]: configure autobind for root
>>>>     [19/38]: configure new location for managed entries
>>>>     [20/38]: configure dirsrv ccache
>>>>     [21/38]: enable SASL mapping fallback
>>>>     [22/38]: restarting directory server
>>>>     [23/38]: adding default layout
>>>>     [24/38]: adding delegation layout
>>>>     [25/38]: creating container for managed entries
>>>>     [26/38]: configuring user private groups
>>>>     [27/38]: configuring netgroups from hostgroups
>>>>     [28/38]: creating default Sudo bind user
>>>>     [29/38]: creating default Auto Member layout
>>>>     [30/38]: adding range check plugin
>>>>     [31/38]: creating default HBAC rule allow_all
>>>>     [32/38]: initializing group membership
>>>>     [33/38]: adding master entry
>>>>     [34/38]: configuring Posix uid/gid generation
>>>>     [35/38]: adding replication acis
>>>>     [36/38]: enabling compatibility plugin
>>>>     [37/38]: tuning directory server
>>>>     [38/38]: configuring directory to start on boot
>>>> Done configuring directory server (dirsrv).
>>>> Configuring certificate server (pki-tomcatd): Estimated time 3 minutes 30 seconds
>>>>     [1/27]: creating certificate server user
>>>>     [2/27]: configuring certificate server instance
>>>>     [3/27]: stopping certificate server instance to update CS.cfg
>>>>     [4/27]: backing up CS.cfg
>>>>     [5/27]: disabling nonces
>>>>     [6/27]: set up CRL publishing
>>>>     [7/27]: enable PKIX certificate path discovery and validation
>>>>     [8/27]: starting certificate server instance
>>>>     [9/27]: creating RA agent certificate database
>>>>     [10/27]: importing CA chain to RA certificate database
>>>>     [11/27]: fixing RA database permissions
>>>>     [12/27]: setting up signing cert profile
>>>>     [13/27]: set certificate subject base
>>>>     [14/27]: enabling Subject Key Identifier
>>>>     [15/27]: enabling Subject Alternative Name
>>>>     [16/27]: enabling CRL and OCSP extensions for certificates
>>>>     [17/27]: setting audit signing renewal to 2 years
>>>>     [18/27]: configuring certificate server to start on boot
>>>>     [19/27]: restarting certificate server
>>>>     [20/27]: requesting RA certificate from CA
>>>>     [21/27]: issuing RA agent certificate
>>>>     [22/27]: adding RA agent as a trusted user
>>>>     [23/27]: configure certmonger for renewals
>>>>     [24/27]: configure certificate renewals
>>>>     [25/27]: configure RA certificate renewal
>>>>     [26/27]: configure Server-Cert certificate renewal
>>>>     [27/27]: Configure HTTP to proxy connections
>>>> Done configuring certificate server (pki-tomcatd).
>>>> Configuring directory server (dirsrv): Estimated time 10 seconds
>>>>     [1/3]: configuring ssl for ds instance
>>>>     [2/3]: restarting directory server
>>>> ipa         : CRITICAL Failed to restart the directory server ([Errno 2] No such file or directory:
>>>> '/etc/systemd/system/dirsrv.target.wants/dirsrv at EXAMPLE-ORG.service'). See the installation log for details.
>>>>     [3/3]: adding CA certificate entry
>>>> Done configuring directory server (dirsrv).
>>>>
>>>> CA did not start in 300.0s
>>>>
>>>> Attaching ipaserver-install.log, pkispawn logs
>>>>
>>>> Any hints on how to overcome the above error.
>>> The error is obviously in Directory Server restart. I am not sure what causes
>>>
>>> 2014-12-07T11:16:25Z DEBUG   [2/3]: restarting directory server
>>> 2014-12-07T11:16:25Z CRITICAL Failed to restart the directory server ([Errno 2]
>>> No such file or directory:
>>> '/etc/systemd/system/dirsrv.target.wants/dirsrv at EXAMPLE-ORG.service'). See the
>>> installation log for details.
>>>
>>> The first restart worked and it uses the same call, AFAIK. It would be
>>> interesting to see the latest logs of the instance after ipa-server-install
>>> crashes:
>>>
>>> # systemctl status dirsrv at EXAMPLE-ORG.service
>>>
>>> It may have some useful logs that would reveal what happened.
>>>
>>> Martin
>
> - -- 
> Niranjan
> irc: mrniranjan
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
>
> iKYEARECAGYFAlSGxYFfFIAAAAAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl
> bnBncC5maWZ0aGhvcnNlbWFuLm5ldEY3OTE3QTg3ODE0RkVCQ0YyNjgyOTRENjJF
> RURDNTVGNjA0N0M3QzcACgkQLu3FX2BHx8e61wCgtCSWtdpOMWVP+Pr7fPmoXiPC
> DAsAoI0phFg3dtQJNRvpm8YCjLEs9r66
> =1MYR
> -----END PGP SIGNATURE-----



From mkosek at redhat.com  Tue Dec  9 11:00:27 2014
From: mkosek at redhat.com (Martin Kosek)
Date: Tue, 09 Dec 2014 12:00:27 +0100
Subject: [Freeipa-users] [Freeipa-interest] Announcing FreeIPA 4.1.2 -
 NEED HELP WITH 2FA/OTP!!!
In-Reply-To: <5486CBDF.7050606@redhat.com>
References: <54775877.6060102@redhat.com>	<176433463.23902008.1417805679430.JavaMail.zimbra@redhat.com>	<54845DA3.3070104@redhat.com>
	<5486BA7E.90100@redhat.com> <5486C09A.5060902@redhat.com>
	<5486C581.9020209@redhat.com> <5486CBDF.7050606@redhat.com>
Message-ID: <5486D64B.5010603@redhat.com>

On 12/09/2014 11:15 AM, thierry bordaz wrote:
> On 12/09/2014 10:48 AM, Niranjan M.R wrote:
> On 12/09/2014 02:57 PM, thierry bordaz wrote:
>>>> Hello,
>>>>
>>>> Niranjan, may I have access to your test machine.
>>>>
> It's a vm on my laptop. I am trying to reproduce on another VM
> to which i can give access. I will provide the details of this VM as soon
> as possible.
> 
> Mean while i am providing ns-slapd access logs, ipa-logs and pkispawn logs.
> 
>> Something curious is that the installer is waiting for DS to restart but it is
>> looking like DS has not received the terminaison signal.
> 
>> 2014-12-09T09:37:49Z DEBUG Waiting for CA to start...
>> ...
>> 2014-12-09T09:42:45Z DEBUG Waiting for CA to start...
> 
> 
>> [09/Dec/2014:04:37:41 -0500] - Warning: Adding configuration attribute
>> "nsslapd-security"
> 
>> << here we should expect a restart of DS >>
> 
>> First why DS did not receive the restart order and then as it is still running
>> (DS looks idle) what does the install is waiting for.

Petr Vobornik today tried installing FreeIPA packages from Copr on Fedora 20
and it worked. (I now wonder if you set SELinux to permissive before installing
FreeIPA, it may have blocked some call).

Maybe the best approach for testing would be to try FreeIPA on Fedora 21, it
contains much less backported packages than the Fedora 20 mkosek/freeipa Copr repo.

Martin



From chymian at gmx.net  Tue Dec  9 12:48:09 2014
From: chymian at gmx.net (chymian)
Date: Tue, 09 Dec 2014 13:48:09 +0100
Subject: [Freeipa-users] Unit pki-tomcatd@pki-tomcat.service entered failed
	state @ vanilla install on jessie
Message-ID: <13509504.9EBG6n5Zxl@hansa>

hey people,

after a successful install of ipa 4.0.5-2 on jessie, the named services started flawless during setup. see attached log, Installation summary (line 3107)
but after reboot, it refuses to start. (did this install a couple times, on vanilla jessie)

I can reach & work with Dogtag https://ipa.eb8.lan:8443/ca, but not the admin-services on https://ipa.eb8.lan/ca/ee/ca and https://ipa.eb8.lan/ca/agent/ca.


$ systemctl status pki-tomcatd at pki-tomcat.service
? pki-tomcatd at pki-tomcat.service - PKI Tomcat Server pki-tomcat
   Loaded: loaded (/lib/systemd/system/pki-tomcatd at .service; enabled)
   Active: failed (Result: resources)

Dez 08 20:40:13 ipa systemd[1]: Starting PKI Tomcat Server pki-tomcat...
Dez 08 20:40:13 ipa systemd[1]: Failed to load environment files: No such file or directory
Dez 08 20:40:13 ipa systemd[1]: pki-tomcatd at pki-tomcat.service failed to run 'start-pre' task: No such file or directory
Dez 08 20:40:13 ipa systemd[1]: Failed to start PKI Tomcat Server pki-tomcat.
Dez 08 20:40:13 ipa systemd[1]: Unit pki-tomcatd at pki-tomcat.service entered failed state.


a second service fails to start:

$ systemctl status dirsrv-snmp.service
? dirsrv-snmp.service - 389 Directory Server SNMP Subagent.
   Loaded: loaded (/lib/systemd/system/dirsrv-snmp.service; enabled)
   Active: failed (Result: exit-code) since Di 2014-12-09 13:25:04 CET; 5min ago
  Process: 156 ExecStart=/usr/sbin/ldap-agent /etc/dirsrv/config/ldap-agent.conf (code=exited, status=1/FAILURE)

Dez 09 13:25:04 ipa systemd[1]: Starting 389 Directory Server SNMP Subagent....
Dez 09 13:25:04 ipa ldap-agent[156]: ldap-agent: No server instances defined in config file
Dez 09 13:25:04 ipa systemd[1]: dirsrv-snmp.service: control process exited, code=exited status=1
Dez 09 13:25:04 ipa systemd[1]: Failed to start 389 Directory Server SNMP Subagent..
Dez 09 13:25:04 ipa systemd[1]: Unit dirsrv-snmp.service entered failed state.


except these, I was able to subscribe a jessie-client with autodiscovery right after I did configure the ipa-server, before first reboot.


any help appreciated, since I do not have much experience with IPA ? yet.
guenter





From chymian at gmx.net  Tue Dec  9 12:54:22 2014
From: chymian at gmx.net (chymian)
Date: Tue, 09 Dec 2014 13:54:22 +0100
Subject: [Freeipa-users] =?utf-8?q?Unit_pki-tomcatd=40pki-tomcat=2Eservice?=
	=?utf-8?q?_entered_failed_state_=40_vanilla_install_on_jessie_?=
	=?utf-8?q?=E2=80=93_with_log_attached?=
Message-ID: <6538670.riIOSljqhg@hansa>

hey people,

after a successful install of ipa 4.0.5-2 on jessie, the named services started flawless during setup. see attached log, Installation summary (line 3107)
but after reboot, it refuses to start. (did this install a couple times, on vanilla jessie)

I can reach & work with Dogtag https://ipa.eb8.lan:8443/ca, but not the admin-services on https://ipa.eb8.lan/ca/ee/ca and https://ipa.eb8.lan/ca/agent/ca.


$ systemctl status pki-tomcatd at pki-tomcat.service
? pki-tomcatd at pki-tomcat.service - PKI Tomcat Server pki-tomcat
   Loaded: loaded (/lib/systemd/system/pki-tomcatd at .service; enabled)
   Active: failed (Result: resources)

Dez 08 20:40:13 ipa systemd[1]: Starting PKI Tomcat Server pki-tomcat...
Dez 08 20:40:13 ipa systemd[1]: Failed to load environment files: No such file or directory
Dez 08 20:40:13 ipa systemd[1]: pki-tomcatd at pki-tomcat.service failed to run 'start-pre' task: No such file or directory
Dez 08 20:40:13 ipa systemd[1]: Failed to start PKI Tomcat Server pki-tomcat.
Dez 08 20:40:13 ipa systemd[1]: Unit pki-tomcatd at pki-tomcat.service entered failed state.


a second service fails to start:

$ systemctl status dirsrv-snmp.service
? dirsrv-snmp.service - 389 Directory Server SNMP Subagent.
   Loaded: loaded (/lib/systemd/system/dirsrv-snmp.service; enabled)
   Active: failed (Result: exit-code) since Di 2014-12-09 13:25:04 CET; 5min ago
  Process: 156 ExecStart=/usr/sbin/ldap-agent /etc/dirsrv/config/ldap-agent.conf (code=exited, status=1/FAILURE)

Dez 09 13:25:04 ipa systemd[1]: Starting 389 Directory Server SNMP Subagent....
Dez 09 13:25:04 ipa ldap-agent[156]: ldap-agent: No server instances defined in config file
Dez 09 13:25:04 ipa systemd[1]: dirsrv-snmp.service: control process exited, code=exited status=1
Dez 09 13:25:04 ipa systemd[1]: Failed to start 389 Directory Server SNMP Subagent..
Dez 09 13:25:04 ipa systemd[1]: Unit dirsrv-snmp.service entered failed state.


except these, I was able to subscribe a jessie-client with autodiscovery right after I did configure the ipa-server, before first reboot.


any help appreciated, since I do not have much experience with IPA ? yet.
guenter
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ipaserver-install.log.zip
Type: application/zip
Size: 111711 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141209/f4b47703/attachment.zip>

From tbordaz at redhat.com  Tue Dec  9 13:10:48 2014
From: tbordaz at redhat.com (thierry bordaz)
Date: Tue, 09 Dec 2014 14:10:48 +0100
Subject: [Freeipa-users]
 =?windows-1252?q?Unit_pki-tomcatd=40pki-tomcat=2E?=
 =?windows-1252?q?service_entered_failed_state_=40_vanilla_install_on_jess?=
 =?windows-1252?q?ie_=96_with_log_attached?=
In-Reply-To: <6538670.riIOSljqhg@hansa>
References: <6538670.riIOSljqhg@hansa>
Message-ID: <5486F4D8.6040700@redhat.com>

On 12/09/2014 01:54 PM, chymian wrote:
> hey people,
>
> after a successful install of ipa 4.0.5-2 on jessie, the named services started flawless during setup. see attached log, Installation summary (line 3107)
> but after reboot, it refuses to start. (did this install a couple times, on vanilla jessie)
>
> I can reach & work with Dogtag https://ipa.eb8.lan:8443/ca, but not the admin-services on https://ipa.eb8.lan/ca/ee/ca and https://ipa.eb8.lan/ca/agent/ca.
>
>
> $ systemctl status pki-tomcatd at pki-tomcat.service
> ? pki-tomcatd at pki-tomcat.service - PKI Tomcat Server pki-tomcat
>     Loaded: loaded (/lib/systemd/system/pki-tomcatd at .service; enabled)
>     Active: failed (Result: resources)
>
> Dez 08 20:40:13 ipa systemd[1]: Starting PKI Tomcat Server pki-tomcat...
> Dez 08 20:40:13 ipa systemd[1]: Failed to load environment files: No such file or directory
> Dez 08 20:40:13 ipa systemd[1]: pki-tomcatd at pki-tomcat.service failed to run 'start-pre' task: No such file or directory
> Dez 08 20:40:13 ipa systemd[1]: Failed to start PKI Tomcat Server pki-tomcat.
> Dez 08 20:40:13 ipa systemd[1]: Unit pki-tomcatd at pki-tomcat.service entered failed state.
>
>
> a second service fails to start:
>
> $ systemctl status dirsrv-snmp.service
> ? dirsrv-snmp.service - 389 Directory Server SNMP Subagent.
>     Loaded: loaded (/lib/systemd/system/dirsrv-snmp.service; enabled)
>     Active: failed (Result: exit-code) since Di 2014-12-09 13:25:04 CET; 5min ago
>    Process: 156 ExecStart=/usr/sbin/ldap-agent /etc/dirsrv/config/ldap-agent.conf (code=exited, status=1/FAILURE)
>
> Dez 09 13:25:04 ipa systemd[1]: Starting 389 Directory Server SNMP Subagent....
> Dez 09 13:25:04 ipa ldap-agent[156]: ldap-agent: No server instances defined in config file
> Dez 09 13:25:04 ipa systemd[1]: dirsrv-snmp.service: control process exited, code=exited status=1
> Dez 09 13:25:04 ipa systemd[1]: Failed to start 389 Directory Server SNMP Subagent..
> Dez 09 13:25:04 ipa systemd[1]: Unit dirsrv-snmp.service entered failed state.

Hello,

regarding this issue. Is there a agent log file under 
/var/log/dirsrv/agent/ ?

thanks
thierry
>
>
> except these, I was able to subscribe a jessie-client with autodiscovery right after I did configure the ipa-server, before first reboot.
>
>
> any help appreciated, since I do not have much experience with IPA ? yet.
> guenter
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141209/44254549/attachment.htm>

From nagemnna at gmail.com  Tue Dec  9 13:33:05 2014
From: nagemnna at gmail.com (Megan .)
Date: Tue, 9 Dec 2014 08:33:05 -0500
Subject: [Freeipa-users] can't register new clients
In-Reply-To: <5486BE72.5020506@redhat.com>
References: <CACMA5-xsgZ2RcF7rx9MS+jtxpyMOofhpU0MnPn+1mcmHGOxNkg@mail.gmail.com>
	<54821AA7.1000007@redhat.com> <54821D9B.80502@redhat.com>
	<CACMA5-xs3gOMAdjg3o5aG6d58d-CvqPh5k9yo23pLSD9uXAq9Q@mail.gmail.com>
	<548225F9.7010001@redhat.com>
	<CACMA5-w=BmD+=9Gj7Q=U0oheEQOb40zfdzST_ASixiuKs5TqHA@mail.gmail.com>
	<54822D6D.1050807@redhat.com>
	<CACMA5-z+rt0e7tkf_UY5L_YzbQNcmRrNbNDQv3H01a=O9sXmxg@mail.gmail.com>
	<CACMA5-wY7+ceQm8GOT11=8MttRgNcZfsS8sg8X25AOMfo+22Jg@mail.gmail.com>
	<5486BE72.5020506@redhat.com>
Message-ID: <CACMA5-wOWDtgXDZU+3CXjtVcxmMm_43Yj6sHj1WF5PGVq5M35Q@mail.gmail.com>

Everything looks ok.

Our Networks team only opened 443 from the client to the server.  is
80 required to be open too for registration?  80 is a lot harder for
me to request on our network.

I think I might have found the issue.  Maybe it can't verify the CA
because its pointing to port 80, and 80 isn't open.  Is it possible to
change the certificate so this information is available via 443 or
does that not make sense since its trying to get information about the
secure connection in the first place.

from the server:
[root at dir1 ipa]# openssl verify -verbose -CAFile ca.crt
.
.
            Authority Information Access:
                OCSP - URI:http://dir1.example.com:80/ca/ocsp
.



[root at data2-uat ipa]# wget https://dir1.example.com/ipa/config/ca.crt
-O /tmp/ipa.crt
--2014-12-09 13:21:32--  https://dir1.example.com/ipa/config/ca.crt
Resolving dir1.example.com... 172.28.27.170
Connecting to dir1.example.com|172.28.27.170|:443... connected.
ERROR: cannot verify dir1.example.com?s certificate, issued by
?/O=EXAMPLE.COM/CN=Certificate Authority?:
  Self-signed certificate encountered.
To connect to dir1.example.com insecurely, use ?--no-check-certificate?.
[root at data2-uat ipa]# wget https://dir1.example.com/ipa/config/ca.crt
-O /tmp/ipa.crt --no-check-certificate
--2014-12-09 13:22:11--  https://dir1.example.com/ipa/config/ca.crt
Resolving dir1.example.com... 172.28.27.170
Connecting to dir1.example.com|172.28.27.170|:443... connected.
WARNING: cannot verify dir1.example.com?s certificate, issued by
?/O=EXAMPLE.COM/CN=Certificate Authority?:
  Self-signed certificate encountered.
HTTP request sent, awaiting response... 200 OK
Length: 1357 (1.3K) [application/x-x509-ca-cert]
Saving to: ?/tmp/ipa.crt?

100%[================================================>] 1,357
--.-K/s   in 0.005s

2014-12-09 13:22:11 (246 KB/s) - ?/tmp/ipa.crt? saved [1357/1357]

[root at data2-uat ipa]# cd /tmp
[root at data2-uat tmp]# openssl s_client -host dir1.example.com  -port
443 -CAfile /tmp/ipa.crt
CONNECTED(00000003)
depth=1 O = EXAMPLE.COM, CN = Certificate Authority
verify return:1
depth=0 O = EXAMPLE.COM, CN = dir1.example.com
verify return:1
---
Certificate chain
 0 s:/O=EXAMPLE.COM/CN=dir1.example.com
   i:/O=EXAMPLE.COM/CN=Certificate Authority
 1 s:/O=EXAMPLE.COM/CN=Certificate Authority
   i:/O=EXAMPLE.COM/CN=Certificate Authority
---
Server certificate
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
subject=/O=EXAMPLE.COM/CN=dir1.example.com
issuer=/O=EXAMPLE.COM/CN=Certificate Authority
---
No client certificate CA names sent
---
SSL handshake has read 2095 bytes and written 591 bytes
---
New, TLSv1/SSLv3, Cipher is AES128-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1.1
    Cipher    : AES128-SHA
    Session-ID: F6A664BC942DF235EF546007379A79A00245G34FA7C0E6F191B911E9CFEC17D0
    Session-ID-ctx:
    Master-Key:
8C9A5FB1DFDDA72FF09780A85A43FA3C1AA14D4FB199F510A0DC3DF0C53DFFFFCDD0F26211CA886342E84030EA891959
    Key-Arg   : None
    Krb5 Principal: None
    PSK identity: None
    PSK identity hint: None
    Start Time: 1418131359
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---
closed

On Tue, Dec 9, 2014 at 4:18 AM, Martin Kosek <mkosek at redhat.com> wrote:
> On 12/08/2014 08:00 PM, Megan . wrote:
>> I looked through the logs on the server and i see the below error in
>> the apache error log when i try to register a client:
>>
>> [Mon Dec 08 12:20:38 2014] [error] SSL Library Error: -12195 Peer does
>> not recognize and trust the CA that issued your certificate
>>
>>
>> I ran ipa-getcert list and everything seems ok (nothing expired) but
>> i'm not sure where to troubleshoot from here.
>
> The next step would be to check the actual HTTP certificate (on the client
> machine) and see what's wrong. I did a simple test you can follow:
>
> # wget http://ipa.mkosek-f21.test/ipa/config/ca.crt -O /tmp/ipa.crt
> # openssl s_client -host ipa.mkosek-f21.test -port 443 -CAfile /tmp/ipa.crt
> CONNECTED(00000003)
> depth=1 O = MKOSEK-F21.TEST, CN = Certificate Authority
> verify return:1
> depth=0 O = MKOSEK-F21.TEST, CN = ipa.mkosek-f21.test
> verify return:1
> ---
> Certificate chain
>  0 s:/O=MKOSEK-F21.TEST/CN=ipa.mkosek-f21.test
>    i:/O=MKOSEK-F21.TEST/CN=Certificate Authority
>  1 s:/O=MKOSEK-F21.TEST/CN=Certificate Authority
>    i:/O=MKOSEK-F21.TEST/CN=Certificate Authority
> ---
> Server certificate
> ...
> SSL-Session:
>     Protocol  : TLSv1.2
>     Cipher    : AES128-SHA
>     Session-ID: 5A4B326D2E8FB80408D628D1975C49C4F78D3E65F31E475F9E7B9BBBE11F576E
>     Session-ID-ctx:
>     Master-Key:
> D5C31E9E36503ADC9F162439B41A7A608260D7DF5EB357FB3D79C9CFAE700912526893E7DD9AA56F5B6CD320FBA98C49
>     Key-Arg   : None
>     Krb5 Principal: None
>     PSK identity: None
>     PSK identity hint: None
>     Start Time: 1418073191
>     Timeout   : 300 (sec)
>     Verify return code: 0 (ok)
> ---
>
>>
>>
>>
>> On Fri, Dec 5, 2014 at 7:51 PM, Megan . <nagemnna at gmail.com> wrote:
>>> It failed again.
>>>
>>>
>>> [root at cache2-uat ~]# certutil -L -d sql:/etc/pki/nssdb
>>>
>>> Certificate Nickname                                         Trust Attributes
>>>                                                              SSL,S/MIME,JAR/XPI
>>> [root at cache2-uat ~]#
>>>
>>> Not sure if its related, but on the directory server in the apache
>>> error.log I see the below every time a client tries to register:
>>>
>>> [Sat Dec 06 00:48:35 2014] [error] SSL Library Error: -12271 SSL
>>> client cannot verify your certificate
>>>
>>> On the directory server i ran ipa-getcert list and the certs seem ok.
>>>
>>>
>>>
>>> On Fri, Dec 5, 2014 at 5:10 PM, Rob Crittenden <rcritten at redhat.com> wrote:
>>>> Megan . wrote:
>>>>> Sorry for being unclear. It still fails.  Same error.
>>>>
>>>> Hmm, strange. Try being explicit about sql:
>>>>
>>>> # certutil -L -d sql:/etc/pki/nssdb
>>>>
>>>> And if there is a CA cert there, delete it.
>>>>
>>>> rob
>>>>
>>>>>
>>>>> On Dec 5, 2014 4:39 PM, "Rob Crittenden" <rcritten at redhat.com
>>>>> <mailto:rcritten at redhat.com>> wrote:
>>>>>
>>>>>     Megan . wrote:
>>>>>     > Thanks.
>>>>>     >
>>>>>     > I did have an issue last week where i tried to do the client install
>>>>>     > and it failed because of a firewall issue.  Networks has it opened
>>>>>     > now.  I deleted ca.crt before trying again.  There doesn't seem to be
>>>>>     > a certificate in /etc/pki/nssdb for it.
>>>>>     >
>>>>>     >
>>>>>     >
>>>>>     > [root at data2-uat ipa]# certutil -L -d /etc/pki/nssdb
>>>>>     >
>>>>>     >
>>>>>     > Certificate Nickname                                         Trust
>>>>>     Attributes
>>>>>     >
>>>>>     >
>>>>>     SSL,S/MIME,JAR/XPI
>>>>>     >
>>>>>     >
>>>>>     > [root at data2-uat ipa]# certutil -D -n 'IPA CA' -d /etc/pki/nssdb
>>>>>     >
>>>>>     > certutil: could not find certificate named "IPA CA":
>>>>>     > SEC_ERROR_BAD_DATABASE: security library: bad database.
>>>>>     >
>>>>>     > [root at data2-uat ipa]# ls
>>>>>     >
>>>>>     > [root at data2-uat ipa]# pwd
>>>>>     >
>>>>>     > /etc/ipa
>>>>>     >
>>>>>     > [root at data2-uat ipa]# ls -al
>>>>>     >
>>>>>     > total 16
>>>>>     >
>>>>>     > drwxr-xr-x.  2 root root  4096 Dec  5 21:16 .
>>>>>     >
>>>>>     > drwxr-xr-x. 82 root root 12288 Dec  5 21:16 ..
>>>>>     >
>>>>>     > [root at data2-uat ipa]#
>>>>>
>>>>>     So trying to install the client again fails or succeeds now?
>>>>>
>>>>>     rob
>>>>>
>>>>>     >
>>>>>     > On Fri, Dec 5, 2014 at 4:03 PM, Rob Crittenden
>>>>>     <rcritten at redhat.com <mailto:rcritten at redhat.com>> wrote:
>>>>>     >> Rob Crittenden wrote:
>>>>>     >>> Megan . wrote:
>>>>>     >>>> Good Day!
>>>>>     >>>>
>>>>>     >>>> I am getting an error when i register new clients.
>>>>>     >>>>
>>>>>     >>>> libcurl failed to execute the HTTP POST transaction.  SSL
>>>>>     connect error
>>>>>     >>>>
>>>>>     >>>> I can't find anything useful not the internet about the error.  Can
>>>>>     >>>> someone help me troubleshoot?
>>>>>     >>>>
>>>>>     >>>> CentOS 6.6  x64
>>>>>     >>>> ipa-client-3.0.0-42.el6.centos.x86_64
>>>>>     >>>> ipa-server-3.0.0-42.el6.centos.x86_64
>>>>>     >>>> curl-7.19.7-40.el6_6.1.x86_64
>>>>>     >>>
>>>>>     >>> Do you have NSS_DEFAULT_DB_TYPE set to sql? I don't know that
>>>>>     we've done
>>>>>     >>> any testing on the client with this set.
>>>>>     >>
>>>>>     >> Never mind, that's not it. The problem is:
>>>>>     >>
>>>>>     >> * NSS error -8054
>>>>>     >>
>>>>>     >> Which is SEC_ERROR_REUSED_ISSUER_AND_SERIAL
>>>>>     >>
>>>>>     >> So I'd do this:
>>>>>     >>
>>>>>     >> # rm /etc/ipa/ca.crt
>>>>>     >>
>>>>>     >> You may also want to ensure that the IPA CA certificate isn't in
>>>>>     >> /etc/pki/nssdb:
>>>>>     >>
>>>>>     >> # certutil -L -d /etc/pki/nssdb
>>>>>     >>
>>>>>     >> And then perhaps
>>>>>     >>
>>>>>     >> # certutil -D -n 'IPA CA' -d /etc/pki/nssdb
>>>>>     >>
>>>>>     >> rob
>>>>>     >>
>>>>>
>>>>
>>
>



From rcritten at redhat.com  Tue Dec  9 14:05:20 2014
From: rcritten at redhat.com (Rob Crittenden)
Date: Tue, 09 Dec 2014 09:05:20 -0500
Subject: [Freeipa-users] can't register new clients
In-Reply-To: <CACMA5-wOWDtgXDZU+3CXjtVcxmMm_43Yj6sHj1WF5PGVq5M35Q@mail.gmail.com>
References: <CACMA5-xsgZ2RcF7rx9MS+jtxpyMOofhpU0MnPn+1mcmHGOxNkg@mail.gmail.com>	<54821AA7.1000007@redhat.com>
	<54821D9B.80502@redhat.com>	<CACMA5-xs3gOMAdjg3o5aG6d58d-CvqPh5k9yo23pLSD9uXAq9Q@mail.gmail.com>	<548225F9.7010001@redhat.com>	<CACMA5-w=BmD+=9Gj7Q=U0oheEQOb40zfdzST_ASixiuKs5TqHA@mail.gmail.com>	<54822D6D.1050807@redhat.com>	<CACMA5-z+rt0e7tkf_UY5L_YzbQNcmRrNbNDQv3H01a=O9sXmxg@mail.gmail.com>	<CACMA5-wY7+ceQm8GOT11=8MttRgNcZfsS8sg8X25AOMfo+22Jg@mail.gmail.com>	<5486BE72.5020506@redhat.com>
	<CACMA5-wOWDtgXDZU+3CXjtVcxmMm_43Yj6sHj1WF5PGVq5M35Q@mail.gmail.com>
Message-ID: <548701A0.8000507@redhat.com>

Megan . wrote:
> Everything looks ok.
> 
> Our Networks team only opened 443 from the client to the server.  is
> 80 required to be open too for registration?  80 is a lot harder for
> me to request on our network.
> 
> I think I might have found the issue.  Maybe it can't verify the CA
> because its pointing to port 80, and 80 isn't open.  Is it possible to
> change the certificate so this information is available via 443 or
> does that not make sense since its trying to get information about the
> secure connection in the first place.

I don't think port 80 is the problem and in any case, it is just a
fallback in case the client can't get it via LDAP which in new installs
shouldn't be an issue. You'd get an error that the CA couldn't be
retrieved at all and not that a duplicate serial existed.

Is this happening on every client or just one?

Did you have a previous IPA install and you are re-enrolling this
client(s) into the new one?

rob

> 
> from the server:
> [root at dir1 ipa]# openssl verify -verbose -CAFile ca.crt
> .
> .
>             Authority Information Access:
>                 OCSP - URI:http://dir1.example.com:80/ca/ocsp
> .
> 
> 
> 
> [root at data2-uat ipa]# wget https://dir1.example.com/ipa/config/ca.crt
> -O /tmp/ipa.crt
> --2014-12-09 13:21:32--  https://dir1.example.com/ipa/config/ca.crt
> Resolving dir1.example.com... 172.28.27.170
> Connecting to dir1.example.com|172.28.27.170|:443... connected.
> ERROR: cannot verify dir1.example.com?s certificate, issued by
> ?/O=EXAMPLE.COM/CN=Certificate Authority?:
>   Self-signed certificate encountered.
> To connect to dir1.example.com insecurely, use ?--no-check-certificate?.
> [root at data2-uat ipa]# wget https://dir1.example.com/ipa/config/ca.crt
> -O /tmp/ipa.crt --no-check-certificate
> --2014-12-09 13:22:11--  https://dir1.example.com/ipa/config/ca.crt
> Resolving dir1.example.com... 172.28.27.170
> Connecting to dir1.example.com|172.28.27.170|:443... connected.
> WARNING: cannot verify dir1.example.com?s certificate, issued by
> ?/O=EXAMPLE.COM/CN=Certificate Authority?:
>   Self-signed certificate encountered.
> HTTP request sent, awaiting response... 200 OK
> Length: 1357 (1.3K) [application/x-x509-ca-cert]
> Saving to: ?/tmp/ipa.crt?
> 
> 100%[================================================>] 1,357
> --.-K/s   in 0.005s
> 
> 2014-12-09 13:22:11 (246 KB/s) - ?/tmp/ipa.crt? saved [1357/1357]
> 
> [root at data2-uat ipa]# cd /tmp
> [root at data2-uat tmp]# openssl s_client -host dir1.example.com  -port
> 443 -CAfile /tmp/ipa.crt
> CONNECTED(00000003)
> depth=1 O = EXAMPLE.COM, CN = Certificate Authority
> verify return:1
> depth=0 O = EXAMPLE.COM, CN = dir1.example.com
> verify return:1
> ---
> Certificate chain
>  0 s:/O=EXAMPLE.COM/CN=dir1.example.com
>    i:/O=EXAMPLE.COM/CN=Certificate Authority
>  1 s:/O=EXAMPLE.COM/CN=Certificate Authority
>    i:/O=EXAMPLE.COM/CN=Certificate Authority
> ---
> Server certificate
> -----BEGIN CERTIFICATE-----
> ...
> -----END CERTIFICATE-----
> subject=/O=EXAMPLE.COM/CN=dir1.example.com
> issuer=/O=EXAMPLE.COM/CN=Certificate Authority
> ---
> No client certificate CA names sent
> ---
> SSL handshake has read 2095 bytes and written 591 bytes
> ---
> New, TLSv1/SSLv3, Cipher is AES128-SHA
> Server public key is 2048 bit
> Secure Renegotiation IS supported
> Compression: NONE
> Expansion: NONE
> SSL-Session:
>     Protocol  : TLSv1.1
>     Cipher    : AES128-SHA
>     Session-ID: F6A664BC942DF235EF546007379A79A00245G34FA7C0E6F191B911E9CFEC17D0
>     Session-ID-ctx:
>     Master-Key:
> 8C9A5FB1DFDDA72FF09780A85A43FA3C1AA14D4FB199F510A0DC3DF0C53DFFFFCDD0F26211CA886342E84030EA891959
>     Key-Arg   : None
>     Krb5 Principal: None
>     PSK identity: None
>     PSK identity hint: None
>     Start Time: 1418131359
>     Timeout   : 300 (sec)
>     Verify return code: 0 (ok)
> ---
> closed
> 
> On Tue, Dec 9, 2014 at 4:18 AM, Martin Kosek <mkosek at redhat.com> wrote:
>> On 12/08/2014 08:00 PM, Megan . wrote:
>>> I looked through the logs on the server and i see the below error in
>>> the apache error log when i try to register a client:
>>>
>>> [Mon Dec 08 12:20:38 2014] [error] SSL Library Error: -12195 Peer does
>>> not recognize and trust the CA that issued your certificate
>>>
>>>
>>> I ran ipa-getcert list and everything seems ok (nothing expired) but
>>> i'm not sure where to troubleshoot from here.
>>
>> The next step would be to check the actual HTTP certificate (on the client
>> machine) and see what's wrong. I did a simple test you can follow:
>>
>> # wget http://ipa.mkosek-f21.test/ipa/config/ca.crt -O /tmp/ipa.crt
>> # openssl s_client -host ipa.mkosek-f21.test -port 443 -CAfile /tmp/ipa.crt
>> CONNECTED(00000003)
>> depth=1 O = MKOSEK-F21.TEST, CN = Certificate Authority
>> verify return:1
>> depth=0 O = MKOSEK-F21.TEST, CN = ipa.mkosek-f21.test
>> verify return:1
>> ---
>> Certificate chain
>>  0 s:/O=MKOSEK-F21.TEST/CN=ipa.mkosek-f21.test
>>    i:/O=MKOSEK-F21.TEST/CN=Certificate Authority
>>  1 s:/O=MKOSEK-F21.TEST/CN=Certificate Authority
>>    i:/O=MKOSEK-F21.TEST/CN=Certificate Authority
>> ---
>> Server certificate
>> ...
>> SSL-Session:
>>     Protocol  : TLSv1.2
>>     Cipher    : AES128-SHA
>>     Session-ID: 5A4B326D2E8FB80408D628D1975C49C4F78D3E65F31E475F9E7B9BBBE11F576E
>>     Session-ID-ctx:
>>     Master-Key:
>> D5C31E9E36503ADC9F162439B41A7A608260D7DF5EB357FB3D79C9CFAE700912526893E7DD9AA56F5B6CD320FBA98C49
>>     Key-Arg   : None
>>     Krb5 Principal: None
>>     PSK identity: None
>>     PSK identity hint: None
>>     Start Time: 1418073191
>>     Timeout   : 300 (sec)
>>     Verify return code: 0 (ok)
>> ---
>>
>>>
>>>
>>>
>>> On Fri, Dec 5, 2014 at 7:51 PM, Megan . <nagemnna at gmail.com> wrote:
>>>> It failed again.
>>>>
>>>>
>>>> [root at cache2-uat ~]# certutil -L -d sql:/etc/pki/nssdb
>>>>
>>>> Certificate Nickname                                         Trust Attributes
>>>>                                                              SSL,S/MIME,JAR/XPI
>>>> [root at cache2-uat ~]#
>>>>
>>>> Not sure if its related, but on the directory server in the apache
>>>> error.log I see the below every time a client tries to register:
>>>>
>>>> [Sat Dec 06 00:48:35 2014] [error] SSL Library Error: -12271 SSL
>>>> client cannot verify your certificate
>>>>
>>>> On the directory server i ran ipa-getcert list and the certs seem ok.
>>>>
>>>>
>>>>
>>>> On Fri, Dec 5, 2014 at 5:10 PM, Rob Crittenden <rcritten at redhat.com> wrote:
>>>>> Megan . wrote:
>>>>>> Sorry for being unclear. It still fails.  Same error.
>>>>>
>>>>> Hmm, strange. Try being explicit about sql:
>>>>>
>>>>> # certutil -L -d sql:/etc/pki/nssdb
>>>>>
>>>>> And if there is a CA cert there, delete it.
>>>>>
>>>>> rob
>>>>>
>>>>>>
>>>>>> On Dec 5, 2014 4:39 PM, "Rob Crittenden" <rcritten at redhat.com
>>>>>> <mailto:rcritten at redhat.com>> wrote:
>>>>>>
>>>>>>     Megan . wrote:
>>>>>>     > Thanks.
>>>>>>     >
>>>>>>     > I did have an issue last week where i tried to do the client install
>>>>>>     > and it failed because of a firewall issue.  Networks has it opened
>>>>>>     > now.  I deleted ca.crt before trying again.  There doesn't seem to be
>>>>>>     > a certificate in /etc/pki/nssdb for it.
>>>>>>     >
>>>>>>     >
>>>>>>     >
>>>>>>     > [root at data2-uat ipa]# certutil -L -d /etc/pki/nssdb
>>>>>>     >
>>>>>>     >
>>>>>>     > Certificate Nickname                                         Trust
>>>>>>     Attributes
>>>>>>     >
>>>>>>     >
>>>>>>     SSL,S/MIME,JAR/XPI
>>>>>>     >
>>>>>>     >
>>>>>>     > [root at data2-uat ipa]# certutil -D -n 'IPA CA' -d /etc/pki/nssdb
>>>>>>     >
>>>>>>     > certutil: could not find certificate named "IPA CA":
>>>>>>     > SEC_ERROR_BAD_DATABASE: security library: bad database.
>>>>>>     >
>>>>>>     > [root at data2-uat ipa]# ls
>>>>>>     >
>>>>>>     > [root at data2-uat ipa]# pwd
>>>>>>     >
>>>>>>     > /etc/ipa
>>>>>>     >
>>>>>>     > [root at data2-uat ipa]# ls -al
>>>>>>     >
>>>>>>     > total 16
>>>>>>     >
>>>>>>     > drwxr-xr-x.  2 root root  4096 Dec  5 21:16 .
>>>>>>     >
>>>>>>     > drwxr-xr-x. 82 root root 12288 Dec  5 21:16 ..
>>>>>>     >
>>>>>>     > [root at data2-uat ipa]#
>>>>>>
>>>>>>     So trying to install the client again fails or succeeds now?
>>>>>>
>>>>>>     rob
>>>>>>
>>>>>>     >
>>>>>>     > On Fri, Dec 5, 2014 at 4:03 PM, Rob Crittenden
>>>>>>     <rcritten at redhat.com <mailto:rcritten at redhat.com>> wrote:
>>>>>>     >> Rob Crittenden wrote:
>>>>>>     >>> Megan . wrote:
>>>>>>     >>>> Good Day!
>>>>>>     >>>>
>>>>>>     >>>> I am getting an error when i register new clients.
>>>>>>     >>>>
>>>>>>     >>>> libcurl failed to execute the HTTP POST transaction.  SSL
>>>>>>     connect error
>>>>>>     >>>>
>>>>>>     >>>> I can't find anything useful not the internet about the error.  Can
>>>>>>     >>>> someone help me troubleshoot?
>>>>>>     >>>>
>>>>>>     >>>> CentOS 6.6  x64
>>>>>>     >>>> ipa-client-3.0.0-42.el6.centos.x86_64
>>>>>>     >>>> ipa-server-3.0.0-42.el6.centos.x86_64
>>>>>>     >>>> curl-7.19.7-40.el6_6.1.x86_64
>>>>>>     >>>
>>>>>>     >>> Do you have NSS_DEFAULT_DB_TYPE set to sql? I don't know that
>>>>>>     we've done
>>>>>>     >>> any testing on the client with this set.
>>>>>>     >>
>>>>>>     >> Never mind, that's not it. The problem is:
>>>>>>     >>
>>>>>>     >> * NSS error -8054
>>>>>>     >>
>>>>>>     >> Which is SEC_ERROR_REUSED_ISSUER_AND_SERIAL
>>>>>>     >>
>>>>>>     >> So I'd do this:
>>>>>>     >>
>>>>>>     >> # rm /etc/ipa/ca.crt
>>>>>>     >>
>>>>>>     >> You may also want to ensure that the IPA CA certificate isn't in
>>>>>>     >> /etc/pki/nssdb:
>>>>>>     >>
>>>>>>     >> # certutil -L -d /etc/pki/nssdb
>>>>>>     >>
>>>>>>     >> And then perhaps
>>>>>>     >>
>>>>>>     >> # certutil -D -n 'IPA CA' -d /etc/pki/nssdb
>>>>>>     >>
>>>>>>     >> rob
>>>>>>     >>
>>>>>>
>>>>>
>>>
>>
> 



From rmeggins at redhat.com  Tue Dec  9 14:26:35 2014
From: rmeggins at redhat.com (Rich Megginson)
Date: Tue, 09 Dec 2014 07:26:35 -0700
Subject: [Freeipa-users]
 =?utf-8?q?Unit_pki-tomcatd=40pki-tomcat=2Eservice?=
 =?utf-8?q?_entered_failed_state_=40_vanilla_install_on_jessie_=E2=80=93_w?=
 =?utf-8?q?ith_log_attached?=
In-Reply-To: <5486F4D8.6040700@redhat.com>
References: <6538670.riIOSljqhg@hansa> <5486F4D8.6040700@redhat.com>
Message-ID: <5487069B.50704@redhat.com>

On 12/09/2014 06:10 AM, thierry bordaz wrote:
> On 12/09/2014 01:54 PM, chymian wrote:
>> hey people,
>>
>> after a successful install of ipa 4.0.5-2 on jessie, the named services started flawless during setup. see attached log, Installation summary (line 3107)
>> but after reboot, it refuses to start. (did this install a couple times, on vanilla jessie)
>>
>> I can reach & work with Dogtaghttps://ipa.eb8.lan:8443/ca, but not the admin-services onhttps://ipa.eb8.lan/ca/ee/ca  andhttps://ipa.eb8.lan/ca/agent/ca.
>>
>>
>> $ systemctl statuspki-tomcatd at pki-tomcat.service
>> ?pki-tomcatd at pki-tomcat.service  - PKI Tomcat Server pki-tomcat
>>     Loaded: loaded (/lib/systemd/system/pki-tomcatd at .service; enabled)
>>     Active: failed (Result: resources)
>>
>> Dez 08 20:40:13 ipa systemd[1]: Starting PKI Tomcat Server pki-tomcat...
>> Dez 08 20:40:13 ipa systemd[1]: Failed to load environment files: No such file or directory
>> Dez 08 20:40:13 ipa systemd[1]:pki-tomcatd at pki-tomcat.service  failed to run 'start-pre' task: No such file or directory
>> Dez 08 20:40:13 ipa systemd[1]: Failed to start PKI Tomcat Server pki-tomcat.
>> Dez 08 20:40:13 ipa systemd[1]: Unitpki-tomcatd at pki-tomcat.service  entered failed state.
>>
>>
>> a second service fails to start:
>>
>> $ systemctl status dirsrv-snmp.service
>> ? dirsrv-snmp.service - 389 Directory Server SNMP Subagent.
>>     Loaded: loaded (/lib/systemd/system/dirsrv-snmp.service; enabled)
>>     Active: failed (Result: exit-code) since Di 2014-12-09 13:25:04 CET; 5min ago
>>    Process: 156 ExecStart=/usr/sbin/ldap-agent /etc/dirsrv/config/ldap-agent.conf (code=exited, status=1/FAILURE)
>>
>> Dez 09 13:25:04 ipa systemd[1]: Starting 389 Directory Server SNMP Subagent....
>> Dez 09 13:25:04 ipa ldap-agent[156]: ldap-agent: No server instances defined in config file
>> Dez 09 13:25:04 ipa systemd[1]: dirsrv-snmp.service: control process exited, code=exited status=1
>> Dez 09 13:25:04 ipa systemd[1]: Failed to start 389 Directory Server SNMP Subagent..
>> Dez 09 13:25:04 ipa systemd[1]: Unit dirsrv-snmp.service entered failed state.
>
> Hello,
>
> regarding this issue. Is there a agent log file under 
> /var/log/dirsrv/agent/ ?

Are you actually trying to use SNMP?  If not, then just ignore this 
service failure.

>
> thanks
> thierry
>>
>> except these, I was able to subscribe a jessie-client with autodiscovery right after I did configure the ipa-server, before first reboot.
>>
>>
>> any help appreciated, since I do not have much experience with IPA ? yet.
>> guenter
>>
>>
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141209/8290a660/attachment.htm>

From mrniranjan at redhat.com  Tue Dec  9 09:48:49 2014
From: mrniranjan at redhat.com (Niranjan M.R)
Date: Tue, 09 Dec 2014 15:18:49 +0530
Subject: [Freeipa-users] [Freeipa-interest] Announcing FreeIPA 4.1.2 -
 NEED HELP WITH 2FA/OTP!!!
In-Reply-To: <5486C09A.5060902@redhat.com>
References: <54775877.6060102@redhat.com>	<176433463.23902008.1417805679430.JavaMail.zimbra@redhat.com>	<54845DA3.3070104@redhat.com>
	<5486BA7E.90100@redhat.com> <5486C09A.5060902@redhat.com>
Message-ID: <5486C581.9020209@redhat.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 12/09/2014 02:57 PM, thierry bordaz wrote:
> Hello,
> 
> Niranjan, may I have access to your test machine.
> 
It's a vm on my laptop. I am trying to reproduce on another VM
to which i can give access. I will provide the details of this VM as soon
as possible.

Mean while i am providing ns-slapd access logs, ipa-logs and pkispawn logs.



> thanks
> theirry
> 
> 
> On 12/09/2014 10:01 AM, Martin Kosek wrote:
>> On 12/07/2014 03:01 PM, Niranjan M.R wrote:
>>> On 12/06/2014 12:24 AM, Dmitri Pal wrote:
>>>> Hello,
>>>> WE NEED HELP!
>>>> The biggest and the most interesting feature of FreeIPA 4.1.2 is support for the two factor authentication using HOTP/TOTP compatible software tokens like FreeOTP (open source compatible alternative to Google Authenticator) and hardware tokens like Yubikeys. This feature allows Kerberos and LDAP clients of a FreeIPA server to authenticate using the normal account password as the first factor and an OTP token as a second factor. For those environments where a 2FA solution is already in place, FreeIPA can act as a proxy via RADIUS. More about this feature can be read here.
>>>> http://www.freeipa.org/page/V4/OTP
>>>> If you want to see this feature in downstream distros sooner rather than later we need your help!
>>>> Please give it a try and provide feedback. We really, really need it!
>>> I am unable to configure ipa-server with freeipa-server-4.1.2-1.fc20.x86_64,  ipa-server-install fails with below error:
>>>
>>> Done configuring certificate server (pki-tomcatd).
>>> Configuring directory server (dirsrv): Estimated time 10 seconds
>>>    [1/3]: configuring ssl for ds instance
>>>    [2/3]: restarting directory server
>>> ipa         : CRITICAL Failed to restart the directory server ([Errno 2] No such file or directory:
>>> '/etc/systemd/system/dirsrv.target.wants/dirsrv at EXAMPLE-ORG.service'). See the installation log for details.
>>>    [3/3]: adding CA certificate entry
>>> Done configuring directory server (dirsrv).
>>> CA did not start in 300.0s
>>>
>>>
>>> Versions used:
>>> ==============
>>> freeipa-client-4.1.2-1.fc20.x86_64
>>> freeipa-server-4.1.2-1.fc20.x86_64
>>> libipa_hbac-1.12.2-2.fc20.x86_64
>>> libipa_hbac-python-1.12.2-2.fc20.x86_64
>>> sssd-ipa-1.12.2-2.fc20.x86_64
>>> device-mapper-multipath-0.4.9-56.fc20.x86_64
>>> python-iniparse-0.4-9.fc20.noarch
>>> freeipa-admintools-4.1.2-1.fc20.x86_64
>>> freeipa-python-4.1.2-1.fc20.x86_64
>>> 389-ds-base-libs-1.3.3.5-1.fc20.x86_64
>>> 389-ds-base-1.3.3.5-1.fc20.x86_64
>>>
>>> BaseOS:Fedora release 20 (Heisenbug)
>>>
>>>
>>> Steps to reproduce:
>>> ---------------
>>>
>>> 1. On Fedora-20 system, Used mkosek freeipa repo:
>>> [mkosek-freeipa]
>>> name=Copr repo for freeipa owned by mkosek
>>> baseurl=http://copr-be.cloud.fedoraproject.org/results/mkosek/freeipa/fedora-$releasever-$basearch/
>>> skip_if_unavailable=True
>>> gpgcheck=0
>>> enabled=1
>>>
>>> 2. Install freeipa-server packages from the above repo
>>>
>>> 3. Issue ipa-server-install
>>>
>>> [root at pkiserver1 ~]# ipa-server-install
>>>
>>> The log file for this installation can be found in /var/log/ipaserver-install.log
>>> ==============================================================================
>>> This program will set up the FreeIPA Server.
>>>
>>> This includes:
>>>    * Configure a stand-alone CA (dogtag) for certificate management
>>>    * Configure the Network Time Daemon (ntpd)
>>>    * Create and configure an instance of Directory Server
>>>    * Create and configure a Kerberos Key Distribution Center (KDC)
>>>    * Configure Apache (httpd)
>>>
>>> To accept the default shown in brackets, press the Enter key.
>>>
>>> WARNING: conflicting time&date synchronization service 'chronyd' will be disabled
>>> in favor of ntpd
>>>
>>> Do you want to configure integrated DNS (BIND)? [no]: yes
>>>
>>> Existing BIND configuration detected, overwrite? [no]: yes
>>> Enter the fully qualified domain name of the computer
>>> on which you're setting up server software. Using the form
>>> <hostname>.<domainname>
>>> Example: master.example.com.
>>>
>>>
>>> Server host name [pkiserver1.example.org]:
>>>
>>> Warning: skipping DNS resolution of host pkiserver1.example.org
>>> The domain name has been determined based on the host name.
>>>
>>> Please confirm the domain name [example.org]:
>>>
>>> The kerberos protocol requires a Realm name to be defined.
>>> This is typically the domain name converted to uppercase.
>>>
>>> Please provide a realm name [EXAMPLE.ORG]:
>>> Certain directory server operations require an administrative user.
>>> This user is referred to as the Directory Manager and has full access
>>> to the Directory for system management tasks and will be added to the
>>>
>>> The IPA server requires an administrative user, named 'admin'.
>>> This user is a regular system account used for IPA server administration.
>>>
>>> IPA admin password:
>>> Password (confirm):
>>>
>>> Do you want to configure DNS forwarders? [yes]: no
>>> No DNS forwarders configured
>>> Do you want to configure the reverse zone? [yes]:
>>> Please specify the reverse zone name [122.168.192.in-addr.arpa.]:
>>> Using reverse zone(s) 122.168.192.in-addr.arpa.
>>>
>>> The IPA Master Server will be configured with:
>>> Hostname:       pkiserver1.example.org
>>> IP address(es): 192.168.122.246
>>> Domain name:    example.org
>>> Realm name:     EXAMPLE.ORG
>>>
>>> BIND DNS server will be configured to serve IPA domain with:
>>> Forwarders:    No forwarders
>>> Reverse zone(s):  122.168.192.in-addr.arpa.
>>>
>>> Continue to configure the system with these values? [no]: yes
>>>
>>> The following operations may take some minutes to complete.
>>> Please wait until the prompt is returned.
>>>
>>>
>>> instance of directory server created for IPA.
>>> The password must be at least 8 characters long.
>>>
>>> Directory Manager password:
>>> Password (confirm):
>>> Configuring NTP daemon (ntpd)
>>>    [1/4]: stopping ntpd
>>>    [2/4]: writing configuration
>>>    [3/4]: configuring ntpd to start on boot
>>>    [4/4]: starting ntpd
>>> Done configuring NTP daemon (ntpd).
>>> Configuring directory server (dirsrv): Estimated time 1 minute
>>>    [1/38]: creating directory server user
>>>    [2/38]: creating directory server instance
>>>    [3/38]: adding default schema
>>>    [4/38]: enabling memberof plugin
>>>    [5/38]: enabling winsync plugin
>>>    [6/38]: configuring replication version plugin
>>>    [7/38]: enabling IPA enrollment plugin
>>>    [8/38]: enabling ldapi
>>>    [9/38]: configuring uniqueness plugin
>>>    [10/38]: configuring uuid plugin
>>>    [11/38]: configuring modrdn plugin
>>>    [12/38]: configuring DNS plugin
>>>    [13/38]: enabling entryUSN plugin
>>>    [14/38]: configuring lockout plugin
>>>    [15/38]: creating indices
>>>    [16/38]: enabling referential integrity plugin
>>>    [17/38]: configuring certmap.conf
>>>    [18/38]: configure autobind for root
>>>    [19/38]: configure new location for managed entries
>>>    [20/38]: configure dirsrv ccache
>>>    [21/38]: enable SASL mapping fallback
>>>    [22/38]: restarting directory server
>>>    [23/38]: adding default layout
>>>    [24/38]: adding delegation layout
>>>    [25/38]: creating container for managed entries
>>>    [26/38]: configuring user private groups
>>>    [27/38]: configuring netgroups from hostgroups
>>>    [28/38]: creating default Sudo bind user
>>>    [29/38]: creating default Auto Member layout
>>>    [30/38]: adding range check plugin
>>>    [31/38]: creating default HBAC rule allow_all
>>>    [32/38]: initializing group membership
>>>    [33/38]: adding master entry
>>>    [34/38]: configuring Posix uid/gid generation
>>>    [35/38]: adding replication acis
>>>    [36/38]: enabling compatibility plugin
>>>    [37/38]: tuning directory server
>>>    [38/38]: configuring directory to start on boot
>>> Done configuring directory server (dirsrv).
>>> Configuring certificate server (pki-tomcatd): Estimated time 3 minutes 30 seconds
>>>    [1/27]: creating certificate server user
>>>    [2/27]: configuring certificate server instance
>>>    [3/27]: stopping certificate server instance to update CS.cfg
>>>    [4/27]: backing up CS.cfg
>>>    [5/27]: disabling nonces
>>>    [6/27]: set up CRL publishing
>>>    [7/27]: enable PKIX certificate path discovery and validation
>>>    [8/27]: starting certificate server instance
>>>    [9/27]: creating RA agent certificate database
>>>    [10/27]: importing CA chain to RA certificate database
>>>    [11/27]: fixing RA database permissions
>>>    [12/27]: setting up signing cert profile
>>>    [13/27]: set certificate subject base
>>>    [14/27]: enabling Subject Key Identifier
>>>    [15/27]: enabling Subject Alternative Name
>>>    [16/27]: enabling CRL and OCSP extensions for certificates
>>>    [17/27]: setting audit signing renewal to 2 years
>>>    [18/27]: configuring certificate server to start on boot
>>>    [19/27]: restarting certificate server
>>>    [20/27]: requesting RA certificate from CA
>>>    [21/27]: issuing RA agent certificate
>>>    [22/27]: adding RA agent as a trusted user
>>>    [23/27]: configure certmonger for renewals
>>>    [24/27]: configure certificate renewals
>>>    [25/27]: configure RA certificate renewal
>>>    [26/27]: configure Server-Cert certificate renewal
>>>    [27/27]: Configure HTTP to proxy connections
>>> Done configuring certificate server (pki-tomcatd).
>>> Configuring directory server (dirsrv): Estimated time 10 seconds
>>>    [1/3]: configuring ssl for ds instance
>>>    [2/3]: restarting directory server
>>> ipa         : CRITICAL Failed to restart the directory server ([Errno 2] No such file or directory:
>>> '/etc/systemd/system/dirsrv.target.wants/dirsrv at EXAMPLE-ORG.service'). See the installation log for details.
>>>    [3/3]: adding CA certificate entry
>>> Done configuring directory server (dirsrv).
>>>
>>> CA did not start in 300.0s
>>>
>>> Attaching ipaserver-install.log, pkispawn logs
>>>
>>> Any hints on how to overcome the above error.
>> The error is obviously in Directory Server restart. I am not sure what causes
>>
>> 2014-12-07T11:16:25Z DEBUG   [2/3]: restarting directory server
>> 2014-12-07T11:16:25Z CRITICAL Failed to restart the directory server ([Errno 2]
>> No such file or directory:
>> '/etc/systemd/system/dirsrv.target.wants/dirsrv at EXAMPLE-ORG.service'). See the
>> installation log for details.
>>
>> The first restart worked and it uses the same call, AFAIK. It would be
>> interesting to see the latest logs of the instance after ipa-server-install
>> crashes:
>>
>> # systemctl status dirsrv at EXAMPLE-ORG.service
>>
>> It may have some useful logs that would reveal what happened.
>>
>> Martin
> 


- -- 
Niranjan
irc: mrniranjan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iKYEARECAGYFAlSGxYFfFIAAAAAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl
bnBncC5maWZ0aGhvcnNlbWFuLm5ldEY3OTE3QTg3ODE0RkVCQ0YyNjgyOTRENjJF
RURDNTVGNjA0N0M3QzcACgkQLu3FX2BHx8e61wCgtCSWtdpOMWVP+Pr7fPmoXiPC
DAsAoI0phFg3dtQJNRvpm8YCjLEs9r66
=1MYR
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ipa-ds-cs.logs.tar.gz
Type: application/x-gzip
Size: 197820 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141209/ccbbe676/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dirsrv-config.tar.gz
Type: application/x-gzip
Size: 150605 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141209/ccbbe676/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x6047C7C7.asc
Type: application/pgp-keys
Size: 1893 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141209/ccbbe676/attachment-0002.bin>

From mrniranjan at redhat.com  Tue Dec  9 09:58:11 2014
From: mrniranjan at redhat.com (Niranjan M.R)
Date: Tue, 09 Dec 2014 15:28:11 +0530
Subject: [Freeipa-users] [Freeipa-interest] Announcing FreeIPA 4.1.2 -
 NEED HELP WITH 2FA/OTP!!!
In-Reply-To: <5486C675.4040003@redhat.com>
References: <54775877.6060102@redhat.com>	<176433463.23902008.1417805679430.JavaMail.zimbra@redhat.com>	<54845DA3.3070104@redhat.com>
	<5486BA7E.90100@redhat.com> <5486C09A.5060902@redhat.com>
	<5486C581.9020209@redhat.com> <5486C675.4040003@redhat.com>
Message-ID: <5486C7B3.3030506@redhat.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 12/09/2014 03:22 PM, Martin Kosek wrote:
> On 12/09/2014 10:48 AM, Niranjan M.R wrote:
>> On 12/09/2014 02:57 PM, thierry bordaz wrote:
>>> Hello,
>>
>>> Niranjan, may I have access to your test machine.
>>
>> It's a vm on my laptop. I am trying to reproduce on another VM
>> to which i can give access. I will provide the details of this VM as soon
>> as possible.
>>
>> Mean while i am providing ns-slapd access logs, ipa-logs and pkispawn logs.
> 
> Thanks. I see no related errors in the DS errors log, I wonder if the suggested
> 
> # systemctl status dirsrv at EXAMPLE-ORG.service
> 
> would show anything interesting.
> 
>>
>>
>>
>>> thanks
>>> theirry
>>
>>
>>> On 12/09/2014 10:01 AM, Martin Kosek wrote:
>>>> On 12/07/2014 03:01 PM, Niranjan M.R wrote:
>>>>> On 12/06/2014 12:24 AM, Dmitri Pal wrote:
>>>>>> Hello,
>>>>>> WE NEED HELP!
>>>>>> The biggest and the most interesting feature of FreeIPA 4.1.2 is support for the two factor authentication using HOTP/TOTP compatible software tokens like FreeOTP (open source compatible alternative to Google Authenticator) and hardware tokens like Yubikeys. This feature allows Kerberos and LDAP clients of a FreeIPA server to authenticate using the normal account password as the first factor and an OTP token as a second factor. For those environments where a 2FA solution is already in place, FreeIPA can act as a proxy via RADIUS. More about this feature can be read here.
>>>>>> http://www.freeipa.org/page/V4/OTP
>>>>>> If you want to see this feature in downstream distros sooner rather than later we need your help!
>>>>>> Please give it a try and provide feedback. We really, really need it!
>>>>> I am unable to configure ipa-server with freeipa-server-4.1.2-1.fc20.x86_64,  ipa-server-install fails with below error:
>>>>>
>>>>> Done configuring certificate server (pki-tomcatd).
>>>>> Configuring directory server (dirsrv): Estimated time 10 seconds
>>>>>    [1/3]: configuring ssl for ds instance
>>>>>    [2/3]: restarting directory server
>>>>> ipa         : CRITICAL Failed to restart the directory server ([Errno 2] No such file or directory:
>>>>> '/etc/systemd/system/dirsrv.target.wants/dirsrv at EXAMPLE-ORG.service'). See the installation log for details.
>>>>>    [3/3]: adding CA certificate entry
>>>>> Done configuring directory server (dirsrv).
>>>>> CA did not start in 300.0s
>>>>>
>>>>>
>>>>> Versions used:
>>>>> ==============
>>>>> freeipa-client-4.1.2-1.fc20.x86_64
>>>>> freeipa-server-4.1.2-1.fc20.x86_64
>>>>> libipa_hbac-1.12.2-2.fc20.x86_64
>>>>> libipa_hbac-python-1.12.2-2.fc20.x86_64
>>>>> sssd-ipa-1.12.2-2.fc20.x86_64
>>>>> device-mapper-multipath-0.4.9-56.fc20.x86_64
>>>>> python-iniparse-0.4-9.fc20.noarch
>>>>> freeipa-admintools-4.1.2-1.fc20.x86_64
>>>>> freeipa-python-4.1.2-1.fc20.x86_64
>>>>> 389-ds-base-libs-1.3.3.5-1.fc20.x86_64
>>>>> 389-ds-base-1.3.3.5-1.fc20.x86_64
>>>>>
>>>>> BaseOS:Fedora release 20 (Heisenbug)
>>>>>
>>>>>
>>>>> Steps to reproduce:
>>>>> ---------------
>>>>>
>>>>> 1. On Fedora-20 system, Used mkosek freeipa repo:
>>>>> [mkosek-freeipa]
>>>>> name=Copr repo for freeipa owned by mkosek
>>>>> baseurl=http://copr-be.cloud.fedoraproject.org/results/mkosek/freeipa/fedora-$releasever-$basearch/
>>>>> skip_if_unavailable=True
>>>>> gpgcheck=0
>>>>> enabled=1
>>>>>
>>>>> 2. Install freeipa-server packages from the above repo
>>>>>
>>>>> 3. Issue ipa-server-install
>>>>>
>>>>> [root at pkiserver1 ~]# ipa-server-install
>>>>>
>>>>> The log file for this installation can be found in /var/log/ipaserver-install.log
>>>>> ==============================================================================
>>>>> This program will set up the FreeIPA Server.
>>>>>
>>>>> This includes:
>>>>>    * Configure a stand-alone CA (dogtag) for certificate management
>>>>>    * Configure the Network Time Daemon (ntpd)
>>>>>    * Create and configure an instance of Directory Server
>>>>>    * Create and configure a Kerberos Key Distribution Center (KDC)
>>>>>    * Configure Apache (httpd)
>>>>>
>>>>> To accept the default shown in brackets, press the Enter key.
>>>>>
>>>>> WARNING: conflicting time&date synchronization service 'chronyd' will be disabled
>>>>> in favor of ntpd
>>>>>
>>>>> Do you want to configure integrated DNS (BIND)? [no]: yes
>>>>>
>>>>> Existing BIND configuration detected, overwrite? [no]: yes
>>>>> Enter the fully qualified domain name of the computer
>>>>> on which you're setting up server software. Using the form
>>>>> <hostname>.<domainname>
>>>>> Example: master.example.com.
>>>>>
>>>>>
>>>>> Server host name [pkiserver1.example.org]:
>>>>>
>>>>> Warning: skipping DNS resolution of host pkiserver1.example.org
>>>>> The domain name has been determined based on the host name.
>>>>>
>>>>> Please confirm the domain name [example.org]:
>>>>>
>>>>> The kerberos protocol requires a Realm name to be defined.
>>>>> This is typically the domain name converted to uppercase.
>>>>>
>>>>> Please provide a realm name [EXAMPLE.ORG]:
>>>>> Certain directory server operations require an administrative user.
>>>>> This user is referred to as the Directory Manager and has full access
>>>>> to the Directory for system management tasks and will be added to the
>>>>>
>>>>> The IPA server requires an administrative user, named 'admin'.
>>>>> This user is a regular system account used for IPA server administration.
>>>>>
>>>>> IPA admin password:
>>>>> Password (confirm):
>>>>>
>>>>> Do you want to configure DNS forwarders? [yes]: no
>>>>> No DNS forwarders configured
>>>>> Do you want to configure the reverse zone? [yes]:
>>>>> Please specify the reverse zone name [122.168.192.in-addr.arpa.]:
>>>>> Using reverse zone(s) 122.168.192.in-addr.arpa.
>>>>>
>>>>> The IPA Master Server will be configured with:
>>>>> Hostname:       pkiserver1.example.org
>>>>> IP address(es): 192.168.122.246
>>>>> Domain name:    example.org
>>>>> Realm name:     EXAMPLE.ORG
>>>>>
>>>>> BIND DNS server will be configured to serve IPA domain with:
>>>>> Forwarders:    No forwarders
>>>>> Reverse zone(s):  122.168.192.in-addr.arpa.
>>>>>
>>>>> Continue to configure the system with these values? [no]: yes
>>>>>
>>>>> The following operations may take some minutes to complete.
>>>>> Please wait until the prompt is returned.
>>>>>
>>>>>
>>>>> instance of directory server created for IPA.
>>>>> The password must be at least 8 characters long.
>>>>>
>>>>> Directory Manager password:
>>>>> Password (confirm):
>>>>> Configuring NTP daemon (ntpd)
>>>>>    [1/4]: stopping ntpd
>>>>>    [2/4]: writing configuration
>>>>>    [3/4]: configuring ntpd to start on boot
>>>>>    [4/4]: starting ntpd
>>>>> Done configuring NTP daemon (ntpd).
>>>>> Configuring directory server (dirsrv): Estimated time 1 minute
>>>>>    [1/38]: creating directory server user
>>>>>    [2/38]: creating directory server instance
>>>>>    [3/38]: adding default schema
>>>>>    [4/38]: enabling memberof plugin
>>>>>    [5/38]: enabling winsync plugin
>>>>>    [6/38]: configuring replication version plugin
>>>>>    [7/38]: enabling IPA enrollment plugin
>>>>>    [8/38]: enabling ldapi
>>>>>    [9/38]: configuring uniqueness plugin
>>>>>    [10/38]: configuring uuid plugin
>>>>>    [11/38]: configuring modrdn plugin
>>>>>    [12/38]: configuring DNS plugin
>>>>>    [13/38]: enabling entryUSN plugin
>>>>>    [14/38]: configuring lockout plugin
>>>>>    [15/38]: creating indices
>>>>>    [16/38]: enabling referential integrity plugin
>>>>>    [17/38]: configuring certmap.conf
>>>>>    [18/38]: configure autobind for root
>>>>>    [19/38]: configure new location for managed entries
>>>>>    [20/38]: configure dirsrv ccache
>>>>>    [21/38]: enable SASL mapping fallback
>>>>>    [22/38]: restarting directory server
>>>>>    [23/38]: adding default layout
>>>>>    [24/38]: adding delegation layout
>>>>>    [25/38]: creating container for managed entries
>>>>>    [26/38]: configuring user private groups
>>>>>    [27/38]: configuring netgroups from hostgroups
>>>>>    [28/38]: creating default Sudo bind user
>>>>>    [29/38]: creating default Auto Member layout
>>>>>    [30/38]: adding range check plugin
>>>>>    [31/38]: creating default HBAC rule allow_all
>>>>>    [32/38]: initializing group membership
>>>>>    [33/38]: adding master entry
>>>>>    [34/38]: configuring Posix uid/gid generation
>>>>>    [35/38]: adding replication acis
>>>>>    [36/38]: enabling compatibility plugin
>>>>>    [37/38]: tuning directory server
>>>>>    [38/38]: configuring directory to start on boot
>>>>> Done configuring directory server (dirsrv).
>>>>> Configuring certificate server (pki-tomcatd): Estimated time 3 minutes 30 seconds
>>>>>    [1/27]: creating certificate server user
>>>>>    [2/27]: configuring certificate server instance
>>>>>    [3/27]: stopping certificate server instance to update CS.cfg
>>>>>    [4/27]: backing up CS.cfg
>>>>>    [5/27]: disabling nonces
>>>>>    [6/27]: set up CRL publishing
>>>>>    [7/27]: enable PKIX certificate path discovery and validation
>>>>>    [8/27]: starting certificate server instance
>>>>>    [9/27]: creating RA agent certificate database
>>>>>    [10/27]: importing CA chain to RA certificate database
>>>>>    [11/27]: fixing RA database permissions
>>>>>    [12/27]: setting up signing cert profile
>>>>>    [13/27]: set certificate subject base
>>>>>    [14/27]: enabling Subject Key Identifier
>>>>>    [15/27]: enabling Subject Alternative Name
>>>>>    [16/27]: enabling CRL and OCSP extensions for certificates
>>>>>    [17/27]: setting audit signing renewal to 2 years
>>>>>    [18/27]: configuring certificate server to start on boot
>>>>>    [19/27]: restarting certificate server
>>>>>    [20/27]: requesting RA certificate from CA
>>>>>    [21/27]: issuing RA agent certificate
>>>>>    [22/27]: adding RA agent as a trusted user
>>>>>    [23/27]: configure certmonger for renewals
>>>>>    [24/27]: configure certificate renewals
>>>>>    [25/27]: configure RA certificate renewal
>>>>>    [26/27]: configure Server-Cert certificate renewal
>>>>>    [27/27]: Configure HTTP to proxy connections
>>>>> Done configuring certificate server (pki-tomcatd).
>>>>> Configuring directory server (dirsrv): Estimated time 10 seconds
>>>>>    [1/3]: configuring ssl for ds instance
>>>>>    [2/3]: restarting directory server
>>>>> ipa         : CRITICAL Failed to restart the directory server ([Errno 2] No such file or directory:
>>>>> '/etc/systemd/system/dirsrv.target.wants/dirsrv at EXAMPLE-ORG.service'). See the installation log for details.
>>>>>    [3/3]: adding CA certificate entry
>>>>> Done configuring directory server (dirsrv).
>>>>>
>>>>> CA did not start in 300.0s
>>>>>
>>>>> Attaching ipaserver-install.log, pkispawn logs
>>>>>
>>>>> Any hints on how to overcome the above error.
>>>> The error is obviously in Directory Server restart. I am not sure what causes
>>>>
>>>> 2014-12-07T11:16:25Z DEBUG   [2/3]: restarting directory server
>>>> 2014-12-07T11:16:25Z CRITICAL Failed to restart the directory server ([Errno 2]
>>>> No such file or directory:
>>>> '/etc/systemd/system/dirsrv.target.wants/dirsrv at EXAMPLE-ORG.service'). See the
>>>> installation log for details.
>>>>
>>>> The first restart worked and it uses the same call, AFAIK. It would be
>>>> interesting to see the latest logs of the instance after ipa-server-install
>>>> crashes:
>>>>
>>>> # systemctl status dirsrv at EXAMPLE-ORG.service

[root at pkiserver1 ~]# systemctl status dirsrv at EXAMPLE-ORG.service
dirsrv at EXAMPLE-ORG.service - 389 Directory Server EXAMPLE-ORG.
   Loaded: loaded (/etc/systemd/system/dirsrv at .service; enabled)
   Active: active (running) since Tue 2014-12-09 04:33:56 EST; 23min ago
 Main PID: 2535 (ns-slapd)
   CGroup: /system.slice/system-dirsrv.slice/dirsrv at EXAMPLE-ORG.service
           ??2535 /usr/sbin/ns-slapd -D /etc/dirsrv/slapd-EXAMPLE-ORG -i /var/run/dirsrv/slapd-EXAMPLE-ORG.pid -w
/var/run/dirsrv/slapd-EXAMPLE-ORG.startpid

Dec 09 04:33:56 pkiserver1.example.org systemd[1]: Started 389 Directory Server EXAMPLE-ORG..
>>>>
>>>> It may have some useful logs that would reveal what happened.
>>>>
>>>> Martin
>>
>>
>>
>>
> 
> 
> 


- -- 
Niranjan
irc: mrniranjan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iKYEARECAGYFAlSGx7NfFIAAAAAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl
bnBncC5maWZ0aGhvcnNlbWFuLm5ldEY3OTE3QTg3ODE0RkVCQ0YyNjgyOTRENjJF
RURDNTVGNjA0N0M3QzcACgkQLu3FX2BHx8eV+ACfZ5YZL9lUgV1qKH7GH498RybK
FS4An1DU7wkpfe4kO5BymIAs9e9UthuX
=Axen
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x6047C7C7.asc
Type: application/pgp-keys
Size: 1893 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141209/64845cec/attachment.bin>

From alee at redhat.com  Tue Dec  9 14:49:04 2014
From: alee at redhat.com (Ade Lee)
Date: Tue, 09 Dec 2014 09:49:04 -0500
Subject: [Freeipa-users]
 =?utf-8?q?Unit_pki-tomcatd=40pki-tomcat=2Eservice?=
 =?utf-8?q?_entered_failed_state_=40_vanilla_install_on_jessie_=E2=80=93_w?=
 =?utf-8?q?ith_log_attached?=
In-Reply-To: <6538670.riIOSljqhg@hansa>
References: <6538670.riIOSljqhg@hansa>
Message-ID: <1418136544.27499.17.camel@aleeredhat.laptop>

On Tue, 2014-12-09 at 13:54 +0100, chymian wrote:
> hey people,
> 
> after a successful install of ipa 4.0.5-2 on jessie, the named services started flawless during setup. see attached log, Installation summary (line 3107)
> but after reboot, it refuses to start. (did this install a couple times, on vanilla jessie)
> 
> I can reach & work with Dogtag https://ipa.eb8.lan:8443/ca, but not the admin-services on https://ipa.eb8.lan/ca/ee/ca and https://ipa.eb8.lan/ca/agent/ca.
> 
> 
> $ systemctl status pki-tomcatd at pki-tomcat.service
> ? pki-tomcatd at pki-tomcat.service - PKI Tomcat Server pki-tomcat
>    Loaded: loaded (/lib/systemd/system/pki-tomcatd at .service; enabled)
>    Active: failed (Result: resources)
> 
> Dez 08 20:40:13 ipa systemd[1]: Starting PKI Tomcat Server pki-tomcat...
> Dez 08 20:40:13 ipa systemd[1]: Failed to load environment files: No such file or directory
> Dez 08 20:40:13 ipa systemd[1]: pki-tomcatd at pki-tomcat.service failed to run 'start-pre' task: No such file or directory
> Dez 08 20:40:13 ipa systemd[1]: Failed to start PKI Tomcat Server pki-tomcat.
> Dez 08 20:40:13 ipa systemd[1]: Unit pki-tomcatd at pki-tomcat.service entered failed state.
> 
> 

Is dogtag actually running?  ps -ef |grep java

You could try restarting it - 
systemctl restart pki-tomcatd at pki-tomcat.service

The logs should be found in the journal --> 
journalctl -u pki-tomcatd at pki-tomcat.service

Other debug logs should be found under /var/log/pki/pki-tomcat/.  Please
provide a tar of that directory.

I am curious what the unit file looks like:  On Fedora, its
at /etc/systemd/system/pki-tomcatd.target.wants/pki-tomcatd at pki-tomcat.service
which points to an EnvironmentFile /etc/tomcat/tomcat.conf.  Does that
file exist?

Ade

> a second service fails to start:
> 
> $ systemctl status dirsrv-snmp.service
> ? dirsrv-snmp.service - 389 Directory Server SNMP Subagent.
>    Loaded: loaded (/lib/systemd/system/dirsrv-snmp.service; enabled)
>    Active: failed (Result: exit-code) since Di 2014-12-09 13:25:04 CET; 5min ago
>   Process: 156 ExecStart=/usr/sbin/ldap-agent /etc/dirsrv/config/ldap-agent.conf (code=exited, status=1/FAILURE)
> 
> Dez 09 13:25:04 ipa systemd[1]: Starting 389 Directory Server SNMP Subagent....
> Dez 09 13:25:04 ipa ldap-agent[156]: ldap-agent: No server instances defined in config file
> Dez 09 13:25:04 ipa systemd[1]: dirsrv-snmp.service: control process exited, code=exited status=1
> Dez 09 13:25:04 ipa systemd[1]: Failed to start 389 Directory Server SNMP Subagent..
> Dez 09 13:25:04 ipa systemd[1]: Unit dirsrv-snmp.service entered failed state.
> 
> 
> except these, I was able to subscribe a jessie-client with autodiscovery right after I did configure the ipa-server, before first reboot.
> 
> 
> any help appreciated, since I do not have much experience with IPA ? yet.
> guenter




From nagemnna at gmail.com  Tue Dec  9 14:57:15 2014
From: nagemnna at gmail.com (Megan .)
Date: Tue, 9 Dec 2014 09:57:15 -0500
Subject: [Freeipa-users] can't register new clients
In-Reply-To: <548701A0.8000507@redhat.com>
References: <CACMA5-xsgZ2RcF7rx9MS+jtxpyMOofhpU0MnPn+1mcmHGOxNkg@mail.gmail.com>
	<54821AA7.1000007@redhat.com> <54821D9B.80502@redhat.com>
	<CACMA5-xs3gOMAdjg3o5aG6d58d-CvqPh5k9yo23pLSD9uXAq9Q@mail.gmail.com>
	<548225F9.7010001@redhat.com>
	<CACMA5-w=BmD+=9Gj7Q=U0oheEQOb40zfdzST_ASixiuKs5TqHA@mail.gmail.com>
	<54822D6D.1050807@redhat.com>
	<CACMA5-z+rt0e7tkf_UY5L_YzbQNcmRrNbNDQv3H01a=O9sXmxg@mail.gmail.com>
	<CACMA5-wY7+ceQm8GOT11=8MttRgNcZfsS8sg8X25AOMfo+22Jg@mail.gmail.com>
	<5486BE72.5020506@redhat.com>
	<CACMA5-wOWDtgXDZU+3CXjtVcxmMm_43Yj6sHj1WF5PGVq5M35Q@mail.gmail.com>
	<548701A0.8000507@redhat.com>
Message-ID: <CACMA5-xNNid1-em7i5QDNaFE47aXxhEDBYg8w71MeMPLhNsHDg@mail.gmail.com>

This is happening with all new clients.  I had to rebuild the LDAP
server onto new hardware and the network team put us on a new VLAN.
so my physical server and IP changed.  I was previously able to
register clients, but after all of the changes, i can no longer
register them.  At this point i'm not sure if there is a network issue
or something wrong with the IPA server.  The existing clients are
communicating fine, no errors or complains.  I have two new clients to
add and both have the same symptoms.

I used these procedures to backup then restore onto the new host
http://www.freeipa.org/page/V3/Backup_and_Restore

To change the IP i just updated /etc/hosts and pushed it out to the clients





On Tue, Dec 9, 2014 at 9:05 AM, Rob Crittenden <rcritten at redhat.com> wrote:
> Megan . wrote:
>> Everything looks ok.
>>
>> Our Networks team only opened 443 from the client to the server.  is
>> 80 required to be open too for registration?  80 is a lot harder for
>> me to request on our network.
>>
>> I think I might have found the issue.  Maybe it can't verify the CA
>> because its pointing to port 80, and 80 isn't open.  Is it possible to
>> change the certificate so this information is available via 443 or
>> does that not make sense since its trying to get information about the
>> secure connection in the first place.
>
> I don't think port 80 is the problem and in any case, it is just a
> fallback in case the client can't get it via LDAP which in new installs
> shouldn't be an issue. You'd get an error that the CA couldn't be
> retrieved at all and not that a duplicate serial existed.
>
> Is this happening on every client or just one?
>
> Did you have a previous IPA install and you are re-enrolling this
> client(s) into the new one?
>
> rob
>
>>
>> from the server:
>> [root at dir1 ipa]# openssl verify -verbose -CAFile ca.crt
>> .
>> .
>>             Authority Information Access:
>>                 OCSP - URI:http://dir1.example.com:80/ca/ocsp
>> .
>>
>>
>>
>> [root at data2-uat ipa]# wget https://dir1.example.com/ipa/config/ca.crt
>> -O /tmp/ipa.crt
>> --2014-12-09 13:21:32--  https://dir1.example.com/ipa/config/ca.crt
>> Resolving dir1.example.com... 172.28.27.170
>> Connecting to dir1.example.com|172.28.27.170|:443... connected.
>> ERROR: cannot verify dir1.example.com?s certificate, issued by
>> ?/O=EXAMPLE.COM/CN=Certificate Authority?:
>>   Self-signed certificate encountered.
>> To connect to dir1.example.com insecurely, use ?--no-check-certificate?.
>> [root at data2-uat ipa]# wget https://dir1.example.com/ipa/config/ca.crt
>> -O /tmp/ipa.crt --no-check-certificate
>> --2014-12-09 13:22:11--  https://dir1.example.com/ipa/config/ca.crt
>> Resolving dir1.example.com... 172.28.27.170
>> Connecting to dir1.example.com|172.28.27.170|:443... connected.
>> WARNING: cannot verify dir1.example.com?s certificate, issued by
>> ?/O=EXAMPLE.COM/CN=Certificate Authority?:
>>   Self-signed certificate encountered.
>> HTTP request sent, awaiting response... 200 OK
>> Length: 1357 (1.3K) [application/x-x509-ca-cert]
>> Saving to: ?/tmp/ipa.crt?
>>
>> 100%[================================================>] 1,357
>> --.-K/s   in 0.005s
>>
>> 2014-12-09 13:22:11 (246 KB/s) - ?/tmp/ipa.crt? saved [1357/1357]
>>
>> [root at data2-uat ipa]# cd /tmp
>> [root at data2-uat tmp]# openssl s_client -host dir1.example.com  -port
>> 443 -CAfile /tmp/ipa.crt
>> CONNECTED(00000003)
>> depth=1 O = EXAMPLE.COM, CN = Certificate Authority
>> verify return:1
>> depth=0 O = EXAMPLE.COM, CN = dir1.example.com
>> verify return:1
>> ---
>> Certificate chain
>>  0 s:/O=EXAMPLE.COM/CN=dir1.example.com
>>    i:/O=EXAMPLE.COM/CN=Certificate Authority
>>  1 s:/O=EXAMPLE.COM/CN=Certificate Authority
>>    i:/O=EXAMPLE.COM/CN=Certificate Authority
>> ---
>> Server certificate
>> -----BEGIN CERTIFICATE-----
>> ...
>> -----END CERTIFICATE-----
>> subject=/O=EXAMPLE.COM/CN=dir1.example.com
>> issuer=/O=EXAMPLE.COM/CN=Certificate Authority
>> ---
>> No client certificate CA names sent
>> ---
>> SSL handshake has read 2095 bytes and written 591 bytes
>> ---
>> New, TLSv1/SSLv3, Cipher is AES128-SHA
>> Server public key is 2048 bit
>> Secure Renegotiation IS supported
>> Compression: NONE
>> Expansion: NONE
>> SSL-Session:
>>     Protocol  : TLSv1.1
>>     Cipher    : AES128-SHA
>>     Session-ID: F6A664BC942DF235EF546007379A79A00245G34FA7C0E6F191B911E9CFEC17D0
>>     Session-ID-ctx:
>>     Master-Key:
>> 8C9A5FB1DFDDA72FF09780A85A43FA3C1AA14D4FB199F510A0DC3DF0C53DFFFFCDD0F26211CA886342E84030EA891959
>>     Key-Arg   : None
>>     Krb5 Principal: None
>>     PSK identity: None
>>     PSK identity hint: None
>>     Start Time: 1418131359
>>     Timeout   : 300 (sec)
>>     Verify return code: 0 (ok)
>> ---
>> closed
>>
>> On Tue, Dec 9, 2014 at 4:18 AM, Martin Kosek <mkosek at redhat.com> wrote:
>>> On 12/08/2014 08:00 PM, Megan . wrote:
>>>> I looked through the logs on the server and i see the below error in
>>>> the apache error log when i try to register a client:
>>>>
>>>> [Mon Dec 08 12:20:38 2014] [error] SSL Library Error: -12195 Peer does
>>>> not recognize and trust the CA that issued your certificate
>>>>
>>>>
>>>> I ran ipa-getcert list and everything seems ok (nothing expired) but
>>>> i'm not sure where to troubleshoot from here.
>>>
>>> The next step would be to check the actual HTTP certificate (on the client
>>> machine) and see what's wrong. I did a simple test you can follow:
>>>
>>> # wget http://ipa.mkosek-f21.test/ipa/config/ca.crt -O /tmp/ipa.crt
>>> # openssl s_client -host ipa.mkosek-f21.test -port 443 -CAfile /tmp/ipa.crt
>>> CONNECTED(00000003)
>>> depth=1 O = MKOSEK-F21.TEST, CN = Certificate Authority
>>> verify return:1
>>> depth=0 O = MKOSEK-F21.TEST, CN = ipa.mkosek-f21.test
>>> verify return:1
>>> ---
>>> Certificate chain
>>>  0 s:/O=MKOSEK-F21.TEST/CN=ipa.mkosek-f21.test
>>>    i:/O=MKOSEK-F21.TEST/CN=Certificate Authority
>>>  1 s:/O=MKOSEK-F21.TEST/CN=Certificate Authority
>>>    i:/O=MKOSEK-F21.TEST/CN=Certificate Authority
>>> ---
>>> Server certificate
>>> ...
>>> SSL-Session:
>>>     Protocol  : TLSv1.2
>>>     Cipher    : AES128-SHA
>>>     Session-ID: 5A4B326D2E8FB80408D628D1975C49C4F78D3E65F31E475F9E7B9BBBE11F576E
>>>     Session-ID-ctx:
>>>     Master-Key:
>>> D5C31E9E36503ADC9F162439B41A7A608260D7DF5EB357FB3D79C9CFAE700912526893E7DD9AA56F5B6CD320FBA98C49
>>>     Key-Arg   : None
>>>     Krb5 Principal: None
>>>     PSK identity: None
>>>     PSK identity hint: None
>>>     Start Time: 1418073191
>>>     Timeout   : 300 (sec)
>>>     Verify return code: 0 (ok)
>>> ---
>>>
>>>>
>>>>
>>>>
>>>> On Fri, Dec 5, 2014 at 7:51 PM, Megan . <nagemnna at gmail.com> wrote:
>>>>> It failed again.
>>>>>
>>>>>
>>>>> [root at cache2-uat ~]# certutil -L -d sql:/etc/pki/nssdb
>>>>>
>>>>> Certificate Nickname                                         Trust Attributes
>>>>>                                                              SSL,S/MIME,JAR/XPI
>>>>> [root at cache2-uat ~]#
>>>>>
>>>>> Not sure if its related, but on the directory server in the apache
>>>>> error.log I see the below every time a client tries to register:
>>>>>
>>>>> [Sat Dec 06 00:48:35 2014] [error] SSL Library Error: -12271 SSL
>>>>> client cannot verify your certificate
>>>>>
>>>>> On the directory server i ran ipa-getcert list and the certs seem ok.
>>>>>
>>>>>
>>>>>
>>>>> On Fri, Dec 5, 2014 at 5:10 PM, Rob Crittenden <rcritten at redhat.com> wrote:
>>>>>> Megan . wrote:
>>>>>>> Sorry for being unclear. It still fails.  Same error.
>>>>>>
>>>>>> Hmm, strange. Try being explicit about sql:
>>>>>>
>>>>>> # certutil -L -d sql:/etc/pki/nssdb
>>>>>>
>>>>>> And if there is a CA cert there, delete it.
>>>>>>
>>>>>> rob
>>>>>>
>>>>>>>
>>>>>>> On Dec 5, 2014 4:39 PM, "Rob Crittenden" <rcritten at redhat.com
>>>>>>> <mailto:rcritten at redhat.com>> wrote:
>>>>>>>
>>>>>>>     Megan . wrote:
>>>>>>>     > Thanks.
>>>>>>>     >
>>>>>>>     > I did have an issue last week where i tried to do the client install
>>>>>>>     > and it failed because of a firewall issue.  Networks has it opened
>>>>>>>     > now.  I deleted ca.crt before trying again.  There doesn't seem to be
>>>>>>>     > a certificate in /etc/pki/nssdb for it.
>>>>>>>     >
>>>>>>>     >
>>>>>>>     >
>>>>>>>     > [root at data2-uat ipa]# certutil -L -d /etc/pki/nssdb
>>>>>>>     >
>>>>>>>     >
>>>>>>>     > Certificate Nickname                                         Trust
>>>>>>>     Attributes
>>>>>>>     >
>>>>>>>     >
>>>>>>>     SSL,S/MIME,JAR/XPI
>>>>>>>     >
>>>>>>>     >
>>>>>>>     > [root at data2-uat ipa]# certutil -D -n 'IPA CA' -d /etc/pki/nssdb
>>>>>>>     >
>>>>>>>     > certutil: could not find certificate named "IPA CA":
>>>>>>>     > SEC_ERROR_BAD_DATABASE: security library: bad database.
>>>>>>>     >
>>>>>>>     > [root at data2-uat ipa]# ls
>>>>>>>     >
>>>>>>>     > [root at data2-uat ipa]# pwd
>>>>>>>     >
>>>>>>>     > /etc/ipa
>>>>>>>     >
>>>>>>>     > [root at data2-uat ipa]# ls -al
>>>>>>>     >
>>>>>>>     > total 16
>>>>>>>     >
>>>>>>>     > drwxr-xr-x.  2 root root  4096 Dec  5 21:16 .
>>>>>>>     >
>>>>>>>     > drwxr-xr-x. 82 root root 12288 Dec  5 21:16 ..
>>>>>>>     >
>>>>>>>     > [root at data2-uat ipa]#
>>>>>>>
>>>>>>>     So trying to install the client again fails or succeeds now?
>>>>>>>
>>>>>>>     rob
>>>>>>>
>>>>>>>     >
>>>>>>>     > On Fri, Dec 5, 2014 at 4:03 PM, Rob Crittenden
>>>>>>>     <rcritten at redhat.com <mailto:rcritten at redhat.com>> wrote:
>>>>>>>     >> Rob Crittenden wrote:
>>>>>>>     >>> Megan . wrote:
>>>>>>>     >>>> Good Day!
>>>>>>>     >>>>
>>>>>>>     >>>> I am getting an error when i register new clients.
>>>>>>>     >>>>
>>>>>>>     >>>> libcurl failed to execute the HTTP POST transaction.  SSL
>>>>>>>     connect error
>>>>>>>     >>>>
>>>>>>>     >>>> I can't find anything useful not the internet about the error.  Can
>>>>>>>     >>>> someone help me troubleshoot?
>>>>>>>     >>>>
>>>>>>>     >>>> CentOS 6.6  x64
>>>>>>>     >>>> ipa-client-3.0.0-42.el6.centos.x86_64
>>>>>>>     >>>> ipa-server-3.0.0-42.el6.centos.x86_64
>>>>>>>     >>>> curl-7.19.7-40.el6_6.1.x86_64
>>>>>>>     >>>
>>>>>>>     >>> Do you have NSS_DEFAULT_DB_TYPE set to sql? I don't know that
>>>>>>>     we've done
>>>>>>>     >>> any testing on the client with this set.
>>>>>>>     >>
>>>>>>>     >> Never mind, that's not it. The problem is:
>>>>>>>     >>
>>>>>>>     >> * NSS error -8054
>>>>>>>     >>
>>>>>>>     >> Which is SEC_ERROR_REUSED_ISSUER_AND_SERIAL
>>>>>>>     >>
>>>>>>>     >> So I'd do this:
>>>>>>>     >>
>>>>>>>     >> # rm /etc/ipa/ca.crt
>>>>>>>     >>
>>>>>>>     >> You may also want to ensure that the IPA CA certificate isn't in
>>>>>>>     >> /etc/pki/nssdb:
>>>>>>>     >>
>>>>>>>     >> # certutil -L -d /etc/pki/nssdb
>>>>>>>     >>
>>>>>>>     >> And then perhaps
>>>>>>>     >>
>>>>>>>     >> # certutil -D -n 'IPA CA' -d /etc/pki/nssdb
>>>>>>>     >>
>>>>>>>     >> rob
>>>>>>>     >>
>>>>>>>
>>>>>>
>>>>
>>>
>>
>



From tbordaz at redhat.com  Tue Dec  9 15:07:57 2014
From: tbordaz at redhat.com (thierry bordaz)
Date: Tue, 09 Dec 2014 16:07:57 +0100
Subject: [Freeipa-users] [Freeipa-interest] Announcing FreeIPA 4.1.2 -
 NEED HELP WITH 2FA/OTP!!!
In-Reply-To: <5486CBDF.7050606@redhat.com>
References: <54775877.6060102@redhat.com>	<176433463.23902008.1417805679430.JavaMail.zimbra@redhat.com>	<54845DA3.3070104@redhat.com>
	<5486BA7E.90100@redhat.com> <5486C09A.5060902@redhat.com>
	<5486C581.9020209@redhat.com> <5486CBDF.7050606@redhat.com>
Message-ID: <5487104D.8050205@redhat.com>

On 12/09/2014 11:15 AM, thierry bordaz wrote:
> On 12/09/2014 10:48 AM, Niranjan M.R wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 12/09/2014 02:57 PM, thierry bordaz wrote:
>>> Hello,
>>>
>>> Niranjan, may I have access to your test machine.
>>>
>> It's a vm on my laptop. I am trying to reproduce on another VM
>> to which i can give access. I will provide the details of this VM as 
>> soon
>> as possible.
>>
>> Mean while i am providing ns-slapd access logs, ipa-logs and pkispawn 
>> logs.
>
> Something curious is that the installer is waiting for DS to restart 
> but it is looking like DS has not received the terminaison signal.
>
> 2014-12-09T09:37:49Z DEBUG Waiting for CA to start...
> ...
> 2014-12-09T09:42:45Z DEBUG Waiting for CA to start...
>
>
> [09/Dec/2014:04:37:41 -0500] - Warning: Adding configuration attribute 
> "nsslapd-security"
>
> << here we should expect a restart of DS >>
>
> First why DS did not receive the restart order and then as it is still 
> running (DS looks idle) what does the install is waiting for.

    At the end of  the CS configuration, the installer configure ssl
    DS,  restart DS it and then reach the ldap to retrieve the CA
    status. It fails

    pki/pki-tomcat/localhost.2014-12-09.log
    Dec 09, 2014 4:37:49 AM
    org.apache.catalina.core.StandardWrapperValve invoke
    SEVERE: Servlet.service() for servlet [caGetStatus] in context with
    path [/ca] threw exception
    java.io.IOException: CS server is not ready to serve.
             at
    com.netscape.cms.servlet.base.CMSServlet.service(CMSServlet.java:443)
             at javax.servlet.http.HttpServlet.service(HttpServlet.java:728)
             at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
             at
    sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
             at
    sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
             at java.lang.reflect.Method.invoke(Method.java:606)
             at
    org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:277)
             at
    org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:274)
             at java.security.AccessController.doPrivileged(Native Method)
             at javax.security.auth.Subject.doAsPrivileged(Subject.java:536)
             at
    org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:309)
             at
    org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:169)
             at
    org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:299)
             at
    org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:57)
             at
    org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:193)
             at
    org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:189)
             at java.security.AccessController.doPrivileged(Native Method)
             at
    org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
             at
    org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222)
             at
    org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)
             at
    org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:502)
             at
    org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)
             at
    org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:100)
             at
    org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:953)
             at
    org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
             at
    org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408)
             at
    org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1041)
             at
    org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:603)
             at
    org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:310)
             at
    java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
             at
    java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
             at java.lang.Thread.run(Thread.java:745)

    Its fails to reach DS because:
    0.localhost-startStop-1 - [09/Dec/2014:04:37:49 EST] [8] [3] In Ldap
    (bound) connection pool to host xxxx port 636, Cannot connect to
    LDAP server. Error: netscape.ldap.LDAPException: IO Error creating
    JSS SSL Socket (-1)

    Having not been able to restart DS, the secure port is not enabled
    so the CA failure after 5min was normal.

    So the remaining question was why the DS service restart failed.
    The systemd file was  dirsrv at dir.service ->
    /usr/lib/systemd/system/dirsrv at .service.


>
>
>
>>
>>
>>> thanks
>>> theirry
>>>
>>>
>>> On 12/09/2014 10:01 AM, Martin Kosek wrote:
>>>> On 12/07/2014 03:01 PM, Niranjan M.R wrote:
>>>>> On 12/06/2014 12:24 AM, Dmitri Pal wrote:
>>>>>> Hello,
>>>>>> WE NEED HELP!
>>>>>> The biggest and the most interesting feature of FreeIPA 4.1.2 is 
>>>>>> support for the two factor authentication using HOTP/TOTP 
>>>>>> compatible software tokens like FreeOTP (open source compatible 
>>>>>> alternative to Google Authenticator) and hardware tokens like 
>>>>>> Yubikeys. This feature allows Kerberos and LDAP clients of a 
>>>>>> FreeIPA server to authenticate using the normal account password 
>>>>>> as the first factor and an OTP token as a second factor. For 
>>>>>> those environments where a 2FA solution is already in place, 
>>>>>> FreeIPA can act as a proxy via RADIUS. More about this feature 
>>>>>> can be read here.
>>>>>> http://www.freeipa.org/page/V4/OTP
>>>>>> If you want to see this feature in downstream distros sooner 
>>>>>> rather than later we need your help!
>>>>>> Please give it a try and provide feedback. We really, really need 
>>>>>> it!
>>>>> I am unable to configure ipa-server with 
>>>>> freeipa-server-4.1.2-1.fc20.x86_64,  ipa-server-install fails with 
>>>>> below error:
>>>>>
>>>>> Done configuring certificate server (pki-tomcatd).
>>>>> Configuring directory server (dirsrv): Estimated time 10 seconds
>>>>>     [1/3]: configuring ssl for ds instance
>>>>>     [2/3]: restarting directory server
>>>>> ipa         : CRITICAL Failed to restart the directory server 
>>>>> ([Errno 2] No such file or directory:
>>>>> '/etc/systemd/system/dirsrv.target.wants/dirsrv at EXAMPLE-ORG.service'). 
>>>>> See the installation log for details.
>>>>>     [3/3]: adding CA certificate entry
>>>>> Done configuring directory server (dirsrv).
>>>>> CA did not start in 300.0s
>>>>>
>>>>>
>>>>> Versions used:
>>>>> ==============
>>>>> freeipa-client-4.1.2-1.fc20.x86_64
>>>>> freeipa-server-4.1.2-1.fc20.x86_64
>>>>> libipa_hbac-1.12.2-2.fc20.x86_64
>>>>> libipa_hbac-python-1.12.2-2.fc20.x86_64
>>>>> sssd-ipa-1.12.2-2.fc20.x86_64
>>>>> device-mapper-multipath-0.4.9-56.fc20.x86_64
>>>>> python-iniparse-0.4-9.fc20.noarch
>>>>> freeipa-admintools-4.1.2-1.fc20.x86_64
>>>>> freeipa-python-4.1.2-1.fc20.x86_64
>>>>> 389-ds-base-libs-1.3.3.5-1.fc20.x86_64
>>>>> 389-ds-base-1.3.3.5-1.fc20.x86_64
>>>>>
>>>>> BaseOS:Fedora release 20 (Heisenbug)
>>>>>
>>>>>
>>>>> Steps to reproduce:
>>>>> ---------------
>>>>>
>>>>> 1. On Fedora-20 system, Used mkosek freeipa repo:
>>>>> [mkosek-freeipa]
>>>>> name=Copr repo for freeipa owned by mkosek
>>>>> baseurl=http://copr-be.cloud.fedoraproject.org/results/mkosek/freeipa/fedora-$releasever-$basearch/ 
>>>>>
>>>>> skip_if_unavailable=True
>>>>> gpgcheck=0
>>>>> enabled=1
>>>>>
>>>>> 2. Install freeipa-server packages from the above repo
>>>>>
>>>>> 3. Issue ipa-server-install
>>>>>
>>>>> [root at pkiserver1 ~]# ipa-server-install
>>>>>
>>>>> The log file for this installation can be found in 
>>>>> /var/log/ipaserver-install.log
>>>>> ============================================================================== 
>>>>>
>>>>> This program will set up the FreeIPA Server.
>>>>>
>>>>> This includes:
>>>>>     * Configure a stand-alone CA (dogtag) for certificate management
>>>>>     * Configure the Network Time Daemon (ntpd)
>>>>>     * Create and configure an instance of Directory Server
>>>>>     * Create and configure a Kerberos Key Distribution Center (KDC)
>>>>>     * Configure Apache (httpd)
>>>>>
>>>>> To accept the default shown in brackets, press the Enter key.
>>>>>
>>>>> WARNING: conflicting time&date synchronization service 'chronyd' 
>>>>> will be disabled
>>>>> in favor of ntpd
>>>>>
>>>>> Do you want to configure integrated DNS (BIND)? [no]: yes
>>>>>
>>>>> Existing BIND configuration detected, overwrite? [no]: yes
>>>>> Enter the fully qualified domain name of the computer
>>>>> on which you're setting up server software. Using the form
>>>>> <hostname>.<domainname>
>>>>> Example: master.example.com.
>>>>>
>>>>>
>>>>> Server host name [pkiserver1.example.org]:
>>>>>
>>>>> Warning: skipping DNS resolution of host pkiserver1.example.org
>>>>> The domain name has been determined based on the host name.
>>>>>
>>>>> Please confirm the domain name [example.org]:
>>>>>
>>>>> The kerberos protocol requires a Realm name to be defined.
>>>>> This is typically the domain name converted to uppercase.
>>>>>
>>>>> Please provide a realm name [EXAMPLE.ORG]:
>>>>> Certain directory server operations require an administrative user.
>>>>> This user is referred to as the Directory Manager and has full access
>>>>> to the Directory for system management tasks and will be added to the
>>>>>
>>>>> The IPA server requires an administrative user, named 'admin'.
>>>>> This user is a regular system account used for IPA server 
>>>>> administration.
>>>>>
>>>>> IPA admin password:
>>>>> Password (confirm):
>>>>>
>>>>> Do you want to configure DNS forwarders? [yes]: no
>>>>> No DNS forwarders configured
>>>>> Do you want to configure the reverse zone? [yes]:
>>>>> Please specify the reverse zone name [122.168.192.in-addr.arpa.]:
>>>>> Using reverse zone(s) 122.168.192.in-addr.arpa.
>>>>>
>>>>> The IPA Master Server will be configured with:
>>>>> Hostname:       pkiserver1.example.org
>>>>> IP address(es): 192.168.122.246
>>>>> Domain name:    example.org
>>>>> Realm name:     EXAMPLE.ORG
>>>>>
>>>>> BIND DNS server will be configured to serve IPA domain with:
>>>>> Forwarders:    No forwarders
>>>>> Reverse zone(s):  122.168.192.in-addr.arpa.
>>>>>
>>>>> Continue to configure the system with these values? [no]: yes
>>>>>
>>>>> The following operations may take some minutes to complete.
>>>>> Please wait until the prompt is returned.
>>>>>
>>>>>
>>>>> instance of directory server created for IPA.
>>>>> The password must be at least 8 characters long.
>>>>>
>>>>> Directory Manager password:
>>>>> Password (confirm):
>>>>> Configuring NTP daemon (ntpd)
>>>>>     [1/4]: stopping ntpd
>>>>>     [2/4]: writing configuration
>>>>>     [3/4]: configuring ntpd to start on boot
>>>>>     [4/4]: starting ntpd
>>>>> Done configuring NTP daemon (ntpd).
>>>>> Configuring directory server (dirsrv): Estimated time 1 minute
>>>>>     [1/38]: creating directory server user
>>>>>     [2/38]: creating directory server instance
>>>>>     [3/38]: adding default schema
>>>>>     [4/38]: enabling memberof plugin
>>>>>     [5/38]: enabling winsync plugin
>>>>>     [6/38]: configuring replication version plugin
>>>>>     [7/38]: enabling IPA enrollment plugin
>>>>>     [8/38]: enabling ldapi
>>>>>     [9/38]: configuring uniqueness plugin
>>>>>     [10/38]: configuring uuid plugin
>>>>>     [11/38]: configuring modrdn plugin
>>>>>     [12/38]: configuring DNS plugin
>>>>>     [13/38]: enabling entryUSN plugin
>>>>>     [14/38]: configuring lockout plugin
>>>>>     [15/38]: creating indices
>>>>>     [16/38]: enabling referential integrity plugin
>>>>>     [17/38]: configuring certmap.conf
>>>>>     [18/38]: configure autobind for root
>>>>>     [19/38]: configure new location for managed entries
>>>>>     [20/38]: configure dirsrv ccache
>>>>>     [21/38]: enable SASL mapping fallback
>>>>>     [22/38]: restarting directory server
>>>>>     [23/38]: adding default layout
>>>>>     [24/38]: adding delegation layout
>>>>>     [25/38]: creating container for managed entries
>>>>>     [26/38]: configuring user private groups
>>>>>     [27/38]: configuring netgroups from hostgroups
>>>>>     [28/38]: creating default Sudo bind user
>>>>>     [29/38]: creating default Auto Member layout
>>>>>     [30/38]: adding range check plugin
>>>>>     [31/38]: creating default HBAC rule allow_all
>>>>>     [32/38]: initializing group membership
>>>>>     [33/38]: adding master entry
>>>>>     [34/38]: configuring Posix uid/gid generation
>>>>>     [35/38]: adding replication acis
>>>>>     [36/38]: enabling compatibility plugin
>>>>>     [37/38]: tuning directory server
>>>>>     [38/38]: configuring directory to start on boot
>>>>> Done configuring directory server (dirsrv).
>>>>> Configuring certificate server (pki-tomcatd): Estimated time 3 
>>>>> minutes 30 seconds
>>>>>     [1/27]: creating certificate server user
>>>>>     [2/27]: configuring certificate server instance
>>>>>     [3/27]: stopping certificate server instance to update CS.cfg
>>>>>     [4/27]: backing up CS.cfg
>>>>>     [5/27]: disabling nonces
>>>>>     [6/27]: set up CRL publishing
>>>>>     [7/27]: enable PKIX certificate path discovery and validation
>>>>>     [8/27]: starting certificate server instance
>>>>>     [9/27]: creating RA agent certificate database
>>>>>     [10/27]: importing CA chain to RA certificate database
>>>>>     [11/27]: fixing RA database permissions
>>>>>     [12/27]: setting up signing cert profile
>>>>>     [13/27]: set certificate subject base
>>>>>     [14/27]: enabling Subject Key Identifier
>>>>>     [15/27]: enabling Subject Alternative Name
>>>>>     [16/27]: enabling CRL and OCSP extensions for certificates
>>>>>     [17/27]: setting audit signing renewal to 2 years
>>>>>     [18/27]: configuring certificate server to start on boot
>>>>>     [19/27]: restarting certificate server
>>>>>     [20/27]: requesting RA certificate from CA
>>>>>     [21/27]: issuing RA agent certificate
>>>>>     [22/27]: adding RA agent as a trusted user
>>>>>     [23/27]: configure certmonger for renewals
>>>>>     [24/27]: configure certificate renewals
>>>>>     [25/27]: configure RA certificate renewal
>>>>>     [26/27]: configure Server-Cert certificate renewal
>>>>>     [27/27]: Configure HTTP to proxy connections
>>>>> Done configuring certificate server (pki-tomcatd).
>>>>> Configuring directory server (dirsrv): Estimated time 10 seconds
>>>>>     [1/3]: configuring ssl for ds instance
>>>>>     [2/3]: restarting directory server
>>>>> ipa         : CRITICAL Failed to restart the directory server 
>>>>> ([Errno 2] No such file or directory:
>>>>> '/etc/systemd/system/dirsrv.target.wants/dirsrv at EXAMPLE-ORG.service'). 
>>>>> See the installation log for details.
>>>>>     [3/3]: adding CA certificate entry
>>>>> Done configuring directory server (dirsrv).
>>>>>
>>>>> CA did not start in 300.0s
>>>>>
>>>>> Attaching ipaserver-install.log, pkispawn logs
>>>>>
>>>>> Any hints on how to overcome the above error.
>>>> The error is obviously in Directory Server restart. I am not sure 
>>>> what causes
>>>>
>>>> 2014-12-07T11:16:25Z DEBUG   [2/3]: restarting directory server
>>>> 2014-12-07T11:16:25Z CRITICAL Failed to restart the directory 
>>>> server ([Errno 2]
>>>> No such file or directory:
>>>> '/etc/systemd/system/dirsrv.target.wants/dirsrv at EXAMPLE-ORG.service'). 
>>>> See the
>>>> installation log for details.
>>>>
>>>> The first restart worked and it uses the same call, AFAIK. It would be
>>>> interesting to see the latest logs of the instance after 
>>>> ipa-server-install
>>>> crashes:
>>>>
>>>> # systemctl status dirsrv at EXAMPLE-ORG.service
>>>>
>>>> It may have some useful logs that would reveal what happened.
>>>>
>>>> Martin
>>
>> - -- Niranjan
>> irc: mrniranjan
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1
>>
>> iKYEARECAGYFAlSGxYFfFIAAAAAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl
>> bnBncC5maWZ0aGhvcnNlbWFuLm5ldEY3OTE3QTg3ODE0RkVCQ0YyNjgyOTRENjJF
>> RURDNTVGNjA0N0M3QzcACgkQLu3FX2BHx8e61wCgtCSWtdpOMWVP+Pr7fPmoXiPC
>> DAsAoI0phFg3dtQJNRvpm8YCjLEs9r66
>> =1MYR
>> -----END PGP SIGNATURE-----
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141209/1f5fa958/attachment.htm>

From tbordaz at redhat.com  Tue Dec  9 17:44:30 2014
From: tbordaz at redhat.com (thierry bordaz)
Date: Tue, 09 Dec 2014 18:44:30 +0100
Subject: [Freeipa-users] [Freeipa-interest] Announcing FreeIPA 4.1.2 -
 NEED HELP WITH 2FA/OTP!!!
In-Reply-To: <5487104D.8050205@redhat.com>
References: <54775877.6060102@redhat.com>	<176433463.23902008.1417805679430.JavaMail.zimbra@redhat.com>	<54845DA3.3070104@redhat.com>
	<5486BA7E.90100@redhat.com> <5486C09A.5060902@redhat.com>
	<5486C581.9020209@redhat.com> <5486CBDF.7050606@redhat.com>
	<5487104D.8050205@redhat.com>
Message-ID: <548734FE.6050108@redhat.com>

On 12/09/2014 04:07 PM, thierry bordaz wrote:
> On 12/09/2014 11:15 AM, thierry bordaz wrote:
>> On 12/09/2014 10:48 AM, Niranjan M.R wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> On 12/09/2014 02:57 PM, thierry bordaz wrote:
>>>> Hello,
>>>>
>>>> Niranjan, may I have access to your test machine.
>>>>
>>> It's a vm on my laptop. I am trying to reproduce on another VM
>>> to which i can give access. I will provide the details of this VM as 
>>> soon
>>> as possible.
>>>
>>> Mean while i am providing ns-slapd access logs, ipa-logs and 
>>> pkispawn logs.
>>
>> Something curious is that the installer is waiting for DS to restart 
>> but it is looking like DS has not received the terminaison signal.
>>
>> 2014-12-09T09:37:49Z DEBUG Waiting for CA to start...
>> ...
>> 2014-12-09T09:42:45Z DEBUG Waiting for CA to start...
>>
>>
>> [09/Dec/2014:04:37:41 -0500] - Warning: Adding configuration 
>> attribute "nsslapd-security"
>>
>> << here we should expect a restart of DS >>
>>
>> First why DS did not receive the restart order and then as it is 
>> still running (DS looks idle) what does the install is waiting for.
>
>     At the end of  the CS configuration, the installer configure ssl
>     DS,  restart DS it and then reach the ldap to retrieve the CA
>     status. It fails
>
>     pki/pki-tomcat/localhost.2014-12-09.log
>     Dec 09, 2014 4:37:49 AM
>     org.apache.catalina.core.StandardWrapperValve invoke
>     SEVERE: Servlet.service() for servlet [caGetStatus] in context
>     with path [/ca] threw exception
>     java.io.IOException: CS server is not ready to serve.
>             at
>     com.netscape.cms.servlet.base.CMSServlet.service(CMSServlet.java:443)
>             at
>     javax.servlet.http.HttpServlet.service(HttpServlet.java:728)
>             at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>             at
>     sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>             at
>     sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>             at java.lang.reflect.Method.invoke(Method.java:606)
>             at
>     org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:277)
>             at
>     org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:274)
>             at java.security.AccessController.doPrivileged(Native Method)
>             at
>     javax.security.auth.Subject.doAsPrivileged(Subject.java:536)
>             at
>     org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:309)
>             at
>     org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:169)
>             at
>     org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:299)
>             at
>     org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:57)
>             at
>     org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:193)
>             at
>     org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:189)
>             at java.security.AccessController.doPrivileged(Native Method)
>             at
>     org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
>             at
>     org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222)
>             at
>     org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)
>             at
>     org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:502)
>             at
>     org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)
>             at
>     org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:100)
>             at
>     org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:953)
>             at
>     org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
>             at
>     org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408)
>             at
>     org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1041)
>             at
>     org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:603)
>             at
>     org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:310)
>             at
>     java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>             at
>     java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>             at java.lang.Thread.run(Thread.java:745)
>
>     Its fails to reach DS because:
>     0.localhost-startStop-1 - [09/Dec/2014:04:37:49 EST] [8] [3] In
>     Ldap (bound) connection pool to host xxxx port 636, Cannot connect
>     to LDAP server. Error: netscape.ldap.LDAPException: IO Error
>     creating JSS SSL Socket (-1)
>
>     Having not been able to restart DS, the secure port is not enabled
>     so the CA failure after 5min was normal.
>
>     So the remaining question was why the DS service restart failed.
>     The systemd file was dirsrv at dir.service ->
>     /usr/lib/systemd/system/dirsrv at .service.
>

I compared the installation logs with my own installation and I have not 
found any difference that would explain why you got 
'/etc/systemd/system/dirsrv.target.wants/dirsrv at dir.service' instead of 
'/etc/systemd/system/dirsrv.target.wants/dirsrv at EXAMPLE-ORG.service'.

I would like to check if /var/lib/ipa/sysrestore/sysrestore.state file 
contains 'serverid=dir' or 'serverid=EXAMPLE-ORG'. would you please sent 
it to me ?

thanks
thierry
>
>
>>
>>
>>
>>>
>>>
>>>> thanks
>>>> theirry
>>>>
>>>>
>>>> On 12/09/2014 10:01 AM, Martin Kosek wrote:
>>>>> On 12/07/2014 03:01 PM, Niranjan M.R wrote:
>>>>>> On 12/06/2014 12:24 AM, Dmitri Pal wrote:
>>>>>>> Hello,
>>>>>>> WE NEED HELP!
>>>>>>> The biggest and the most interesting feature of FreeIPA 4.1.2 is 
>>>>>>> support for the two factor authentication using HOTP/TOTP 
>>>>>>> compatible software tokens like FreeOTP (open source compatible 
>>>>>>> alternative to Google Authenticator) and hardware tokens like 
>>>>>>> Yubikeys. This feature allows Kerberos and LDAP clients of a 
>>>>>>> FreeIPA server to authenticate using the normal account password 
>>>>>>> as the first factor and an OTP token as a second factor. For 
>>>>>>> those environments where a 2FA solution is already in place, 
>>>>>>> FreeIPA can act as a proxy via RADIUS. More about this feature 
>>>>>>> can be read here.
>>>>>>> http://www.freeipa.org/page/V4/OTP
>>>>>>> If you want to see this feature in downstream distros sooner 
>>>>>>> rather than later we need your help!
>>>>>>> Please give it a try and provide feedback. We really, really 
>>>>>>> need it!
>>>>>> I am unable to configure ipa-server with 
>>>>>> freeipa-server-4.1.2-1.fc20.x86_64,  ipa-server-install fails 
>>>>>> with below error:
>>>>>>
>>>>>> Done configuring certificate server (pki-tomcatd).
>>>>>> Configuring directory server (dirsrv): Estimated time 10 seconds
>>>>>>     [1/3]: configuring ssl for ds instance
>>>>>>     [2/3]: restarting directory server
>>>>>> ipa         : CRITICAL Failed to restart the directory server 
>>>>>> ([Errno 2] No such file or directory:
>>>>>> '/etc/systemd/system/dirsrv.target.wants/dirsrv at EXAMPLE-ORG.service'). 
>>>>>> See the installation log for details.
>>>>>>     [3/3]: adding CA certificate entry
>>>>>> Done configuring directory server (dirsrv).
>>>>>> CA did not start in 300.0s
>>>>>>
>>>>>>
>>>>>> Versions used:
>>>>>> ==============
>>>>>> freeipa-client-4.1.2-1.fc20.x86_64
>>>>>> freeipa-server-4.1.2-1.fc20.x86_64
>>>>>> libipa_hbac-1.12.2-2.fc20.x86_64
>>>>>> libipa_hbac-python-1.12.2-2.fc20.x86_64
>>>>>> sssd-ipa-1.12.2-2.fc20.x86_64
>>>>>> device-mapper-multipath-0.4.9-56.fc20.x86_64
>>>>>> python-iniparse-0.4-9.fc20.noarch
>>>>>> freeipa-admintools-4.1.2-1.fc20.x86_64
>>>>>> freeipa-python-4.1.2-1.fc20.x86_64
>>>>>> 389-ds-base-libs-1.3.3.5-1.fc20.x86_64
>>>>>> 389-ds-base-1.3.3.5-1.fc20.x86_64
>>>>>>
>>>>>> BaseOS:Fedora release 20 (Heisenbug)
>>>>>>
>>>>>>
>>>>>> Steps to reproduce:
>>>>>> ---------------
>>>>>>
>>>>>> 1. On Fedora-20 system, Used mkosek freeipa repo:
>>>>>> [mkosek-freeipa]
>>>>>> name=Copr repo for freeipa owned by mkosek
>>>>>> baseurl=http://copr-be.cloud.fedoraproject.org/results/mkosek/freeipa/fedora-$releasever-$basearch/ 
>>>>>>
>>>>>> skip_if_unavailable=True
>>>>>> gpgcheck=0
>>>>>> enabled=1
>>>>>>
>>>>>> 2. Install freeipa-server packages from the above repo
>>>>>>
>>>>>> 3. Issue ipa-server-install
>>>>>>
>>>>>> [root at pkiserver1 ~]# ipa-server-install
>>>>>>
>>>>>> The log file for this installation can be found in 
>>>>>> /var/log/ipaserver-install.log
>>>>>> ============================================================================== 
>>>>>>
>>>>>> This program will set up the FreeIPA Server.
>>>>>>
>>>>>> This includes:
>>>>>>     * Configure a stand-alone CA (dogtag) for certificate management
>>>>>>     * Configure the Network Time Daemon (ntpd)
>>>>>>     * Create and configure an instance of Directory Server
>>>>>>     * Create and configure a Kerberos Key Distribution Center (KDC)
>>>>>>     * Configure Apache (httpd)
>>>>>>
>>>>>> To accept the default shown in brackets, press the Enter key.
>>>>>>
>>>>>> WARNING: conflicting time&date synchronization service 'chronyd' 
>>>>>> will be disabled
>>>>>> in favor of ntpd
>>>>>>
>>>>>> Do you want to configure integrated DNS (BIND)? [no]: yes
>>>>>>
>>>>>> Existing BIND configuration detected, overwrite? [no]: yes
>>>>>> Enter the fully qualified domain name of the computer
>>>>>> on which you're setting up server software. Using the form
>>>>>> <hostname>.<domainname>
>>>>>> Example: master.example.com.
>>>>>>
>>>>>>
>>>>>> Server host name [pkiserver1.example.org]:
>>>>>>
>>>>>> Warning: skipping DNS resolution of host pkiserver1.example.org
>>>>>> The domain name has been determined based on the host name.
>>>>>>
>>>>>> Please confirm the domain name [example.org]:
>>>>>>
>>>>>> The kerberos protocol requires a Realm name to be defined.
>>>>>> This is typically the domain name converted to uppercase.
>>>>>>
>>>>>> Please provide a realm name [EXAMPLE.ORG]:
>>>>>> Certain directory server operations require an administrative user.
>>>>>> This user is referred to as the Directory Manager and has full 
>>>>>> access
>>>>>> to the Directory for system management tasks and will be added to 
>>>>>> the
>>>>>>
>>>>>> The IPA server requires an administrative user, named 'admin'.
>>>>>> This user is a regular system account used for IPA server 
>>>>>> administration.
>>>>>>
>>>>>> IPA admin password:
>>>>>> Password (confirm):
>>>>>>
>>>>>> Do you want to configure DNS forwarders? [yes]: no
>>>>>> No DNS forwarders configured
>>>>>> Do you want to configure the reverse zone? [yes]:
>>>>>> Please specify the reverse zone name [122.168.192.in-addr.arpa.]:
>>>>>> Using reverse zone(s) 122.168.192.in-addr.arpa.
>>>>>>
>>>>>> The IPA Master Server will be configured with:
>>>>>> Hostname:       pkiserver1.example.org
>>>>>> IP address(es): 192.168.122.246
>>>>>> Domain name:    example.org
>>>>>> Realm name:     EXAMPLE.ORG
>>>>>>
>>>>>> BIND DNS server will be configured to serve IPA domain with:
>>>>>> Forwarders:    No forwarders
>>>>>> Reverse zone(s):  122.168.192.in-addr.arpa.
>>>>>>
>>>>>> Continue to configure the system with these values? [no]: yes
>>>>>>
>>>>>> The following operations may take some minutes to complete.
>>>>>> Please wait until the prompt is returned.
>>>>>>
>>>>>>
>>>>>> instance of directory server created for IPA.
>>>>>> The password must be at least 8 characters long.
>>>>>>
>>>>>> Directory Manager password:
>>>>>> Password (confirm):
>>>>>> Configuring NTP daemon (ntpd)
>>>>>>     [1/4]: stopping ntpd
>>>>>>     [2/4]: writing configuration
>>>>>>     [3/4]: configuring ntpd to start on boot
>>>>>>     [4/4]: starting ntpd
>>>>>> Done configuring NTP daemon (ntpd).
>>>>>> Configuring directory server (dirsrv): Estimated time 1 minute
>>>>>>     [1/38]: creating directory server user
>>>>>>     [2/38]: creating directory server instance
>>>>>>     [3/38]: adding default schema
>>>>>>     [4/38]: enabling memberof plugin
>>>>>>     [5/38]: enabling winsync plugin
>>>>>>     [6/38]: configuring replication version plugin
>>>>>>     [7/38]: enabling IPA enrollment plugin
>>>>>>     [8/38]: enabling ldapi
>>>>>>     [9/38]: configuring uniqueness plugin
>>>>>>     [10/38]: configuring uuid plugin
>>>>>>     [11/38]: configuring modrdn plugin
>>>>>>     [12/38]: configuring DNS plugin
>>>>>>     [13/38]: enabling entryUSN plugin
>>>>>>     [14/38]: configuring lockout plugin
>>>>>>     [15/38]: creating indices
>>>>>>     [16/38]: enabling referential integrity plugin
>>>>>>     [17/38]: configuring certmap.conf
>>>>>>     [18/38]: configure autobind for root
>>>>>>     [19/38]: configure new location for managed entries
>>>>>>     [20/38]: configure dirsrv ccache
>>>>>>     [21/38]: enable SASL mapping fallback
>>>>>>     [22/38]: restarting directory server
>>>>>>     [23/38]: adding default layout
>>>>>>     [24/38]: adding delegation layout
>>>>>>     [25/38]: creating container for managed entries
>>>>>>     [26/38]: configuring user private groups
>>>>>>     [27/38]: configuring netgroups from hostgroups
>>>>>>     [28/38]: creating default Sudo bind user
>>>>>>     [29/38]: creating default Auto Member layout
>>>>>>     [30/38]: adding range check plugin
>>>>>>     [31/38]: creating default HBAC rule allow_all
>>>>>>     [32/38]: initializing group membership
>>>>>>     [33/38]: adding master entry
>>>>>>     [34/38]: configuring Posix uid/gid generation
>>>>>>     [35/38]: adding replication acis
>>>>>>     [36/38]: enabling compatibility plugin
>>>>>>     [37/38]: tuning directory server
>>>>>>     [38/38]: configuring directory to start on boot
>>>>>> Done configuring directory server (dirsrv).
>>>>>> Configuring certificate server (pki-tomcatd): Estimated time 3 
>>>>>> minutes 30 seconds
>>>>>>     [1/27]: creating certificate server user
>>>>>>     [2/27]: configuring certificate server instance
>>>>>>     [3/27]: stopping certificate server instance to update CS.cfg
>>>>>>     [4/27]: backing up CS.cfg
>>>>>>     [5/27]: disabling nonces
>>>>>>     [6/27]: set up CRL publishing
>>>>>>     [7/27]: enable PKIX certificate path discovery and validation
>>>>>>     [8/27]: starting certificate server instance
>>>>>>     [9/27]: creating RA agent certificate database
>>>>>>     [10/27]: importing CA chain to RA certificate database
>>>>>>     [11/27]: fixing RA database permissions
>>>>>>     [12/27]: setting up signing cert profile
>>>>>>     [13/27]: set certificate subject base
>>>>>>     [14/27]: enabling Subject Key Identifier
>>>>>>     [15/27]: enabling Subject Alternative Name
>>>>>>     [16/27]: enabling CRL and OCSP extensions for certificates
>>>>>>     [17/27]: setting audit signing renewal to 2 years
>>>>>>     [18/27]: configuring certificate server to start on boot
>>>>>>     [19/27]: restarting certificate server
>>>>>>     [20/27]: requesting RA certificate from CA
>>>>>>     [21/27]: issuing RA agent certificate
>>>>>>     [22/27]: adding RA agent as a trusted user
>>>>>>     [23/27]: configure certmonger for renewals
>>>>>>     [24/27]: configure certificate renewals
>>>>>>     [25/27]: configure RA certificate renewal
>>>>>>     [26/27]: configure Server-Cert certificate renewal
>>>>>>     [27/27]: Configure HTTP to proxy connections
>>>>>> Done configuring certificate server (pki-tomcatd).
>>>>>> Configuring directory server (dirsrv): Estimated time 10 seconds
>>>>>>     [1/3]: configuring ssl for ds instance
>>>>>>     [2/3]: restarting directory server
>>>>>> ipa         : CRITICAL Failed to restart the directory server 
>>>>>> ([Errno 2] No such file or directory:
>>>>>> '/etc/systemd/system/dirsrv.target.wants/dirsrv at EXAMPLE-ORG.service'). 
>>>>>> See the installation log for details.
>>>>>>     [3/3]: adding CA certificate entry
>>>>>> Done configuring directory server (dirsrv).
>>>>>>
>>>>>> CA did not start in 300.0s
>>>>>>
>>>>>> Attaching ipaserver-install.log, pkispawn logs
>>>>>>
>>>>>> Any hints on how to overcome the above error.
>>>>> The error is obviously in Directory Server restart. I am not sure 
>>>>> what causes
>>>>>
>>>>> 2014-12-07T11:16:25Z DEBUG   [2/3]: restarting directory server
>>>>> 2014-12-07T11:16:25Z CRITICAL Failed to restart the directory 
>>>>> server ([Errno 2]
>>>>> No such file or directory:
>>>>> '/etc/systemd/system/dirsrv.target.wants/dirsrv at EXAMPLE-ORG.service'). 
>>>>> See the
>>>>> installation log for details.
>>>>>
>>>>> The first restart worked and it uses the same call, AFAIK. It 
>>>>> would be
>>>>> interesting to see the latest logs of the instance after 
>>>>> ipa-server-install
>>>>> crashes:
>>>>>
>>>>> # systemctl status dirsrv at EXAMPLE-ORG.service
>>>>>
>>>>> It may have some useful logs that would reveal what happened.
>>>>>
>>>>> Martin
>>>
>>> - -- Niranjan
>>> irc: mrniranjan
>>> -----BEGIN PGP SIGNATURE-----
>>> Version: GnuPG v1
>>>
>>> iKYEARECAGYFAlSGxYFfFIAAAAAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl
>>> bnBncC5maWZ0aGhvcnNlbWFuLm5ldEY3OTE3QTg3ODE0RkVCQ0YyNjgyOTRENjJF
>>> RURDNTVGNjA0N0M3QzcACgkQLu3FX2BHx8e61wCgtCSWtdpOMWVP+Pr7fPmoXiPC
>>> DAsAoI0phFg3dtQJNRvpm8YCjLEs9r66
>>> =1MYR
>>> -----END PGP SIGNATURE-----
>>
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141209/513d5d45/attachment.htm>

From alee at redhat.com  Tue Dec  9 18:04:51 2014
From: alee at redhat.com (Ade Lee)
Date: Tue, 09 Dec 2014 13:04:51 -0500
Subject: [Freeipa-users] CA Replication Installation Failing
In-Reply-To: <4ED173A868981548967B4FCA2707222628049113@AACMBXP04.exchserver.com>
References: <4ED173A868981548967B4FCA270722262803F3C5@AACMBXP04.exchserver.com>
	<4ED173A868981548967B4FCA2707222628048DF6@AACMBXP04.exchserver.com>
	, <54867F51.1030603@redhat.com>
	<4ED173A868981548967B4FCA2707222628049113@AACMBXP04.exchserver.com>
Message-ID: <1418148291.27499.20.camel@aleeredhat.laptop>

On Tue, 2014-12-09 at 07:48 +0000, Les Stott wrote:
> 
> 
> ______________________________________________________________________
> From: freeipa-users-bounces at redhat.com
> [freeipa-users-bounces at redhat.com] on behalf of Dmitri Pal
> [dpal at redhat.com]
> Sent: Tuesday, December 09, 2014 3:49 PM
> To: freeipa-users at redhat.com
> Subject: Re: [Freeipa-users] CA Replication Installation Failing
> 
> 
> 
> On 12/08/2014 11:04 PM, Les Stott wrote:
> 
> > Does anyone have any ideas on the below errors when trying to add CA
> > replication to an existing replica?
> > 
> > 
> 
> > People who might be able to help are or PTO right now.
> > 
> > Is your installation older than 2 years?
> 
> No, December 2013 was when it was originally built.
> 
> > Did you generate a new replica package or use the original one?
> 
> I used the original replica file for serverb, based on instructions i
> came across. I can try regenerating the replica file.
> 
> Interestingly, now that you mention it, servera had to be restored a
> couple of months back. Perhaps this is an issue and regenerating the
> replica file for serverb will be required.
> 
> I will try this.
> 

I think that this is a safe bet to be the problem.

The error in the log snippet you posted says:

 <errorString>The pkcs12 file is not correct.</errorString>

This indicates that the clone CA was unable to decode the pkcs12 file in
the replica.  Perhaps the certs changed -- or the DM password changed?

Ade
> > May be the problem is that the cert that is in that package already
> expired?
> 
> original replica file was created on Dec 16 2013. Cert is not set to
> expire until 2015-12-17.
> 
> > Just a thought...
> >
> > The simplest workaround IMO would be to prepare Server C, install it
> with CA and then decommission replica B. 
> > Do not forget to clean replication agreements on master.
> >
> > But that would be work around, would not solve this specific
> problem, it will kill it.
> 
> I actually do have serverc and serverd. I planned to have CA
> replication on at least 2 other servers, but held off on trying on
> serverc due to issues with serverb.
> 
> I'll report back what i find after regenerating the replica file and
> re-trying to setup CA replication.
> 
> Thanks,
> 
> Les
> 
> >  
> > 
> > Thanks in advance,
> > 
> >  
> > 
> > Les
> > 
> >  
> > 
> > From:freeipa-users-bounces at redhat.com
> > [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Les Stott
> > Sent: Tuesday, 2 December 2014 6:17 PM
> > To: freeipa-users at redhat.com
> > Subject: [Freeipa-users] CA Replication Installation Failing
> > 
> > 
> >  
> > 
> > Hi All,
> > 
> >  
> > 
> > I have RHEL6 with ipa servers running standard ipa server 3.0.0-42.
> > Pki components are also standard version 9.0.3-38.
> > 
> >  
> > 
> > Servera is the master
> > 
> > Serverb is the replica
> > 
> >  
> > 
> > Both have been running for many, many months. Serverb was initially
> > setup as a replica, but not a CA replica.
> > 
> >  
> > 
> > I am now trying to add CA Replication to serverb but it is failing
> > midway through and I cannot figure out why.
> > 
> >  
> > 
> > Annoyingly, I used the same method/command to setup a CA replica on
> > test servers and it completed without issue.
> > 
> >  
> > 
> > Here is what I get?.(for the sake of brevity, I am excluding the
> > lines for connection check which were all OK)
> > 
> >  
> > 
> > =================
> > 
> > /usr/sbin/ipa-ca-install /var/lib/ipa/replica-info-serverb.mydomain.com.gpg
> > 
> > Directory Manager (existing master) password:
> > 
> > Get credentials to log in to remote master
> > 
> > admin at MYDOMAIN.COM password:
> > 
> > Execute check on remote master
> > 
> > Connection check OK
> > 
> > Configuring directory server for the CA (pkids): Estimated time 30
> > seconds
> > 
> >   [1/3]: creating directory server user
> > 
> >   [2/3]: creating directory server instance
> > 
> >   [3/3]: restarting directory server
> > 
> > Done configuring directory server for the CA (pkids).
> > 
> > Configuring certificate server (pki-cad): Estimated time 3 minutes
> > 30 seconds
> > 
> >   [1/16]: creating certificate server user
> > 
> >   [2/16]: creating pki-ca instance
> > 
> >   [3/16]: configuring certificate server instance
> > 
> > ipa         : CRITICAL failed to configure ca instance Command
> > '/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname
> > serverb.mydomain.com -cs_port 9445
> > -client_certdb_dir /tmp/tmp-t3aHM7 -client_certdb_pwd XXXXXXXX
> > -preop_pin exoyO2y7bawG5yjZMACM -domain_name IPA -admin_user admin
> > -admin_email root at localhost -admin_password XXXXXXXX -agent_name
> > ipa-ca-agent -agent_key_size 2048 -agent_key_type rsa
> > -agent_cert_subject CN=ipa-ca-agent,O=MYDOMAIN.COM -ldap_host
> > serverb.mydomain.com -ldap_port 7389 -bind_dn cn=Directory Manager
> > -bind_password XXXXXXXX -base_dn o=ipaca -db_name ipaca -key_size
> > 2048 -key_type rsa -key_algorithm SHA256withRSA -save_p12 true
> > -backup_pwd XXXXXXXX -subsystem_name pki-cad -token_name internal
> > -ca_subsystem_cert_subject_name CN=CA Subsystem,O=MYDOMAIN.COM
> > -ca_subsystem_cert_subject_name CN=CA Subsystem,O=MYDOMAIN.COM
> > -ca_ocsp_cert_subject_name CN=OCSP Subsystem,O=MYDOMAIN.COM
> > -ca_server_cert_subject_name CN=serverb.mydomain.com,O=MYDOMAIN.COM
> > -ca_audit_signing_cert_subject_name CN=CA Audit,O=MYDOMAIN.COM
> > -ca_sign_cert_subject_name CN=Certificate Authority,O=MYDOMAIN.COM
> > -external false -clone true -clone_p12_file ca.p12
> > -clone_p12_password XXXXXXXX -sd_hostname servera.mydomain.com
> > -sd_admin_port 443 -sd_admin_name admin -sd_admin_password XXXXXXXX
> > -clone_start_tls true -clone_uri https://servera.mydomain.com:443'
> > returned non-zero exit status 255
> > 
> >  
> > 
> > Your system may be partly configured.
> > 
> > Run /usr/sbin/ipa-server-install --uninstall to clean up.
> > 
> >  
> > 
> > Configuration of CA failed
> > 
> > =================
> > 
> >  
> > 
> > Additional excerpt from the log
> > file /var/log/ipareplica-ca-install.log at the point of failure?.
> > 
> >  
> > 
> > =================
> > 
> >  
> > 
> > #############################################
> > 
> > Attempting to connect to: serverb.mydomain.com:9445
> > 
> > Connected.
> > 
> > Posting Query =
> > https://serverb.mydomain.com:9445//ca/admin/console/config/wizard?p=7&op=next&xml=true&__password=XXXXXXXX&path=ca.p12
> > 
> > RESPONSE STATUS:  HTTP/1.1 200 OK
> > 
> > RESPONSE HEADER:  Server: Apache-Coyote/1.1
> > 
> > RESPONSE HEADER:  Content-Type: application/xml;charset=UTF-8
> > 
> > RESPONSE HEADER:  Date: Tue, 02 Dec 2014 05:44:19 GMT
> > 
> > RESPONSE HEADER:  Connection: close
> > 
> > <?xml version="1.0" encoding="UTF-8"?>
> > 
> > <!-- BEGIN COPYRIGHT BLOCK
> > 
> >      This program is free software; you can redistribute it and/or
> > modify
> > 
> >      it under the terms of the GNU General Public License as
> > published by
> > 
> >      the Free Software Foundation; version 2 of the License.
> > 
> >  
> > 
> >      This program is distributed in the hope that it will be useful,
> > 
> >      but WITHOUT ANY WARRANTY; without even the implied warranty of
> > 
> >      MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> > 
> >      GNU General Public License for more details.
> > 
> >  
> > 
> >      You should have received a copy of the GNU General Public
> > License along
> > 
> >      with this program; if not, write to the Free Software
> > Foundation, Inc.,
> > 
> >      51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
> > 
> >  
> > 
> >      Copyright (C) 2007 Red Hat, Inc.
> > 
> >      All rights reserved.
> > 
> >      END COPYRIGHT BLOCK -->
> > 
> > <response>
> > 
> >   <panel>admin/console/config/restorekeycertpanel.vm</panel>
> > 
> >   <res/>
> > 
> >   <updateStatus>failure</updateStatus>
> > 
> >   <password/>
> > 
> >   <errorString>The pkcs12 file is not correct.</errorString>
> > 
> >   <size>19</size>
> > 
> >   <title>Import Keys and Certificates</title>
> > 
> >   <panels>
> > 
> >     <Vector>
> > 
> >       <Panel>
> > 
> >         <Id>welcome</Id>
> > 
> >         <Name>Welcome</Name>
> > 
> >       </Panel>
> > 
> >       <Panel>
> > 
> >         <Id>module</Id>
> > 
> >         <Name>Key Store</Name>
> > 
> >       </Panel>
> > 
> >       <Panel>
> > 
> >         <Id>confighsmlogin</Id>
> > 
> >         <Name>ConfigHSMLogin</Name>
> > 
> >       </Panel>
> > 
> >       <Panel>
> > 
> >         <Id>securitydomain</Id>
> > 
> >         <Name>Security Domain</Name>
> > 
> >       </Panel>
> > 
> >       <Panel>
> > 
> >         <Id>securitydomain</Id>
> > 
> >         <Name>Display Certificate Chain</Name>
> > 
> >       </Panel>
> > 
> >       <Panel>
> > 
> >         <Id>subsystem</Id>
> > 
> >         <Name>Subsystem Type</Name>
> > 
> >       </Panel>
> > 
> >       <Panel>
> > 
> >         <Id>clone</Id>
> > 
> >         <Name>Display Certificate Chain</Name>
> > 
> >       </Panel>
> > 
> >       <Panel>
> > 
> >         <Id>restorekeys</Id>
> > 
> >         <Name>Import Keys and Certificates</Name>
> > 
> >       </Panel>
> > 
> >       <Panel>
> > 
> >         <Id>cahierarchy</Id>
> > 
> >         <Name>PKI Hierarchy</Name>
> > 
> >       </Panel>
> > 
> >       <Panel>
> > 
> >         <Id>database</Id>
> > 
> >         <Name>Internal Database</Name>
> > 
> >       </Panel>
> > 
> >       <Panel>
> > 
> >         <Id>size</Id>
> > 
> >         <Name>Key Pairs</Name>
> > 
> >       </Panel>
> > 
> >       <Panel>
> > 
> >         <Id>subjectname</Id>
> > 
> >         <Name>Subject Names</Name>
> > 
> >       </Panel>
> > 
> >       <Panel>
> > 
> >         <Id>certrequest</Id>
> > 
> >         <Name>Requests and Certificates</Name>
> > 
> >       </Panel>
> > 
> >       <Panel>
> > 
> >         <Id>backupkeys</Id>
> > 
> >         <Name>Export Keys and Certificates</Name>
> > 
> >       </Panel>
> > 
> >       <Panel>
> > 
> >         <Id>savepk12</Id>
> > 
> >         <Name>Save Keys and Certificates</Name>
> > 
> >       </Panel>
> > 
> >       <Panel>
> > 
> >         <Id>importcachain</Id>
> > 
> >         <Name>Import CA's Certificate Chain</Name>
> > 
> >       </Panel>
> > 
> >       <Panel>
> > 
> >         <Id>admin</Id>
> > 
> >         <Name>Administrator</Name>
> > 
> >       </Panel>
> > 
> >       <Panel>
> > 
> >         <Id>importadmincert</Id>
> > 
> >         <Name>Import Administrator's Certificate</Name>
> > 
> >       </Panel>
> > 
> >       <Panel>
> > 
> >         <Id>done</Id>
> > 
> >         <Name>Done</Name>
> > 
> >       </Panel>
> > 
> >     </Vector>
> > 
> >   </panels>
> > 
> >   <name>CA Setup Wizard</name>
> > 
> >   <p>7</p>
> > 
> >   <path/>
> > 
> >   <req/>
> > 
> >   <panelname>restorekeys</panelname>
> > 
> > </response>
> > 
> > Error in RestoreKeyCertPanel(): updateStatus returns failure
> > 
> > ERROR: ConfigureCA: RestoreKeyCertPanel() failure
> > 
> > ERROR: unable to create CA
> > 
> >  
> > 
> > #######################################################################
> > 
> > 2014-12-02T05:44:19Z DEBUG stderr=
> > 
> > 2014-12-02T05:44:19Z CRITICAL failed to configure ca instance
> > Command '/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname
> > serverb.mydomain.com -cs_port 9445
> > -client_certdb_dir /tmp/tmp-1Tqws5 -client_certdb_pwd XXXXXXXX
> > -preop_pin rdkE0y2CiGMKNcRRPKKc -domain_name IPA -admin_user admin
> > -admin_email root at localhost -admin_password XXXXXXXX -agent_name
> > ipa-ca-agent -agent_key_size 2048 -agent_key_type rsa
> > -agent_cert_subject CN=ipa-ca-agent,O=MYDOMAIN.COM -ldap_host
> > serverb.mydomain.com -ldap_port 7389 -bind_dn cn=Directory Manager
> > -bind_password XXXXXXXX -base_dn o=ipaca -db_name ipaca -key_size
> > 2048 -key_type rsa -key_algorithm SHA256withRSA -save_p12 true
> > -backup_pwd XXXXXXXX -subsystem_name pki-cad -token_name internal
> > -ca_subsystem_cert_subject_name CN=CA Subsystem,O=MYDOMAIN.COM
> > -ca_subsystem_cert_subject_name CN=CA Subsystem,O=MYDOMAIN.COM
> > -ca_ocsp_cert_subject_name CN=OCSP Subsystem,O=MYDOMAIN.COM
> > -ca_server_cert_subject_name CN=serverb.mydomain.com,O=MYDOMAIN.COM
> > -ca_audit_signing_cert_subject_name CN=CA Audit,O=MYDOMAIN.COM
> > -ca_sign_cert_subject_name CN=Certificate Authority,O=MYDOMAIN.COM
> > -external false -clone true -clone_p12_file ca.p12
> > -clone_p12_password XXXXXXXX -sd_hostname servera.mydomain.com
> > -sd_admin_port 443 -sd_admin_name admin -sd_admin_password XXXXXXXX
> > -clone_start_tls true -clone_uri https://servera.mydomain.com:443'
> > returned non-zero exit status 255
> > 
> > 2014-12-02T05:44:19Z INFO   File
> > "/usr/lib/python2.6/site-packages/ipaserver/install/installutils.py", line 614, in run_script
> > 
> >     return_value = main_function()
> > 
> >  
> > 
> >   File "/usr/sbin/ipa-ca-install", line 149, in main
> > 
> >     (CA, cs) = cainstance.install_replica_ca(config,
> > postinstall=True)
> > 
> >  
> > 
> >   File
> > "/usr/lib/python2.6/site-packages/ipaserver/install/cainstance.py",
> > line 1626, in install_replica_ca
> > 
> >     subject_base=config.subject_base)
> > 
> >  
> > 
> >   File
> > "/usr/lib/python2.6/site-packages/ipaserver/install/cainstance.py",
> > line 626, in configure_instance
> > 
> >     self.start_creation(runtime=210)
> > 
> >  
> > 
> >   File
> > "/usr/lib/python2.6/site-packages/ipaserver/install/service.py",
> > line 358, in start_creation
> > 
> >     method()
> > 
> >  
> > 
> >   File
> > "/usr/lib/python2.6/site-packages/ipaserver/install/cainstance.py",
> > line 888, in __configure_instance
> > 
> >     raise RuntimeError('Configuration of CA failed')
> > 
> >  
> > 
> > 2014-12-02T05:44:19Z INFO The ipa-ca-install command failed,
> > exception: RuntimeError: Configuration of CA failed
> > 
> >  
> > 
> > =================
> > 
> >  
> > 
> > I am not sure why this is happening.
> > 
> >  
> > 
> > Certutil shows that the setup isn?t complete on serverb when
> > comparing against the CA replica in my test servers which were
> > successful.
> > 
> >  
> > 
> > # certutil -L -d /var/lib/pki-ca/alias
> > 
> >  
> > 
> > Certificate Nickname                                         Trust
> > Attributes
> > 
> > 
> > SSL,S/MIME,JAR/XPI
> > 
> >  
> > 
> > Certificate Authority - MYDOMAIN.COM                      CT,c,
> > 
> > Server-Cert cert-pki-ca
> > CTu,Cu,Cu
> > 
> >  
> > 
> > # certutil -K -d /var/lib/pki-ca/alias
> > 
> > certutil: Checking token "NSS Certificate DB" in slot "NSS User
> > Private Key and Certificate Services"
> > 
> > Enter Password or Pin for "NSS Certificate DB":
> > 
> > < 0> rsa      ef25de4fb656a27e297899509bc3dad582bcd643   NSS
> > Certificate DB:Server-Cert cert-pki-ca
> > 
> >  
> > 
> >  
> > 
> > As yet, I have not tried ?/usr/sbin/ipa-server-install ?uninstall?
> > in an attempt to cleanup as this is a production server and apart
> > from CA replication, it is running fine. I have tried multiple times
> > manually removing pki instances and reinstalling but it still won?t
> > get past the above error.
> > 
> >  
> > 
> > Can anyone shed any light on this?
> > 
> >  
> > 
> > Thanks in advance,
> > 
> >  
> > 
> > Les
> > 
> >  
> > 
> >  
> > 
> >  
> > 
> >  
> > 
> > 
> > 
> > 
> 
> 
> -- 
> Thank you,
> Dmitri Pal
> 
> Sr. Engineering Manager IdM portfolio
> Red Hat, Inc.




From william.muriithi at gmail.com  Tue Dec  9 22:19:58 2014
From: william.muriithi at gmail.com (William Muriithi)
Date: Tue, 09 Dec 2014 17:19:58 -0500
Subject: [Freeipa-users] SUDO options on freeipa
Message-ID: <20141209221958.6041746.37061.10383@gmail.com>

Afternoon?
?
I have the following commands and I need to set up for Jenkins to run through sudo. ?For this to work, I need to add two sudo options, no password and no requiretty

Is this something supported by IPA version ipa-server-3.3.3-28.el7_0.3.x86_64 ? ?I can't seem to get it working and there is very little documentation on sudo options with IPA on the web.


ipa sudorule-add jenkins --desc "Allow jenkins to deploy ?jboss, imageserver and fileserver ?on all ?the systems"

ipa sudocmdgroup-add-member --sudocmds '/sbin/service jboss start' jenkins_commands
ipa sudocmdgroup-add-member --sudocmds '/sbin/service jboss stop' jenkins_commands

[root at ipa3-yyz-int ~]# ipa sudorule-add-option jenkins_commands --sudooption !authenticate
-bash: !authenticate: event not found

[root at ipa3-yyz-int ~]# ipa sudorule-add-option jenkins_commands
Sudo Option: !requiretty
ipa: ERROR: no such entry

What is the proper way of handling SUDO options with ipa?

Thanks?

William



From rcritten at redhat.com  Tue Dec  9 22:31:38 2014
From: rcritten at redhat.com (Rob Crittenden)
Date: Tue, 09 Dec 2014 17:31:38 -0500
Subject: [Freeipa-users] SUDO options on freeipa
In-Reply-To: <20141209221958.6041746.37061.10383@gmail.com>
References: <20141209221958.6041746.37061.10383@gmail.com>
Message-ID: <5487784A.6080308@redhat.com>

William Muriithi wrote:
> Afternoon 
> ?
> I have the following commands and I need to set up for Jenkins to run through sudo.  For this to work, I need to add two sudo options, no password and no requiretty
> 
> Is this something supported by IPA version ipa-server-3.3.3-28.el7_0.3.x86_64 ?  I can't seem to get it working and there is very little documentation on sudo options with IPA on the web.
> 
> 
> ipa sudorule-add jenkins --desc "Allow jenkins to deploy  jboss, imageserver and fileserver  on all  the systems"
> 
> ipa sudocmdgroup-add-member --sudocmds '/sbin/service jboss start' jenkins_commands
> ipa sudocmdgroup-add-member --sudocmds '/sbin/service jboss stop' jenkins_commands
> 
> [root at ipa3-yyz-int ~]# ipa sudorule-add-option jenkins_commands --sudooption !authenticate
> -bash: !authenticate: event not found
> 
> [root at ipa3-yyz-int ~]# ipa sudorule-add-option jenkins_commands
> Sudo Option: !requiretty
> ipa: ERROR: no such entry
> 
> What is the proper way of handling SUDO options with ipa?

Bash is interpreting the bang, put single quotes around the options and
it should work.

rob



From chymian at gmx.net  Tue Dec  9 22:52:08 2014
From: chymian at gmx.net (chymian)
Date: Tue, 09 Dec 2014 23:52:08 +0100
Subject: [Freeipa-users]
	=?utf-8?q?Unit_pki-tomcatd=40pki-tomcat=2Eservice?=
	=?utf-8?q?_entered_failed_state_=40_vanilla_install_on_jessie_?=
	=?utf-8?q?=E2=80=93_with_log_attached?=
In-Reply-To: <1418136544.27499.17.camel@aleeredhat.laptop>
References: <6538670.riIOSljqhg@hansa>
	<1418136544.27499.17.camel@aleeredhat.laptop>
Message-ID: <10374562.nWQdItF8xj@hansa>

Am Dienstag, 9. Dezember 2014, 09:49:04 schrieb Ade Lee:
> On Tue, 2014-12-09 at 13:54 +0100, chymian wrote:
> > hey people,
> > 
> > after a successful install of ipa 4.0.5-2 on jessie, the named services started flawless during setup. see attached log, Installation summary (line 3107)
> > but after reboot, it refuses to start. (did this install a couple times, on vanilla jessie)
> > 
> > I can reach & work with Dogtag https://ipa.eb8.lan:8443/ca, but not the admin-services on https://ipa.eb8.lan/ca/ee/ca and https://ipa.eb8.lan/ca/agent/ca.
> > 
> > 
> > $ systemctl status pki-tomcatd at pki-tomcat.service
> > ? pki-tomcatd at pki-tomcat.service - PKI Tomcat Server pki-tomcat
> >    Loaded: loaded (/lib/systemd/system/pki-tomcatd at .service; enabled)
> >    Active: failed (Result: resources)
> > 
> > Dez 08 20:40:13 ipa systemd[1]: Starting PKI Tomcat Server pki-tomcat...
> > Dez 08 20:40:13 ipa systemd[1]: Failed to load environment files: No such file or directory
> > Dez 08 20:40:13 ipa systemd[1]: pki-tomcatd at pki-tomcat.service failed to run 'start-pre' task: No such file or directory
> > Dez 08 20:40:13 ipa systemd[1]: Failed to start PKI Tomcat Server pki-tomcat.
> > Dez 08 20:40:13 ipa systemd[1]: Unit pki-tomcatd at pki-tomcat.service entered failed state.
> > 
> > 
> 
> Is dogtag actually running?  ps -ef |grep java

it shows:
pkiuser    676     1  0 13:25 ?        00:00:26 /usr/lib/jvm/default-java/bin/java -Djava.util.logging.config.file=/var/lib/pki/pki-tomcat/conf/logging.properties -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -DRESTEASY_LIB=/usr/share/java/ -Djava.endorsed.dirs=/usr/share/tomcat7/endorsed -classpath /usr/share/tomcat7/bin/bootstrap.jar:/var/lib/pki/pki-tomcat/bin/tomcat-juli.jar -Dcatalina.base=/var/lib/pki/pki-tomcat -Dcatalina.home=/usr/share/tomcat7 -Djava.io.tmpdir=/var/lib/pki/pki-tomcat/temp org.apache.catalina.startup.Bootstrap start

is it ment to be, that the dogtag-pki package it?s self is not installed, just the dogtag-pki-server-theme is
and a couple pki-packages? pki-base, pki-ca, pki-server, pki-tools?


> 
> You could try restarting it - 
> systemctl restart pki-tomcatd at pki-tomcat.service

fails with same log-msg.

> 
> The logs should be found in the journal --> 
> journalctl -u pki-tomcatd at pki-tomcat.service

same as above.

> 
> Other debug logs should be found under /var/log/pki/pki-tomcat/.  Please
> provide a tar of that directory.

attached

> I am curious what the unit file looks like:  On Fedora, its
> at /etc/systemd/system/pki-tomcatd.target.wants/pki-tomcatd at pki-tomcat.service

lrwxrwxrwx 1 pkiuser pkiuser 40 Dez  8 20:22 pki-tomcatd at pki-tomcat.service -> /lib/systemd/system/pki-tomcatd at .service
root at ipa /etc/systemd/system/pki-tomcatd.target.wants
$ cat pki-tomcatd at pki-tomcat.service
[Unit]
Description=PKI Tomcat Server %i
After=pki-tomcatd.target network.target
PartOf=pki-tomcatd.target

[Service]
Type=simple
EnvironmentFile=/etc/tomcat/tomcat.conf
Environment="NAME=%i"
EnvironmentFile=-/etc/default/%i
ExecStartPre=/usr/bin/pkidaemon start %i
ExecStart=/usr/libexec/tomcat/server start
ExecStop=/usr/libexec/tomcat/server stop
SuccessExitStatus=143
User=pkiuser
Group=pkiuser

[Install]
WantedBy=multi-user.target


> which points to an EnvironmentFile /etc/tomcat/tomcat.conf.  Does that
> file exist?

there is not even an dir. /etc/tomcat/, or rather a tomcat.conf in it.

this is what was installed:

ii  libtomcat7-java                          7.0.56-1
ii  libtomcatjss-java                        7.1.1-2
ii  tomcat7-common                           7.0.56-1
ii  tomcat7-user                             7.0.56-1

and if I would install tomcat7, it would give me an /etc/tomcat7 ? not a /etc/tomcat

and, here on debian, there is no such dir. /usr/libexec.
seems that the unitfile is more a centos one.


but: 

systemctl status pki-tomcatd.service
? pki-tomcatd.service - LSB: Start pki-tomcatd at boot time
   Loaded: loaded (/etc/init.d/pki-tomcatd)
   Active: active (running) since Di 2014-12-09 13:25:12 CET; 10h ago
   CGroup: /user.slice/user-0.slice/session-5.scope/system.slice/pki-tomcatd.service
           ??676 /usr/lib/jvm/default-java/bin/java -Djava.util.logging.config.file=/var/lib/pki/pki-tomcat/conf/logging.properties -Djava.util.log...

Dez 09 13:25:12 ipa pki-tomcatd[484]: .
Dez 09 13:25:12 ipa systemd[1]: Started LSB: Start pki-tomcatd at boot time.


which is started with a /etc/init.d/pki-tomcatd script, not systemd-unit-file ? yet.

> 
> Ade

thx,
guenter

> 
> > a second service fails to start:
> > 
> > $ systemctl status dirsrv-snmp.service
> > ? dirsrv-snmp.service - 389 Directory Server SNMP Subagent.
> >    Loaded: loaded (/lib/systemd/system/dirsrv-snmp.service; enabled)
> >    Active: failed (Result: exit-code) since Di 2014-12-09 13:25:04 CET; 5min ago
> >   Process: 156 ExecStart=/usr/sbin/ldap-agent /etc/dirsrv/config/ldap-agent.conf (code=exited, status=1/FAILURE)
> > 
> > Dez 09 13:25:04 ipa systemd[1]: Starting 389 Directory Server SNMP Subagent....
> > Dez 09 13:25:04 ipa ldap-agent[156]: ldap-agent: No server instances defined in config file
> > Dez 09 13:25:04 ipa systemd[1]: dirsrv-snmp.service: control process exited, code=exited status=1
> > Dez 09 13:25:04 ipa systemd[1]: Failed to start 389 Directory Server SNMP Subagent..
> > Dez 09 13:25:04 ipa systemd[1]: Unit dirsrv-snmp.service entered failed state.
> > 
> > 
> > except these, I was able to subscribe a jessie-client with autodiscovery right after I did configure the ipa-server, before first reboot.
> > 
> > 
> > any help appreciated, since I do not have much experience with IPA ? yet.
> > guenter
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141209/7fc3f90a/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pki-tomcat-fail-on-jessie.tar.xz
Type: application/x-xz-compressed-tar
Size: 76476 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141209/7fc3f90a/attachment.bin>

From chymian at gmx.net  Tue Dec  9 22:52:11 2014
From: chymian at gmx.net (chymian)
Date: Tue, 09 Dec 2014 23:52:11 +0100
Subject: [Freeipa-users]
	=?utf-8?q?Unit_pki-tomcatd=40pki-tomcat=2Eservice?=
	=?utf-8?q?_entered_failed_state_=40_vanilla_install_on_jessie_?=
	=?utf-8?q?=E2=80=93_with_log_attached?=
In-Reply-To: <5486F4D8.6040700@redhat.com>
References: <6538670.riIOSljqhg@hansa> <5486F4D8.6040700@redhat.com>
Message-ID: <3498884.j87NNgj6SR@hansa>

> Am Dienstag, 9. Dezember 2014, 14:10:48 schrieb thierry bordaz:
> 
> On 12/09/2014 01:54 PM, chymian wrote:
> > hey people,
> > 
> > after a successful install of ipa 4.0.5-2 on jessie, the named services
> > started flawless during setup. see attached log, Installation summary
> > (line
> > 3107) but after reboot, it refuses to start. (did this install a couple
> > times, on vanilla jessie)
> > 
> > I can reach & work with Dogtag https://ipa.eb8.lan:8443/ca, but not the
> > admin-services on https://ipa.eb8.lan/ca/ee/ca and
> > https://ipa.eb8.lan/ca/agent/ca.
> > 
> > 
> > $ systemctl status pki-tomcatd at pki-tomcat.service
> > ? pki-tomcatd at pki-tomcat.service - PKI Tomcat Server pki-tomcat
> > 
> >    Loaded: loaded (/lib/systemd/system/pki-tomcatd at .service; enabled)
> >    Active: failed (Result: resources)
> > 
> > Dez 08 20:40:13 ipa systemd[1]: Starting PKI Tomcat Server pki-tomcat...
> > Dez 08 20:40:13 ipa systemd[1]: Failed to load environment files: No such
> > file or directory Dez 08 20:40:13 ipa systemd[1]:
> > pki-tomcatd at pki-tomcat.service failed to run 'start-pre' task: No such
> > file
> > or directory Dez 08 20:40:13 ipa systemd[1]: Failed to start PKI Tomcat
> > Server pki-tomcat. Dez 08 20:40:13 ipa systemd[1]: Unit
> > pki-tomcatd at pki-tomcat.service entered failed state.
> > 
> > 
> > a second service fails to start:
> > 
> > $ systemctl status dirsrv-snmp.service
> > ? dirsrv-snmp.service - 389 Directory Server SNMP Subagent.
> > 
> >    Loaded: loaded (/lib/systemd/system/dirsrv-snmp.service; enabled)
> >    Active: failed (Result: exit-code) since Di 2014-12-09 13:25:04 CET;
> >    5min
> >    ago
> >   
> >   Process: 156 ExecStart=/usr/sbin/ldap-agent
> >   /etc/dirsrv/config/ldap-agent.conf (code=exited, status=1/FAILURE)>
> > 
> > Dez 09 13:25:04 ipa systemd[1]: Starting 389 Directory Server SNMP
> > Subagent.... Dez 09 13:25:04 ipa ldap-agent[156]: ldap-agent: No server
> > instances defined in config file Dez 09 13:25:04 ipa systemd[1]:
> > dirsrv-snmp.service: control process exited, code=exited status=1 Dez 09
> > 13:25:04 ipa systemd[1]: Failed to start 389 Directory Server SNMP
> > Subagent.. Dez 09 13:25:04 ipa systemd[1]: Unit dirsrv-snmp.service
> > entered
> > failed state.
> 
> Hello,
> 
> regarding this issue. Is there a agent log file under /var/log/dirsrv/agent/
> ?
> 
> thanks
> thierry
> 

thierry,
no there aren?t any files, except the slapd-EB8-LAN/ directory in /var/log/dirsrv/
not even an  /var/log/dirsrv/agent/

anything else I can provide?
 
thanks,
guenter

> 
> > except these, I was able to subscribe a jessie-client with autodiscovery
> > right after I did configure the ipa-server, before first reboot.
> > 
> > 
> > any help appreciated, since I do not have much experience with IPA ? yet.
> > guenter



From tlau at tetrioncapital.com  Wed Dec 10 01:43:46 2014
From: tlau at tetrioncapital.com (Thomas Lau)
Date: Wed, 10 Dec 2014 09:43:46 +0800
Subject: [Freeipa-users] Change default password expiry date
Message-ID: <CAEZt6eCtbiaFSPXe-Zg1tWVM7JuRxBngLeK4g=2=0GZ4QLrnZw@mail.gmail.com>

Hi All,

FreeIPA Default is using 60days password expiry, how could I change it?

Also, for existing accounts, can I just change krbPasswordExpiration
on LDAP? anywhere else I need to change? do I need to generate keytab
on Kerberos to activate new expiry date?



From dpal at redhat.com  Wed Dec 10 02:36:28 2014
From: dpal at redhat.com (Dmitri Pal)
Date: Tue, 09 Dec 2014 21:36:28 -0500
Subject: [Freeipa-users] Change default password expiry date
In-Reply-To: <CAEZt6eCtbiaFSPXe-Zg1tWVM7JuRxBngLeK4g=2=0GZ4QLrnZw@mail.gmail.com>
References: <CAEZt6eCtbiaFSPXe-Zg1tWVM7JuRxBngLeK4g=2=0GZ4QLrnZw@mail.gmail.com>
Message-ID: <5487B1AC.1030002@redhat.com>

On 12/09/2014 08:43 PM, Thomas Lau wrote:
> Hi All,
>
> FreeIPA Default is using 60days password expiry, how could I change it?

You go to password policies and change the global password policy.
You change MAX lifetime.
This is a global setting it will apply to new passwords/keytabs when 
they are changed next time.
You can create other policies and apply them to groups it you need.

>
> Also, for existing accounts, can I just change krbPasswordExpiration
> on LDAP?

I think the answer is yes.

> anywhere else I need to change?

I think the answer is no

> do I need to generate keytab
> on Kerberos to activate new expiry date?
>
If you change the expiration in the attribute then no.

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.



From tlau at tetrioncapital.com  Wed Dec 10 02:45:20 2014
From: tlau at tetrioncapital.com (Thomas Lau)
Date: Wed, 10 Dec 2014 10:45:20 +0800
Subject: [Freeipa-users] change directory manager password
Message-ID: <CAEZt6eBC1-V6+iJ2FX9BAt+foJBg_nS+ycFd_C_1CCpLouE=-w@mail.gmail.com>

Hi All,

Does anyone know to change directory manager password?



From tlau at tetrioncapital.com  Wed Dec 10 02:46:33 2014
From: tlau at tetrioncapital.com (Thomas Lau)
Date: Wed, 10 Dec 2014 10:46:33 +0800
Subject: [Freeipa-users] change directory manager password
In-Reply-To: <CAEZt6eBC1-V6+iJ2FX9BAt+foJBg_nS+ycFd_C_1CCpLouE=-w@mail.gmail.com>
References: <CAEZt6eBC1-V6+iJ2FX9BAt+foJBg_nS+ycFd_C_1CCpLouE=-w@mail.gmail.com>
Message-ID: <CAEZt6eCezuP=3i+bTbfziRmHWArttrE+uJtmKmdqk7i6fF+CcA@mail.gmail.com>

By the way, if I change Directory manager password, do I need to do
anything else for replication cluster?

On Wed, Dec 10, 2014 at 10:45 AM, Thomas Lau <tlau at tetrioncapital.com> wrote:
> Hi All,
>
> Does anyone know to change directory manager password?



-- 
Thomas Lau
Director of Infrastructure
Tetrion Capital Limited

Direct: +852-3976-8903
Mobile: +852-9323-9670
Address: 20/F, IFC 1, Central district, Hong Kong



From rmeggins at redhat.com  Wed Dec 10 03:33:32 2014
From: rmeggins at redhat.com (Rich Megginson)
Date: Tue, 09 Dec 2014 20:33:32 -0700
Subject: [Freeipa-users] change directory manager password
In-Reply-To: <CAEZt6eCezuP=3i+bTbfziRmHWArttrE+uJtmKmdqk7i6fF+CcA@mail.gmail.com>
References: <CAEZt6eBC1-V6+iJ2FX9BAt+foJBg_nS+ycFd_C_1CCpLouE=-w@mail.gmail.com>
	<CAEZt6eCezuP=3i+bTbfziRmHWArttrE+uJtmKmdqk7i6fF+CcA@mail.gmail.com>
Message-ID: <5487BF0C.4030306@redhat.com>

On 12/09/2014 07:46 PM, Thomas Lau wrote:
> By the way, if I change Directory manager password, do I need to do
> anything else for replication cluster?

http://www.port389.org/docs/389ds/howto/howto-resetdirmgrpassword.html

Unless you are using directory manager for replication (please tell me 
you are not), you shouldn't have to do anything.

>
> On Wed, Dec 10, 2014 at 10:45 AM, Thomas Lau <tlau at tetrioncapital.com> wrote:
>> Hi All,
>>
>> Does anyone know to change directory manager password?
>
>



From guenter at amrah.net  Tue Dec  9 23:17:13 2014
From: guenter at amrah.net (=?ISO-8859-1?Q?g=FCnter?=)
Date: Wed, 10 Dec 2014 00:17:13 +0100
Subject: [Freeipa-users]
	=?utf-8?q?Unit_pki-tomcatd=40pki-tomcat=2Eservice?=
	=?utf-8?q?_entered_failed_state_=40_vanilla_install_on_jessie_?=
	=?utf-8?q?=E2=80=93_with_log_attached?=
In-Reply-To: <5487069B.50704@redhat.com>
References: <6538670.riIOSljqhg@hansa> <5486F4D8.6040700@redhat.com>
	<5487069B.50704@redhat.com>
Message-ID: <1583128.0xJ38rxGeR@hansa>

> Am Dienstag, 9. Dezember 2014, 07:26:35 schrieb Rich Megginson:
> 
> > On 12/09/2014 06:10 AM, thierry bordaz wrote:
> > 
> > > On 12/09/2014 01:54 PM, chymian wrote:
> > > hey people,
> > > 
> > > after a successful install of ipa 4.0.5-2 on jessie, the named services
> > > started flawless during setup. see attached log, Installation summary
> > > (line
> > > 3107) but after reboot, it refuses to start. (did this install a couple
> > > times, on vanilla jessie)
> > > 
> > > I can reach & work with Dogtag https://ipa.eb8.lan:8443/ca, but not the
> > > admin-services on https://ipa.eb8.lan/ca/ee/ca and
> > > https://ipa.eb8.lan/ca/agent/ca.
> > > 
> > > 
> > > $ systemctl status pki-tomcatd at pki-tomcat.service
> > > ? pki-tomcatd at pki-tomcat.service - PKI Tomcat Server pki-tomcat
> > > 
> > >    Loaded: loaded (/lib/systemd/system/pki-tomcatd at .service; enabled)
> > >    Active: failed (Result: resources)
> > > 
> > > Dez 08 20:40:13 ipa systemd[1]: Starting PKI Tomcat Server pki-tomcat...
> > > Dez 08 20:40:13 ipa systemd[1]: Failed to load environment files: No
> > > such
> > > file or directory Dez 08 20:40:13 ipa systemd[1]:
> > > pki-tomcatd at pki-tomcat.service failed to run 'start-pre' task: No such
> > > file
> > > or directory Dez 08 20:40:13 ipa systemd[1]: Failed to start PKI Tomcat
> > > Server pki-tomcat. Dez 08 20:40:13 ipa systemd[1]: Unit
> > > pki-tomcatd at pki-tomcat.service entered failed state.
> > > 
> > > 
> > > a second service fails to start:
> > > 
> > > $ systemctl status dirsrv-snmp.service
> > > ? dirsrv-snmp.service - 389 Directory Server SNMP Subagent.
> > > 
> > >    Loaded: loaded (/lib/systemd/system/dirsrv-snmp.service; enabled)
> > >    Active: failed (Result: exit-code) since Di 2014-12-09 13:25:04 CET;
> > >    5min
> > >    ago
> > >   
> > >   Process: 156 ExecStart=/usr/sbin/ldap-agent
> > >   /etc/dirsrv/config/ldap-agent.conf (code=exited, status=1/FAILURE)>
> > > 
> > > Dez 09 13:25:04 ipa systemd[1]: Starting 389 Directory Server SNMP
> > > Subagent.... Dez 09 13:25:04 ipa ldap-agent[156]: ldap-agent: No server
> > > instances defined in config file Dez 09 13:25:04 ipa systemd[1]:
> > > dirsrv-snmp.service: control process exited, code=exited status=1 Dez 09
> > > 13:25:04 ipa systemd[1]: Failed to start 389 Directory Server SNMP
> > > Subagent.. Dez 09 13:25:04 ipa systemd[1]: Unit dirsrv-snmp.service
> > > entered failed state.
> >
> >
> > Hello,
> > 
> > regarding this issue. Is there a agent log file under
> > /var/log/dirsrv/agent/
> > ?
> > 
> Are you actually trying to use SNMP?  If not, then just ignore this
> service
> failure.

rich, 
I thought the same way, since I?m not using SNMP. 
but I?m **very** happy and thankful for all the work, people have done, that ipa-server made it to debian ? finally \o/ 
so I do, what I can to help iron out the last folds? ? which in my case ?only? is: testing, reporting & testing solutions?

cheers
guenter

> > 
> > 
> > 
> > thanks
> > thierry
> > 
> > > except these, I was able to subscribe a jessie-client with autodiscovery
> > > right after I did configure the ipa-server, before first reboot.
> > > 
> > > 
> > > any help appreciated, since I do not have much experience with IPA ?
> > > yet.
> > > guenter



From simo at redhat.com  Wed Dec 10 04:03:29 2014
From: simo at redhat.com (Simo Sorce)
Date: Tue, 9 Dec 2014 23:03:29 -0500
Subject: [Freeipa-users] change directory manager password
In-Reply-To: <5487BF0C.4030306@redhat.com>
References: <CAEZt6eBC1-V6+iJ2FX9BAt+foJBg_nS+ycFd_C_1CCpLouE=-w@mail.gmail.com>
	<CAEZt6eCezuP=3i+bTbfziRmHWArttrE+uJtmKmdqk7i6fF+CcA@mail.gmail.com>
	<5487BF0C.4030306@redhat.com>
Message-ID: <20141209230329.7bc28828@willson.usersys.redhat.com>

On Tue, 09 Dec 2014 20:33:32 -0700
Rich Megginson <rmeggins at redhat.com> wrote:

> On 12/09/2014 07:46 PM, Thomas Lau wrote:
> > By the way, if I change Directory manager password, do I need to do
> > anything else for replication cluster?
> 
> http://www.port389.org/docs/389ds/howto/howto-resetdirmgrpassword.html
> 
> Unless you are using directory manager for replication (please tell
> me you are not), you shouldn't have to do anything.

Given this is freeipa-users I assume ipa-replica-install/manage
converted his replication agreements to use GSSAPI :-)

So, no, in FreeIPA replication doesn't care about the DM password.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York



From Less at imagine-sw.com  Wed Dec 10 07:22:08 2014
From: Less at imagine-sw.com (Les Stott)
Date: Wed, 10 Dec 2014 07:22:08 +0000
Subject: [Freeipa-users] CA Replication Installation Failing
In-Reply-To: <1418148291.27499.20.camel@aleeredhat.laptop>
References: <4ED173A868981548967B4FCA270722262803F3C5@AACMBXP04.exchserver.com>
	<4ED173A868981548967B4FCA2707222628048DF6@AACMBXP04.exchserver.com>	,
	<54867F51.1030603@redhat.com>
	<4ED173A868981548967B4FCA2707222628049113@AACMBXP04.exchserver.com>
	<1418148291.27499.20.camel@aleeredhat.laptop>
Message-ID: <4ED173A868981548967B4FCA270722262804A449@AACMBXP04.exchserver.com>



> -----Original Message-----
> From: Ade Lee [mailto:alee at redhat.com]
> Sent: Wednesday, 10 December 2014 5:05 AM
> To: Les Stott
> Cc: freeipa-users at redhat.com
> Subject: Re: [Freeipa-users] CA Replication Installation Failing
> 
> On Tue, 2014-12-09 at 07:48 +0000, Les Stott wrote:
> >
> >
> >
> __________________________________________________________
> ____________
> > From: freeipa-users-bounces at redhat.com
> > [freeipa-users-bounces at redhat.com] on behalf of Dmitri Pal
> > [dpal at redhat.com]
> > Sent: Tuesday, December 09, 2014 3:49 PM
> > To: freeipa-users at redhat.com
> > Subject: Re: [Freeipa-users] CA Replication Installation Failing
> >
> >
> >
> > On 12/08/2014 11:04 PM, Les Stott wrote:
> >
> > > Does anyone have any ideas on the below errors when trying to add CA
> > > replication to an existing replica?
> > >
> > >
> >
> > > People who might be able to help are or PTO right now.
> > >
> > > Is your installation older than 2 years?
> >
> > No, December 2013 was when it was originally built.
> >
> > > Did you generate a new replica package or use the original one?
> >
> > I used the original replica file for serverb, based on instructions i
> > came across. I can try regenerating the replica file.
> >
> > Interestingly, now that you mention it, servera had to be restored a
> > couple of months back. Perhaps this is an issue and regenerating the
> > replica file for serverb will be required.
> >
> > I will try this.
> >
> 
> I think that this is a safe bet to be the problem.
> 
> The error in the log snippet you posted says:
> 
>  <errorString>The pkcs12 file is not correct.</errorString>
> 
> This indicates that the clone CA was unable to decode the pkcs12 file in the
> replica.  Perhaps the certs changed -- or the DM password changed?
> 
> Ade

I regenerated the replica file and retired the CA replica setup, but it failed at the same point with the same error.

I am thinking that the next step is to uninstall the ipa replica to cleanup, remove all traces and re-add as a replica on serverb.

I wonder if the cert that its having an issue with is the one on serverB under /etc/ipa/ca.crt which is from Dec 2013.

I will try that in a couple of days as I have to schedule this work in as its in production.

Regards,

Les


> > > May be the problem is that the cert that is in that package already
> > expired?
> >
> > original replica file was created on Dec 16 2013. Cert is not set to
> > expire until 2015-12-17.
> >
> > > Just a thought...
> > >
> > > The simplest workaround IMO would be to prepare Server C, install it
> > with CA and then decommission replica B.
> > > Do not forget to clean replication agreements on master.
> > >
> > > But that would be work around, would not solve this specific
> > problem, it will kill it.
> >
> > I actually do have serverc and serverd. I planned to have CA
> > replication on at least 2 other servers, but held off on trying on
> > serverc due to issues with serverb.
> >
> > I'll report back what i find after regenerating the replica file and
> > re-trying to setup CA replication.
> >
> > Thanks,
> >
> > Les
> >
> > >
> > >
> > > Thanks in advance,
> > >
> > >
> > >
> > > Les
> > >
> > >
> > >
> > > From:freeipa-users-bounces at redhat.com
> > > [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Les Stott
> > > Sent: Tuesday, 2 December 2014 6:17 PM
> > > To: freeipa-users at redhat.com
> > > Subject: [Freeipa-users] CA Replication Installation Failing
> > >
> > >
> > >
> > >
> > > Hi All,
> > >
> > >
> > >
> > > I have RHEL6 with ipa servers running standard ipa server 3.0.0-42.
> > > Pki components are also standard version 9.0.3-38.
> > >
> > >
> > >
> > > Servera is the master
> > >
> > > Serverb is the replica
> > >
> > >
> > >
> > > Both have been running for many, many months. Serverb was initially
> > > setup as a replica, but not a CA replica.
> > >
> > >
> > >
> > > I am now trying to add CA Replication to serverb but it is failing
> > > midway through and I cannot figure out why.
> > >
> > >
> > >
> > > Annoyingly, I used the same method/command to setup a CA replica on
> > > test servers and it completed without issue.
> > >
> > >
> > >
> > > Here is what I get?.(for the sake of brevity, I am excluding the
> > > lines for connection check which were all OK)
> > >
> > >
> > >
> > > =================
> > >
> > > /usr/sbin/ipa-ca-install
> > > /var/lib/ipa/replica-info-serverb.mydomain.com.gpg
> > >
> > > Directory Manager (existing master) password:
> > >
> > > Get credentials to log in to remote master
> > >
> > > admin at MYDOMAIN.COM password:
> > >
> > > Execute check on remote master
> > >
> > > Connection check OK
> > >
> > > Configuring directory server for the CA (pkids): Estimated time 30
> > > seconds
> > >
> > >   [1/3]: creating directory server user
> > >
> > >   [2/3]: creating directory server instance
> > >
> > >   [3/3]: restarting directory server
> > >
> > > Done configuring directory server for the CA (pkids).
> > >
> > > Configuring certificate server (pki-cad): Estimated time 3 minutes
> > > 30 seconds
> > >
> > >   [1/16]: creating certificate server user
> > >
> > >   [2/16]: creating pki-ca instance
> > >
> > >   [3/16]: configuring certificate server instance
> > >
> > > ipa         : CRITICAL failed to configure ca instance Command
> > > '/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname
> > > serverb.mydomain.com -cs_port 9445 -client_certdb_dir
> > > /tmp/tmp-t3aHM7 -client_certdb_pwd XXXXXXXX -preop_pin
> > > exoyO2y7bawG5yjZMACM -domain_name IPA -admin_user admin -
> admin_email
> > > root at localhost -admin_password XXXXXXXX -agent_name ipa-ca-agent
> > > -agent_key_size 2048 -agent_key_type rsa -agent_cert_subject
> > > CN=ipa-ca-agent,O=MYDOMAIN.COM -ldap_host
> serverb.mydomain.com
> > > -ldap_port 7389 -bind_dn cn=Directory Manager -bind_password
> > > XXXXXXXX -base_dn o=ipaca -db_name ipaca -key_size
> > > 2048 -key_type rsa -key_algorithm SHA256withRSA -save_p12 true
> > > -backup_pwd XXXXXXXX -subsystem_name pki-cad -token_name
> internal
> > > -ca_subsystem_cert_subject_name CN=CA
> Subsystem,O=MYDOMAIN.COM
> > > -ca_subsystem_cert_subject_name CN=CA
> Subsystem,O=MYDOMAIN.COM
> > > -ca_ocsp_cert_subject_name CN=OCSP Subsystem,O=MYDOMAIN.COM
> > > -ca_server_cert_subject_name
> CN=serverb.mydomain.com,O=MYDOMAIN.COM
> > > -ca_audit_signing_cert_subject_name CN=CA
> Audit,O=MYDOMAIN.COM
> > > -ca_sign_cert_subject_name CN=Certificate
> Authority,O=MYDOMAIN.COM
> > > -external false -clone true -clone_p12_file ca.p12
> > > -clone_p12_password XXXXXXXX -sd_hostname servera.mydomain.com
> > > -sd_admin_port 443 -sd_admin_name admin -sd_admin_password
> XXXXXXXX
> > > -clone_start_tls true -clone_uri https://servera.mydomain.com:443'
> > > returned non-zero exit status 255
> > >
> > >
> > >
> > > Your system may be partly configured.
> > >
> > > Run /usr/sbin/ipa-server-install --uninstall to clean up.
> > >
> > >
> > >
> > > Configuration of CA failed
> > >
> > > =================
> > >
> > >
> > >
> > > Additional excerpt from the log
> > > file /var/log/ipareplica-ca-install.log at the point of failure?.
> > >
> > >
> > >
> > > =================
> > >
> > >
> > >
> > > #############################################
> > >
> > > Attempting to connect to: serverb.mydomain.com:9445
> > >
> > > Connected.
> > >
> > > Posting Query =
> > >
> https://serverb.mydomain.com:9445//ca/admin/console/config/wizard?p=
> > > 7&op=next&xml=true&__password=XXXXXXXX&path=ca.p12
> > >
> > > RESPONSE STATUS:  HTTP/1.1 200 OK
> > >
> > > RESPONSE HEADER:  Server: Apache-Coyote/1.1
> > >
> > > RESPONSE HEADER:  Content-Type: application/xml;charset=UTF-8
> > >
> > > RESPONSE HEADER:  Date: Tue, 02 Dec 2014 05:44:19 GMT
> > >
> > > RESPONSE HEADER:  Connection: close
> > >
> > > <?xml version="1.0" encoding="UTF-8"?>
> > >
> > > <!-- BEGIN COPYRIGHT BLOCK
> > >
> > >      This program is free software; you can redistribute it and/or
> > > modify
> > >
> > >      it under the terms of the GNU General Public License as
> > > published by
> > >
> > >      the Free Software Foundation; version 2 of the License.
> > >
> > >
> > >
> > >      This program is distributed in the hope that it will be useful,
> > >
> > >      but WITHOUT ANY WARRANTY; without even the implied warranty of
> > >
> > >      MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> > >
> > >      GNU General Public License for more details.
> > >
> > >
> > >
> > >      You should have received a copy of the GNU General Public
> > > License along
> > >
> > >      with this program; if not, write to the Free Software
> > > Foundation, Inc.,
> > >
> > >      51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
> > >
> > >
> > >
> > >      Copyright (C) 2007 Red Hat, Inc.
> > >
> > >      All rights reserved.
> > >
> > >      END COPYRIGHT BLOCK -->
> > >
> > > <response>
> > >
> > >   <panel>admin/console/config/restorekeycertpanel.vm</panel>
> > >
> > >   <res/>
> > >
> > >   <updateStatus>failure</updateStatus>
> > >
> > >   <password/>
> > >
> > >   <errorString>The pkcs12 file is not correct.</errorString>
> > >
> > >   <size>19</size>
> > >
> > >   <title>Import Keys and Certificates</title>
> > >
> > >   <panels>
> > >
> > >     <Vector>
> > >
> > >       <Panel>
> > >
> > >         <Id>welcome</Id>
> > >
> > >         <Name>Welcome</Name>
> > >
> > >       </Panel>
> > >
> > >       <Panel>
> > >
> > >         <Id>module</Id>
> > >
> > >         <Name>Key Store</Name>
> > >
> > >       </Panel>
> > >
> > >       <Panel>
> > >
> > >         <Id>confighsmlogin</Id>
> > >
> > >         <Name>ConfigHSMLogin</Name>
> > >
> > >       </Panel>
> > >
> > >       <Panel>
> > >
> > >         <Id>securitydomain</Id>
> > >
> > >         <Name>Security Domain</Name>
> > >
> > >       </Panel>
> > >
> > >       <Panel>
> > >
> > >         <Id>securitydomain</Id>
> > >
> > >         <Name>Display Certificate Chain</Name>
> > >
> > >       </Panel>
> > >
> > >       <Panel>
> > >
> > >         <Id>subsystem</Id>
> > >
> > >         <Name>Subsystem Type</Name>
> > >
> > >       </Panel>
> > >
> > >       <Panel>
> > >
> > >         <Id>clone</Id>
> > >
> > >         <Name>Display Certificate Chain</Name>
> > >
> > >       </Panel>
> > >
> > >       <Panel>
> > >
> > >         <Id>restorekeys</Id>
> > >
> > >         <Name>Import Keys and Certificates</Name>
> > >
> > >       </Panel>
> > >
> > >       <Panel>
> > >
> > >         <Id>cahierarchy</Id>
> > >
> > >         <Name>PKI Hierarchy</Name>
> > >
> > >       </Panel>
> > >
> > >       <Panel>
> > >
> > >         <Id>database</Id>
> > >
> > >         <Name>Internal Database</Name>
> > >
> > >       </Panel>
> > >
> > >       <Panel>
> > >
> > >         <Id>size</Id>
> > >
> > >         <Name>Key Pairs</Name>
> > >
> > >       </Panel>
> > >
> > >       <Panel>
> > >
> > >         <Id>subjectname</Id>
> > >
> > >         <Name>Subject Names</Name>
> > >
> > >       </Panel>
> > >
> > >       <Panel>
> > >
> > >         <Id>certrequest</Id>
> > >
> > >         <Name>Requests and Certificates</Name>
> > >
> > >       </Panel>
> > >
> > >       <Panel>
> > >
> > >         <Id>backupkeys</Id>
> > >
> > >         <Name>Export Keys and Certificates</Name>
> > >
> > >       </Panel>
> > >
> > >       <Panel>
> > >
> > >         <Id>savepk12</Id>
> > >
> > >         <Name>Save Keys and Certificates</Name>
> > >
> > >       </Panel>
> > >
> > >       <Panel>
> > >
> > >         <Id>importcachain</Id>
> > >
> > >         <Name>Import CA's Certificate Chain</Name>
> > >
> > >       </Panel>
> > >
> > >       <Panel>
> > >
> > >         <Id>admin</Id>
> > >
> > >         <Name>Administrator</Name>
> > >
> > >       </Panel>
> > >
> > >       <Panel>
> > >
> > >         <Id>importadmincert</Id>
> > >
> > >         <Name>Import Administrator's Certificate</Name>
> > >
> > >       </Panel>
> > >
> > >       <Panel>
> > >
> > >         <Id>done</Id>
> > >
> > >         <Name>Done</Name>
> > >
> > >       </Panel>
> > >
> > >     </Vector>
> > >
> > >   </panels>
> > >
> > >   <name>CA Setup Wizard</name>
> > >
> > >   <p>7</p>
> > >
> > >   <path/>
> > >
> > >   <req/>
> > >
> > >   <panelname>restorekeys</panelname>
> > >
> > > </response>
> > >
> > > Error in RestoreKeyCertPanel(): updateStatus returns failure
> > >
> > > ERROR: ConfigureCA: RestoreKeyCertPanel() failure
> > >
> > > ERROR: unable to create CA
> > >
> > >
> > >
> > >
> ##########################################################
> ##########
> > > ###
> > >
> > > 2014-12-02T05:44:19Z DEBUG stderr=
> > >
> > > 2014-12-02T05:44:19Z CRITICAL failed to configure ca instance
> > > Command '/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname
> > > serverb.mydomain.com -cs_port 9445 -client_certdb_dir
> > > /tmp/tmp-1Tqws5 -client_certdb_pwd XXXXXXXX -preop_pin
> > > rdkE0y2CiGMKNcRRPKKc -domain_name IPA -admin_user admin -
> admin_email
> > > root at localhost -admin_password XXXXXXXX -agent_name ipa-ca-agent
> > > -agent_key_size 2048 -agent_key_type rsa -agent_cert_subject
> > > CN=ipa-ca-agent,O=MYDOMAIN.COM -ldap_host
> serverb.mydomain.com
> > > -ldap_port 7389 -bind_dn cn=Directory Manager -bind_password
> > > XXXXXXXX -base_dn o=ipaca -db_name ipaca -key_size
> > > 2048 -key_type rsa -key_algorithm SHA256withRSA -save_p12 true
> > > -backup_pwd XXXXXXXX -subsystem_name pki-cad -token_name
> internal
> > > -ca_subsystem_cert_subject_name CN=CA
> Subsystem,O=MYDOMAIN.COM
> > > -ca_subsystem_cert_subject_name CN=CA
> Subsystem,O=MYDOMAIN.COM
> > > -ca_ocsp_cert_subject_name CN=OCSP Subsystem,O=MYDOMAIN.COM
> > > -ca_server_cert_subject_name
> CN=serverb.mydomain.com,O=MYDOMAIN.COM
> > > -ca_audit_signing_cert_subject_name CN=CA
> Audit,O=MYDOMAIN.COM
> > > -ca_sign_cert_subject_name CN=Certificate
> Authority,O=MYDOMAIN.COM
> > > -external false -clone true -clone_p12_file ca.p12
> > > -clone_p12_password XXXXXXXX -sd_hostname servera.mydomain.com
> > > -sd_admin_port 443 -sd_admin_name admin -sd_admin_password
> XXXXXXXX
> > > -clone_start_tls true -clone_uri https://servera.mydomain.com:443'
> > > returned non-zero exit status 255
> > >
> > > 2014-12-02T05:44:19Z INFO   File
> > > "/usr/lib/python2.6/site-packages/ipaserver/install/installutils.py"
> > > , line 614, in run_script
> > >
> > >     return_value = main_function()
> > >
> > >
> > >
> > >   File "/usr/sbin/ipa-ca-install", line 149, in main
> > >
> > >     (CA, cs) = cainstance.install_replica_ca(config,
> > > postinstall=True)
> > >
> > >
> > >
> > >   File
> > > "/usr/lib/python2.6/site-packages/ipaserver/install/cainstance.py",
> > > line 1626, in install_replica_ca
> > >
> > >     subject_base=config.subject_base)
> > >
> > >
> > >
> > >   File
> > > "/usr/lib/python2.6/site-packages/ipaserver/install/cainstance.py",
> > > line 626, in configure_instance
> > >
> > >     self.start_creation(runtime=210)
> > >
> > >
> > >
> > >   File
> > > "/usr/lib/python2.6/site-packages/ipaserver/install/service.py",
> > > line 358, in start_creation
> > >
> > >     method()
> > >
> > >
> > >
> > >   File
> > > "/usr/lib/python2.6/site-packages/ipaserver/install/cainstance.py",
> > > line 888, in __configure_instance
> > >
> > >     raise RuntimeError('Configuration of CA failed')
> > >
> > >
> > >
> > > 2014-12-02T05:44:19Z INFO The ipa-ca-install command failed,
> > > exception: RuntimeError: Configuration of CA failed
> > >
> > >
> > >
> > > =================
> > >
> > >
> > >
> > > I am not sure why this is happening.
> > >
> > >
> > >
> > > Certutil shows that the setup isn?t complete on serverb when
> > > comparing against the CA replica in my test servers which were
> > > successful.
> > >
> > >
> > >
> > > # certutil -L -d /var/lib/pki-ca/alias
> > >
> > >
> > >
> > > Certificate Nickname                                         Trust
> > > Attributes
> > >
> > >
> > > SSL,S/MIME,JAR/XPI
> > >
> > >
> > >
> > > Certificate Authority - MYDOMAIN.COM                      CT,c,
> > >
> > > Server-Cert cert-pki-ca
> > > CTu,Cu,Cu
> > >
> > >
> > >
> > > # certutil -K -d /var/lib/pki-ca/alias
> > >
> > > certutil: Checking token "NSS Certificate DB" in slot "NSS User
> > > Private Key and Certificate Services"
> > >
> > > Enter Password or Pin for "NSS Certificate DB":
> > >
> > > < 0> rsa      ef25de4fb656a27e297899509bc3dad582bcd643   NSS
> > > Certificate DB:Server-Cert cert-pki-ca
> > >
> > >
> > >
> > >
> > >
> > > As yet, I have not tried ?/usr/sbin/ipa-server-install ?uninstall?
> > > in an attempt to cleanup as this is a production server and apart
> > > from CA replication, it is running fine. I have tried multiple times
> > > manually removing pki instances and reinstalling but it still won?t
> > > get past the above error.
> > >
> > >
> > >
> > > Can anyone shed any light on this?
> > >
> > >
> > >
> > > Thanks in advance,
> > >
> > >
> > >
> > > Les
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
> >
> > --
> > Thank you,
> > Dmitri Pal
> >
> > Sr. Engineering Manager IdM portfolio
> > Red Hat, Inc.
> 




From tlau at tetrioncapital.com  Wed Dec 10 07:46:11 2014
From: tlau at tetrioncapital.com (Thomas Lau)
Date: Wed, 10 Dec 2014 15:46:11 +0800
Subject: [Freeipa-users] change directory manager password
In-Reply-To: <20141209230329.7bc28828@willson.usersys.redhat.com>
References: <CAEZt6eBC1-V6+iJ2FX9BAt+foJBg_nS+ycFd_C_1CCpLouE=-w@mail.gmail.com>
	<CAEZt6eCezuP=3i+bTbfziRmHWArttrE+uJtmKmdqk7i6fF+CcA@mail.gmail.com>
	<5487BF0C.4030306@redhat.com>
	<20141209230329.7bc28828@willson.usersys.redhat.com>
Message-ID: <CAEZt6eB5Lht6-NDSvr2H0_-cbfb2Xadbfe2qU-EH8e5w_Wm28g@mail.gmail.com>

Hi All,

So I am using FreeIPA 3.3.3, when I change password on one IPA host,
the other clusters will in sync with the change or I need to do it one
by one manually?

On Wed, Dec 10, 2014 at 12:03 PM, Simo Sorce <simo at redhat.com> wrote:
> On Tue, 09 Dec 2014 20:33:32 -0700
> Rich Megginson <rmeggins at redhat.com> wrote:
>
>> On 12/09/2014 07:46 PM, Thomas Lau wrote:
>> > By the way, if I change Directory manager password, do I need to do
>> > anything else for replication cluster?
>>
>> http://www.port389.org/docs/389ds/howto/howto-resetdirmgrpassword.html
>>
>> Unless you are using directory manager for replication (please tell
>> me you are not), you shouldn't have to do anything.
>
> Given this is freeipa-users I assume ipa-replica-install/manage
> converted his replication agreements to use GSSAPI :-)
>
> So, no, in FreeIPA replication doesn't care about the DM password.
>
> Simo.
>
> --
> Simo Sorce * Red Hat, Inc * New York
>
> --
> 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



-- 
Thomas Lau
Director of Infrastructure
Tetrion Capital Limited

Direct: +852-3976-8903
Mobile: +852-9323-9670
Address: 20/F, IFC 1, Central district, Hong Kong



From mkosek at redhat.com  Wed Dec 10 08:19:10 2014
From: mkosek at redhat.com (Martin Kosek)
Date: Wed, 10 Dec 2014 09:19:10 +0100
Subject: [Freeipa-users] can't register new clients
In-Reply-To: <CACMA5-xNNid1-em7i5QDNaFE47aXxhEDBYg8w71MeMPLhNsHDg@mail.gmail.com>
References: <CACMA5-xsgZ2RcF7rx9MS+jtxpyMOofhpU0MnPn+1mcmHGOxNkg@mail.gmail.com>	<54821AA7.1000007@redhat.com>	<54821D9B.80502@redhat.com>	<CACMA5-xs3gOMAdjg3o5aG6d58d-CvqPh5k9yo23pLSD9uXAq9Q@mail.gmail.com>	<548225F9.7010001@redhat.com>	<CACMA5-w=BmD+=9Gj7Q=U0oheEQOb40zfdzST_ASixiuKs5TqHA@mail.gmail.com>	<54822D6D.1050807@redhat.com>	<CACMA5-z+rt0e7tkf_UY5L_YzbQNcmRrNbNDQv3H01a=O9sXmxg@mail.gmail.com>	<CACMA5-wY7+ceQm8GOT11=8MttRgNcZfsS8sg8X25AOMfo+22Jg@mail.gmail.com>	<5486BE72.5020506@redhat.com>	<CACMA5-wOWDtgXDZU+3CXjtVcxmMm_43Yj6sHj1WF5PGVq5M35Q@mail.gmail.com>	<548701A0.8000507@redhat.com>
	<CACMA5-xNNid1-em7i5QDNaFE47aXxhEDBYg8w71MeMPLhNsHDg@mail.gmail.com>
Message-ID: <548801FE.1080901@redhat.com>

On 12/09/2014 03:57 PM, Megan . wrote:
> This is happening with all new clients.  I had to rebuild the LDAP
> server onto new hardware and the network team put us on a new VLAN.
> so my physical server and IP changed.  I was previously able to
> register clients, but after all of the changes, i can no longer
> register them.  At this point i'm not sure if there is a network issue
> or something wrong with the IPA server.  The existing clients are
> communicating fine, no errors or complains.  I have two new clients to
> add and both have the same symptoms.
> 
> I used these procedures to backup then restore onto the new host
> http://www.freeipa.org/page/V3/Backup_and_Restore
> 
> To change the IP i just updated /etc/hosts and pushed it out to the clients

This may be related. Did the backup and restore really go correctly? AFAIK,
this feature did not go through more heavy testing in the community yet, so
there may be rough edges. There were several bug fixes to backup and restore
scripts in FreeIPA 4.1.x releases already.

But if the hostname is the same, A/AAAA and PTR DNS records are still valid and
your other clients work fine, it should be OK.

So you are saying that installation still fails with the NSS error -8054? I am
thinking that the next step should be to run ipa-client-install with --force
flag to make sure that it does not clean the certificate downloaded from LDAP
and check that the cert downloaded to /ect/ipa/ca.crt is indeed OK (you already
tested the one downloaded by wget, but theoretically, the one in LDAP could be
different).

> On Tue, Dec 9, 2014 at 9:05 AM, Rob Crittenden <rcritten at redhat.com> wrote:
>> Megan . wrote:
>>> Everything looks ok.
>>>
>>> Our Networks team only opened 443 from the client to the server.  is
>>> 80 required to be open too for registration?  80 is a lot harder for
>>> me to request on our network.
>>>
>>> I think I might have found the issue.  Maybe it can't verify the CA
>>> because its pointing to port 80, and 80 isn't open.  Is it possible to
>>> change the certificate so this information is available via 443 or
>>> does that not make sense since its trying to get information about the
>>> secure connection in the first place.
>>
>> I don't think port 80 is the problem and in any case, it is just a
>> fallback in case the client can't get it via LDAP which in new installs
>> shouldn't be an issue. You'd get an error that the CA couldn't be
>> retrieved at all and not that a duplicate serial existed.
>>
>> Is this happening on every client or just one?
>>
>> Did you have a previous IPA install and you are re-enrolling this
>> client(s) into the new one?
>>
>> rob
>>
>>>
>>> from the server:
>>> [root at dir1 ipa]# openssl verify -verbose -CAFile ca.crt
>>> .
>>> .
>>>             Authority Information Access:
>>>                 OCSP - URI:http://dir1.example.com:80/ca/ocsp
>>> .
>>>
>>>
>>>
>>> [root at data2-uat ipa]# wget https://dir1.example.com/ipa/config/ca.crt
>>> -O /tmp/ipa.crt
>>> --2014-12-09 13:21:32--  https://dir1.example.com/ipa/config/ca.crt
>>> Resolving dir1.example.com... 172.28.27.170
>>> Connecting to dir1.example.com|172.28.27.170|:443... connected.
>>> ERROR: cannot verify dir1.example.com?s certificate, issued by
>>> ?/O=EXAMPLE.COM/CN=Certificate Authority?:
>>>   Self-signed certificate encountered.
>>> To connect to dir1.example.com insecurely, use ?--no-check-certificate?.
>>> [root at data2-uat ipa]# wget https://dir1.example.com/ipa/config/ca.crt
>>> -O /tmp/ipa.crt --no-check-certificate
>>> --2014-12-09 13:22:11--  https://dir1.example.com/ipa/config/ca.crt
>>> Resolving dir1.example.com... 172.28.27.170
>>> Connecting to dir1.example.com|172.28.27.170|:443... connected.
>>> WARNING: cannot verify dir1.example.com?s certificate, issued by
>>> ?/O=EXAMPLE.COM/CN=Certificate Authority?:
>>>   Self-signed certificate encountered.
>>> HTTP request sent, awaiting response... 200 OK
>>> Length: 1357 (1.3K) [application/x-x509-ca-cert]
>>> Saving to: ?/tmp/ipa.crt?
>>>
>>> 100%[================================================>] 1,357
>>> --.-K/s   in 0.005s
>>>
>>> 2014-12-09 13:22:11 (246 KB/s) - ?/tmp/ipa.crt? saved [1357/1357]
>>>
>>> [root at data2-uat ipa]# cd /tmp
>>> [root at data2-uat tmp]# openssl s_client -host dir1.example.com  -port
>>> 443 -CAfile /tmp/ipa.crt
>>> CONNECTED(00000003)
>>> depth=1 O = EXAMPLE.COM, CN = Certificate Authority
>>> verify return:1
>>> depth=0 O = EXAMPLE.COM, CN = dir1.example.com
>>> verify return:1
>>> ---
>>> Certificate chain
>>>  0 s:/O=EXAMPLE.COM/CN=dir1.example.com
>>>    i:/O=EXAMPLE.COM/CN=Certificate Authority
>>>  1 s:/O=EXAMPLE.COM/CN=Certificate Authority
>>>    i:/O=EXAMPLE.COM/CN=Certificate Authority
>>> ---
>>> Server certificate
>>> -----BEGIN CERTIFICATE-----
>>> ...
>>> -----END CERTIFICATE-----
>>> subject=/O=EXAMPLE.COM/CN=dir1.example.com
>>> issuer=/O=EXAMPLE.COM/CN=Certificate Authority
>>> ---
>>> No client certificate CA names sent
>>> ---
>>> SSL handshake has read 2095 bytes and written 591 bytes
>>> ---
>>> New, TLSv1/SSLv3, Cipher is AES128-SHA
>>> Server public key is 2048 bit
>>> Secure Renegotiation IS supported
>>> Compression: NONE
>>> Expansion: NONE
>>> SSL-Session:
>>>     Protocol  : TLSv1.1
>>>     Cipher    : AES128-SHA
>>>     Session-ID: F6A664BC942DF235EF546007379A79A00245G34FA7C0E6F191B911E9CFEC17D0
>>>     Session-ID-ctx:
>>>     Master-Key:
>>> 8C9A5FB1DFDDA72FF09780A85A43FA3C1AA14D4FB199F510A0DC3DF0C53DFFFFCDD0F26211CA886342E84030EA891959
>>>     Key-Arg   : None
>>>     Krb5 Principal: None
>>>     PSK identity: None
>>>     PSK identity hint: None
>>>     Start Time: 1418131359
>>>     Timeout   : 300 (sec)
>>>     Verify return code: 0 (ok)
>>> ---
>>> closed
>>>
>>> On Tue, Dec 9, 2014 at 4:18 AM, Martin Kosek <mkosek at redhat.com> wrote:
>>>> On 12/08/2014 08:00 PM, Megan . wrote:
>>>>> I looked through the logs on the server and i see the below error in
>>>>> the apache error log when i try to register a client:
>>>>>
>>>>> [Mon Dec 08 12:20:38 2014] [error] SSL Library Error: -12195 Peer does
>>>>> not recognize and trust the CA that issued your certificate
>>>>>
>>>>>
>>>>> I ran ipa-getcert list and everything seems ok (nothing expired) but
>>>>> i'm not sure where to troubleshoot from here.
>>>>
>>>> The next step would be to check the actual HTTP certificate (on the client
>>>> machine) and see what's wrong. I did a simple test you can follow:
>>>>
>>>> # wget http://ipa.mkosek-f21.test/ipa/config/ca.crt -O /tmp/ipa.crt
>>>> # openssl s_client -host ipa.mkosek-f21.test -port 443 -CAfile /tmp/ipa.crt
>>>> CONNECTED(00000003)
>>>> depth=1 O = MKOSEK-F21.TEST, CN = Certificate Authority
>>>> verify return:1
>>>> depth=0 O = MKOSEK-F21.TEST, CN = ipa.mkosek-f21.test
>>>> verify return:1
>>>> ---
>>>> Certificate chain
>>>>  0 s:/O=MKOSEK-F21.TEST/CN=ipa.mkosek-f21.test
>>>>    i:/O=MKOSEK-F21.TEST/CN=Certificate Authority
>>>>  1 s:/O=MKOSEK-F21.TEST/CN=Certificate Authority
>>>>    i:/O=MKOSEK-F21.TEST/CN=Certificate Authority
>>>> ---
>>>> Server certificate
>>>> ...
>>>> SSL-Session:
>>>>     Protocol  : TLSv1.2
>>>>     Cipher    : AES128-SHA
>>>>     Session-ID: 5A4B326D2E8FB80408D628D1975C49C4F78D3E65F31E475F9E7B9BBBE11F576E
>>>>     Session-ID-ctx:
>>>>     Master-Key:
>>>> D5C31E9E36503ADC9F162439B41A7A608260D7DF5EB357FB3D79C9CFAE700912526893E7DD9AA56F5B6CD320FBA98C49
>>>>     Key-Arg   : None
>>>>     Krb5 Principal: None
>>>>     PSK identity: None
>>>>     PSK identity hint: None
>>>>     Start Time: 1418073191
>>>>     Timeout   : 300 (sec)
>>>>     Verify return code: 0 (ok)
>>>> ---
>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Fri, Dec 5, 2014 at 7:51 PM, Megan . <nagemnna at gmail.com> wrote:
>>>>>> It failed again.
>>>>>>
>>>>>>
>>>>>> [root at cache2-uat ~]# certutil -L -d sql:/etc/pki/nssdb
>>>>>>
>>>>>> Certificate Nickname                                         Trust Attributes
>>>>>>                                                              SSL,S/MIME,JAR/XPI
>>>>>> [root at cache2-uat ~]#
>>>>>>
>>>>>> Not sure if its related, but on the directory server in the apache
>>>>>> error.log I see the below every time a client tries to register:
>>>>>>
>>>>>> [Sat Dec 06 00:48:35 2014] [error] SSL Library Error: -12271 SSL
>>>>>> client cannot verify your certificate
>>>>>>
>>>>>> On the directory server i ran ipa-getcert list and the certs seem ok.
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Fri, Dec 5, 2014 at 5:10 PM, Rob Crittenden <rcritten at redhat.com> wrote:
>>>>>>> Megan . wrote:
>>>>>>>> Sorry for being unclear. It still fails.  Same error.
>>>>>>>
>>>>>>> Hmm, strange. Try being explicit about sql:
>>>>>>>
>>>>>>> # certutil -L -d sql:/etc/pki/nssdb
>>>>>>>
>>>>>>> And if there is a CA cert there, delete it.
>>>>>>>
>>>>>>> rob
>>>>>>>
>>>>>>>>
>>>>>>>> On Dec 5, 2014 4:39 PM, "Rob Crittenden" <rcritten at redhat.com
>>>>>>>> <mailto:rcritten at redhat.com>> wrote:
>>>>>>>>
>>>>>>>>     Megan . wrote:
>>>>>>>>     > Thanks.
>>>>>>>>     >
>>>>>>>>     > I did have an issue last week where i tried to do the client install
>>>>>>>>     > and it failed because of a firewall issue.  Networks has it opened
>>>>>>>>     > now.  I deleted ca.crt before trying again.  There doesn't seem to be
>>>>>>>>     > a certificate in /etc/pki/nssdb for it.
>>>>>>>>     >
>>>>>>>>     >
>>>>>>>>     >
>>>>>>>>     > [root at data2-uat ipa]# certutil -L -d /etc/pki/nssdb
>>>>>>>>     >
>>>>>>>>     >
>>>>>>>>     > Certificate Nickname                                         Trust
>>>>>>>>     Attributes
>>>>>>>>     >
>>>>>>>>     >
>>>>>>>>     SSL,S/MIME,JAR/XPI
>>>>>>>>     >
>>>>>>>>     >
>>>>>>>>     > [root at data2-uat ipa]# certutil -D -n 'IPA CA' -d /etc/pki/nssdb
>>>>>>>>     >
>>>>>>>>     > certutil: could not find certificate named "IPA CA":
>>>>>>>>     > SEC_ERROR_BAD_DATABASE: security library: bad database.
>>>>>>>>     >
>>>>>>>>     > [root at data2-uat ipa]# ls
>>>>>>>>     >
>>>>>>>>     > [root at data2-uat ipa]# pwd
>>>>>>>>     >
>>>>>>>>     > /etc/ipa
>>>>>>>>     >
>>>>>>>>     > [root at data2-uat ipa]# ls -al
>>>>>>>>     >
>>>>>>>>     > total 16
>>>>>>>>     >
>>>>>>>>     > drwxr-xr-x.  2 root root  4096 Dec  5 21:16 .
>>>>>>>>     >
>>>>>>>>     > drwxr-xr-x. 82 root root 12288 Dec  5 21:16 ..
>>>>>>>>     >
>>>>>>>>     > [root at data2-uat ipa]#
>>>>>>>>
>>>>>>>>     So trying to install the client again fails or succeeds now?
>>>>>>>>
>>>>>>>>     rob
>>>>>>>>
>>>>>>>>     >
>>>>>>>>     > On Fri, Dec 5, 2014 at 4:03 PM, Rob Crittenden
>>>>>>>>     <rcritten at redhat.com <mailto:rcritten at redhat.com>> wrote:
>>>>>>>>     >> Rob Crittenden wrote:
>>>>>>>>     >>> Megan . wrote:
>>>>>>>>     >>>> Good Day!
>>>>>>>>     >>>>
>>>>>>>>     >>>> I am getting an error when i register new clients.
>>>>>>>>     >>>>
>>>>>>>>     >>>> libcurl failed to execute the HTTP POST transaction.  SSL
>>>>>>>>     connect error
>>>>>>>>     >>>>
>>>>>>>>     >>>> I can't find anything useful not the internet about the error.  Can
>>>>>>>>     >>>> someone help me troubleshoot?
>>>>>>>>     >>>>
>>>>>>>>     >>>> CentOS 6.6  x64
>>>>>>>>     >>>> ipa-client-3.0.0-42.el6.centos.x86_64
>>>>>>>>     >>>> ipa-server-3.0.0-42.el6.centos.x86_64
>>>>>>>>     >>>> curl-7.19.7-40.el6_6.1.x86_64
>>>>>>>>     >>>
>>>>>>>>     >>> Do you have NSS_DEFAULT_DB_TYPE set to sql? I don't know that
>>>>>>>>     we've done
>>>>>>>>     >>> any testing on the client with this set.
>>>>>>>>     >>
>>>>>>>>     >> Never mind, that's not it. The problem is:
>>>>>>>>     >>
>>>>>>>>     >> * NSS error -8054
>>>>>>>>     >>
>>>>>>>>     >> Which is SEC_ERROR_REUSED_ISSUER_AND_SERIAL
>>>>>>>>     >>
>>>>>>>>     >> So I'd do this:
>>>>>>>>     >>
>>>>>>>>     >> # rm /etc/ipa/ca.crt
>>>>>>>>     >>
>>>>>>>>     >> You may also want to ensure that the IPA CA certificate isn't in
>>>>>>>>     >> /etc/pki/nssdb:
>>>>>>>>     >>
>>>>>>>>     >> # certutil -L -d /etc/pki/nssdb
>>>>>>>>     >>
>>>>>>>>     >> And then perhaps
>>>>>>>>     >>
>>>>>>>>     >> # certutil -D -n 'IPA CA' -d /etc/pki/nssdb
>>>>>>>>     >>
>>>>>>>>     >> rob
>>>>>>>>     >>
>>>>>>>>
>>>>>>>
>>>>>
>>>>
>>>
>>



From mkosek at redhat.com  Wed Dec 10 09:21:59 2014
From: mkosek at redhat.com (Martin Kosek)
Date: Wed, 10 Dec 2014 10:21:59 +0100
Subject: [Freeipa-users] Change default password expiry date
In-Reply-To: <5487B1AC.1030002@redhat.com>
References: <CAEZt6eCtbiaFSPXe-Zg1tWVM7JuRxBngLeK4g=2=0GZ4QLrnZw@mail.gmail.com>
	<5487B1AC.1030002@redhat.com>
Message-ID: <548810B7.5090001@redhat.com>

On 12/10/2014 03:36 AM, Dmitri Pal wrote:
> On 12/09/2014 08:43 PM, Thomas Lau wrote:
>> Hi All,
>>
>> FreeIPA Default is using 60days password expiry, how could I change it?
> 
> You go to password policies and change the global password policy.
> You change MAX lifetime.
> This is a global setting it will apply to new passwords/keytabs when they are
> changed next time.
> You can create other policies and apply them to groups it you need.

Right. BTW, the default is 90 days, not sixty:

# ipa pwpolicy-show
  Group: global_policy
  Max lifetime (days): 90
  Min lifetime (hours): 1
  History size: 0
  Character classes: 0
  Min length: 8
  Max failures: 6
  Failure reset interval: 60
  Lockout duration: 600

> 
>>
>> Also, for existing accounts, can I just change krbPasswordExpiration
>> on LDAP?
> 
> I think the answer is yes.

You will need to be Directory Manager for such change. Normally, it is excepted
that the new password policy is applied on next user password change.

> 
>> anywhere else I need to change?
> 
> I think the answer is no

Right.

> 
>> do I need to generate keytab
>> on Kerberos to activate new expiry date?
>>
> If you change the expiration in the attribute then no.
> 

More on password policies here:

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/user-pwdpolicy.html



From tbordaz at redhat.com  Wed Dec 10 09:28:17 2014
From: tbordaz at redhat.com (thierry bordaz)
Date: Wed, 10 Dec 2014 10:28:17 +0100
Subject: [Freeipa-users]
 =?utf-8?q?Unit_pki-tomcatd=40pki-tomcat=2Eservice?=
 =?utf-8?q?_entered_failed_state_=40_vanilla_install_on_jessie_=E2=80=93_w?=
 =?utf-8?q?ith_log_attached?=
In-Reply-To: <3498884.j87NNgj6SR@hansa>
References: <6538670.riIOSljqhg@hansa> <5486F4D8.6040700@redhat.com>
	<3498884.j87NNgj6SR@hansa>
Message-ID: <54881231.7000602@redhat.com>

On 12/09/2014 11:52 PM, chymian wrote:
>> Am Dienstag, 9. Dezember 2014, 14:10:48 schrieb thierry bordaz:
>>
>> On 12/09/2014 01:54 PM, chymian wrote:
>>> hey people,
>>>
>>> after a successful install of ipa 4.0.5-2 on jessie, the named services
>>> started flawless during setup. see attached log, Installation summary
>>> (line
>>> 3107) but after reboot, it refuses to start. (did this install a couple
>>> times, on vanilla jessie)
>>>
>>> I can reach & work with Dogtag https://ipa.eb8.lan:8443/ca, but not the
>>> admin-services on https://ipa.eb8.lan/ca/ee/ca and
>>> https://ipa.eb8.lan/ca/agent/ca.
>>>
>>>
>>> $ systemctl status pki-tomcatd at pki-tomcat.service
>>> ? pki-tomcatd at pki-tomcat.service - PKI Tomcat Server pki-tomcat
>>>
>>>     Loaded: loaded (/lib/systemd/system/pki-tomcatd at .service; enabled)
>>>     Active: failed (Result: resources)
>>>
>>> Dez 08 20:40:13 ipa systemd[1]: Starting PKI Tomcat Server pki-tomcat...
>>> Dez 08 20:40:13 ipa systemd[1]: Failed to load environment files: No such
>>> file or directory Dez 08 20:40:13 ipa systemd[1]:
>>> pki-tomcatd at pki-tomcat.service failed to run 'start-pre' task: No such
>>> file
>>> or directory Dez 08 20:40:13 ipa systemd[1]: Failed to start PKI Tomcat
>>> Server pki-tomcat. Dez 08 20:40:13 ipa systemd[1]: Unit
>>> pki-tomcatd at pki-tomcat.service entered failed state.
>>>
>>>
>>> a second service fails to start:
>>>
>>> $ systemctl status dirsrv-snmp.service
>>> ? dirsrv-snmp.service - 389 Directory Server SNMP Subagent.
>>>
>>>     Loaded: loaded (/lib/systemd/system/dirsrv-snmp.service; enabled)
>>>     Active: failed (Result: exit-code) since Di 2014-12-09 13:25:04 CET;
>>>     5min
>>>     ago
>>>    
>>>    Process: 156 ExecStart=/usr/sbin/ldap-agent
>>>    /etc/dirsrv/config/ldap-agent.conf (code=exited, status=1/FAILURE)>
>>>
>>> Dez 09 13:25:04 ipa systemd[1]: Starting 389 Directory Server SNMP
>>> Subagent.... Dez 09 13:25:04 ipa ldap-agent[156]: ldap-agent: No server
>>> instances defined in config file Dez 09 13:25:04 ipa systemd[1]:
>>> dirsrv-snmp.service: control process exited, code=exited status=1 Dez 09
>>> 13:25:04 ipa systemd[1]: Failed to start 389 Directory Server SNMP
>>> Subagent.. Dez 09 13:25:04 ipa systemd[1]: Unit dirsrv-snmp.service
>>> entered
>>> failed state.
>> Hello,
>>
>> regarding this issue. Is there a agent log file under /var/log/dirsrv/agent/
>> ?
>>
>> thanks
>> thierry
>>
> thierry,
> no there aren?t any files, except the slapd-EB8-LAN/ directory in /var/log/dirsrv/
> not even an  /var/log/dirsrv/agent/
>
> anything else I can provide?

Hello Guenter,

It is looking like no server have been configured in 
/etc/dirsrv/config/ldap-agent.conf to be monitored.
So the ldap-agent started by this service returns an errors at startup.
As you are not using snmp, like Rich said you may ignore this service 
failure.

thanks
thierry
>   
> thanks,
> guenter
>
>>> except these, I was able to subscribe a jessie-client with autodiscovery
>>> right after I did configure the ipa-server, before first reboot.
>>>
>>>
>>> any help appreciated, since I do not have much experience with IPA ? yet.
>>> guenter



From gianluca.cecchi at gmail.com  Wed Dec 10 11:55:16 2014
From: gianluca.cecchi at gmail.com (Gianluca Cecchi)
Date: Wed, 10 Dec 2014 12:55:16 +0100
Subject: [Freeipa-users] vSphere 5.1 and FreeIPA 3.3 on CentOS 7 finally
 works! [How I did it...]
In-Reply-To: <5486C602.80106@redhat.com>
References: <CAG2kNCyXWXxMx0V96bYgMq--9zaBwhWMBENrOgSXnMMr9=F85Q@mail.gmail.com>
	<5485E119.10203@redhat.com>
	<CAG2kNCyWUhbVZUbpo0rgE_NAucs5S4x6_dj4JcCXTNWyLNSAFw@mail.gmail.com>
	<CAG2kNCyj=b4c-5C59uvba37hoXwX8rHmtE9DC1vbKk+YM5p1ZQ@mail.gmail.com>
	<5486C602.80106@redhat.com>
Message-ID: <CAG2kNCyMr00bjoZLzs_WmwE4LXRSZAq5ppn6D5O1Cv0ND41mLQ@mail.gmail.com>

On Tue, Dec 9, 2014 at 10:50 AM, Martin Kosek <mkosek at redhat.com> wrote:

> On 12/09/2014 12:50 AM, Gianluca Cecchi wrote:
> > On Mon, Dec 8, 2014 at 7:17 PM, Gianluca Cecchi <
> gianluca.cecchi at gmail.com>
> > wrote:
> >
> >> OK. I will check requirements to write into The wiki
> >>
>

Hello,
now I was able to login and I created this draft page, you can check and
feel free to review...
http://www.freeipa.org/page/HowTo/vsphere5_integration
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141210/322fef5e/attachment.htm>

From ctcard at hotmail.com  Wed Dec 10 11:57:26 2014
From: ctcard at hotmail.com (Chris Card)
Date: Wed, 10 Dec 2014 11:57:26 +0000
Subject: [Freeipa-users] freeipa / sudo
Message-ID: <DUB125-W16B0DB66FBF254466DC9FDCC620@phx.gbl>

Hi,
I've installed freeipa 4.1.1 on Fedora 21, and successfully set up a freeipa server and a freeipa client machine.
I've set up a user with ssh keys, and can successfully ssh onto the client machine.
I'm trying to setup sudo rules so that if the user is in a given user group, then the user can run "sudo su -" on the client to become root.

Here is my setup:

[root at fedora21-freeipa log]# ipa user-show ccard
? User login: ccard
? First name: Chris
? Last name: Card
? Home directory: /home/ccard
? Login shell: /bin/sh
? Email address: ccard at testdomain21.com
? UID: 1581000001
? GID: 1581000001
? Account disabled: False
? Password: True
? Member of groups: ipausers, cog_rw
? Indirect Member of Sudo rule: All
? Kerberos keys available: True
? SSH public key fingerprint: 98:3D:15:93:A2:F7:79:A8:D6:F6:8B:5B:21:3F:E6:78 ccard (ssh-rsa)
[root at fedora21-freeipa log]# ipa group-show cog_rw
? Group name: cog_rw
? GID: 1581000003
? Member users: ccard
? Member of Sudo rule: All
[root at fedora21-freeipa log]# ipa sudorule-show All
? Rule name: All
? Enabled: TRUE
? Host category: all
? Command category: all
? RunAs User category: all
? RunAs Group category: all
? User Groups: cog_rw
? Sudo Option: !authenticate

I've found that this setup works eventually, but I have to wait for several minutes after changing the settings (through the freeipa gui), before it works.?
I've found that changing entry_cache_sudo_timeout and stopping/starting sssd on the client machine helps, and that sss_cache doesn't support invalidating the sudo rules, which is annoying.

I've also tried making the sudo rule more restrictive by adding a host group e.g.

[root at fedora21-freeipa log]# ipa hostgroup-show
Host-group: cog
? Host-group: cog
? Member hosts: ipaclient21.testdomain21.com
? Member of Sudo rule: All
[root at fedora21-freeipa log]# ipa sudorule-show All
? Rule name: All
? Enabled: TRUE
? Command category: all
? RunAs User category: all
? RunAs Group category: all
? User Groups: cog_rw
? Host Groups: cog
? Sudo Option: !authenticate

but this setup doesn't work, i.e. even though the user is in the user group and the client machine is in the host group, sudo su - fails. Is this a bug, or have I missed something?

Chris

 		 	   		  



From mkosek at redhat.com  Wed Dec 10 12:01:49 2014
From: mkosek at redhat.com (Martin Kosek)
Date: Wed, 10 Dec 2014 13:01:49 +0100
Subject: [Freeipa-users] freeipa / sudo
In-Reply-To: <DUB125-W16B0DB66FBF254466DC9FDCC620@phx.gbl>
References: <DUB125-W16B0DB66FBF254466DC9FDCC620@phx.gbl>
Message-ID: <5488362D.4040609@redhat.com>

On 12/10/2014 12:57 PM, Chris Card wrote:
> Hi,
> I've installed freeipa 4.1.1 on Fedora 21, and successfully set up a freeipa server and a freeipa client machine.
> I've set up a user with ssh keys, and can successfully ssh onto the client machine.
> I'm trying to setup sudo rules so that if the user is in a given user group, then the user can run "sudo su -" on the client to become root.
> 
> Here is my setup:
> 
> [root at fedora21-freeipa log]# ipa user-show ccard
>   User login: ccard
>   First name: Chris
>   Last name: Card
>   Home directory: /home/ccard
>   Login shell: /bin/sh
>   Email address: ccard at testdomain21.com
>   UID: 1581000001
>   GID: 1581000001
>   Account disabled: False
>   Password: True
>   Member of groups: ipausers, cog_rw
>   Indirect Member of Sudo rule: All
>   Kerberos keys available: True
>   SSH public key fingerprint: 98:3D:15:93:A2:F7:79:A8:D6:F6:8B:5B:21:3F:E6:78 ccard (ssh-rsa)
> [root at fedora21-freeipa log]# ipa group-show cog_rw
>   Group name: cog_rw
>   GID: 1581000003
>   Member users: ccard
>   Member of Sudo rule: All
> [root at fedora21-freeipa log]# ipa sudorule-show All
>   Rule name: All
>   Enabled: TRUE
>   Host category: all
>   Command category: all
>   RunAs User category: all
>   RunAs Group category: all
>   User Groups: cog_rw
>   Sudo Option: !authenticate
> 
> I've found that this setup works eventually, but I have to wait for several minutes after changing the settings (through the freeipa gui), before it works. 
> I've found that changing entry_cache_sudo_timeout and stopping/starting sssd on the client machine helps, and that sss_cache doesn't support invalidating the sudo rules, which is annoying.
> 
> I've also tried making the sudo rule more restrictive by adding a host group e.g.
> 
> [root at fedora21-freeipa log]# ipa hostgroup-show
> Host-group: cog
>   Host-group: cog
>   Member hosts: ipaclient21.testdomain21.com
>   Member of Sudo rule: All
> [root at fedora21-freeipa log]# ipa sudorule-show All
>   Rule name: All
>   Enabled: TRUE
>   Command category: all
>   RunAs User category: all
>   RunAs Group category: all
>   User Groups: cog_rw
>   Host Groups: cog
>   Sudo Option: !authenticate
> 
> but this setup doesn't work, i.e. even though the user is in the user group and the client machine is in the host group, sudo su - fails. Is this a bug, or have I missed something?
> 
> Chris
> 
>  		 	   		  
> 

With FreeIPA 4.1.1, client sudo integration should be automatically configured,
so it should just work, including hostgroups. In your case, I would start with
investigating

http://www.freeipa.org/page/Troubleshooting#sudo_does_not_work_for_hostgroups

If that does not help, I bet SSSD devs will ask for logs.

Martin



From ctcard at hotmail.com  Wed Dec 10 12:57:35 2014
From: ctcard at hotmail.com (Chris Card)
Date: Wed, 10 Dec 2014 12:57:35 +0000
Subject: [Freeipa-users] freeipa / sudo
In-Reply-To: <5488362D.4040609@redhat.com>
References: <DUB125-W16B0DB66FBF254466DC9FDCC620@phx.gbl>,
	<5488362D.4040609@redhat.com>
Message-ID: <DUB125-W201847FB050F16A133931CC620@phx.gbl>

> On 12/10/2014 12:57 PM, Chris Card wrote:
thanks Martin,
>> I've installed freeipa 4.1.1 on Fedora 21, and successfully set up a freeipa server and a freeipa client machine.
>> I've set up a user with ssh keys, and can successfully ssh onto the client machine.
>> I'm trying to setup sudo rules so that if the user is in a given user group, then the user can run "sudo su -" on the client to become root.
<snip>
>> [root at fedora21-freeipa log]# ipa hostgroup-show
>> Host-group: cog
>> Host-group: cog
>> Member hosts: ipaclient21.testdomain21.com
>> Member of Sudo rule: All
>> [root at fedora21-freeipa log]# ipa sudorule-show All
>> Rule name: All
>> Enabled: TRUE
>> Command category: all
>> RunAs User category: all
>> RunAs Group category: all
>> User Groups: cog_rw
>> Host Groups: cog
>> Sudo Option: !authenticate
>>
>> but this setup doesn't work, i.e. even though the user is in the user group and the client machine is in the host group, sudo su - fails. Is this a bug, or have I missed something?
>>
>> Chris
>>
>>
>>
>
> With FreeIPA 4.1.1, client sudo integration should be automatically configured,
> so it should just work, including hostgroups. In your case, I would start with
> investigating
>
> http://www.freeipa.org/page/Troubleshooting#sudo_does_not_work_for_hostgroups
>
> If that does not help, I bet SSSD devs will ask for logs.
>
I've done the troubleshooting steps:

[root at ipaclient21 log]# nisdomainname?
testdomain21.com
[root at ipaclient21 log]# getent netgroup cog
cog ? ? ? ? ? ? ? ? ? (ipaclient21.testdomain21.com,-,testdomain21.com)

I tried adding sudoers_debug 2 to /etc/sudo-ldap.conf on the client machine, but I'm not sure if that's the right file (it didn't exist before).
I have debug_level set to 9 in /etc/sssd/sssd.conf, so I can see some stuff in /var/log/sssd/sssd_testdomain21.com.log but no obvious error messages.

Chris 		 	   		  



From rmeggins at redhat.com  Wed Dec 10 13:37:23 2014
From: rmeggins at redhat.com (Rich Megginson)
Date: Wed, 10 Dec 2014 06:37:23 -0700
Subject: [Freeipa-users] change directory manager password
In-Reply-To: <CAEZt6eB5Lht6-NDSvr2H0_-cbfb2Xadbfe2qU-EH8e5w_Wm28g@mail.gmail.com>
References: <CAEZt6eBC1-V6+iJ2FX9BAt+foJBg_nS+ycFd_C_1CCpLouE=-w@mail.gmail.com>	<CAEZt6eCezuP=3i+bTbfziRmHWArttrE+uJtmKmdqk7i6fF+CcA@mail.gmail.com>	<5487BF0C.4030306@redhat.com>	<20141209230329.7bc28828@willson.usersys.redhat.com>
	<CAEZt6eB5Lht6-NDSvr2H0_-cbfb2Xadbfe2qU-EH8e5w_Wm28g@mail.gmail.com>
Message-ID: <54884C93.6030505@redhat.com>

On 12/10/2014 12:46 AM, Thomas Lau wrote:
> Hi All,
>
> So I am using FreeIPA 3.3.3, when I change password on one IPA host,
> the other clusters will in sync with the change or I need to do it one
> by one manually?

You have to do every server manually.  Changes to the cn=config tree are 
not replicated.

>
> On Wed, Dec 10, 2014 at 12:03 PM, Simo Sorce <simo at redhat.com> wrote:
>> On Tue, 09 Dec 2014 20:33:32 -0700
>> Rich Megginson <rmeggins at redhat.com> wrote:
>>
>>> On 12/09/2014 07:46 PM, Thomas Lau wrote:
>>>> By the way, if I change Directory manager password, do I need to do
>>>> anything else for replication cluster?
>>> http://www.port389.org/docs/389ds/howto/howto-resetdirmgrpassword.html
>>>
>>> Unless you are using directory manager for replication (please tell
>>> me you are not), you shouldn't have to do anything.
>> Given this is freeipa-users I assume ipa-replica-install/manage
>> converted his replication agreements to use GSSAPI :-)
>>
>> So, no, in FreeIPA replication doesn't care about the DM password.
>>
>> Simo.
>>
>> --
>> Simo Sorce * Red Hat, Inc * New York
>>
>> --
>> 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
>
>



From chymian at gmx.net  Wed Dec 10 14:32:05 2014
From: chymian at gmx.net (chymian)
Date: Wed, 10 Dec 2014 15:32:05 +0100
Subject: [Freeipa-users]
	=?utf-8?q?Unit_pki-tomcatd=40pki-tomcat=2Eservice?=
	=?utf-8?q?_entered_failed_state_=40_vanilla_install_on_jessie_?=
	=?utf-8?q?=E2=80=93_with_log_attached?=
In-Reply-To: <54881231.7000602@redhat.com>
References: <6538670.riIOSljqhg@hansa> <3498884.j87NNgj6SR@hansa>
	<54881231.7000602@redhat.com>
Message-ID: <2690722.QDL8tDtr1J@hansa>

Am Mittwoch, 10. Dezember 2014, 10:28:17 schrieb thierry bordaz:
> On 12/09/2014 11:52 PM, chymian wrote:
> >> Am Dienstag, 9. Dezember 2014, 14:10:48 schrieb thierry bordaz:
> >>
> >> On 12/09/2014 01:54 PM, chymian wrote:
> >>> hey people,
> >>>
> >>> after a successful install of ipa 4.0.5-2 on jessie, the named services
> >>> started flawless during setup. see attached log, Installation summary
> >>> (line
> >>> 3107) but after reboot, it refuses to start. (did this install a couple
> >>> times, on vanilla jessie)
> >>>
> >>> I can reach & work with Dogtag https://ipa.eb8.lan:8443/ca, but not the
> >>> admin-services on https://ipa.eb8.lan/ca/ee/ca and
> >>> https://ipa.eb8.lan/ca/agent/ca.
> >>>
> >>>
> >>> $ systemctl status pki-tomcatd at pki-tomcat.service
> >>> ? pki-tomcatd at pki-tomcat.service - PKI Tomcat Server pki-tomcat
> >>>
> >>>     Loaded: loaded (/lib/systemd/system/pki-tomcatd at .service; enabled)
> >>>     Active: failed (Result: resources)
> >>>
> >>> Dez 08 20:40:13 ipa systemd[1]: Starting PKI Tomcat Server pki-tomcat...
> >>> Dez 08 20:40:13 ipa systemd[1]: Failed to load environment files: No such
> >>> file or directory Dez 08 20:40:13 ipa systemd[1]:
> >>> pki-tomcatd at pki-tomcat.service failed to run 'start-pre' task: No such
> >>> file
> >>> or directory Dez 08 20:40:13 ipa systemd[1]: Failed to start PKI Tomcat
> >>> Server pki-tomcat. Dez 08 20:40:13 ipa systemd[1]: Unit
> >>> pki-tomcatd at pki-tomcat.service entered failed state.
> >>>
> >>>
> >>> a second service fails to start:
> >>>
> >>> $ systemctl status dirsrv-snmp.service
> >>> ? dirsrv-snmp.service - 389 Directory Server SNMP Subagent.
> >>>
> >>>     Loaded: loaded (/lib/systemd/system/dirsrv-snmp.service; enabled)
> >>>     Active: failed (Result: exit-code) since Di 2014-12-09 13:25:04 CET;
> >>>     5min
> >>>     ago
> >>>    
> >>>    Process: 156 ExecStart=/usr/sbin/ldap-agent
> >>>    /etc/dirsrv/config/ldap-agent.conf (code=exited, status=1/FAILURE)>
> >>>
> >>> Dez 09 13:25:04 ipa systemd[1]: Starting 389 Directory Server SNMP
> >>> Subagent.... Dez 09 13:25:04 ipa ldap-agent[156]: ldap-agent: No server
> >>> instances defined in config file Dez 09 13:25:04 ipa systemd[1]:
> >>> dirsrv-snmp.service: control process exited, code=exited status=1 Dez 09
> >>> 13:25:04 ipa systemd[1]: Failed to start 389 Directory Server SNMP
> >>> Subagent.. Dez 09 13:25:04 ipa systemd[1]: Unit dirsrv-snmp.service
> >>> entered
> >>> failed state.
> >> Hello,
> >>
> >> regarding this issue. Is there a agent log file under /var/log/dirsrv/agent/
> >> ?
> >>
> >> thanks
> >> thierry
> >>
> > thierry,
> > no there aren?t any files, except the slapd-EB8-LAN/ directory in /var/log/dirsrv/
> > not even an  /var/log/dirsrv/agent/
> >
> > anything else I can provide?
> 
> Hello Guenter,
> 
> It is looking like no server have been configured in 
> /etc/dirsrv/config/ldap-agent.conf to be monitored.
> So the ldap-agent started by this service returns an errors at startup.
> As you are not using snmp, like Rich said you may ignore this service 
> failure.
> 
> thanks
> thierry

hello thierry,
yes, it?s seems to be empty ? same as on a plain cos6/ipa 3.3 installation.
but there, the service does not get started, and therefore, no error is thrown.
may I suggest to do a check in the startup scripts weather a service is configured or not, or "systemctl disable" it by default?

thx for your help
guenter

  
> >   
> > thanks,
> > guenter
> >
> >>> except these, I was able to subscribe a jessie-client with autodiscovery
> >>> right after I did configure the ipa-server, before first reboot.
> >>>
> >>>
> >>> any help appreciated, since I do not have much experience with IPA ? yet.
> >>> guenter
> 




From rcritten at redhat.com  Wed Dec 10 15:23:38 2014
From: rcritten at redhat.com (Rob Crittenden)
Date: Wed, 10 Dec 2014 10:23:38 -0500
Subject: [Freeipa-users] change directory manager password
In-Reply-To: <54884C93.6030505@redhat.com>
References: <CAEZt6eBC1-V6+iJ2FX9BAt+foJBg_nS+ycFd_C_1CCpLouE=-w@mail.gmail.com>	<CAEZt6eCezuP=3i+bTbfziRmHWArttrE+uJtmKmdqk7i6fF+CcA@mail.gmail.com>	<5487BF0C.4030306@redhat.com>	<20141209230329.7bc28828@willson.usersys.redhat.com>	<CAEZt6eB5Lht6-NDSvr2H0_-cbfb2Xadbfe2qU-EH8e5w_Wm28g@mail.gmail.com>
	<54884C93.6030505@redhat.com>
Message-ID: <5488657A.6010207@redhat.com>

Rich Megginson wrote:
> On 12/10/2014 12:46 AM, Thomas Lau wrote:
>> Hi All,
>>
>> So I am using FreeIPA 3.3.3, when I change password on one IPA host,
>> the other clusters will in sync with the change or I need to do it one
>> by one manually?
> 
> You have to do every server manually.  Changes to the cn=config tree are
> not replicated.

You should also take a look at this:
http://www.freeipa.org/page/Howto/Change_Directory_Manager_Password

rob

> 
>>
>> On Wed, Dec 10, 2014 at 12:03 PM, Simo Sorce <simo at redhat.com> wrote:
>>> On Tue, 09 Dec 2014 20:33:32 -0700
>>> Rich Megginson <rmeggins at redhat.com> wrote:
>>>
>>>> On 12/09/2014 07:46 PM, Thomas Lau wrote:
>>>>> By the way, if I change Directory manager password, do I need to do
>>>>> anything else for replication cluster?
>>>> http://www.port389.org/docs/389ds/howto/howto-resetdirmgrpassword.html
>>>>
>>>> Unless you are using directory manager for replication (please tell
>>>> me you are not), you shouldn't have to do anything.
>>> Given this is freeipa-users I assume ipa-replica-install/manage
>>> converted his replication agreements to use GSSAPI :-)
>>>
>>> So, no, in FreeIPA replication doesn't care about the DM password.
>>>
>>> Simo.
>>>
>>> -- 
>>> Simo Sorce * Red Hat, Inc * New York
>>>
>>> -- 
>>> 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
>>
>>
> 



From ctcard at hotmail.com  Wed Dec 10 15:54:59 2014
From: ctcard at hotmail.com (Chris Card)
Date: Wed, 10 Dec 2014 15:54:59 +0000
Subject: [Freeipa-users] freeipa / sudo
In-Reply-To: <DUB125-W201847FB050F16A133931CC620@phx.gbl>
References: <DUB125-W16B0DB66FBF254466DC9FDCC620@phx.gbl>, ,
	<5488362D.4040609@redhat.com>,
	<DUB125-W201847FB050F16A133931CC620@phx.gbl>
Message-ID: <DUB125-W696A68B0EABE4DB4889F64CC620@phx.gbl>



>
>> On 12/10/2014 12:57 PM, Chris Card wrote:
> thanks Martin,
>>> I've installed freeipa 4.1.1 on Fedora 21, and successfully set up a freeipa server and a freeipa client machine.
>>> I've set up a user with ssh keys, and can successfully ssh onto the client machine.
>>> I'm trying to setup sudo rules so that if the user is in a given user group, then the user can run "sudo su -" on the client to become root.
> <snip>
>>> [root at fedora21-freeipa log]# ipa hostgroup-show
>>> Host-group: cog
>>> Host-group: cog
>>> Member hosts: ipaclient21.testdomain21.com
>>> Member of Sudo rule: All
>>> [root at fedora21-freeipa log]# ipa sudorule-show All
>>> Rule name: All
>>> Enabled: TRUE
>>> Command category: all
>>> RunAs User category: all
>>> RunAs Group category: all
>>> User Groups: cog_rw
>>> Host Groups: cog
>>> Sudo Option: !authenticate
>>>
>>> but this setup doesn't work, i.e. even though the user is in the user group and the client machine is in the host group, sudo su - fails. Is this a bug, or have I missed something?
>>>
>>> Chris
>>>
>>>
>>>
>>
>> With FreeIPA 4.1.1, client sudo integration should be automatically configured,
>> so it should just work, including hostgroups. In your case, I would start with
>> investigating
>>
>> http://www.freeipa.org/page/Troubleshooting#sudo_does_not_work_for_hostgroups
>>
>> If that does not help, I bet SSSD devs will ask for logs.
>>
> I've done the troubleshooting steps:
>
> [root at ipaclient21 log]# nisdomainname
> testdomain21.com
> [root at ipaclient21 log]# getent netgroup cog
> cog (ipaclient21.testdomain21.com,-,testdomain21.com)
>
> I tried adding sudoers_debug 2 to /etc/sudo-ldap.conf on the client machine, but I'm not sure if that's the right file (it didn't exist before).
> I have debug_level set to 9 in /etc/sssd/sssd.conf, so I can see some stuff in /var/log/sssd/sssd_testdomain21.com.log but no obvious error messages.

I worked out how to set up debug for sudo. sudoers_debug is deprecated now, but I created /etc/sssd.conf with a line

Debug sudo /var/log/sudo_debug all at debug

and I saw this in the debug output:

Dec 10 15:42:57 sudo[10046] -> sudo_sss_check_host @ ./sssd.c:557
Dec 10 15:42:57 sudo[10046] val[0]=+cog?
Dec 10 15:42:57 sudo[10046] -> addr_matches @ ./match_addr.c:189
Dec 10 15:42:57 sudo[10046] -> addr_matches_if @ ./match_addr.c:61
Dec 10 15:42:57 sudo[10046] <- addr_matches_if @ ./match_addr.c:99 := false
Dec 10 15:42:57 sudo[10046] <- addr_matches @ ./match_addr.c:199 := false
Dec 10 15:42:57 sudo[10046] -> netgr_matches @ ./match.c:899
Dec 10 15:42:57 sudo[10046] <- netgr_matches @ ./match.c:918 := false
Dec 10 15:42:57 sudo[10046] -> hostname_matches @ ./match.c:758
Dec 10 15:42:57 sudo[10046] <- hostname_matches @ ./match.c:769 := false
Dec 10 15:42:57 sudo[10046] sssd/ldap sudoHost '+cog' ... not

The problem is that the hostname command on the client was returning a short hostname, ipaclient21, instead of a FQDN, ipaclient21.testdomain21.com and when I forced the hostname to be the FQDN the sudo command worked.

The short hostname comes from the fact that the client machine is an openstack instance, and that appears to be a feature of openstack instances :(

Chris 		 	   		  



From simo at redhat.com  Wed Dec 10 17:43:51 2014
From: simo at redhat.com (Simo Sorce)
Date: Wed, 10 Dec 2014 12:43:51 -0500
Subject: [Freeipa-users] freeipa / sudo
In-Reply-To: <DUB125-W16B0DB66FBF254466DC9FDCC620@phx.gbl>
References: <DUB125-W16B0DB66FBF254466DC9FDCC620@phx.gbl>
Message-ID: <20141210124351.060c9cfa@willson.usersys.redhat.com>

On Wed, 10 Dec 2014 11:57:26 +0000
Chris Card <ctcard at hotmail.com> wrote:

> Hi,
> I've installed freeipa 4.1.1 on Fedora 21, and successfully set up a
> freeipa server and a freeipa client machine. I've set up a user with
> ssh keys, and can successfully ssh onto the client machine. I'm
> trying to setup sudo rules so that if the user is in a given user
> group, then the user can run "sudo su -" on the client to become root.

FWIW you should probably use just sudo -i it will avoid authorization
issues to run the su service.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York



From nagemnna at gmail.com  Wed Dec 10 19:10:21 2014
From: nagemnna at gmail.com (Megan .)
Date: Wed, 10 Dec 2014 14:10:21 -0500
Subject: [Freeipa-users] can't register new clients
In-Reply-To: <548801FE.1080901@redhat.com>
References: <CACMA5-xsgZ2RcF7rx9MS+jtxpyMOofhpU0MnPn+1mcmHGOxNkg@mail.gmail.com>
	<54821AA7.1000007@redhat.com> <54821D9B.80502@redhat.com>
	<CACMA5-xs3gOMAdjg3o5aG6d58d-CvqPh5k9yo23pLSD9uXAq9Q@mail.gmail.com>
	<548225F9.7010001@redhat.com>
	<CACMA5-w=BmD+=9Gj7Q=U0oheEQOb40zfdzST_ASixiuKs5TqHA@mail.gmail.com>
	<54822D6D.1050807@redhat.com>
	<CACMA5-z+rt0e7tkf_UY5L_YzbQNcmRrNbNDQv3H01a=O9sXmxg@mail.gmail.com>
	<CACMA5-wY7+ceQm8GOT11=8MttRgNcZfsS8sg8X25AOMfo+22Jg@mail.gmail.com>
	<5486BE72.5020506@redhat.com>
	<CACMA5-wOWDtgXDZU+3CXjtVcxmMm_43Yj6sHj1WF5PGVq5M35Q@mail.gmail.com>
	<548701A0.8000507@redhat.com>
	<CACMA5-xNNid1-em7i5QDNaFE47aXxhEDBYg8w71MeMPLhNsHDg@mail.gmail.com>
	<548801FE.1080901@redhat.com>
Message-ID: <CACMA5-x9MvYUM_3SJ5kGomAetMep+QOiNc-=Tdc0iG9yObAz9g@mail.gmail.com>

Ok, Thank you for the information.

During the restore i ran into
https://fedorahosted.org/freeipa/ticket/4726 and sudo -u apache
kdestroy fixed it.  I think there was also something else minor that i
was able to fix by running a command differently.

I had two clients that I HAD to get online due to a deadline, so i
manually configured the clients using
(http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/linux-manual.html)
and they work fine now.

I have a third client that I'm working with where i have some more
time.  This one is on the same VLAN as the directory server, so that
eliminates and network related issues as a possibility.


I ran

openssl s_client -host dir1.example.com -port 443 -CAfile ca.crt

against the ca.crt that was left from the failed install and it looks
fine.  I might try to regenerate the certificate and see if that helps
although it looks like a real pain for verso 3 according to
http://www.freeipa.org/page/Howto/CA_Certificate_Renewal#Procedure_in_IPA_.3C_4.0


[root at walker ipa]# openssl s_client -host dir1.example.com -port 443
-CAfile ca.crt
CONNECTED(00000003)
depth=1 O = example.com, CN = Certificate Authority
verify error:num=19:self signed certificate in certificate chain
verify return:0
---
Certificate chain
 0 s:/O=example.com/CN=dir1.example.com
   i:/O=example.com/CN=Certificate Authority
 1 s:/O=example.com/CN=Certificate Authority
   i:/O=example.com/CN=Certificate Authority
---
Server certificate
-----BEGIN CERTIFICATE-----
Masdfasdf more stuff here
-----END CERTIFICATE-----
subject=/O=example.com/CN=dir1.example.com
issuer=/O=example.com/CN=Certificate Authority
---
No client certificate CA names sent
---
SSL handshake has read 2095 bytes and written 591 bytes
---
New, TLSv1/SSLv3, Cipher is AES128-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1.1
    Cipher    : AES128-SHA
    Session-ID:
22BBDF13AA4DDFFF7562A624D0A6B1B35B9999CE727FD59AFF1572B4928851DFB91B
    Session-ID-ctx:
    Master-Key:
9EF37866161FD89469DD5631744051123456788F5C035CB8F5E8A85F9B2FAAE96698F48559D1338C42B4F20FC
    Key-Arg   : None
    Krb5 Principal: None
    PSK identity: None
    PSK identity hint: None
    Start Time: 1418237923
    Timeout   : 300 (sec)
    Verify return code: 19 (self signed certificate in certificate chain)
---

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>301 Moved Permanently</title>
</head><body>
<h1>Moved Permanently</h1>
<p>The document has moved <a
href="https://dir1.example.com/ipa/ui">here</a>.</p>
<hr>
<address>Apache/2.2.15 (CentOS) Server at dir1.example.com Port 443</address>
</body></html>
closed

On Wed, Dec 10, 2014 at 3:19 AM, Martin Kosek <mkosek at redhat.com> wrote:
> On 12/09/2014 03:57 PM, Megan . wrote:
>> This is happening with all new clients.  I had to rebuild the LDAP
>> server onto new hardware and the network team put us on a new VLAN.
>> so my physical server and IP changed.  I was previously able to
>> register clients, but after all of the changes, i can no longer
>> register them.  At this point i'm not sure if there is a network issue
>> or something wrong with the IPA server.  The existing clients are
>> communicating fine, no errors or complains.  I have two new clients to
>> add and both have the same symptoms.
>>
>> I used these procedures to backup then restore onto the new host
>> http://www.freeipa.org/page/V3/Backup_and_Restore
>>
>> To change the IP i just updated /etc/hosts and pushed it out to the clients
>
> This may be related. Did the backup and restore really go correctly? AFAIK,
> this feature did not go through more heavy testing in the community yet, so
> there may be rough edges. There were several bug fixes to backup and restore
> scripts in FreeIPA 4.1.x releases already.
>
> But if the hostname is the same, A/AAAA and PTR DNS records are still valid and
> your other clients work fine, it should be OK.
>
> So you are saying that installation still fails with the NSS error -8054? I am
> thinking that the next step should be to run ipa-client-install with --force
> flag to make sure that it does not clean the certificate downloaded from LDAP
> and check that the cert downloaded to /ect/ipa/ca.crt is indeed OK (you already
> tested the one downloaded by wget, but theoretically, the one in LDAP could be
> different).
>
>> On Tue, Dec 9, 2014 at 9:05 AM, Rob Crittenden <rcritten at redhat.com> wrote:
>>> Megan . wrote:
>>>> Everything looks ok.
>>>>
>>>> Our Networks team only opened 443 from the client to the server.  is
>>>> 80 required to be open too for registration?  80 is a lot harder for
>>>> me to request on our network.
>>>>
>>>> I think I might have found the issue.  Maybe it can't verify the CA
>>>> because its pointing to port 80, and 80 isn't open.  Is it possible to
>>>> change the certificate so this information is available via 443 or
>>>> does that not make sense since its trying to get information about the
>>>> secure connection in the first place.
>>>
>>> I don't think port 80 is the problem and in any case, it is just a
>>> fallback in case the client can't get it via LDAP which in new installs
>>> shouldn't be an issue. You'd get an error that the CA couldn't be
>>> retrieved at all and not that a duplicate serial existed.
>>>
>>> Is this happening on every client or just one?
>>>
>>> Did you have a previous IPA install and you are re-enrolling this
>>> client(s) into the new one?
>>>
>>> rob
>>>
>>>>
>>>> from the server:
>>>> [root at dir1 ipa]# openssl verify -verbose -CAFile ca.crt
>>>> .
>>>> .
>>>>             Authority Information Access:
>>>>                 OCSP - URI:http://dir1.example.com:80/ca/ocsp
>>>> .
>>>>
>>>>
>>>>
>>>> [root at data2-uat ipa]# wget https://dir1.example.com/ipa/config/ca.crt
>>>> -O /tmp/ipa.crt
>>>> --2014-12-09 13:21:32--  https://dir1.example.com/ipa/config/ca.crt
>>>> Resolving dir1.example.com... 172.28.27.170
>>>> Connecting to dir1.example.com|172.28.27.170|:443... connected.
>>>> ERROR: cannot verify dir1.example.com?s certificate, issued by
>>>> ?/O=EXAMPLE.COM/CN=Certificate Authority?:
>>>>   Self-signed certificate encountered.
>>>> To connect to dir1.example.com insecurely, use ?--no-check-certificate?.
>>>> [root at data2-uat ipa]# wget https://dir1.example.com/ipa/config/ca.crt
>>>> -O /tmp/ipa.crt --no-check-certificate
>>>> --2014-12-09 13:22:11--  https://dir1.example.com/ipa/config/ca.crt
>>>> Resolving dir1.example.com... 172.28.27.170
>>>> Connecting to dir1.example.com|172.28.27.170|:443... connected.
>>>> WARNING: cannot verify dir1.example.com?s certificate, issued by
>>>> ?/O=EXAMPLE.COM/CN=Certificate Authority?:
>>>>   Self-signed certificate encountered.
>>>> HTTP request sent, awaiting response... 200 OK
>>>> Length: 1357 (1.3K) [application/x-x509-ca-cert]
>>>> Saving to: ?/tmp/ipa.crt?
>>>>
>>>> 100%[================================================>] 1,357
>>>> --.-K/s   in 0.005s
>>>>
>>>> 2014-12-09 13:22:11 (246 KB/s) - ?/tmp/ipa.crt? saved [1357/1357]
>>>>
>>>> [root at data2-uat ipa]# cd /tmp
>>>> [root at data2-uat tmp]# openssl s_client -host dir1.example.com  -port
>>>> 443 -CAfile /tmp/ipa.crt
>>>> CONNECTED(00000003)
>>>> depth=1 O = EXAMPLE.COM, CN = Certificate Authority
>>>> verify return:1
>>>> depth=0 O = EXAMPLE.COM, CN = dir1.example.com
>>>> verify return:1
>>>> ---
>>>> Certificate chain
>>>>  0 s:/O=EXAMPLE.COM/CN=dir1.example.com
>>>>    i:/O=EXAMPLE.COM/CN=Certificate Authority
>>>>  1 s:/O=EXAMPLE.COM/CN=Certificate Authority
>>>>    i:/O=EXAMPLE.COM/CN=Certificate Authority
>>>> ---
>>>> Server certificate
>>>> -----BEGIN CERTIFICATE-----
>>>> ...
>>>> -----END CERTIFICATE-----
>>>> subject=/O=EXAMPLE.COM/CN=dir1.example.com
>>>> issuer=/O=EXAMPLE.COM/CN=Certificate Authority
>>>> ---
>>>> No client certificate CA names sent
>>>> ---
>>>> SSL handshake has read 2095 bytes and written 591 bytes
>>>> ---
>>>> New, TLSv1/SSLv3, Cipher is AES128-SHA
>>>> Server public key is 2048 bit
>>>> Secure Renegotiation IS supported
>>>> Compression: NONE
>>>> Expansion: NONE
>>>> SSL-Session:
>>>>     Protocol  : TLSv1.1
>>>>     Cipher    : AES128-SHA
>>>>     Session-ID: F6A664BC942DF235EF546007379A79A00245G34FA7C0E6F191B911E9CFEC17D0
>>>>     Session-ID-ctx:
>>>>     Master-Key:
>>>> 8C9A5FB1DFDDA72FF09780A85A43FA3C1AA14D4FB199F510A0DC3DF0C53DFFFFCDD0F26211CA886342E84030EA891959
>>>>     Key-Arg   : None
>>>>     Krb5 Principal: None
>>>>     PSK identity: None
>>>>     PSK identity hint: None
>>>>     Start Time: 1418131359
>>>>     Timeout   : 300 (sec)
>>>>     Verify return code: 0 (ok)
>>>> ---
>>>> closed
>>>>
>>>> On Tue, Dec 9, 2014 at 4:18 AM, Martin Kosek <mkosek at redhat.com> wrote:
>>>>> On 12/08/2014 08:00 PM, Megan . wrote:
>>>>>> I looked through the logs on the server and i see the below error in
>>>>>> the apache error log when i try to register a client:
>>>>>>
>>>>>> [Mon Dec 08 12:20:38 2014] [error] SSL Library Error: -12195 Peer does
>>>>>> not recognize and trust the CA that issued your certificate
>>>>>>
>>>>>>
>>>>>> I ran ipa-getcert list and everything seems ok (nothing expired) but
>>>>>> i'm not sure where to troubleshoot from here.
>>>>>
>>>>> The next step would be to check the actual HTTP certificate (on the client
>>>>> machine) and see what's wrong. I did a simple test you can follow:
>>>>>
>>>>> # wget http://ipa.mkosek-f21.test/ipa/config/ca.crt -O /tmp/ipa.crt
>>>>> # openssl s_client -host ipa.mkosek-f21.test -port 443 -CAfile /tmp/ipa.crt
>>>>> CONNECTED(00000003)
>>>>> depth=1 O = MKOSEK-F21.TEST, CN = Certificate Authority
>>>>> verify return:1
>>>>> depth=0 O = MKOSEK-F21.TEST, CN = ipa.mkosek-f21.test
>>>>> verify return:1
>>>>> ---
>>>>> Certificate chain
>>>>>  0 s:/O=MKOSEK-F21.TEST/CN=ipa.mkosek-f21.test
>>>>>    i:/O=MKOSEK-F21.TEST/CN=Certificate Authority
>>>>>  1 s:/O=MKOSEK-F21.TEST/CN=Certificate Authority
>>>>>    i:/O=MKOSEK-F21.TEST/CN=Certificate Authority
>>>>> ---
>>>>> Server certificate
>>>>> ...
>>>>> SSL-Session:
>>>>>     Protocol  : TLSv1.2
>>>>>     Cipher    : AES128-SHA
>>>>>     Session-ID: 5A4B326D2E8FB80408D628D1975C49C4F78D3E65F31E475F9E7B9BBBE11F576E
>>>>>     Session-ID-ctx:
>>>>>     Master-Key:
>>>>> D5C31E9E36503ADC9F162439B41A7A608260D7DF5EB357FB3D79C9CFAE700912526893E7DD9AA56F5B6CD320FBA98C49
>>>>>     Key-Arg   : None
>>>>>     Krb5 Principal: None
>>>>>     PSK identity: None
>>>>>     PSK identity hint: None
>>>>>     Start Time: 1418073191
>>>>>     Timeout   : 300 (sec)
>>>>>     Verify return code: 0 (ok)
>>>>> ---
>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Fri, Dec 5, 2014 at 7:51 PM, Megan . <nagemnna at gmail.com> wrote:
>>>>>>> It failed again.
>>>>>>>
>>>>>>>
>>>>>>> [root at cache2-uat ~]# certutil -L -d sql:/etc/pki/nssdb
>>>>>>>
>>>>>>> Certificate Nickname                                         Trust Attributes
>>>>>>>                                                              SSL,S/MIME,JAR/XPI
>>>>>>> [root at cache2-uat ~]#
>>>>>>>
>>>>>>> Not sure if its related, but on the directory server in the apache
>>>>>>> error.log I see the below every time a client tries to register:
>>>>>>>
>>>>>>> [Sat Dec 06 00:48:35 2014] [error] SSL Library Error: -12271 SSL
>>>>>>> client cannot verify your certificate
>>>>>>>
>>>>>>> On the directory server i ran ipa-getcert list and the certs seem ok.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Dec 5, 2014 at 5:10 PM, Rob Crittenden <rcritten at redhat.com> wrote:
>>>>>>>> Megan . wrote:
>>>>>>>>> Sorry for being unclear. It still fails.  Same error.
>>>>>>>>
>>>>>>>> Hmm, strange. Try being explicit about sql:
>>>>>>>>
>>>>>>>> # certutil -L -d sql:/etc/pki/nssdb
>>>>>>>>
>>>>>>>> And if there is a CA cert there, delete it.
>>>>>>>>
>>>>>>>> rob
>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Dec 5, 2014 4:39 PM, "Rob Crittenden" <rcritten at redhat.com
>>>>>>>>> <mailto:rcritten at redhat.com>> wrote:
>>>>>>>>>
>>>>>>>>>     Megan . wrote:
>>>>>>>>>     > Thanks.
>>>>>>>>>     >
>>>>>>>>>     > I did have an issue last week where i tried to do the client install
>>>>>>>>>     > and it failed because of a firewall issue.  Networks has it opened
>>>>>>>>>     > now.  I deleted ca.crt before trying again.  There doesn't seem to be
>>>>>>>>>     > a certificate in /etc/pki/nssdb for it.
>>>>>>>>>     >
>>>>>>>>>     >
>>>>>>>>>     >
>>>>>>>>>     > [root at data2-uat ipa]# certutil -L -d /etc/pki/nssdb
>>>>>>>>>     >
>>>>>>>>>     >
>>>>>>>>>     > Certificate Nickname                                         Trust
>>>>>>>>>     Attributes
>>>>>>>>>     >
>>>>>>>>>     >
>>>>>>>>>     SSL,S/MIME,JAR/XPI
>>>>>>>>>     >
>>>>>>>>>     >
>>>>>>>>>     > [root at data2-uat ipa]# certutil -D -n 'IPA CA' -d /etc/pki/nssdb
>>>>>>>>>     >
>>>>>>>>>     > certutil: could not find certificate named "IPA CA":
>>>>>>>>>     > SEC_ERROR_BAD_DATABASE: security library: bad database.
>>>>>>>>>     >
>>>>>>>>>     > [root at data2-uat ipa]# ls
>>>>>>>>>     >
>>>>>>>>>     > [root at data2-uat ipa]# pwd
>>>>>>>>>     >
>>>>>>>>>     > /etc/ipa
>>>>>>>>>     >
>>>>>>>>>     > [root at data2-uat ipa]# ls -al
>>>>>>>>>     >
>>>>>>>>>     > total 16
>>>>>>>>>     >
>>>>>>>>>     > drwxr-xr-x.  2 root root  4096 Dec  5 21:16 .
>>>>>>>>>     >
>>>>>>>>>     > drwxr-xr-x. 82 root root 12288 Dec  5 21:16 ..
>>>>>>>>>     >
>>>>>>>>>     > [root at data2-uat ipa]#
>>>>>>>>>
>>>>>>>>>     So trying to install the client again fails or succeeds now?
>>>>>>>>>
>>>>>>>>>     rob
>>>>>>>>>
>>>>>>>>>     >
>>>>>>>>>     > On Fri, Dec 5, 2014 at 4:03 PM, Rob Crittenden
>>>>>>>>>     <rcritten at redhat.com <mailto:rcritten at redhat.com>> wrote:
>>>>>>>>>     >> Rob Crittenden wrote:
>>>>>>>>>     >>> Megan . wrote:
>>>>>>>>>     >>>> Good Day!
>>>>>>>>>     >>>>
>>>>>>>>>     >>>> I am getting an error when i register new clients.
>>>>>>>>>     >>>>
>>>>>>>>>     >>>> libcurl failed to execute the HTTP POST transaction.  SSL
>>>>>>>>>     connect error
>>>>>>>>>     >>>>
>>>>>>>>>     >>>> I can't find anything useful not the internet about the error.  Can
>>>>>>>>>     >>>> someone help me troubleshoot?
>>>>>>>>>     >>>>
>>>>>>>>>     >>>> CentOS 6.6  x64
>>>>>>>>>     >>>> ipa-client-3.0.0-42.el6.centos.x86_64
>>>>>>>>>     >>>> ipa-server-3.0.0-42.el6.centos.x86_64
>>>>>>>>>     >>>> curl-7.19.7-40.el6_6.1.x86_64
>>>>>>>>>     >>>
>>>>>>>>>     >>> Do you have NSS_DEFAULT_DB_TYPE set to sql? I don't know that
>>>>>>>>>     we've done
>>>>>>>>>     >>> any testing on the client with this set.
>>>>>>>>>     >>
>>>>>>>>>     >> Never mind, that's not it. The problem is:
>>>>>>>>>     >>
>>>>>>>>>     >> * NSS error -8054
>>>>>>>>>     >>
>>>>>>>>>     >> Which is SEC_ERROR_REUSED_ISSUER_AND_SERIAL
>>>>>>>>>     >>
>>>>>>>>>     >> So I'd do this:
>>>>>>>>>     >>
>>>>>>>>>     >> # rm /etc/ipa/ca.crt
>>>>>>>>>     >>
>>>>>>>>>     >> You may also want to ensure that the IPA CA certificate isn't in
>>>>>>>>>     >> /etc/pki/nssdb:
>>>>>>>>>     >>
>>>>>>>>>     >> # certutil -L -d /etc/pki/nssdb
>>>>>>>>>     >>
>>>>>>>>>     >> And then perhaps
>>>>>>>>>     >>
>>>>>>>>>     >> # certutil -D -n 'IPA CA' -d /etc/pki/nssdb
>>>>>>>>>     >>
>>>>>>>>>     >> rob
>>>>>>>>>     >>
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>



From dpal at redhat.com  Wed Dec 10 19:20:31 2014
From: dpal at redhat.com (Dmitri Pal)
Date: Wed, 10 Dec 2014 14:20:31 -0500
Subject: [Freeipa-users] vSphere 5.1 and FreeIPA 3.3 on CentOS 7 finally
 works! [How I did it...]
In-Reply-To: <CAG2kNCyMr00bjoZLzs_WmwE4LXRSZAq5ppn6D5O1Cv0ND41mLQ@mail.gmail.com>
References: <CAG2kNCyXWXxMx0V96bYgMq--9zaBwhWMBENrOgSXnMMr9=F85Q@mail.gmail.com>	<5485E119.10203@redhat.com>	<CAG2kNCyWUhbVZUbpo0rgE_NAucs5S4x6_dj4JcCXTNWyLNSAFw@mail.gmail.com>	<CAG2kNCyj=b4c-5C59uvba37hoXwX8rHmtE9DC1vbKk+YM5p1ZQ@mail.gmail.com>	<5486C602.80106@redhat.com>
	<CAG2kNCyMr00bjoZLzs_WmwE4LXRSZAq5ppn6D5O1Cv0ND41mLQ@mail.gmail.com>
Message-ID: <54889CFF.3020500@redhat.com>

On 12/10/2014 06:55 AM, Gianluca Cecchi wrote:
> On Tue, Dec 9, 2014 at 10:50 AM, Martin Kosek <mkosek at redhat.com 
> <mailto:mkosek at redhat.com>> wrote:
>
>     On 12/09/2014 12:50 AM, Gianluca Cecchi wrote:
>     > On Mon, Dec 8, 2014 at 7:17 PM, Gianluca Cecchi
>     <gianluca.cecchi at gmail.com <mailto:gianluca.cecchi at gmail.com>>
>     > wrote:
>     >
>     >> OK. I will check requirements to write into The wiki
>     >>
>
>
> Hello,
> now I was able to login and I created this draft page, you can check 
> and feel free to review...
> http://www.freeipa.org/page/HowTo/vsphere5_integration
I scanned the page.
Looks good. Thanks a lot!

I hope someone with the similar use case can verify the steps.

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141210/a8f7b4cc/attachment.htm>

From mkosek at redhat.com  Thu Dec 11 07:02:45 2014
From: mkosek at redhat.com (Martin Kosek)
Date: Thu, 11 Dec 2014 08:02:45 +0100
Subject: [Freeipa-users] freeipa / sudo
In-Reply-To: <DUB125-W696A68B0EABE4DB4889F64CC620@phx.gbl>
References: <DUB125-W16B0DB66FBF254466DC9FDCC620@phx.gbl>, ,
	<5488362D.4040609@redhat.com>,
	<DUB125-W201847FB050F16A133931CC620@phx.gbl>
	<DUB125-W696A68B0EABE4DB4889F64CC620@phx.gbl>
Message-ID: <54894195.5090708@redhat.com>

On 12/10/2014 04:54 PM, Chris Card wrote:
> 
> 
>>
>>> On 12/10/2014 12:57 PM, Chris Card wrote:
>> thanks Martin,
>>>> I've installed freeipa 4.1.1 on Fedora 21, and successfully set up a freeipa server and a freeipa client machine.
>>>> I've set up a user with ssh keys, and can successfully ssh onto the client machine.
>>>> I'm trying to setup sudo rules so that if the user is in a given user group, then the user can run "sudo su -" on the client to become root.
>> <snip>
>>>> [root at fedora21-freeipa log]# ipa hostgroup-show
>>>> Host-group: cog
>>>> Host-group: cog
>>>> Member hosts: ipaclient21.testdomain21.com
>>>> Member of Sudo rule: All
>>>> [root at fedora21-freeipa log]# ipa sudorule-show All
>>>> Rule name: All
>>>> Enabled: TRUE
>>>> Command category: all
>>>> RunAs User category: all
>>>> RunAs Group category: all
>>>> User Groups: cog_rw
>>>> Host Groups: cog
>>>> Sudo Option: !authenticate
>>>>
>>>> but this setup doesn't work, i.e. even though the user is in the user group and the client machine is in the host group, sudo su - fails. Is this a bug, or have I missed something?
>>>>
>>>> Chris
>>>>
>>>>
>>>>
>>>
>>> With FreeIPA 4.1.1, client sudo integration should be automatically configured,
>>> so it should just work, including hostgroups. In your case, I would start with
>>> investigating
>>>
>>> http://www.freeipa.org/page/Troubleshooting#sudo_does_not_work_for_hostgroups
>>>
>>> If that does not help, I bet SSSD devs will ask for logs.
>>>
>> I've done the troubleshooting steps:
>>
>> [root at ipaclient21 log]# nisdomainname
>> testdomain21.com
>> [root at ipaclient21 log]# getent netgroup cog
>> cog (ipaclient21.testdomain21.com,-,testdomain21.com)
>>
>> I tried adding sudoers_debug 2 to /etc/sudo-ldap.conf on the client machine, but I'm not sure if that's the right file (it didn't exist before).
>> I have debug_level set to 9 in /etc/sssd/sssd.conf, so I can see some stuff in /var/log/sssd/sssd_testdomain21.com.log but no obvious error messages.
> 
> I worked out how to set up debug for sudo. sudoers_debug is deprecated now, but I created /etc/sssd.conf with a line
> 
> Debug sudo /var/log/sudo_debug all at debug
> 
> and I saw this in the debug output:
> 
> Dec 10 15:42:57 sudo[10046] -> sudo_sss_check_host @ ./sssd.c:557
> Dec 10 15:42:57 sudo[10046] val[0]=+cog 
> Dec 10 15:42:57 sudo[10046] -> addr_matches @ ./match_addr.c:189
> Dec 10 15:42:57 sudo[10046] -> addr_matches_if @ ./match_addr.c:61
> Dec 10 15:42:57 sudo[10046] <- addr_matches_if @ ./match_addr.c:99 := false
> Dec 10 15:42:57 sudo[10046] <- addr_matches @ ./match_addr.c:199 := false
> Dec 10 15:42:57 sudo[10046] -> netgr_matches @ ./match.c:899
> Dec 10 15:42:57 sudo[10046] <- netgr_matches @ ./match.c:918 := false
> Dec 10 15:42:57 sudo[10046] -> hostname_matches @ ./match.c:758
> Dec 10 15:42:57 sudo[10046] <- hostname_matches @ ./match.c:769 := false
> Dec 10 15:42:57 sudo[10046] sssd/ldap sudoHost '+cog' ... not
> 
> The problem is that the hostname command on the client was returning a short hostname, ipaclient21, instead of a FQDN, ipaclient21.testdomain21.com and when I forced the hostname to be the FQDN the sudo command worked.
>
>
> The short hostname comes from the fact that the client machine is an openstack instance, and that appears to be a feature of openstack instances :(


So on the OpenStack instance, even "hostname -f" does not show the FQDN? If
this is the case, I am not sure what we could do, sudo somehow needs to learn
the FQDN.



From ctcard at hotmail.com  Thu Dec 11 08:42:20 2014
From: ctcard at hotmail.com (Chris Card)
Date: Thu, 11 Dec 2014 08:42:20 +0000
Subject: [Freeipa-users] freeipa / sudo
In-Reply-To: <54894195.5090708@redhat.com>
References: <DUB125-W16B0DB66FBF254466DC9FDCC620@phx.gbl>, ,
	<5488362D.4040609@redhat.com>,
	<DUB125-W201847FB050F16A133931CC620@phx.gbl>
	<DUB125-W696A68B0EABE4DB4889F64CC620@phx.gbl>,
	<54894195.5090708@redhat.com>
Message-ID: <DUB125-W316148DDC6B645481224CFCC630@phx.gbl>


> On 12/10/2014 04:54 PM, Chris Card wrote:
>>
>>
>>>
>>>> On 12/10/2014 12:57 PM, Chris Card wrote:
>>> thanks Martin,
>>>>> I've installed freeipa 4.1.1 on Fedora 21, and successfully set up a freeipa server and a freeipa client machine.
>>>>> I've set up a user with ssh keys, and can successfully ssh onto the client machine.
>>>>> I'm trying to setup sudo rules so that if the user is in a given user group, then the user can run "sudo su -" on the client to become root.
>>> <snip>
>>>>> [root at fedora21-freeipa log]# ipa hostgroup-show
>>>>> Host-group: cog
>>>>> Host-group: cog
>>>>> Member hosts: ipaclient21.testdomain21.com
>>>>> Member of Sudo rule: All
>>>>> [root at fedora21-freeipa log]# ipa sudorule-show All
>>>>> Rule name: All
>>>>> Enabled: TRUE
>>>>> Command category: all
>>>>> RunAs User category: all
>>>>> RunAs Group category: all
>>>>> User Groups: cog_rw
>>>>> Host Groups: cog
>>>>> Sudo Option: !authenticate
>>>>>
>>>>> but this setup doesn't work, i.e. even though the user is in the user group and the client machine is in the host group, sudo su - fails. Is this a bug, or have I missed something?
>>>>>
>>>>> Chris
>>>>>
>>>>>
>>>>>
>>>>
>>>> With FreeIPA 4.1.1, client sudo integration should be automatically configured,
>>>> so it should just work, including hostgroups. In your case, I would start with
>>>> investigating
>>>>
>>>> http://www.freeipa.org/page/Troubleshooting#sudo_does_not_work_for_hostgroups
>>>>
>>>> If that does not help, I bet SSSD devs will ask for logs.
>>>>
>>> I've done the troubleshooting steps:
>>>
>>> [root at ipaclient21 log]# nisdomainname
>>> testdomain21.com
>>> [root at ipaclient21 log]# getent netgroup cog
>>> cog (ipaclient21.testdomain21.com,-,testdomain21.com)
>>>
>>> I tried adding sudoers_debug 2 to /etc/sudo-ldap.conf on the client machine, but I'm not sure if that's the right file (it didn't exist before).
>>> I have debug_level set to 9 in /etc/sssd/sssd.conf, so I can see some stuff in /var/log/sssd/sssd_testdomain21.com.log but no obvious error messages.
>>
>> I worked out how to set up debug for sudo. sudoers_debug is deprecated now, but I created /etc/sssd.conf with a line
>>
>> Debug sudo /var/log/sudo_debug all at debug
>>
>> and I saw this in the debug output:
>>
>> Dec 10 15:42:57 sudo[10046] -> sudo_sss_check_host @ ./sssd.c:557
>> Dec 10 15:42:57 sudo[10046] val[0]=+cog
>> Dec 10 15:42:57 sudo[10046] -> addr_matches @ ./match_addr.c:189
>> Dec 10 15:42:57 sudo[10046] -> addr_matches_if @ ./match_addr.c:61
>> Dec 10 15:42:57 sudo[10046] <- addr_matches_if @ ./match_addr.c:99 := false
>> Dec 10 15:42:57 sudo[10046] <- addr_matches @ ./match_addr.c:199 := false
>> Dec 10 15:42:57 sudo[10046] -> netgr_matches @ ./match.c:899
>> Dec 10 15:42:57 sudo[10046] <- netgr_matches @ ./match.c:918 := false
>> Dec 10 15:42:57 sudo[10046] -> hostname_matches @ ./match.c:758
>> Dec 10 15:42:57 sudo[10046] <- hostname_matches @ ./match.c:769 := false
>> Dec 10 15:42:57 sudo[10046] sssd/ldap sudoHost '+cog' ... not
>>
>> The problem is that the hostname command on the client was returning a short hostname, ipaclient21, instead of a FQDN, ipaclient21.testdomain21.com and when I forced the hostname to be the FQDN the sudo command worked.
>>
>>
>> The short hostname comes from the fact that the client machine is an openstack instance, and that appears to be a feature of openstack instances :(
>
>
> So on the OpenStack instance, even "hostname -f" does not show the FQDN? If
> this is the case, I am not sure what we could do, sudo somehow needs to learn
> the FQDN.
>
I can set up the instance so that hostname -f returns the FQDN, but the only way I can get hostname to return the FQDN is if I explicitly run "hostname <FQDN>"; unfortunately this doesn't survive a reboot.

Chris 		 	   		  



From pspacek at redhat.com  Thu Dec 11 09:19:59 2014
From: pspacek at redhat.com (Petr Spacek)
Date: Thu, 11 Dec 2014 10:19:59 +0100
Subject: [Freeipa-users] vSphere 5.1 and FreeIPA 3.3 on CentOS 7 finally
 works! [How I did it...]
In-Reply-To: <54889CFF.3020500@redhat.com>
References: <CAG2kNCyXWXxMx0V96bYgMq--9zaBwhWMBENrOgSXnMMr9=F85Q@mail.gmail.com>	<5485E119.10203@redhat.com>	<CAG2kNCyWUhbVZUbpo0rgE_NAucs5S4x6_dj4JcCXTNWyLNSAFw@mail.gmail.com>	<CAG2kNCyj=b4c-5C59uvba37hoXwX8rHmtE9DC1vbKk+YM5p1ZQ@mail.gmail.com>	<5486C602.80106@redhat.com>	<CAG2kNCyMr00bjoZLzs_WmwE4LXRSZAq5ppn6D5O1Cv0ND41mLQ@mail.gmail.com>
	<54889CFF.3020500@redhat.com>
Message-ID: <548961BF.3060800@redhat.com>

On 10.12.2014 20:20, Dmitri Pal wrote:
> On 12/10/2014 06:55 AM, Gianluca Cecchi wrote:
>> On Tue, Dec 9, 2014 at 10:50 AM, Martin Kosek <mkosek at redhat.com
>> <mailto:mkosek at redhat.com>> wrote:
>>
>>     On 12/09/2014 12:50 AM, Gianluca Cecchi wrote:
>>     > On Mon, Dec 8, 2014 at 7:17 PM, Gianluca Cecchi
>>     <gianluca.cecchi at gmail.com <mailto:gianluca.cecchi at gmail.com>>
>>     > wrote:
>>     >
>>     >> OK. I will check requirements to write into The wiki
>>     >>
>>
>>
>> Hello,
>> now I was able to login and I created this draft page, you can check and
>> feel free to review...
>> http://www.freeipa.org/page/HowTo/vsphere5_integration
> I scanned the page.
> Looks good. Thanks a lot!
> 
> I hope someone with the similar use case can verify the steps.

Link to the how-to was added to:
http://www.freeipa.org/page/HowTos#Virtualization

-- 
Petr^2 Spacek



From mkosek at redhat.com  Thu Dec 11 09:38:39 2014
From: mkosek at redhat.com (Martin Kosek)
Date: Thu, 11 Dec 2014 10:38:39 +0100
Subject: [Freeipa-users] freeipa / sudo
In-Reply-To: <DUB125-W316148DDC6B645481224CFCC630@phx.gbl>
References: <DUB125-W16B0DB66FBF254466DC9FDCC620@phx.gbl>, ,
	<5488362D.4040609@redhat.com>,
	<DUB125-W201847FB050F16A133931CC620@phx.gbl>
	<DUB125-W696A68B0EABE4DB4889F64CC620@phx.gbl>,
	<54894195.5090708@redhat.com>
	<DUB125-W316148DDC6B645481224CFCC630@phx.gbl>
Message-ID: <5489661F.8040203@redhat.com>

On 12/11/2014 09:42 AM, Chris Card wrote:
> 
>> On 12/10/2014 04:54 PM, Chris Card wrote:
>>>
>>>
>>>>
>>>>> On 12/10/2014 12:57 PM, Chris Card wrote:
>>>> thanks Martin,
>>>>>> I've installed freeipa 4.1.1 on Fedora 21, and successfully set up a freeipa server and a freeipa client machine.
>>>>>> I've set up a user with ssh keys, and can successfully ssh onto the client machine.
>>>>>> I'm trying to setup sudo rules so that if the user is in a given user group, then the user can run "sudo su -" on the client to become root.
>>>> <snip>
>>>>>> [root at fedora21-freeipa log]# ipa hostgroup-show
>>>>>> Host-group: cog
>>>>>> Host-group: cog
>>>>>> Member hosts: ipaclient21.testdomain21.com
>>>>>> Member of Sudo rule: All
>>>>>> [root at fedora21-freeipa log]# ipa sudorule-show All
>>>>>> Rule name: All
>>>>>> Enabled: TRUE
>>>>>> Command category: all
>>>>>> RunAs User category: all
>>>>>> RunAs Group category: all
>>>>>> User Groups: cog_rw
>>>>>> Host Groups: cog
>>>>>> Sudo Option: !authenticate
>>>>>>
>>>>>> but this setup doesn't work, i.e. even though the user is in the user group and the client machine is in the host group, sudo su - fails. Is this a bug, or have I missed something?
>>>>>>
>>>>>> Chris
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> With FreeIPA 4.1.1, client sudo integration should be automatically configured,
>>>>> so it should just work, including hostgroups. In your case, I would start with
>>>>> investigating
>>>>>
>>>>> http://www.freeipa.org/page/Troubleshooting#sudo_does_not_work_for_hostgroups
>>>>>
>>>>> If that does not help, I bet SSSD devs will ask for logs.
>>>>>
>>>> I've done the troubleshooting steps:
>>>>
>>>> [root at ipaclient21 log]# nisdomainname
>>>> testdomain21.com
>>>> [root at ipaclient21 log]# getent netgroup cog
>>>> cog (ipaclient21.testdomain21.com,-,testdomain21.com)
>>>>
>>>> I tried adding sudoers_debug 2 to /etc/sudo-ldap.conf on the client machine, but I'm not sure if that's the right file (it didn't exist before).
>>>> I have debug_level set to 9 in /etc/sssd/sssd.conf, so I can see some stuff in /var/log/sssd/sssd_testdomain21.com.log but no obvious error messages.
>>>
>>> I worked out how to set up debug for sudo. sudoers_debug is deprecated now, but I created /etc/sssd.conf with a line
>>>
>>> Debug sudo /var/log/sudo_debug all at debug
>>>
>>> and I saw this in the debug output:
>>>
>>> Dec 10 15:42:57 sudo[10046] -> sudo_sss_check_host @ ./sssd.c:557
>>> Dec 10 15:42:57 sudo[10046] val[0]=+cog
>>> Dec 10 15:42:57 sudo[10046] -> addr_matches @ ./match_addr.c:189
>>> Dec 10 15:42:57 sudo[10046] -> addr_matches_if @ ./match_addr.c:61
>>> Dec 10 15:42:57 sudo[10046] <- addr_matches_if @ ./match_addr.c:99 := false
>>> Dec 10 15:42:57 sudo[10046] <- addr_matches @ ./match_addr.c:199 := false
>>> Dec 10 15:42:57 sudo[10046] -> netgr_matches @ ./match.c:899
>>> Dec 10 15:42:57 sudo[10046] <- netgr_matches @ ./match.c:918 := false
>>> Dec 10 15:42:57 sudo[10046] -> hostname_matches @ ./match.c:758
>>> Dec 10 15:42:57 sudo[10046] <- hostname_matches @ ./match.c:769 := false
>>> Dec 10 15:42:57 sudo[10046] sssd/ldap sudoHost '+cog' ... not
>>>
>>> The problem is that the hostname command on the client was returning a short hostname, ipaclient21, instead of a FQDN, ipaclient21.testdomain21.com and when I forced the hostname to be the FQDN the sudo command worked.
>>>
>>>
>>> The short hostname comes from the fact that the client machine is an openstack instance, and that appears to be a feature of openstack instances :(
>>
>>
>> So on the OpenStack instance, even "hostname -f" does not show the FQDN? If
>> this is the case, I am not sure what we could do, sudo somehow needs to learn
>> the FQDN.
>>
> I can set up the instance so that hostname -f returns the FQDN, but the only way I can get hostname to return the FQDN is if I explicitly run "hostname <FQDN>"; unfortunately this doesn't survive a reboot.

You should be able to just set the hostname to /etc/hostname (for older
platforms, it may also be in /etc/sysconfig/network) and it should survive the
reboot. I do not think that OpenStack really cares that much what hostname did
you set up in the system after the VM is created.

At least my OpenStack VM with the FreeIPA demo works this way.

Martin



From gianluca.cecchi at gmail.com  Thu Dec 11 11:31:06 2014
From: gianluca.cecchi at gmail.com (Gianluca Cecchi)
Date: Thu, 11 Dec 2014 12:31:06 +0100
Subject: [Freeipa-users] vSphere 5.1 and FreeIPA 3.3 on CentOS 7 finally
 works! [How I did it...]
In-Reply-To: <548961BF.3060800@redhat.com>
References: <CAG2kNCyXWXxMx0V96bYgMq--9zaBwhWMBENrOgSXnMMr9=F85Q@mail.gmail.com>
	<5485E119.10203@redhat.com>
	<CAG2kNCyWUhbVZUbpo0rgE_NAucs5S4x6_dj4JcCXTNWyLNSAFw@mail.gmail.com>
	<CAG2kNCyj=b4c-5C59uvba37hoXwX8rHmtE9DC1vbKk+YM5p1ZQ@mail.gmail.com>
	<5486C602.80106@redhat.com>
	<CAG2kNCyMr00bjoZLzs_WmwE4LXRSZAq5ppn6D5O1Cv0ND41mLQ@mail.gmail.com>
	<54889CFF.3020500@redhat.com> <548961BF.3060800@redhat.com>
Message-ID: <CAG2kNCxoaWTU-h0a3zy0giZ758Rx7t2TSHksuPBR9zN2XrYmNQ@mail.gmail.com>

On Thu, Dec 11, 2014 at 10:19 AM, Petr Spacek <pspacek at redhat.com> wrote:

>
> Link to the how-to was added to:
> http://www.freeipa.org/page/HowTos#Virtualization
>
> --
> Petr^2 Spacek
>
>
>
thanks!
Gianluca
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141211/ca8ff9da/attachment.htm>

From mkosek at redhat.com  Thu Dec 11 12:43:54 2014
From: mkosek at redhat.com (Martin Kosek)
Date: Thu, 11 Dec 2014 13:43:54 +0100
Subject: [Freeipa-users] vSphere 5.1 and FreeIPA 3.3 on CentOS 7 finally
 works! [How I did it...]
In-Reply-To: <54889CFF.3020500@redhat.com>
References: <CAG2kNCyXWXxMx0V96bYgMq--9zaBwhWMBENrOgSXnMMr9=F85Q@mail.gmail.com>	<5485E119.10203@redhat.com>	<CAG2kNCyWUhbVZUbpo0rgE_NAucs5S4x6_dj4JcCXTNWyLNSAFw@mail.gmail.com>	<CAG2kNCyj=b4c-5C59uvba37hoXwX8rHmtE9DC1vbKk+YM5p1ZQ@mail.gmail.com>	<5486C602.80106@redhat.com>
	<CAG2kNCyMr00bjoZLzs_WmwE4LXRSZAq5ppn6D5O1Cv0ND41mLQ@mail.gmail.com>
	<54889CFF.3020500@redhat.com>
Message-ID: <5489918A.7070908@redhat.com>

On 12/10/2014 08:20 PM, Dmitri Pal wrote:
> On 12/10/2014 06:55 AM, Gianluca Cecchi wrote:
>> On Tue, Dec 9, 2014 at 10:50 AM, Martin Kosek <mkosek at redhat.com
>> <mailto:mkosek at redhat.com>> wrote:
>>
>>     On 12/09/2014 12:50 AM, Gianluca Cecchi wrote:
>>     > On Mon, Dec 8, 2014 at 7:17 PM, Gianluca Cecchi
>>     <gianluca.cecchi at gmail.com <mailto:gianluca.cecchi at gmail.com>>
>>     > wrote:
>>     >
>>     >> OK. I will check requirements to write into The wiki
>>     >>
>>
>>
>> Hello,
>> now I was able to login and I created this draft page, you can check and feel
>> free to review...
>> http://www.freeipa.org/page/HowTo/vsphere5_integration
> I scanned the page.
> Looks good. Thanks a lot!
> 
> I hope someone with the similar use case can verify the steps.
> 

+1, thanks! I see the page is already linked from

http://www.freeipa.org/page/HowTos#Virtualization

so we are covered on that front.

Martin



From ctcard at hotmail.com  Thu Dec 11 12:57:07 2014
From: ctcard at hotmail.com (Chris Card)
Date: Thu, 11 Dec 2014 12:57:07 +0000
Subject: [Freeipa-users] freeipa / sudo
In-Reply-To: <5489661F.8040203@redhat.com>
References: <DUB125-W16B0DB66FBF254466DC9FDCC620@phx.gbl>, ,
	<5488362D.4040609@redhat.com>,
	<DUB125-W201847FB050F16A133931CC620@phx.gbl>
	<DUB125-W696A68B0EABE4DB4889F64CC620@phx.gbl>,
	<54894195.5090708@redhat.com>
	<DUB125-W316148DDC6B645481224CFCC630@phx.gbl>,
	<5489661F.8040203@redhat.com>
Message-ID: <DUB125-W73BF7F9A8F95AEC8CCA0AFCC630@phx.gbl>

> On 12/11/2014 09:42 AM, Chris Card wrote:
>>
>>> On 12/10/2014 04:54 PM, Chris Card wrote:
>>>>
>>>>
>>>>>
>>>>>> On 12/10/2014 12:57 PM, Chris Card wrote:
>>>>> thanks Martin,
>>>>>>> I've installed freeipa 4.1.1 on Fedora 21, and successfully set up a freeipa server and a freeipa client machine.
>>>>>>> I've set up a user with ssh keys, and can successfully ssh onto the client machine.
>>>>>>> I'm trying to setup sudo rules so that if the user is in a given user group, then the user can run "sudo su -" on the client to become root.
>>>>> <snip>
>>>>>>> [root at fedora21-freeipa log]# ipa hostgroup-show
>>>>>>> Host-group: cog
>>>>>>> Host-group: cog
>>>>>>> Member hosts: ipaclient21.testdomain21.com
>>>>>>> Member of Sudo rule: All
>>>>>>> [root at fedora21-freeipa log]# ipa sudorule-show All
>>>>>>> Rule name: All
>>>>>>> Enabled: TRUE
>>>>>>> Command category: all
>>>>>>> RunAs User category: all
>>>>>>> RunAs Group category: all
>>>>>>> User Groups: cog_rw
>>>>>>> Host Groups: cog
>>>>>>> Sudo Option: !authenticate
>>>>>>>
>>>>>>> but this setup doesn't work, i.e. even though the user is in the user group and the client machine is in the host group, sudo su - fails. Is this a bug, or have I missed something?
>>>>>>>
>>>>>>> Chris
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> With FreeIPA 4.1.1, client sudo integration should be automatically configured,
>>>>>> so it should just work, including hostgroups. In your case, I would start with
>>>>>> investigating
>>>>>>
>>>>>> http://www.freeipa.org/page/Troubleshooting#sudo_does_not_work_for_hostgroups
>>>>>>
>>>>>> If that does not help, I bet SSSD devs will ask for logs.
>>>>>>
>>>>> I've done the troubleshooting steps:
>>>>>
>>>>> [root at ipaclient21 log]# nisdomainname
>>>>> testdomain21.com
>>>>> [root at ipaclient21 log]# getent netgroup cog
>>>>> cog (ipaclient21.testdomain21.com,-,testdomain21.com)
>>>>>
>>>>> I tried adding sudoers_debug 2 to /etc/sudo-ldap.conf on the client machine, but I'm not sure if that's the right file (it didn't exist before).
>>>>> I have debug_level set to 9 in /etc/sssd/sssd.conf, so I can see some stuff in /var/log/sssd/sssd_testdomain21.com.log but no obvious error messages.
>>>>
>>>> I worked out how to set up debug for sudo. sudoers_debug is deprecated now, but I created /etc/sssd.conf with a line
>>>>
>>>> Debug sudo /var/log/sudo_debug all at debug
>>>>
>>>> and I saw this in the debug output:
>>>>
>>>> Dec 10 15:42:57 sudo[10046] -> sudo_sss_check_host @ ./sssd.c:557
>>>> Dec 10 15:42:57 sudo[10046] val[0]=+cog
>>>> Dec 10 15:42:57 sudo[10046] -> addr_matches @ ./match_addr.c:189
>>>> Dec 10 15:42:57 sudo[10046] -> addr_matches_if @ ./match_addr.c:61
>>>> Dec 10 15:42:57 sudo[10046] <- addr_matches_if @ ./match_addr.c:99 := false
>>>> Dec 10 15:42:57 sudo[10046] <- addr_matches @ ./match_addr.c:199 := false
>>>> Dec 10 15:42:57 sudo[10046] -> netgr_matches @ ./match.c:899
>>>> Dec 10 15:42:57 sudo[10046] <- netgr_matches @ ./match.c:918 := false
>>>> Dec 10 15:42:57 sudo[10046] -> hostname_matches @ ./match.c:758
>>>> Dec 10 15:42:57 sudo[10046] <- hostname_matches @ ./match.c:769 := false
>>>> Dec 10 15:42:57 sudo[10046] sssd/ldap sudoHost '+cog' ... not
>>>>
>>>> The problem is that the hostname command on the client was returning a short hostname, ipaclient21, instead of a FQDN, ipaclient21.testdomain21.com and when I forced the hostname to be the FQDN the sudo command worked.
>>>>
>>>>
>>>> The short hostname comes from the fact that the client machine is an openstack instance, and that appears to be a feature of openstack instances :(
>>>
>>>
>>> So on the OpenStack instance, even "hostname -f" does not show the FQDN? If
>>> this is the case, I am not sure what we could do, sudo somehow needs to learn
>>> the FQDN.
>>>
>> I can set up the instance so that hostname -f returns the FQDN, but the only way I can get hostname to return the FQDN is if I explicitly run "hostname <FQDN>"; unfortunately this doesn't survive a reboot.
>
> You should be able to just set the hostname to /etc/hostname (for older
> platforms, it may also be in /etc/sysconfig/network) and it should survive the
> reboot. I do not think that OpenStack really cares that much what hostname did
> you set up in the system after the VM is created.
>
> At least my OpenStack VM with the FreeIPA demo works this way.
>
I found that simply editing /etc/hostname and rebooting didn't work, because cloud-init resets the hostname. But if I create the instance with a cloud-init script to set the hostname to the FQDN, and then reboot the instance after creation, /etc/hostname contains the FQDN and hostname returns the FQDN.

Chris

 		 	   		  



From mkosek at redhat.com  Thu Dec 11 13:08:57 2014
From: mkosek at redhat.com (Martin Kosek)
Date: Thu, 11 Dec 2014 14:08:57 +0100
Subject: [Freeipa-users] freeipa / sudo
In-Reply-To: <DUB125-W73BF7F9A8F95AEC8CCA0AFCC630@phx.gbl>
References: <DUB125-W16B0DB66FBF254466DC9FDCC620@phx.gbl>, ,
	<5488362D.4040609@redhat.com>,
	<DUB125-W201847FB050F16A133931CC620@phx.gbl>
	<DUB125-W696A68B0EABE4DB4889F64CC620@phx.gbl>,
	<54894195.5090708@redhat.com>
	<DUB125-W316148DDC6B645481224CFCC630@phx.gbl>,
	<5489661F.8040203@redhat.com>
	<DUB125-W73BF7F9A8F95AEC8CCA0AFCC630@phx.gbl>
Message-ID: <54899769.5020600@redhat.com>

On 12/11/2014 01:57 PM, Chris Card wrote:
>> On 12/11/2014 09:42 AM, Chris Card wrote:
>>>
>>>> On 12/10/2014 04:54 PM, Chris Card wrote:
>>>>>
>>>>>
>>>>>>
>>>>>>> On 12/10/2014 12:57 PM, Chris Card wrote:
>>>>>> thanks Martin,
>>>>>>>> I've installed freeipa 4.1.1 on Fedora 21, and successfully set up a freeipa server and a freeipa client machine.
>>>>>>>> I've set up a user with ssh keys, and can successfully ssh onto the client machine.
>>>>>>>> I'm trying to setup sudo rules so that if the user is in a given user group, then the user can run "sudo su -" on the client to become root.
>>>>>> <snip>
>>>>>>>> [root at fedora21-freeipa log]# ipa hostgroup-show
>>>>>>>> Host-group: cog
>>>>>>>> Host-group: cog
>>>>>>>> Member hosts: ipaclient21.testdomain21.com
>>>>>>>> Member of Sudo rule: All
>>>>>>>> [root at fedora21-freeipa log]# ipa sudorule-show All
>>>>>>>> Rule name: All
>>>>>>>> Enabled: TRUE
>>>>>>>> Command category: all
>>>>>>>> RunAs User category: all
>>>>>>>> RunAs Group category: all
>>>>>>>> User Groups: cog_rw
>>>>>>>> Host Groups: cog
>>>>>>>> Sudo Option: !authenticate
>>>>>>>>
>>>>>>>> but this setup doesn't work, i.e. even though the user is in the user group and the client machine is in the host group, sudo su - fails. Is this a bug, or have I missed something?
>>>>>>>>
>>>>>>>> Chris
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> With FreeIPA 4.1.1, client sudo integration should be automatically configured,
>>>>>>> so it should just work, including hostgroups. In your case, I would start with
>>>>>>> investigating
>>>>>>>
>>>>>>> http://www.freeipa.org/page/Troubleshooting#sudo_does_not_work_for_hostgroups
>>>>>>>
>>>>>>> If that does not help, I bet SSSD devs will ask for logs.
>>>>>>>
>>>>>> I've done the troubleshooting steps:
>>>>>>
>>>>>> [root at ipaclient21 log]# nisdomainname
>>>>>> testdomain21.com
>>>>>> [root at ipaclient21 log]# getent netgroup cog
>>>>>> cog (ipaclient21.testdomain21.com,-,testdomain21.com)
>>>>>>
>>>>>> I tried adding sudoers_debug 2 to /etc/sudo-ldap.conf on the client machine, but I'm not sure if that's the right file (it didn't exist before).
>>>>>> I have debug_level set to 9 in /etc/sssd/sssd.conf, so I can see some stuff in /var/log/sssd/sssd_testdomain21.com.log but no obvious error messages.
>>>>>
>>>>> I worked out how to set up debug for sudo. sudoers_debug is deprecated now, but I created /etc/sssd.conf with a line
>>>>>
>>>>> Debug sudo /var/log/sudo_debug all at debug
>>>>>
>>>>> and I saw this in the debug output:
>>>>>
>>>>> Dec 10 15:42:57 sudo[10046] -> sudo_sss_check_host @ ./sssd.c:557
>>>>> Dec 10 15:42:57 sudo[10046] val[0]=+cog
>>>>> Dec 10 15:42:57 sudo[10046] -> addr_matches @ ./match_addr.c:189
>>>>> Dec 10 15:42:57 sudo[10046] -> addr_matches_if @ ./match_addr.c:61
>>>>> Dec 10 15:42:57 sudo[10046] <- addr_matches_if @ ./match_addr.c:99 := false
>>>>> Dec 10 15:42:57 sudo[10046] <- addr_matches @ ./match_addr.c:199 := false
>>>>> Dec 10 15:42:57 sudo[10046] -> netgr_matches @ ./match.c:899
>>>>> Dec 10 15:42:57 sudo[10046] <- netgr_matches @ ./match.c:918 := false
>>>>> Dec 10 15:42:57 sudo[10046] -> hostname_matches @ ./match.c:758
>>>>> Dec 10 15:42:57 sudo[10046] <- hostname_matches @ ./match.c:769 := false
>>>>> Dec 10 15:42:57 sudo[10046] sssd/ldap sudoHost '+cog' ... not
>>>>>
>>>>> The problem is that the hostname command on the client was returning a short hostname, ipaclient21, instead of a FQDN, ipaclient21.testdomain21.com and when I forced the hostname to be the FQDN the sudo command worked.
>>>>>
>>>>>
>>>>> The short hostname comes from the fact that the client machine is an openstack instance, and that appears to be a feature of openstack instances :(
>>>>
>>>>
>>>> So on the OpenStack instance, even "hostname -f" does not show the FQDN? If
>>>> this is the case, I am not sure what we could do, sudo somehow needs to learn
>>>> the FQDN.
>>>>
>>> I can set up the instance so that hostname -f returns the FQDN, but the only way I can get hostname to return the FQDN is if I explicitly run "hostname <FQDN>"; unfortunately this doesn't survive a reboot.
>>
>> You should be able to just set the hostname to /etc/hostname (for older
>> platforms, it may also be in /etc/sysconfig/network) and it should survive the
>> reboot. I do not think that OpenStack really cares that much what hostname did
>> you set up in the system after the VM is created.
>>
>> At least my OpenStack VM with the FreeIPA demo works this way.
>>
> I found that simply editing /etc/hostname and rebooting didn't work, because cloud-init resets the hostname. But if I create the instance with a cloud-init script to set the hostname to the FQDN, and then reboot the instance after creation, /etc/hostname contains the FQDN and hostname returns the FQDN.
> 
> Chris

Ah, right. I just remembered I also need to set it up with cloud-init. This is
the config I use for the FreeIPA demo:

#cloud-config: FreeIPA cloud configuration
hostname: ipa.demo1.freeipa.org
fqdn: ipa.demo1.freeipa.org
manage_etc_hosts: false



From chymian at gmx.net  Thu Dec 11 13:09:46 2014
From: chymian at gmx.net (chymian)
Date: Thu, 11 Dec 2014 14:09:46 +0100
Subject: [Freeipa-users]
	=?utf-8?q?Unit_pki-tomcatd=40pki-tomcat=2Eservice?=
	=?utf-8?q?_entered_failed_state_=40_vanilla_install_on_jessie_?=
	=?utf-8?q?=E2=80=93_with_log_attached?=
In-Reply-To: <10374562.nWQdItF8xj@hansa>
References: <6538670.riIOSljqhg@hansa>
	<1418136544.27499.17.camel@aleeredhat.laptop>
	<10374562.nWQdItF8xj@hansa>
Message-ID: <3615241.KPCVUYf6We@hansa>

> Am Dienstag, 9. Dezember 2014, 23:52:08 schrieb chymian:
> 
> Am Dienstag, 9. Dezember 2014, 09:49:04 schrieb Ade Lee:
> > On Tue, 2014-12-09 at 13:54 +0100, chymian wrote:
> > > hey people,
> > > 
> > > after a successful install of ipa 4.0.5-2 on jessie, the named services
> > > started flawless during setup. see attached log, Installation summary
> > > (line 3107) but after reboot, it refuses to start. (did this install a
> > > couple times, on vanilla jessie)
> > > 
> > > I can reach & work with Dogtag https://ipa.eb8.lan:8443/ca, but not the
> > > admin-services on https://ipa.eb8.lan/ca/ee/ca and
> > > https://ipa.eb8.lan/ca/agent/ca.
> > > 
> > > 
> > > $ systemctl status pki-tomcatd at pki-tomcat.service
> > > ? pki-tomcatd at pki-tomcat.service - PKI Tomcat Server pki-tomcat
> > > 
> > >    Loaded: loaded (/lib/systemd/system/pki-tomcatd at .service; enabled)
> > >    Active: failed (Result: resources)
> > > 
> > > Dez 08 20:40:13 ipa systemd[1]: Starting PKI Tomcat Server pki-tomcat...
> > > Dez 08 20:40:13 ipa systemd[1]: Failed to load environment files: No
> > > such file or directory Dez 08 20:40:13 ipa systemd[1]:
> > > pki-tomcatd at pki-tomcat.service failed to run 'start-pre' task: No such
> > > file or directory Dez 08 20:40:13 ipa systemd[1]: Failed to start PKI
> > > Tomcat Server pki-tomcat. Dez 08 20:40:13 ipa systemd[1]: Unit
> > > pki-tomcatd at pki-tomcat.service entered failed state.> > 
> > Is dogtag actually running?  ps -ef |grep java
> 
> it shows:
> pkiuser    676     1  0 13:25 ?        00:00:26
> /usr/lib/jvm/default-java/bin/java
> -Djava.util.logging.config.file=/var/lib/pki/pki-tomcat/conf/logging.proper
> ties -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
> -DRESTEASY_LIB=/usr/share/java/
> -Djava.endorsed.dirs=/usr/share/tomcat7/endorsed -classpath
> /usr/share/tomcat7/bin/bootstrap.jar:/var/lib/pki/pki-tomcat/bin/tomcat-jul
> i.jar -Dcatalina.base=/var/lib/pki/pki-tomcat
> -Dcatalina.home=/usr/share/tomcat7
> -Djava.io.tmpdir=/var/lib/pki/pki-tomcat/temp
> org.apache.catalina.startup.Bootstrap start
> 
> is it ment to be, that the dogtag-pki package it?s self is not installed,
> just the dogtag-pki-server-theme is and a couple pki-packages? pki-base,
> pki-ca, pki-server, pki-tools?
> 
> > You could try restarting it -
> > systemctl restart pki-tomcatd at pki-tomcat.service
> 
> fails with same log-msg.
> 
> > The logs should be found in the journal -->
> > journalctl -u pki-tomcatd at pki-tomcat.service
> 
> same as above.
> 
> > Other debug logs should be found under /var/log/pki/pki-tomcat/.  Please
> > provide a tar of that directory.
> 
> attached
> 
> > I am curious what the unit file looks like:  On Fedora, its
> > at
> > /etc/systemd/system/pki-tomcatd.target.wants/pki-tomcatd at pki-tomcat.servi
> > ce> 
> lrwxrwxrwx 1 pkiuser pkiuser 40 Dez  8 20:22 pki-tomcatd at pki-tomcat.service
> -> /lib/systemd/system/pki-tomcatd at .service root at ipa
> /etc/systemd/system/pki-tomcatd.target.wants
> $ cat pki-tomcatd at pki-tomcat.service
> [Unit]
> Description=PKI Tomcat Server %i
> After=pki-tomcatd.target network.target
> PartOf=pki-tomcatd.target
> 
> [Service]
> Type=simple
> EnvironmentFile=/etc/tomcat/tomcat.conf
> Environment="NAME=%i"
> EnvironmentFile=-/etc/default/%i
> ExecStartPre=/usr/bin/pkidaemon start %i
> ExecStart=/usr/libexec/tomcat/server start
> ExecStop=/usr/libexec/tomcat/server stop
> SuccessExitStatus=143
> User=pkiuser
> Group=pkiuser
> 
> [Install]
> WantedBy=multi-user.target
> 
> > which points to an EnvironmentFile /etc/tomcat/tomcat.conf.  Does that
> > file exist?
> 
> there is not even an dir. /etc/tomcat/, or rather a tomcat.conf in it.
> 
> this is what was installed:
> 
> ii  libtomcat7-java                          7.0.56-1
> ii  libtomcatjss-java                        7.1.1-2
> ii  tomcat7-common                           7.0.56-1
> ii  tomcat7-user                             7.0.56-1
> 
> and if I would install tomcat7, it would give me an /etc/tomcat7 ? not a
> /etc/tomcat
> 
> and, here on debian, there is no such dir. /usr/libexec.
> seems that the unitfile is more a centos one.
> 
> 
> but:
> 
> systemctl status pki-tomcatd.service
> ? pki-tomcatd.service - LSB: Start pki-tomcatd at boot time
> 
>    Loaded: loaded (/etc/init.d/pki-tomcatd)
>    Active: active (running) since Di 2014-12-09 13:25:12 CET; 10h ago
>    CGroup:
>    /user.slice/user-0.slice/session-5.scope/system.slice/pki-tomcatd.servic
>    e>    
>            ??676 /usr/lib/jvm/default-java/bin/java
>            -Djava.util.logging.config.file=/var/lib/pki/pki-tomcat/conf/log
>            ging.properties -Djava.util.log...> 
> Dez 09 13:25:12 ipa pki-tomcatd[484]: .
> Dez 09 13:25:12 ipa systemd[1]: Started LSB: Start pki-tomcatd at boot time.
> 
> 
> which is started with a /etc/init.d/pki-tomcatd script, not
> systemd-unit-file ? yet.> 
> > Ade
> 
> thx,
> guenter


hello ade,
what happens next?
is there anything I can provide?

should I open a bug with debian/freeIPA team?

have a nice day,
guenter



From mrniranjan at redhat.com  Thu Dec 11 07:56:55 2014
From: mrniranjan at redhat.com (Niranjan M.R)
Date: Thu, 11 Dec 2014 13:26:55 +0530
Subject: [Freeipa-users] [Freeipa-interest] Announcing FreeIPA 4.1.2 -
 NEED HELP WITH 2FA/OTP!!!
In-Reply-To: <548734FE.6050108@redhat.com>
References: <54775877.6060102@redhat.com>	<176433463.23902008.1417805679430.JavaMail.zimbra@redhat.com>	<54845DA3.3070104@redhat.com>	<5486BA7E.90100@redhat.com>
	<5486C09A.5060902@redhat.com>	<5486C581.9020209@redhat.com>
	<5486CBDF.7050606@redhat.com>	<5487104D.8050205@redhat.com>
	<548734FE.6050108@redhat.com>
Message-ID: <54894E47.9060503@redhat.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 12/09/2014 11:14 PM, thierry bordaz wrote:
> On 12/09/2014 04:07 PM, thierry bordaz wrote:
>> On 12/09/2014 11:15 AM, thierry bordaz wrote:
>>> On 12/09/2014 10:48 AM, Niranjan M.R wrote:
> On 12/09/2014 02:57 PM, thierry bordaz wrote:
>>>>>> Hello,
>>>>>>
>>>>>> Niranjan, may I have access to your test machine.
>>>>>>
> It's a vm on my laptop. I am trying to reproduce on another VM
> to which i can give access. I will provide the details of this VM as soon
> as possible.
> 
> Mean while i am providing ns-slapd access logs, ipa-logs and pkispawn logs.
>>>>
>>>> Something curious is that the installer is waiting for DS to restart but it is looking like DS has not received the terminaison signal.
>>>>
>>>> 2014-12-09T09:37:49Z DEBUG Waiting for CA to start...
>>>> ...
>>>> 2014-12-09T09:42:45Z DEBUG Waiting for CA to start...
>>>>
>>>>
>>>> [09/Dec/2014:04:37:41 -0500] - Warning: Adding configuration attribute "nsslapd-security"
>>>>
>>>> << here we should expect a restart of DS >>
>>>>
>>>> First why DS did not receive the restart order and then as it is still running (DS looks idle) what does the install is waiting for.
>>>
>>>     At the end of  the CS configuration, the installer configure ssl DS,  restart DS it and then reach the ldap to retrieve the CA status. It fails
>>>
>>>     pki/pki-tomcat/localhost.2014-12-09.log
>>>     Dec 09, 2014 4:37:49 AM org.apache.catalina.core.StandardWrapperValve invoke
>>>     SEVERE: Servlet.service() for servlet [caGetStatus] in context with path [/ca] threw exception
>>>     java.io.IOException: CS server is not ready to serve.
>>>             at com.netscape.cms.servlet.base.CMSServlet.service(CMSServlet.java:443)
>>>             at javax.servlet.http.HttpServlet.service(HttpServlet.java:728)
>>>             at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>             at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>>>             at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>>             at java.lang.reflect.Method.invoke(Method.java:606)
>>>             at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:277)
>>>             at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:274)
>>>             at java.security.AccessController.doPrivileged(Native Method)
>>>             at javax.security.auth.Subject.doAsPrivileged(Subject.java:536)
>>>             at org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:309)
>>>             at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:169)
>>>             at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:299)
>>>             at org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:57)
>>>             at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:193)
>>>             at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:189)
>>>             at java.security.AccessController.doPrivileged(Native Method)
>>>             at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
>>>             at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222)
>>>             at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)
>>>             at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:502)
>>>             at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)
>>>             at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:100)
>>>             at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:953)
>>>             at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
>>>             at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408)
>>>             at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1041)
>>>             at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:603)
>>>             at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:310)
>>>             at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>>>             at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>>>             at java.lang.Thread.run(Thread.java:745)
>>>
>>>     Its fails to reach DS because:
>>>     0.localhost-startStop-1 - [09/Dec/2014:04:37:49 EST] [8] [3] In Ldap (bound) connection pool to host xxxx port 636, Cannot connect to LDAP
>>>     server. Error: netscape.ldap.LDAPException: IO Error creating JSS SSL Socket (-1)
>>>
>>>     Having not been able to restart DS, the secure port is not enabled so the CA failure after 5min was normal.
>>>
>>>     So the remaining question was why the DS service restart failed.
>>>     The systemd file was  dirsrv at dir.service -> /usr/lib/systemd/system/dirsrv at .service.
>>>
> 
>> I compared the installation logs with my own installation and I have not found any difference that would explain why you got
>> '/etc/systemd/system/dirsrv.target.wants/dirsrv at dir.service'  instead of '/etc/systemd/system/dirsrv.target.wants/dirsrv at EXAMPLE-ORG.service'.
> 
>> I would like to check if /var/lib/ipa/sysrestore/sysrestore.state file contains 'serverid=dir' or 'serverid=EXAMPLE-ORG'. would you please sent it to me ?

I am attaching the sysrestore.state and all the logs. Thanks a lot for looking in to this.


> 
>> thanks
>> thierry
>>>
>>>
>>>>
>>>>
>>>>
> 
> 
>>>>>> thanks
>>>>>> theirry
>>>>>>
>>>>>>
>>>>>> On 12/09/2014 10:01 AM, Martin Kosek wrote:
>>>>>>> On 12/07/2014 03:01 PM, Niranjan M.R wrote:
>>>>>>>> On 12/06/2014 12:24 AM, Dmitri Pal wrote:
>>>>>>>>> Hello,
>>>>>>>>> WE NEED HELP!
>>>>>>>>> The biggest and the most interesting feature of FreeIPA 4.1.2 is support for the two factor authentication using HOTP/TOTP compatible software
>>>>>>>>> tokens like FreeOTP (open source compatible alternative to Google Authenticator) and hardware tokens like Yubikeys. This feature allows
>>>>>>>>> Kerberos and LDAP clients of a FreeIPA server to authenticate using the normal account password as the first factor and an OTP token as a
>>>>>>>>> second factor. For those environments where a 2FA solution is already in place, FreeIPA can act as a proxy via RADIUS. More about this feature
>>>>>>>>> can be read here.
>>>>>>>>> http://www.freeipa.org/page/V4/OTP
>>>>>>>>> If you want to see this feature in downstream distros sooner rather than later we need your help!
>>>>>>>>> Please give it a try and provide feedback. We really, really need it!
>>>>>>>> I am unable to configure ipa-server with freeipa-server-4.1.2-1.fc20.x86_64,  ipa-server-install fails with below error:
>>>>>>>>
>>>>>>>> Done configuring certificate server (pki-tomcatd).
>>>>>>>> Configuring directory server (dirsrv): Estimated time 10 seconds
>>>>>>>>     [1/3]: configuring ssl for ds instance
>>>>>>>>     [2/3]: restarting directory server
>>>>>>>> ipa         : CRITICAL Failed to restart the directory server ([Errno 2] No such file or directory:
>>>>>>>> '/etc/systemd/system/dirsrv.target.wants/dirsrv at EXAMPLE-ORG.service'). See the installation log for details.
>>>>>>>>     [3/3]: adding CA certificate entry
>>>>>>>> Done configuring directory server (dirsrv).
>>>>>>>> CA did not start in 300.0s
>>>>>>>>
>>>>>>>>
>>>>>>>> Versions used:
>>>>>>>> ==============
>>>>>>>> freeipa-client-4.1.2-1.fc20.x86_64
>>>>>>>> freeipa-server-4.1.2-1.fc20.x86_64
>>>>>>>> libipa_hbac-1.12.2-2.fc20.x86_64
>>>>>>>> libipa_hbac-python-1.12.2-2.fc20.x86_64
>>>>>>>> sssd-ipa-1.12.2-2.fc20.x86_64
>>>>>>>> device-mapper-multipath-0.4.9-56.fc20.x86_64
>>>>>>>> python-iniparse-0.4-9.fc20.noarch
>>>>>>>> freeipa-admintools-4.1.2-1.fc20.x86_64
>>>>>>>> freeipa-python-4.1.2-1.fc20.x86_64
>>>>>>>> 389-ds-base-libs-1.3.3.5-1.fc20.x86_64
>>>>>>>> 389-ds-base-1.3.3.5-1.fc20.x86_64
>>>>>>>>
>>>>>>>> BaseOS:Fedora release 20 (Heisenbug)
>>>>>>>>
>>>>>>>>
>>>>>>>> Steps to reproduce:
>>>>>>>> ---------------
>>>>>>>>
>>>>>>>> 1. On Fedora-20 system, Used mkosek freeipa repo:
>>>>>>>> [mkosek-freeipa]
>>>>>>>> name=Copr repo for freeipa owned by mkosek
>>>>>>>> baseurl=http://copr-be.cloud.fedoraproject.org/results/mkosek/freeipa/fedora-$releasever-$basearch/
>>>>>>>> skip_if_unavailable=True
>>>>>>>> gpgcheck=0
>>>>>>>> enabled=1
>>>>>>>>
>>>>>>>> 2. Install freeipa-server packages from the above repo
>>>>>>>>
>>>>>>>> 3. Issue ipa-server-install
>>>>>>>>
>>>>>>>> [root at pkiserver1 ~]# ipa-server-install
>>>>>>>>
>>>>>>>> The log file for this installation can be found in /var/log/ipaserver-install.log
>>>>>>>> ==============================================================================
>>>>>>>> This program will set up the FreeIPA Server.
>>>>>>>>
>>>>>>>> This includes:
>>>>>>>>     * Configure a stand-alone CA (dogtag) for certificate management
>>>>>>>>     * Configure the Network Time Daemon (ntpd)
>>>>>>>>     * Create and configure an instance of Directory Server
>>>>>>>>     * Create and configure a Kerberos Key Distribution Center (KDC)
>>>>>>>>     * Configure Apache (httpd)
>>>>>>>>
>>>>>>>> To accept the default shown in brackets, press the Enter key.
>>>>>>>>
>>>>>>>> WARNING: conflicting time&date synchronization service 'chronyd' will be disabled
>>>>>>>> in favor of ntpd
>>>>>>>>
>>>>>>>> Do you want to configure integrated DNS (BIND)? [no]: yes
>>>>>>>>
>>>>>>>> Existing BIND configuration detected, overwrite? [no]: yes
>>>>>>>> Enter the fully qualified domain name of the computer
>>>>>>>> on which you're setting up server software. Using the form
>>>>>>>> <hostname>.<domainname>
>>>>>>>> Example: master.example.com.
>>>>>>>>
>>>>>>>>
>>>>>>>> Server host name [pkiserver1.example.org]:
>>>>>>>>
>>>>>>>> Warning: skipping DNS resolution of host pkiserver1.example.org
>>>>>>>> The domain name has been determined based on the host name.
>>>>>>>>
>>>>>>>> Please confirm the domain name [example.org]:
>>>>>>>>
>>>>>>>> The kerberos protocol requires a Realm name to be defined.
>>>>>>>> This is typically the domain name converted to uppercase.
>>>>>>>>
>>>>>>>> Please provide a realm name [EXAMPLE.ORG]:
>>>>>>>> Certain directory server operations require an administrative user.
>>>>>>>> This user is referred to as the Directory Manager and has full access
>>>>>>>> to the Directory for system management tasks and will be added to the
>>>>>>>>
>>>>>>>> The IPA server requires an administrative user, named 'admin'.
>>>>>>>> This user is a regular system account used for IPA server administration.
>>>>>>>>
>>>>>>>> IPA admin password:
>>>>>>>> Password (confirm):
>>>>>>>>
>>>>>>>> Do you want to configure DNS forwarders? [yes]: no
>>>>>>>> No DNS forwarders configured
>>>>>>>> Do you want to configure the reverse zone? [yes]:
>>>>>>>> Please specify the reverse zone name [122.168.192.in-addr.arpa.]:
>>>>>>>> Using reverse zone(s) 122.168.192.in-addr.arpa.
>>>>>>>>
>>>>>>>> The IPA Master Server will be configured with:
>>>>>>>> Hostname:       pkiserver1.example.org
>>>>>>>> IP address(es): 192.168.122.246
>>>>>>>> Domain name:    example.org
>>>>>>>> Realm name:     EXAMPLE.ORG
>>>>>>>>
>>>>>>>> BIND DNS server will be configured to serve IPA domain with:
>>>>>>>> Forwarders:    No forwarders
>>>>>>>> Reverse zone(s):  122.168.192.in-addr.arpa.
>>>>>>>>
>>>>>>>> Continue to configure the system with these values? [no]: yes
>>>>>>>>
>>>>>>>> The following operations may take some minutes to complete.
>>>>>>>> Please wait until the prompt is returned.
>>>>>>>>
>>>>>>>>
>>>>>>>> instance of directory server created for IPA.
>>>>>>>> The password must be at least 8 characters long.
>>>>>>>>
>>>>>>>> Directory Manager password:
>>>>>>>> Password (confirm):
>>>>>>>> Configuring NTP daemon (ntpd)
>>>>>>>>     [1/4]: stopping ntpd
>>>>>>>>     [2/4]: writing configuration
>>>>>>>>     [3/4]: configuring ntpd to start on boot
>>>>>>>>     [4/4]: starting ntpd
>>>>>>>> Done configuring NTP daemon (ntpd).
>>>>>>>> Configuring directory server (dirsrv): Estimated time 1 minute
>>>>>>>>     [1/38]: creating directory server user
>>>>>>>>     [2/38]: creating directory server instance
>>>>>>>>     [3/38]: adding default schema
>>>>>>>>     [4/38]: enabling memberof plugin
>>>>>>>>     [5/38]: enabling winsync plugin
>>>>>>>>     [6/38]: configuring replication version plugin
>>>>>>>>     [7/38]: enabling IPA enrollment plugin
>>>>>>>>     [8/38]: enabling ldapi
>>>>>>>>     [9/38]: configuring uniqueness plugin
>>>>>>>>     [10/38]: configuring uuid plugin
>>>>>>>>     [11/38]: configuring modrdn plugin
>>>>>>>>     [12/38]: configuring DNS plugin
>>>>>>>>     [13/38]: enabling entryUSN plugin
>>>>>>>>     [14/38]: configuring lockout plugin
>>>>>>>>     [15/38]: creating indices
>>>>>>>>     [16/38]: enabling referential integrity plugin
>>>>>>>>     [17/38]: configuring certmap.conf
>>>>>>>>     [18/38]: configure autobind for root
>>>>>>>>     [19/38]: configure new location for managed entries
>>>>>>>>     [20/38]: configure dirsrv ccache
>>>>>>>>     [21/38]: enable SASL mapping fallback
>>>>>>>>     [22/38]: restarting directory server
>>>>>>>>     [23/38]: adding default layout
>>>>>>>>     [24/38]: adding delegation layout
>>>>>>>>     [25/38]: creating container for managed entries
>>>>>>>>     [26/38]: configuring user private groups
>>>>>>>>     [27/38]: configuring netgroups from hostgroups
>>>>>>>>     [28/38]: creating default Sudo bind user
>>>>>>>>     [29/38]: creating default Auto Member layout
>>>>>>>>     [30/38]: adding range check plugin
>>>>>>>>     [31/38]: creating default HBAC rule allow_all
>>>>>>>>     [32/38]: initializing group membership
>>>>>>>>     [33/38]: adding master entry
>>>>>>>>     [34/38]: configuring Posix uid/gid generation
>>>>>>>>     [35/38]: adding replication acis
>>>>>>>>     [36/38]: enabling compatibility plugin
>>>>>>>>     [37/38]: tuning directory server
>>>>>>>>     [38/38]: configuring directory to start on boot
>>>>>>>> Done configuring directory server (dirsrv).
>>>>>>>> Configuring certificate server (pki-tomcatd): Estimated time 3 minutes 30 seconds
>>>>>>>>     [1/27]: creating certificate server user
>>>>>>>>     [2/27]: configuring certificate server instance
>>>>>>>>     [3/27]: stopping certificate server instance to update CS.cfg
>>>>>>>>     [4/27]: backing up CS.cfg
>>>>>>>>     [5/27]: disabling nonces
>>>>>>>>     [6/27]: set up CRL publishing
>>>>>>>>     [7/27]: enable PKIX certificate path discovery and validation
>>>>>>>>     [8/27]: starting certificate server instance
>>>>>>>>     [9/27]: creating RA agent certificate database
>>>>>>>>     [10/27]: importing CA chain to RA certificate database
>>>>>>>>     [11/27]: fixing RA database permissions
>>>>>>>>     [12/27]: setting up signing cert profile
>>>>>>>>     [13/27]: set certificate subject base
>>>>>>>>     [14/27]: enabling Subject Key Identifier
>>>>>>>>     [15/27]: enabling Subject Alternative Name
>>>>>>>>     [16/27]: enabling CRL and OCSP extensions for certificates
>>>>>>>>     [17/27]: setting audit signing renewal to 2 years
>>>>>>>>     [18/27]: configuring certificate server to start on boot
>>>>>>>>     [19/27]: restarting certificate server
>>>>>>>>     [20/27]: requesting RA certificate from CA
>>>>>>>>     [21/27]: issuing RA agent certificate
>>>>>>>>     [22/27]: adding RA agent as a trusted user
>>>>>>>>     [23/27]: configure certmonger for renewals
>>>>>>>>     [24/27]: configure certificate renewals
>>>>>>>>     [25/27]: configure RA certificate renewal
>>>>>>>>     [26/27]: configure Server-Cert certificate renewal
>>>>>>>>     [27/27]: Configure HTTP to proxy connections
>>>>>>>> Done configuring certificate server (pki-tomcatd).
>>>>>>>> Configuring directory server (dirsrv): Estimated time 10 seconds
>>>>>>>>     [1/3]: configuring ssl for ds instance
>>>>>>>>     [2/3]: restarting directory server
>>>>>>>> ipa         : CRITICAL Failed to restart the directory server ([Errno 2] No such file or directory:
>>>>>>>> '/etc/systemd/system/dirsrv.target.wants/dirsrv at EXAMPLE-ORG.service'). See the installation log for details.
>>>>>>>>     [3/3]: adding CA certificate entry
>>>>>>>> Done configuring directory server (dirsrv).
>>>>>>>>
>>>>>>>> CA did not start in 300.0s
>>>>>>>>
>>>>>>>> Attaching ipaserver-install.log, pkispawn logs
>>>>>>>>
>>>>>>>> Any hints on how to overcome the above error.
>>>>>>> The error is obviously in Directory Server restart. I am not sure what causes
>>>>>>>
>>>>>>> 2014-12-07T11:16:25Z DEBUG   [2/3]: restarting directory server
>>>>>>> 2014-12-07T11:16:25Z CRITICAL Failed to restart the directory server ([Errno 2]
>>>>>>> No such file or directory:
>>>>>>> '/etc/systemd/system/dirsrv.target.wants/dirsrv at EXAMPLE-ORG.service'). See the
>>>>>>> installation log for details.
>>>>>>>
>>>>>>> The first restart worked and it uses the same call, AFAIK. It would be
>>>>>>> interesting to see the latest logs of the instance after ipa-server-install
>>>>>>> crashes:
>>>>>>>
>>>>>>> # systemctl status dirsrv at EXAMPLE-ORG.service
>>>>>>>
>>>>>>> It may have some useful logs that would reveal what happened.
>>>>>>>
>>>>>>> Martin
> 
> -- Niranjan
> irc: mrniranjan
>>>
>>
>>
>>
> 
> 
> 

- -- 
Niranjan
irc: mrniranjan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iKYEARECAGYFAlSJTkdfFIAAAAAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl
bnBncC5maWZ0aGhvcnNlbWFuLm5ldEY3OTE3QTg3ODE0RkVCQ0YyNjgyOTRENjJF
RURDNTVGNjA0N0M3QzcACgkQLu3FX2BHx8cirgCfXtbPkzQcb+yLpjN1cf1UheC8
sXcAn3GBoeGcgRscYLIF4cCfh3KwQJpW
=rTOO
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ipa-logs.tar.gz
Type: application/x-gzip
Size: 301779 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141211/596df932/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x6047C7C7.asc
Type: application/pgp-keys
Size: 1893 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141211/596df932/attachment-0001.bin>

From tbordaz at redhat.com  Thu Dec 11 14:35:00 2014
From: tbordaz at redhat.com (thierry bordaz)
Date: Thu, 11 Dec 2014 15:35:00 +0100
Subject: [Freeipa-users] [Freeipa-interest] Announcing FreeIPA 4.1.2 -
 NEED HELP WITH 2FA/OTP!!!
In-Reply-To: <54894E47.9060503@redhat.com>
References: <54775877.6060102@redhat.com>	<176433463.23902008.1417805679430.JavaMail.zimbra@redhat.com>	<54845DA3.3070104@redhat.com>	<5486BA7E.90100@redhat.com>
	<5486C09A.5060902@redhat.com>	<5486C581.9020209@redhat.com>
	<5486CBDF.7050606@redhat.com>	<5487104D.8050205@redhat.com>
	<548734FE.6050108@redhat.com> <54894E47.9060503@redhat.com>
Message-ID: <5489AB94.5030102@redhat.com>

On 12/11/2014 08:56 AM, Niranjan M.R wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 12/09/2014 11:14 PM, thierry bordaz wrote:
>> On 12/09/2014 04:07 PM, thierry bordaz wrote:
>>> On 12/09/2014 11:15 AM, thierry bordaz wrote:
>>>> On 12/09/2014 10:48 AM, Niranjan M.R wrote:
>> On 12/09/2014 02:57 PM, thierry bordaz wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>> Niranjan, may I have access to your test machine.
>>>>>>>
>> It's a vm on my laptop. I am trying to reproduce on another VM
>> to which i can give access. I will provide the details of this VM as soon
>> as possible.
>>
>> Mean while i am providing ns-slapd access logs, ipa-logs and pkispawn logs.
>>>>> Something curious is that the installer is waiting for DS to restart but it is looking like DS has not received the terminaison signal.
>>>>>
>>>>> 2014-12-09T09:37:49Z DEBUG Waiting for CA to start...
>>>>> ...
>>>>> 2014-12-09T09:42:45Z DEBUG Waiting for CA to start...
>>>>>
>>>>>
>>>>> [09/Dec/2014:04:37:41 -0500] - Warning: Adding configuration attribute "nsslapd-security"
>>>>>
>>>>> << here we should expect a restart of DS >>
>>>>>
>>>>> First why DS did not receive the restart order and then as it is still running (DS looks idle) what does the install is waiting for.
>>>>      At the end of  the CS configuration, the installer configure ssl DS,  restart DS it and then reach the ldap to retrieve the CA status. It fails
>>>>
>>>>      pki/pki-tomcat/localhost.2014-12-09.log
>>>>      Dec 09, 2014 4:37:49 AM org.apache.catalina.core.StandardWrapperValve invoke
>>>>      SEVERE: Servlet.service() for servlet [caGetStatus] in context with path [/ca] threw exception
>>>>      java.io.IOException: CS server is not ready to serve.
>>>>              at com.netscape.cms.servlet.base.CMSServlet.service(CMSServlet.java:443)
>>>>              at javax.servlet.http.HttpServlet.service(HttpServlet.java:728)
>>>>              at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>>              at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>>>>              at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>>>              at java.lang.reflect.Method.invoke(Method.java:606)
>>>>              at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:277)
>>>>              at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:274)
>>>>              at java.security.AccessController.doPrivileged(Native Method)
>>>>              at javax.security.auth.Subject.doAsPrivileged(Subject.java:536)
>>>>              at org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:309)
>>>>              at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:169)
>>>>              at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:299)
>>>>              at org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:57)
>>>>              at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:193)
>>>>              at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:189)
>>>>              at java.security.AccessController.doPrivileged(Native Method)
>>>>              at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
>>>>              at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222)
>>>>              at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)
>>>>              at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:502)
>>>>              at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)
>>>>              at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:100)
>>>>              at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:953)
>>>>              at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
>>>>              at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408)
>>>>              at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1041)
>>>>              at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:603)
>>>>              at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:310)
>>>>              at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>>>>              at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>>>>              at java.lang.Thread.run(Thread.java:745)
>>>>
>>>>      Its fails to reach DS because:
>>>>      0.localhost-startStop-1 - [09/Dec/2014:04:37:49 EST] [8] [3] In Ldap (bound) connection pool to host xxxx port 636, Cannot connect to LDAP
>>>>      server. Error: netscape.ldap.LDAPException: IO Error creating JSS SSL Socket (-1)
>>>>
>>>>      Having not been able to restart DS, the secure port is not enabled so the CA failure after 5min was normal.
>>>>
>>>>      So the remaining question was why the DS service restart failed.
>>>>      The systemd file was  dirsrv at dir.service -> /usr/lib/systemd/system/dirsrv at .service.
>>>>
>>> I compared the installation logs with my own installation and I have not found any difference that would explain why you got
>>> '/etc/systemd/system/dirsrv.target.wants/dirsrv at dir.service'  instead of '/etc/systemd/system/dirsrv.target.wants/dirsrv at EXAMPLE-ORG.service'.
>>> I would like to check if /var/lib/ipa/sysrestore/sysrestore.state file contains 'serverid=dir' or 'serverid=EXAMPLE-ORG'. would you please sent it to me ?
> I am attaching the sysrestore.state and all the logs. Thanks a lot for looking in to this.

Hello,

    Well the sysrestore contains the expected service 'dirsrv' but not
    'dir'.

    I am sorry but I have no clue of what would explain why the service
    link 'dirsrv at EXAMPLE-ORG.service' would have been turned into
    'dirsrv at dir.service'.

    The service was correctly set just before pki-tomcatd configuration.
    Once pki-tomcatd completed, SSL is configured on directory and the
    restart failed because the service was incorrectly set.
    Looking at the log of pki-tomcatd configuration, I do not find
    anything related to directory service in that period of time.
    Looking at the code, the only reason that could explain such file
    (dirsrv at dir.service) would be that a service 'dir' was enabled (in
    addition to removal of EXAMPLE-ORG). But nowhere a 'dir' service is
    enabled.

    thanks
    thierry

>
>
>>> thanks
>>> thierry
>>>>
>>>>>
>>>>>
>>
>>>>>>> thanks
>>>>>>> theirry
>>>>>>>
>>>>>>>
>>>>>>> On 12/09/2014 10:01 AM, Martin Kosek wrote:
>>>>>>>> On 12/07/2014 03:01 PM, Niranjan M.R wrote:
>>>>>>>>> On 12/06/2014 12:24 AM, Dmitri Pal wrote:
>>>>>>>>>> Hello,
>>>>>>>>>> WE NEED HELP!
>>>>>>>>>> The biggest and the most interesting feature of FreeIPA 4.1.2 is support for the two factor authentication using HOTP/TOTP compatible software
>>>>>>>>>> tokens like FreeOTP (open source compatible alternative to Google Authenticator) and hardware tokens like Yubikeys. This feature allows
>>>>>>>>>> Kerberos and LDAP clients of a FreeIPA server to authenticate using the normal account password as the first factor and an OTP token as a
>>>>>>>>>> second factor. For those environments where a 2FA solution is already in place, FreeIPA can act as a proxy via RADIUS. More about this feature
>>>>>>>>>> can be read here.
>>>>>>>>>> http://www.freeipa.org/page/V4/OTP
>>>>>>>>>> If you want to see this feature in downstream distros sooner rather than later we need your help!
>>>>>>>>>> Please give it a try and provide feedback. We really, really need it!
>>>>>>>>> I am unable to configure ipa-server with freeipa-server-4.1.2-1.fc20.x86_64,  ipa-server-install fails with below error:
>>>>>>>>>
>>>>>>>>> Done configuring certificate server (pki-tomcatd).
>>>>>>>>> Configuring directory server (dirsrv): Estimated time 10 seconds
>>>>>>>>>      [1/3]: configuring ssl for ds instance
>>>>>>>>>      [2/3]: restarting directory server
>>>>>>>>> ipa         : CRITICAL Failed to restart the directory server ([Errno 2] No such file or directory:
>>>>>>>>> '/etc/systemd/system/dirsrv.target.wants/dirsrv at EXAMPLE-ORG.service'). See the installation log for details.
>>>>>>>>>      [3/3]: adding CA certificate entry
>>>>>>>>> Done configuring directory server (dirsrv).
>>>>>>>>> CA did not start in 300.0s
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Versions used:
>>>>>>>>> ==============
>>>>>>>>> freeipa-client-4.1.2-1.fc20.x86_64
>>>>>>>>> freeipa-server-4.1.2-1.fc20.x86_64
>>>>>>>>> libipa_hbac-1.12.2-2.fc20.x86_64
>>>>>>>>> libipa_hbac-python-1.12.2-2.fc20.x86_64
>>>>>>>>> sssd-ipa-1.12.2-2.fc20.x86_64
>>>>>>>>> device-mapper-multipath-0.4.9-56.fc20.x86_64
>>>>>>>>> python-iniparse-0.4-9.fc20.noarch
>>>>>>>>> freeipa-admintools-4.1.2-1.fc20.x86_64
>>>>>>>>> freeipa-python-4.1.2-1.fc20.x86_64
>>>>>>>>> 389-ds-base-libs-1.3.3.5-1.fc20.x86_64
>>>>>>>>> 389-ds-base-1.3.3.5-1.fc20.x86_64
>>>>>>>>>
>>>>>>>>> BaseOS:Fedora release 20 (Heisenbug)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Steps to reproduce:
>>>>>>>>> ---------------
>>>>>>>>>
>>>>>>>>> 1. On Fedora-20 system, Used mkosek freeipa repo:
>>>>>>>>> [mkosek-freeipa]
>>>>>>>>> name=Copr repo for freeipa owned by mkosek
>>>>>>>>> baseurl=http://copr-be.cloud.fedoraproject.org/results/mkosek/freeipa/fedora-$releasever-$basearch/
>>>>>>>>> skip_if_unavailable=True
>>>>>>>>> gpgcheck=0
>>>>>>>>> enabled=1
>>>>>>>>>
>>>>>>>>> 2. Install freeipa-server packages from the above repo
>>>>>>>>>
>>>>>>>>> 3. Issue ipa-server-install
>>>>>>>>>
>>>>>>>>> [root at pkiserver1 ~]# ipa-server-install
>>>>>>>>>
>>>>>>>>> The log file for this installation can be found in /var/log/ipaserver-install.log
>>>>>>>>> ==============================================================================
>>>>>>>>> This program will set up the FreeIPA Server.
>>>>>>>>>
>>>>>>>>> This includes:
>>>>>>>>>      * Configure a stand-alone CA (dogtag) for certificate management
>>>>>>>>>      * Configure the Network Time Daemon (ntpd)
>>>>>>>>>      * Create and configure an instance of Directory Server
>>>>>>>>>      * Create and configure a Kerberos Key Distribution Center (KDC)
>>>>>>>>>      * Configure Apache (httpd)
>>>>>>>>>
>>>>>>>>> To accept the default shown in brackets, press the Enter key.
>>>>>>>>>
>>>>>>>>> WARNING: conflicting time&date synchronization service 'chronyd' will be disabled
>>>>>>>>> in favor of ntpd
>>>>>>>>>
>>>>>>>>> Do you want to configure integrated DNS (BIND)? [no]: yes
>>>>>>>>>
>>>>>>>>> Existing BIND configuration detected, overwrite? [no]: yes
>>>>>>>>> Enter the fully qualified domain name of the computer
>>>>>>>>> on which you're setting up server software. Using the form
>>>>>>>>> <hostname>.<domainname>
>>>>>>>>> Example: master.example.com.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Server host name [pkiserver1.example.org]:
>>>>>>>>>
>>>>>>>>> Warning: skipping DNS resolution of host pkiserver1.example.org
>>>>>>>>> The domain name has been determined based on the host name.
>>>>>>>>>
>>>>>>>>> Please confirm the domain name [example.org]:
>>>>>>>>>
>>>>>>>>> The kerberos protocol requires a Realm name to be defined.
>>>>>>>>> This is typically the domain name converted to uppercase.
>>>>>>>>>
>>>>>>>>> Please provide a realm name [EXAMPLE.ORG]:
>>>>>>>>> Certain directory server operations require an administrative user.
>>>>>>>>> This user is referred to as the Directory Manager and has full access
>>>>>>>>> to the Directory for system management tasks and will be added to the
>>>>>>>>>
>>>>>>>>> The IPA server requires an administrative user, named 'admin'.
>>>>>>>>> This user is a regular system account used for IPA server administration.
>>>>>>>>>
>>>>>>>>> IPA admin password:
>>>>>>>>> Password (confirm):
>>>>>>>>>
>>>>>>>>> Do you want to configure DNS forwarders? [yes]: no
>>>>>>>>> No DNS forwarders configured
>>>>>>>>> Do you want to configure the reverse zone? [yes]:
>>>>>>>>> Please specify the reverse zone name [122.168.192.in-addr.arpa.]:
>>>>>>>>> Using reverse zone(s) 122.168.192.in-addr.arpa.
>>>>>>>>>
>>>>>>>>> The IPA Master Server will be configured with:
>>>>>>>>> Hostname:       pkiserver1.example.org
>>>>>>>>> IP address(es): 192.168.122.246
>>>>>>>>> Domain name:    example.org
>>>>>>>>> Realm name:     EXAMPLE.ORG
>>>>>>>>>
>>>>>>>>> BIND DNS server will be configured to serve IPA domain with:
>>>>>>>>> Forwarders:    No forwarders
>>>>>>>>> Reverse zone(s):  122.168.192.in-addr.arpa.
>>>>>>>>>
>>>>>>>>> Continue to configure the system with these values? [no]: yes
>>>>>>>>>
>>>>>>>>> The following operations may take some minutes to complete.
>>>>>>>>> Please wait until the prompt is returned.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> instance of directory server created for IPA.
>>>>>>>>> The password must be at least 8 characters long.
>>>>>>>>>
>>>>>>>>> Directory Manager password:
>>>>>>>>> Password (confirm):
>>>>>>>>> Configuring NTP daemon (ntpd)
>>>>>>>>>      [1/4]: stopping ntpd
>>>>>>>>>      [2/4]: writing configuration
>>>>>>>>>      [3/4]: configuring ntpd to start on boot
>>>>>>>>>      [4/4]: starting ntpd
>>>>>>>>> Done configuring NTP daemon (ntpd).
>>>>>>>>> Configuring directory server (dirsrv): Estimated time 1 minute
>>>>>>>>>      [1/38]: creating directory server user
>>>>>>>>>      [2/38]: creating directory server instance
>>>>>>>>>      [3/38]: adding default schema
>>>>>>>>>      [4/38]: enabling memberof plugin
>>>>>>>>>      [5/38]: enabling winsync plugin
>>>>>>>>>      [6/38]: configuring replication version plugin
>>>>>>>>>      [7/38]: enabling IPA enrollment plugin
>>>>>>>>>      [8/38]: enabling ldapi
>>>>>>>>>      [9/38]: configuring uniqueness plugin
>>>>>>>>>      [10/38]: configuring uuid plugin
>>>>>>>>>      [11/38]: configuring modrdn plugin
>>>>>>>>>      [12/38]: configuring DNS plugin
>>>>>>>>>      [13/38]: enabling entryUSN plugin
>>>>>>>>>      [14/38]: configuring lockout plugin
>>>>>>>>>      [15/38]: creating indices
>>>>>>>>>      [16/38]: enabling referential integrity plugin
>>>>>>>>>      [17/38]: configuring certmap.conf
>>>>>>>>>      [18/38]: configure autobind for root
>>>>>>>>>      [19/38]: configure new location for managed entries
>>>>>>>>>      [20/38]: configure dirsrv ccache
>>>>>>>>>      [21/38]: enable SASL mapping fallback
>>>>>>>>>      [22/38]: restarting directory server
>>>>>>>>>      [23/38]: adding default layout
>>>>>>>>>      [24/38]: adding delegation layout
>>>>>>>>>      [25/38]: creating container for managed entries
>>>>>>>>>      [26/38]: configuring user private groups
>>>>>>>>>      [27/38]: configuring netgroups from hostgroups
>>>>>>>>>      [28/38]: creating default Sudo bind user
>>>>>>>>>      [29/38]: creating default Auto Member layout
>>>>>>>>>      [30/38]: adding range check plugin
>>>>>>>>>      [31/38]: creating default HBAC rule allow_all
>>>>>>>>>      [32/38]: initializing group membership
>>>>>>>>>      [33/38]: adding master entry
>>>>>>>>>      [34/38]: configuring Posix uid/gid generation
>>>>>>>>>      [35/38]: adding replication acis
>>>>>>>>>      [36/38]: enabling compatibility plugin
>>>>>>>>>      [37/38]: tuning directory server
>>>>>>>>>      [38/38]: configuring directory to start on boot
>>>>>>>>> Done configuring directory server (dirsrv).
>>>>>>>>> Configuring certificate server (pki-tomcatd): Estimated time 3 minutes 30 seconds
>>>>>>>>>      [1/27]: creating certificate server user
>>>>>>>>>      [2/27]: configuring certificate server instance
>>>>>>>>>      [3/27]: stopping certificate server instance to update CS.cfg
>>>>>>>>>      [4/27]: backing up CS.cfg
>>>>>>>>>      [5/27]: disabling nonces
>>>>>>>>>      [6/27]: set up CRL publishing
>>>>>>>>>      [7/27]: enable PKIX certificate path discovery and validation
>>>>>>>>>      [8/27]: starting certificate server instance
>>>>>>>>>      [9/27]: creating RA agent certificate database
>>>>>>>>>      [10/27]: importing CA chain to RA certificate database
>>>>>>>>>      [11/27]: fixing RA database permissions
>>>>>>>>>      [12/27]: setting up signing cert profile
>>>>>>>>>      [13/27]: set certificate subject base
>>>>>>>>>      [14/27]: enabling Subject Key Identifier
>>>>>>>>>      [15/27]: enabling Subject Alternative Name
>>>>>>>>>      [16/27]: enabling CRL and OCSP extensions for certificates
>>>>>>>>>      [17/27]: setting audit signing renewal to 2 years
>>>>>>>>>      [18/27]: configuring certificate server to start on boot
>>>>>>>>>      [19/27]: restarting certificate server
>>>>>>>>>      [20/27]: requesting RA certificate from CA
>>>>>>>>>      [21/27]: issuing RA agent certificate
>>>>>>>>>      [22/27]: adding RA agent as a trusted user
>>>>>>>>>      [23/27]: configure certmonger for renewals
>>>>>>>>>      [24/27]: configure certificate renewals
>>>>>>>>>      [25/27]: configure RA certificate renewal
>>>>>>>>>      [26/27]: configure Server-Cert certificate renewal
>>>>>>>>>      [27/27]: Configure HTTP to proxy connections
>>>>>>>>> Done configuring certificate server (pki-tomcatd).
>>>>>>>>> Configuring directory server (dirsrv): Estimated time 10 seconds
>>>>>>>>>      [1/3]: configuring ssl for ds instance
>>>>>>>>>      [2/3]: restarting directory server
>>>>>>>>> ipa         : CRITICAL Failed to restart the directory server ([Errno 2] No such file or directory:
>>>>>>>>> '/etc/systemd/system/dirsrv.target.wants/dirsrv at EXAMPLE-ORG.service'). See the installation log for details.
>>>>>>>>>      [3/3]: adding CA certificate entry
>>>>>>>>> Done configuring directory server (dirsrv).
>>>>>>>>>
>>>>>>>>> CA did not start in 300.0s
>>>>>>>>>
>>>>>>>>> Attaching ipaserver-install.log, pkispawn logs
>>>>>>>>>
>>>>>>>>> Any hints on how to overcome the above error.
>>>>>>>> The error is obviously in Directory Server restart. I am not sure what causes
>>>>>>>>
>>>>>>>> 2014-12-07T11:16:25Z DEBUG   [2/3]: restarting directory server
>>>>>>>> 2014-12-07T11:16:25Z CRITICAL Failed to restart the directory server ([Errno 2]
>>>>>>>> No such file or directory:
>>>>>>>> '/etc/systemd/system/dirsrv.target.wants/dirsrv at EXAMPLE-ORG.service'). See the
>>>>>>>> installation log for details.
>>>>>>>>
>>>>>>>> The first restart worked and it uses the same call, AFAIK. It would be
>>>>>>>> interesting to see the latest logs of the instance after ipa-server-install
>>>>>>>> crashes:
>>>>>>>>
>>>>>>>> # systemctl status dirsrv at EXAMPLE-ORG.service
>>>>>>>>
>>>>>>>> It may have some useful logs that would reveal what happened.
>>>>>>>>
>>>>>>>> Martin
>> -- Niranjan
>> irc: mrniranjan
>>>
>>>
>>
>>
> - -- 
> Niranjan
> irc: mrniranjan
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
>
> iKYEARECAGYFAlSJTkdfFIAAAAAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl
> bnBncC5maWZ0aGhvcnNlbWFuLm5ldEY3OTE3QTg3ODE0RkVCQ0YyNjgyOTRENjJF
> RURDNTVGNjA0N0M3QzcACgkQLu3FX2BHx8cirgCfXtbPkzQcb+yLpjN1cf1UheC8
> sXcAn3GBoeGcgRscYLIF4cCfh3KwQJpW
> =rTOO
> -----END PGP SIGNATURE-----

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141211/4f527e95/attachment.htm>

From dpal at redhat.com  Thu Dec 11 15:38:42 2014
From: dpal at redhat.com (Dmitri Pal)
Date: Thu, 11 Dec 2014 10:38:42 -0500
Subject: [Freeipa-users] freeipa / sudo
In-Reply-To: <54899769.5020600@redhat.com>
References: <DUB125-W16B0DB66FBF254466DC9FDCC620@phx.gbl>, ,
	<5488362D.4040609@redhat.com>,
	<DUB125-W201847FB050F16A133931CC620@phx.gbl>	<DUB125-W696A68B0EABE4DB4889F64CC620@phx.gbl>,
	<54894195.5090708@redhat.com>	<DUB125-W316148DDC6B645481224CFCC630@phx.gbl>,
	<5489661F.8040203@redhat.com>	<DUB125-W73BF7F9A8F95AEC8CCA0AFCC630@phx.gbl>
	<54899769.5020600@redhat.com>
Message-ID: <5489BA82.4000609@redhat.com>

On 12/11/2014 08:08 AM, Martin Kosek wrote:
> On 12/11/2014 01:57 PM, Chris Card wrote:
>>> On 12/11/2014 09:42 AM, Chris Card wrote:
>>>>> On 12/10/2014 04:54 PM, Chris Card wrote:
>>>>>>
>>>>>>>> On 12/10/2014 12:57 PM, Chris Card wrote:
>>>>>>> thanks Martin,
>>>>>>>>> I've installed freeipa 4.1.1 on Fedora 21, and successfully set up a freeipa server and a freeipa client machine.
>>>>>>>>> I've set up a user with ssh keys, and can successfully ssh onto the client machine.
>>>>>>>>> I'm trying to setup sudo rules so that if the user is in a given user group, then the user can run "sudo su -" on the client to become root.
>>>>>>> <snip>
>>>>>>>>> [root at fedora21-freeipa log]# ipa hostgroup-show
>>>>>>>>> Host-group: cog
>>>>>>>>> Host-group: cog
>>>>>>>>> Member hosts: ipaclient21.testdomain21.com
>>>>>>>>> Member of Sudo rule: All
>>>>>>>>> [root at fedora21-freeipa log]# ipa sudorule-show All
>>>>>>>>> Rule name: All
>>>>>>>>> Enabled: TRUE
>>>>>>>>> Command category: all
>>>>>>>>> RunAs User category: all
>>>>>>>>> RunAs Group category: all
>>>>>>>>> User Groups: cog_rw
>>>>>>>>> Host Groups: cog
>>>>>>>>> Sudo Option: !authenticate
>>>>>>>>>
>>>>>>>>> but this setup doesn't work, i.e. even though the user is in the user group and the client machine is in the host group, sudo su - fails. Is this a bug, or have I missed something?
>>>>>>>>>
>>>>>>>>> Chris
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>> With FreeIPA 4.1.1, client sudo integration should be automatically configured,
>>>>>>>> so it should just work, including hostgroups. In your case, I would start with
>>>>>>>> investigating
>>>>>>>>
>>>>>>>> http://www.freeipa.org/page/Troubleshooting#sudo_does_not_work_for_hostgroups
>>>>>>>>
>>>>>>>> If that does not help, I bet SSSD devs will ask for logs.
>>>>>>>>
>>>>>>> I've done the troubleshooting steps:
>>>>>>>
>>>>>>> [root at ipaclient21 log]# nisdomainname
>>>>>>> testdomain21.com
>>>>>>> [root at ipaclient21 log]# getent netgroup cog
>>>>>>> cog (ipaclient21.testdomain21.com,-,testdomain21.com)
>>>>>>>
>>>>>>> I tried adding sudoers_debug 2 to /etc/sudo-ldap.conf on the client machine, but I'm not sure if that's the right file (it didn't exist before).
>>>>>>> I have debug_level set to 9 in /etc/sssd/sssd.conf, so I can see some stuff in /var/log/sssd/sssd_testdomain21.com.log but no obvious error messages.
>>>>>> I worked out how to set up debug for sudo. sudoers_debug is deprecated now, but I created /etc/sssd.conf with a line
>>>>>>
>>>>>> Debug sudo /var/log/sudo_debug all at debug
>>>>>>
>>>>>> and I saw this in the debug output:
>>>>>>
>>>>>> Dec 10 15:42:57 sudo[10046] -> sudo_sss_check_host @ ./sssd.c:557
>>>>>> Dec 10 15:42:57 sudo[10046] val[0]=+cog
>>>>>> Dec 10 15:42:57 sudo[10046] -> addr_matches @ ./match_addr.c:189
>>>>>> Dec 10 15:42:57 sudo[10046] -> addr_matches_if @ ./match_addr.c:61
>>>>>> Dec 10 15:42:57 sudo[10046] <- addr_matches_if @ ./match_addr.c:99 := false
>>>>>> Dec 10 15:42:57 sudo[10046] <- addr_matches @ ./match_addr.c:199 := false
>>>>>> Dec 10 15:42:57 sudo[10046] -> netgr_matches @ ./match.c:899
>>>>>> Dec 10 15:42:57 sudo[10046] <- netgr_matches @ ./match.c:918 := false
>>>>>> Dec 10 15:42:57 sudo[10046] -> hostname_matches @ ./match.c:758
>>>>>> Dec 10 15:42:57 sudo[10046] <- hostname_matches @ ./match.c:769 := false
>>>>>> Dec 10 15:42:57 sudo[10046] sssd/ldap sudoHost '+cog' ... not
>>>>>>
>>>>>> The problem is that the hostname command on the client was returning a short hostname, ipaclient21, instead of a FQDN, ipaclient21.testdomain21.com and when I forced the hostname to be the FQDN the sudo command worked.
>>>>>>
>>>>>>
>>>>>> The short hostname comes from the fact that the client machine is an openstack instance, and that appears to be a feature of openstack instances :(
>>>>>
>>>>> So on the OpenStack instance, even "hostname -f" does not show the FQDN? If
>>>>> this is the case, I am not sure what we could do, sudo somehow needs to learn
>>>>> the FQDN.
>>>>>
>>>> I can set up the instance so that hostname -f returns the FQDN, but the only way I can get hostname to return the FQDN is if I explicitly run "hostname <FQDN>"; unfortunately this doesn't survive a reboot.
>>> You should be able to just set the hostname to /etc/hostname (for older
>>> platforms, it may also be in /etc/sysconfig/network) and it should survive the
>>> reboot. I do not think that OpenStack really cares that much what hostname did
>>> you set up in the system after the VM is created.
>>>
>>> At least my OpenStack VM with the FreeIPA demo works this way.
>>>
>> I found that simply editing /etc/hostname and rebooting didn't work, because cloud-init resets the hostname. But if I create the instance with a cloud-init script to set the hostname to the FQDN, and then reboot the instance after creation, /etc/hostname contains the FQDN and hostname returns the FQDN.
>>
>> Chris
> Ah, right. I just remembered I also need to set it up with cloud-init. This is
> the config I use for the FreeIPA demo:
>
> #cloud-config: FreeIPA cloud configuration
> hostname: ipa.demo1.freeipa.org
> fqdn: ipa.demo1.freeipa.org
> manage_etc_hosts: false
>
Is it worth a howto? Seems like  a valuable piece of info...


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.



From alee at redhat.com  Thu Dec 11 16:49:56 2014
From: alee at redhat.com (Ade Lee)
Date: Thu, 11 Dec 2014 11:49:56 -0500
Subject: [Freeipa-users]
 =?utf-8?q?Unit_pki-tomcatd=40pki-tomcat=2Eservice?=
 =?utf-8?q?_entered_failed_state_=40_vanilla_install_on_jessie_=E2=80=93_w?=
 =?utf-8?q?ith_log_attached?=
In-Reply-To: <10374562.nWQdItF8xj@hansa>
References: <6538670.riIOSljqhg@hansa>
	<1418136544.27499.17.camel@aleeredhat.laptop>
	<10374562.nWQdItF8xj@hansa>
Message-ID: <1418316596.5473.10.camel@aleeredhat.laptop>

On Tue, 2014-12-09 at 23:52 +0100, chymian wrote:
> Am Dienstag, 9. Dezember 2014, 09:49:04 schrieb Ade Lee:
> 
> > On Tue, 2014-12-09 at 13:54 +0100, chymian wrote:
> 
> > > hey people,
> 
> > > 
> 
> > > after a successful install of ipa 4.0.5-2 on jessie, the named
> services started flawless during setup. see attached log, Installation
> summary (line 3107)
> 
> > > but after reboot, it refuses to start. (did this install a couple
> times, on vanilla jessie)
> 
> > > 
> 
> > > I can reach & work with Dogtag https://ipa.eb8.lan:8443/ca, but
> not the admin-services on https://ipa.eb8.lan/ca/ee/ca and
> https://ipa.eb8.lan/ca/agent/ca.
> 
> > > 
> 
> > > 
> 
> > > $ systemctl status pki-tomcatd at pki-tomcat.service
> 
> > > ? pki-tomcatd at pki-tomcat.service - PKI Tomcat Server pki-tomcat
> 
> > > Loaded: loaded (/lib/systemd/system/pki-tomcatd at .service; enabled)
> 
> > > Active: failed (Result: resources)
> 
> > > 
> 
> > > Dez 08 20:40:13 ipa systemd[1]: Starting PKI Tomcat Server
> pki-tomcat...
> 
> > > Dez 08 20:40:13 ipa systemd[1]: Failed to load environment files:
> No such file or directory
> 
> > > Dez 08 20:40:13 ipa systemd[1]: pki-tomcatd at pki-tomcat.service
> failed to run 'start-pre' task: No such file or directory
> 
> > > Dez 08 20:40:13 ipa systemd[1]: Failed to start PKI Tomcat Server
> pki-tomcat.
> 
> > > Dez 08 20:40:13 ipa systemd[1]: Unit
> pki-tomcatd at pki-tomcat.service entered failed state.
> 
> > > 
> 
> > > 
> 
> > 
> 
> > Is dogtag actually running? ps -ef |grep java
> 
>  
> 
> it shows:
> 
> pkiuser 676 1 0 13:25 ? 00:00:26 /usr/lib/jvm/default-java/bin/java
> -Djava.util.logging.config.file=/var/lib/pki/pki-tomcat/conf/logging.properties -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -DRESTEASY_LIB=/usr/share/java/ -Djava.endorsed.dirs=/usr/share/tomcat7/endorsed -classpath /usr/share/tomcat7/bin/bootstrap.jar:/var/lib/pki/pki-tomcat/bin/tomcat-juli.jar -Dcatalina.base=/var/lib/pki/pki-tomcat -Dcatalina.home=/usr/share/tomcat7 -Djava.io.tmpdir=/var/lib/pki/pki-tomcat/temp org.apache.catalina.startup.Bootstrap start
> 
>  
> 
> is it ment to be, that the dogtag-pki package it?s self is not
> installed, just the dogtag-pki-server-theme is
> 
> and a couple pki-packages? pki-base, pki-ca, pki-server, pki-tools?
> 
>  
Ok, so as far as I can see, the dogtag CA is in fact up and operational.
The systemctl error messages are probably a result of the systemd unit
scripts not yet being used.

We clearly see that the IPA RA and Jar signing certs are issued with no
problems.  I do notice a few attempts to reach the agent pages which
result in failed authentication.  My guess is that you are trying to
access these pages using the browser and are not providing the agent
cert.

As you have the dogtag-pki-server-theme package installed, you should be
able to reach the UI.  But ..

-- If you try to access the dogtag UI pages through port 80 and 443,
then you are going through the apache instance for IPA.  This instance
talks to Dogtag on the back-end using AJP, and has a proxy configuration
file that only permits certain URL paths to go through.

-- If you want to access the Dogtag UI pages, you need to access
https://host:8443/... or http://host:8080/...

To access the agent pages, you need to import the IPA RA agent
certificate into your browser (and trust the CA cert).  That cert/key is
in the IPA HTTP certdb.  You will need to extract it from there as a p12
file and import it into your browser.

Ade
> 
>  
> 
> > 
> 
> > You could try restarting it - 
> 
> > systemctl restart pki-tomcatd at pki-tomcat.service
> 
>  
> 
> fails with same log-msg.
> 
>  
> 
> > 
> 
> > The logs should be found in the journal --> 
> 
> > journalctl -u pki-tomcatd at pki-tomcat.service
> 
>  
> 
> same as above.
> 
>  
> 
> > 
> 
> > Other debug logs should be found under /var/log/pki/pki-tomcat/.
> Please
> 
> > provide a tar of that directory.
> 
>  
> 
> attached
> 
>  
> 
> > I am curious what the unit file looks like: On Fedora, its
> 
> >
> at /etc/systemd/system/pki-tomcatd.target.wants/pki-tomcatd at pki-tomcat.service
> 
>  
> 
> lrwxrwxrwx 1 pkiuser pkiuser 40 Dez 8 20:22
> pki-tomcatd at pki-tomcat.service
> -> /lib/systemd/system/pki-tomcatd at .service
> 
> root at ipa /etc/systemd/system/pki-tomcatd.target.wants
> 
> $ cat pki-tomcatd at pki-tomcat.service
> 
> [Unit]
> 
> Description=PKI Tomcat Server %i
> 
> After=pki-tomcatd.target network.target
> 
> PartOf=pki-tomcatd.target
> 
>  
> 
> [Service]
> 
> Type=simple
> 
> EnvironmentFile=/etc/tomcat/tomcat.conf
> 
> Environment="NAME=%i"
> 
> EnvironmentFile=-/etc/default/%i
> 
> ExecStartPre=/usr/bin/pkidaemon start %i
> 
> ExecStart=/usr/libexec/tomcat/server start
> 
> ExecStop=/usr/libexec/tomcat/server stop
> 
> SuccessExitStatus=143
> 
> User=pkiuser
> 
> Group=pkiuser
> 
>  
> 
> [Install]
> 
> WantedBy=multi-user.target
> 
>  
> 
>  
> 
> > which points to an EnvironmentFile /etc/tomcat/tomcat.conf. Does
> that
> 
> > file exist?
> 
>  
> 
> there is not even an dir. /etc/tomcat/, or rather a tomcat.conf in it.
> 
>  
> 
> this is what was installed:
> 
>  
> 
> ii libtomcat7-java 7.0.56-1
> 
> ii libtomcatjss-java 7.1.1-2
> 
> ii tomcat7-common 7.0.56-1
> 
> ii tomcat7-user 7.0.56-1
> 
>  
> 
> and if I would install tomcat7, it would give me an /etc/tomcat7 ? not
> a /etc/tomcat
> 
>  
> 
> and, here on debian, there is no such dir. /usr/libexec.
> 
> seems that the unitfile is more a centos one.
> 
>  
> 
>  
> 
> but: 
> 
>  
> 
> systemctl status pki-tomcatd.service
> 
> ? pki-tomcatd.service - LSB: Start pki-tomcatd at boot time
> 
> Loaded: loaded (/etc/init.d/pki-tomcatd)
> 
> Active: active (running) since Di 2014-12-09 13:25:12 CET; 10h ago
> 
> CGroup: /user.slice/user-0.slice/session-5.scope/system.slice/pki-tomcatd.service
> 
> ??676 /usr/lib/jvm/default-java/bin/java
> -Djava.util.logging.config.file=/var/lib/pki/pki-tomcat/conf/logging.properties -Djava.util.log...
> 
>  
> 
> Dez 09 13:25:12 ipa pki-tomcatd[484]: .
> 
> Dez 09 13:25:12 ipa systemd[1]: Started LSB: Start pki-tomcatd at boot
> time.
> 
>  
> 
>  
> 
> which is started with a /etc/init.d/pki-tomcatd script, not
> systemd-unit-file ? yet.
> 
>  
> 
> > 
> 
> > Ade
> 
>  
> 
> thx,
> 
> guenter
> 
>  
> 
> > 
> 
> > > a second service fails to start:
> 
> > > 
> 
> > > $ systemctl status dirsrv-snmp.service
> 
> > > ? dirsrv-snmp.service - 389 Directory Server SNMP Subagent.
> 
> > > Loaded: loaded (/lib/systemd/system/dirsrv-snmp.service; enabled)
> 
> > > Active: failed (Result: exit-code) since Di 2014-12-09 13:25:04
> CET; 5min ago
> 
> > > Process: 156
> ExecStart=/usr/sbin/ldap-agent /etc/dirsrv/config/ldap-agent.conf
> (code=exited, status=1/FAILURE)
> 
> > > 
> 
> > > Dez 09 13:25:04 ipa systemd[1]: Starting 389 Directory Server SNMP
> Subagent....
> 
> > > Dez 09 13:25:04 ipa ldap-agent[156]: ldap-agent: No server
> instances defined in config file
> 
> > > Dez 09 13:25:04 ipa systemd[1]: dirsrv-snmp.service: control
> process exited, code=exited status=1
> 
> > > Dez 09 13:25:04 ipa systemd[1]: Failed to start 389 Directory
> Server SNMP Subagent..
> 
> > > Dez 09 13:25:04 ipa systemd[1]: Unit dirsrv-snmp.service entered
> failed state.
> 
> > > 
> 
> > > 
> 
> > > except these, I was able to subscribe a jessie-client with
> autodiscovery right after I did configure the ipa-server, before first
> reboot.
> 
> > > 
> 
> > > 
> 
> > > any help appreciated, since I do not have much experience with IPA
> ? yet.
> 
> > > guenter
> 
> > 
> 
> > 
> 
>  
> 




From mchesler at chesent.com  Thu Dec 11 17:19:51 2014
From: mchesler at chesent.com (Matt Chesler)
Date: Thu, 11 Dec 2014 12:19:51 -0500
Subject: [Freeipa-users] Replica re-initialization
Message-ID: <CACjq759+ZKi+u1nhgztiSPKA7OpSZtaeLRH+U2Bdw3vk8Vs6Yw@mail.gmail.com>

I have a cluster of four IPA masters that should be performing fully meshed
replication.  I discovered yesterday that a recently created user only
existed on a single master.  After looking through all four masters, it
appears that several recent updates only exist on one of the masters.  I do
not see any replication errors in any of the logs, but I'm not 100% sure
how far back this issue goes.  I do believe the one master with up-to-date
data is a reliable representation of what the LDAP directory should look
like.  I ran a reinitialize command (ipa-replica-manage re-initialize
--from reliable-server.fqdn) on two of the out-of-date masters yesterday
around 4pm EST.  It's now a little after 12pm EST and the "Update in
progress" message is still scrolling by once a second on both terminals.
I'd greatly appreciate suggestions about a) how to determine the status of
the reinitialize command and b) any other ideas about how to resolve this
issue and monitor for it better in the future.  Thanks in advance for your
help!

Thanks,

Matt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141211/423e6fef/attachment.htm>

From manuel.lopes72 at gmail.com  Thu Dec 11 17:45:49 2014
From: manuel.lopes72 at gmail.com (Manuel Lopes)
Date: Thu, 11 Dec 2014 18:45:49 +0100
Subject: [Freeipa-users] Forest trust and AD child domain
Message-ID: <CAKFNJrsYA9M1j5cjH5kA4c6U9QGEr5pGd90QVRDWf8ajHk9tqw@mail.gmail.com>

 Hello,


We have been following the AD integration guide for IPAv3:
http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup



Our setup is:

? 2 domain controllers with Windows 2008 R2 AD DC -> windows.com
<http://example.com/> as Forest Root Domain and acme.windows.com
<http://acme.example.com/> as transitive child domain

? RHEL7 as IPA server with domain: linux.com
<http://linux.acme.example.com/>



We have established a forest trust between windows.com and linux.com and
everything seems OK from an IPA perspective.



We can work with Kerberos tickets without any issue from ?windows? domain
or his child domain ?acme?. (kinit, kvno?)



When we use samba tools, the following command is working fine.

*[root at support1 ]# wbinfo -n 'WINDOWS\Domain Admins'*

*S-1-5-21-1701591335-3855227394-3044674468-512 SID_DOM_GROUP (2)*



But, the same command against the acme domain returns an error.

*[root at support1 ]# wbinfo -n 'ACME\Domain Admins'*

*failed to call wbcLookupName: WBC_ERR_DOMAIN_NOT_FOUND*

*Could not lookup name ACME\Domain Admins*



Same problem with the following command:

*[root at support1]# ipa group-add-member ad_users_external --external
"ACME\Domain Users"*

*[member user]:*

*[member group]:*

*  Group name: ad_users_external*

*  Description: AD users external map*

*  External member: *

*  Member of groups: ad_users*

*  Failed members:*

*    member user:*

*    member group: ACME\Domain Users: Cannot find specified domain or
server name*

*-------------------------*

*Number of members added 0*





Any help would be appreciated



Regards
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141211/294b221b/attachment.htm>

From sbose at redhat.com  Thu Dec 11 19:05:42 2014
From: sbose at redhat.com (Sumit Bose)
Date: Thu, 11 Dec 2014 20:05:42 +0100
Subject: [Freeipa-users] Forest trust and AD child domain
In-Reply-To: <CAKFNJrsYA9M1j5cjH5kA4c6U9QGEr5pGd90QVRDWf8ajHk9tqw@mail.gmail.com>
References: <CAKFNJrsYA9M1j5cjH5kA4c6U9QGEr5pGd90QVRDWf8ajHk9tqw@mail.gmail.com>
Message-ID: <20141211190542.GT14057@localhost.localdomain>

On Thu, Dec 11, 2014 at 06:45:49PM +0100, Manuel Lopes wrote:
>  Hello,
> 
> 
> We have been following the AD integration guide for IPAv3:
> http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup
> 
> 
> 
> Our setup is:
> 
> ? 2 domain controllers with Windows 2008 R2 AD DC -> windows.com
> <http://example.com/> as Forest Root Domain and acme.windows.com
> <http://acme.example.com/> as transitive child domain
> 
> ? RHEL7 as IPA server with domain: linux.com
> <http://linux.acme.example.com/>
> 
> 
> 
> We have established a forest trust between windows.com and linux.com and
> everything seems OK from an IPA perspective.
> 
> 
> 
> We can work with Kerberos tickets without any issue from ?windows? domain
> or his child domain ?acme?. (kinit, kvno?)
> 
> 
> 
> When we use samba tools, the following command is working fine.
> 
> *[root at support1 ]# wbinfo -n 'WINDOWS\Domain Admins'*
> 
> *S-1-5-21-1701591335-3855227394-3044674468-512 SID_DOM_GROUP (2)*
> 
> 
> 
> But, the same command against the acme domain returns an error.
> 
> *[root at support1 ]# wbinfo -n 'ACME\Domain Admins'*
> 
> *failed to call wbcLookupName: WBC_ERR_DOMAIN_NOT_FOUND*
> 
> *Could not lookup name ACME\Domain Admins*
> 
> 
> 
> Same problem with the following command:
> 
> *[root at support1]# ipa group-add-member ad_users_external --external
> "ACME\Domain Users"*
> 
> *[member user]:*
> 
> *[member group]:*
> 
> *  Group name: ad_users_external*
> 
> *  Description: AD users external map*
> 
> *  External member: *
> 
> *  Member of groups: ad_users*
> 
> *  Failed members:*
> 
> *    member user:*
> 
> *    member group: ACME\Domain Users: Cannot find specified domain or
> server name*
> 
> *-------------------------*
> 
> *Number of members added 0*
> 
> 
> 
> 
> 
> Any help would be appreciated

Does

ipa trustdomain-find windows.com

show acme.windows.com as well ?

Does

ipa trust-fetch-domains ad.devel

help to retrieve the child domain?

Please note that if acme.windows.com now shows up you might have to wait
1-2 minutes until SSSD's negative caches are flushed and the new domains
is discovered by SSSD, as an alternative you can just restart SSSD.

HTH

bye,
Sumit

> 
> 
> 
> Regards

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



From freeipa at pettyvices.com  Thu Dec 11 23:32:19 2014
From: freeipa at pettyvices.com (freeipa at pettyvices.com)
Date: Thu, 11 Dec 2014 15:32:19 -0800 (PST)
Subject: [Freeipa-users] Host based 2FA ?
Message-ID: <alpine.DEB.2.02.1412111523250.24600@e.crebbs.net>


I'd like to be able to require 2FA on *certain* hosts and allow just 
passwords on others.

It seems you can check both "passwords" and "2FA" under the user.

I was hoping I could create a HBAC such that certain hosts would only 
allow 2FA, but I can't see an obvious way to do that.

Is it possible?  Help on how would be great.  If not, feature request?

thanks,

-t



From dpal at redhat.com  Thu Dec 11 23:30:06 2014
From: dpal at redhat.com (Dmitri Pal)
Date: Thu, 11 Dec 2014 18:30:06 -0500
Subject: [Freeipa-users] Host based 2FA ?
In-Reply-To: <alpine.DEB.2.02.1412111523250.24600@e.crebbs.net>
References: <alpine.DEB.2.02.1412111523250.24600@e.crebbs.net>
Message-ID: <548A28FE.7030000@redhat.com>

On 12/11/2014 06:32 PM, freeipa at pettyvices.com wrote:
>
> I'd like to be able to require 2FA on *certain* hosts and allow just 
> passwords on others.
>
> It seems you can check both "passwords" and "2FA" under the user.
>
> I was hoping I could create a HBAC such that certain hosts would only 
> allow 2FA, but I can't see an obvious way to do that.
>
> Is it possible?  Help on how would be great.  If not, feature request?
>
> thanks,
>
> -t
>
We have several tickets:

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

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

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

If you see https://fedorahosted.org/freeipa/ticket/4498#comment:6 we 
discussed this use case.
And I was about to fork it as said but then I realized that there is not 
good way on the KDC to determine the host you are coming from.
So IMO it should be a policy decision on SSSD.
There are two options:
- short term solution: allow SSSD to have a local overwrite to require 
OTP if server offers different options.
- longer term solution: actually have a per host policy that is 
centrally managed that is fetched per host and enforced by SSSD.

Before filing tickets I would like to hear opinions on the matter.

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141211/5db0bcdc/attachment.htm>

From manuel.lopes72 at gmail.com  Fri Dec 12 01:06:05 2014
From: manuel.lopes72 at gmail.com (Manuel Lopes)
Date: Fri, 12 Dec 2014 02:06:05 +0100
Subject: [Freeipa-users] Forest trust and AD child domain
In-Reply-To: <20141211190542.GT14057@localhost.localdomain>
References: <CAKFNJrsYA9M1j5cjH5kA4c6U9QGEr5pGd90QVRDWf8ajHk9tqw@mail.gmail.com>
	<20141211190542.GT14057@localhost.localdomain>
Message-ID: <CAKFNJrt_+GkUwDNuDhZLoGEFNfSV=omb=qCJfbJJq=RkXHxqnQ@mail.gmail.com>

Hi Sumit,

Thank you very much for the prompt reply

[root at support1 ~]# ipa trustdomain-find windows.com
  Domain name: windows.com
  Domain NetBIOS name: WINDOWS
  Domain Security Identifier: S-1-5-21-1701591335-3855227394-3044674468
  Domain enabled: True

  Domain name: acme.windows.com
  Domain NetBIOS name: ACME
  Domain Security Identifier: S-1-5-21-1215373191-1991333051-3772904882
  Domain enabled: True
----------------------------
Number of entries returned 2
----------------------------

[root at support1 ~]# ipa trust-fetch-domains windows.com
-------------------------------
No new trust domains were found
-------------------------------
----------------------------
Number of entries returned 0
----------------------------

Regards
Le 11 d?c. 2014 20:08, "Sumit Bose" <sbose at redhat.com
<javascript:_e(%7B%7D,'cvml','sbose at redhat.com');>> a ?crit :

> On Thu, Dec 11, 2014 at 06:45:49PM +0100, Manuel Lopes wrote:
> >  Hello,
> >
> >
> > We have been following the AD integration guide for IPAv3:
> > http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup
> >
> >
> >
> > Our setup is:
> >
> > ? 2 domain controllers with Windows 2008 R2 AD DC -> windows.com
> > <http://example.com/> as Forest Root Domain and acme.windows.com
> > <http://acme.example.com/> as transitive child domain
> >
> > ? RHEL7 as IPA server with domain: linux.com
> > <http://linux.acme.example.com/>
> >
> >
> >
> > We have established a forest trust between windows.com and linux.com and
> > everything seems OK from an IPA perspective.
> >
> >
> >
> > We can work with Kerberos tickets without any issue from ?windows? domain
> > or his child domain ?acme?. (kinit, kvno?)
> >
> >
> >
> > When we use samba tools, the following command is working fine.
> >
> > *[root at support1 ]# wbinfo -n 'WINDOWS\Domain Admins'*
> >
> > *S-1-5-21-1701591335-3855227394-3044674468-512 SID_DOM_GROUP (2)*
> >
> >
> >
> > But, the same command against the acme domain returns an error.
> >
> > *[root at support1 ]# wbinfo -n 'ACME\Domain Admins'*
> >
> > *failed to call wbcLookupName: WBC_ERR_DOMAIN_NOT_FOUND*
> >
> > *Could not lookup name ACME\Domain Admins*
> >
> >
> >
> > Same problem with the following command:
> >
> > *[root at support1]# ipa group-add-member ad_users_external --external
> > "ACME\Domain Users"*
> >
> > *[member user]:*
> >
> > *[member group]:*
> >
> > *  Group name: ad_users_external*
> >
> > *  Description: AD users external map*
> >
> > *  External member: *
> >
> > *  Member of groups: ad_users*
> >
> > *  Failed members:*
> >
> > *    member user:*
> >
> > *    member group: ACME\Domain Users: Cannot find specified domain or
> > server name*
> >
> > *-------------------------*
> >
> > *Number of members added 0*
> >
> >
> >
> >
> >
> > Any help would be appreciated
>
> Does
>
> ipa trustdomain-find windows.com
>
> show acme.windows.com as well ?
>
> Does
>
> ipa trust-fetch-domains ad.devel
>
> help to retrieve the child domain?
>
> Please note that if acme.windows.com now shows up you might have to wait
> 1-2 minutes until SSSD's negative caches are flushed and the new domains
> is discovered by SSSD, as an alternative you can just restart SSSD.
>
> HTH
>
> bye,
> Sumit
>
> >
> >
> >
> > Regards
>
> > --
> > 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141212/5b0e8cf2/attachment.htm>

From jeldo26 at live.com  Fri Dec 12 05:36:24 2014
From: jeldo26 at live.com (Eldo Joseph)
Date: Fri, 12 Dec 2014 05:36:24 +0000
Subject: [Freeipa-users] Trusted Realm Across IPA Servers
Message-ID: <SNT147-W566C135C7D901E47461DCCF600@phx.gbl>

Hi All,
I have requirement to access the service under different IPA servers, can some one help me on this... 
IPA Servers are running on V3. 
-Eldo-  		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141212/65ab5ef5/attachment.htm>

From sbose at redhat.com  Fri Dec 12 09:33:11 2014
From: sbose at redhat.com (Sumit Bose)
Date: Fri, 12 Dec 2014 10:33:11 +0100
Subject: [Freeipa-users] Forest trust and AD child domain
In-Reply-To: <CAKFNJrt_+GkUwDNuDhZLoGEFNfSV=omb=qCJfbJJq=RkXHxqnQ@mail.gmail.com>
References: <CAKFNJrsYA9M1j5cjH5kA4c6U9QGEr5pGd90QVRDWf8ajHk9tqw@mail.gmail.com>
	<20141211190542.GT14057@localhost.localdomain>
	<CAKFNJrt_+GkUwDNuDhZLoGEFNfSV=omb=qCJfbJJq=RkXHxqnQ@mail.gmail.com>
Message-ID: <20141212093311.GU14057@localhost.localdomain>

On Fri, Dec 12, 2014 at 02:06:05AM +0100, Manuel Lopes wrote:
> Hi Sumit,
> 
> Thank you very much for the prompt reply
> 
> [root at support1 ~]# ipa trustdomain-find windows.com
>   Domain name: windows.com
>   Domain NetBIOS name: WINDOWS
>   Domain Security Identifier: S-1-5-21-1701591335-3855227394-3044674468
>   Domain enabled: True
> 
>   Domain name: acme.windows.com
>   Domain NetBIOS name: ACME
>   Domain Security Identifier: S-1-5-21-1215373191-1991333051-3772904882
>   Domain enabled: True
> ----------------------------
> Number of entries returned 2
> ----------------------------

ok, so ACME was discovered successful, can you check next the output of

ipa idrange-find

The important attribute is the 'Range type' for the AD domains. If it is
'Active Directory trust range with POSIX attributes' it is expected that
users and groups in the AD forest have the POSIX UID and GID attributes
set and only those users and groups will be available in the IPA domain.
In this case please check if 'ACME\Domain Users' have the GID attribute
set.

If this does not help (please mind the negative cache of SSSD) please
send the SSSD logs in /var/log/sssd on the IPA server. You might need to
enable logging in sssd.conf by setting 'debug_level = 10' in the
[domain/..] and [nss] section of sssd.conf.

bye,
Sumit

> 
> [root at support1 ~]# ipa trust-fetch-domains windows.com
> -------------------------------
> No new trust domains were found
> -------------------------------
> ----------------------------
> Number of entries returned 0
> ----------------------------
> 
> Regards
> Le 11 d?c. 2014 20:08, "Sumit Bose" <sbose at redhat.com
> <javascript:_e(%7B%7D,'cvml','sbose at redhat.com');>> a ?crit :
> 
> > On Thu, Dec 11, 2014 at 06:45:49PM +0100, Manuel Lopes wrote:
> > >  Hello,
> > >
> > >
> > > We have been following the AD integration guide for IPAv3:
> > > http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup
> > >
> > >
> > >
> > > Our setup is:
> > >
> > > ? 2 domain controllers with Windows 2008 R2 AD DC -> windows.com
> > > <http://example.com/> as Forest Root Domain and acme.windows.com
> > > <http://acme.example.com/> as transitive child domain
> > >
> > > ? RHEL7 as IPA server with domain: linux.com
> > > <http://linux.acme.example.com/>
> > >
> > >
> > >
> > > We have established a forest trust between windows.com and linux.com and
> > > everything seems OK from an IPA perspective.
> > >
> > >
> > >
> > > We can work with Kerberos tickets without any issue from ?windows? domain
> > > or his child domain ?acme?. (kinit, kvno?)
> > >
> > >
> > >
> > > When we use samba tools, the following command is working fine.
> > >
> > > *[root at support1 ]# wbinfo -n 'WINDOWS\Domain Admins'*
> > >
> > > *S-1-5-21-1701591335-3855227394-3044674468-512 SID_DOM_GROUP (2)*
> > >
> > >
> > >
> > > But, the same command against the acme domain returns an error.
> > >
> > > *[root at support1 ]# wbinfo -n 'ACME\Domain Admins'*
> > >
> > > *failed to call wbcLookupName: WBC_ERR_DOMAIN_NOT_FOUND*
> > >
> > > *Could not lookup name ACME\Domain Admins*
> > >
> > >
> > >
> > > Same problem with the following command:
> > >
> > > *[root at support1]# ipa group-add-member ad_users_external --external
> > > "ACME\Domain Users"*
> > >
> > > *[member user]:*
> > >
> > > *[member group]:*
> > >
> > > *  Group name: ad_users_external*
> > >
> > > *  Description: AD users external map*
> > >
> > > *  External member: *
> > >
> > > *  Member of groups: ad_users*
> > >
> > > *  Failed members:*
> > >
> > > *    member user:*
> > >
> > > *    member group: ACME\Domain Users: Cannot find specified domain or
> > > server name*
> > >
> > > *-------------------------*
> > >
> > > *Number of members added 0*
> > >
> > >
> > >
> > >
> > >
> > > Any help would be appreciated
> >
> > Does
> >
> > ipa trustdomain-find windows.com
> >
> > show acme.windows.com as well ?
> >
> > Does
> >
> > ipa trust-fetch-domains ad.devel
> >
> > help to retrieve the child domain?
> >
> > Please note that if acme.windows.com now shows up you might have to wait
> > 1-2 minutes until SSSD's negative caches are flushed and the new domains
> > is discovered by SSSD, as an alternative you can just restart SSSD.
> >
> > HTH
> >
> > bye,
> > Sumit
> >
> > >
> > >
> > >
> > > Regards
> >
> > > --
> > > 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



From mkosek at redhat.com  Fri Dec 12 12:58:01 2014
From: mkosek at redhat.com (Martin Kosek)
Date: Fri, 12 Dec 2014 13:58:01 +0100
Subject: [Freeipa-users] freeipa / sudo
In-Reply-To: <5489BA82.4000609@redhat.com>
References: <DUB125-W16B0DB66FBF254466DC9FDCC620@phx.gbl>, ,
	<5488362D.4040609@redhat.com>,
	<DUB125-W201847FB050F16A133931CC620@phx.gbl>	<DUB125-W696A68B0EABE4DB4889F64CC620@phx.gbl>,
	<54894195.5090708@redhat.com>	<DUB125-W316148DDC6B645481224CFCC630@phx.gbl>,
	<5489661F.8040203@redhat.com>	<DUB125-W73BF7F9A8F95AEC8CCA0AFCC630@phx.gbl>	<54899769.5020600@redhat.com>
	<5489BA82.4000609@redhat.com>
Message-ID: <548AE659.90605@redhat.com>

On 12/11/2014 04:38 PM, Dmitri Pal wrote:
> On 12/11/2014 08:08 AM, Martin Kosek wrote:
>> On 12/11/2014 01:57 PM, Chris Card wrote:
>>>> On 12/11/2014 09:42 AM, Chris Card wrote:
>>>>>> On 12/10/2014 04:54 PM, Chris Card wrote:
>>>>>>>
>>>>>>>>> On 12/10/2014 12:57 PM, Chris Card wrote:
>>>>>>>> thanks Martin,
>>>>>>>>>> I've installed freeipa 4.1.1 on Fedora 21, and successfully set up a
>>>>>>>>>> freeipa server and a freeipa client machine.
>>>>>>>>>> I've set up a user with ssh keys, and can successfully ssh onto the
>>>>>>>>>> client machine.
>>>>>>>>>> I'm trying to setup sudo rules so that if the user is in a given user
>>>>>>>>>> group, then the user can run "sudo su -" on the client to become root.
>>>>>>>> <snip>
>>>>>>>>>> [root at fedora21-freeipa log]# ipa hostgroup-show
>>>>>>>>>> Host-group: cog
>>>>>>>>>> Host-group: cog
>>>>>>>>>> Member hosts: ipaclient21.testdomain21.com
>>>>>>>>>> Member of Sudo rule: All
>>>>>>>>>> [root at fedora21-freeipa log]# ipa sudorule-show All
>>>>>>>>>> Rule name: All
>>>>>>>>>> Enabled: TRUE
>>>>>>>>>> Command category: all
>>>>>>>>>> RunAs User category: all
>>>>>>>>>> RunAs Group category: all
>>>>>>>>>> User Groups: cog_rw
>>>>>>>>>> Host Groups: cog
>>>>>>>>>> Sudo Option: !authenticate
>>>>>>>>>>
>>>>>>>>>> but this setup doesn't work, i.e. even though the user is in the user
>>>>>>>>>> group and the client machine is in the host group, sudo su - fails.
>>>>>>>>>> Is this a bug, or have I missed something?
>>>>>>>>>>
>>>>>>>>>> Chris
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> With FreeIPA 4.1.1, client sudo integration should be automatically
>>>>>>>>> configured,
>>>>>>>>> so it should just work, including hostgroups. In your case, I would
>>>>>>>>> start with
>>>>>>>>> investigating
>>>>>>>>>
>>>>>>>>> http://www.freeipa.org/page/Troubleshooting#sudo_does_not_work_for_hostgroups
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> If that does not help, I bet SSSD devs will ask for logs.
>>>>>>>>>
>>>>>>>> I've done the troubleshooting steps:
>>>>>>>>
>>>>>>>> [root at ipaclient21 log]# nisdomainname
>>>>>>>> testdomain21.com
>>>>>>>> [root at ipaclient21 log]# getent netgroup cog
>>>>>>>> cog (ipaclient21.testdomain21.com,-,testdomain21.com)
>>>>>>>>
>>>>>>>> I tried adding sudoers_debug 2 to /etc/sudo-ldap.conf on the client
>>>>>>>> machine, but I'm not sure if that's the right file (it didn't exist
>>>>>>>> before).
>>>>>>>> I have debug_level set to 9 in /etc/sssd/sssd.conf, so I can see some
>>>>>>>> stuff in /var/log/sssd/sssd_testdomain21.com.log but no obvious error
>>>>>>>> messages.
>>>>>>> I worked out how to set up debug for sudo. sudoers_debug is deprecated
>>>>>>> now, but I created /etc/sssd.conf with a line
>>>>>>>
>>>>>>> Debug sudo /var/log/sudo_debug all at debug
>>>>>>>
>>>>>>> and I saw this in the debug output:
>>>>>>>
>>>>>>> Dec 10 15:42:57 sudo[10046] -> sudo_sss_check_host @ ./sssd.c:557
>>>>>>> Dec 10 15:42:57 sudo[10046] val[0]=+cog
>>>>>>> Dec 10 15:42:57 sudo[10046] -> addr_matches @ ./match_addr.c:189
>>>>>>> Dec 10 15:42:57 sudo[10046] -> addr_matches_if @ ./match_addr.c:61
>>>>>>> Dec 10 15:42:57 sudo[10046] <- addr_matches_if @ ./match_addr.c:99 := false
>>>>>>> Dec 10 15:42:57 sudo[10046] <- addr_matches @ ./match_addr.c:199 := false
>>>>>>> Dec 10 15:42:57 sudo[10046] -> netgr_matches @ ./match.c:899
>>>>>>> Dec 10 15:42:57 sudo[10046] <- netgr_matches @ ./match.c:918 := false
>>>>>>> Dec 10 15:42:57 sudo[10046] -> hostname_matches @ ./match.c:758
>>>>>>> Dec 10 15:42:57 sudo[10046] <- hostname_matches @ ./match.c:769 := false
>>>>>>> Dec 10 15:42:57 sudo[10046] sssd/ldap sudoHost '+cog' ... not
>>>>>>>
>>>>>>> The problem is that the hostname command on the client was returning a
>>>>>>> short hostname, ipaclient21, instead of a FQDN,
>>>>>>> ipaclient21.testdomain21.com and when I forced the hostname to be the
>>>>>>> FQDN the sudo command worked.
>>>>>>>
>>>>>>>
>>>>>>> The short hostname comes from the fact that the client machine is an
>>>>>>> openstack instance, and that appears to be a feature of openstack
>>>>>>> instances :(
>>>>>>
>>>>>> So on the OpenStack instance, even "hostname -f" does not show the FQDN? If
>>>>>> this is the case, I am not sure what we could do, sudo somehow needs to
>>>>>> learn
>>>>>> the FQDN.
>>>>>>
>>>>> I can set up the instance so that hostname -f returns the FQDN, but the
>>>>> only way I can get hostname to return the FQDN is if I explicitly run
>>>>> "hostname <FQDN>"; unfortunately this doesn't survive a reboot.
>>>> You should be able to just set the hostname to /etc/hostname (for older
>>>> platforms, it may also be in /etc/sysconfig/network) and it should survive the
>>>> reboot. I do not think that OpenStack really cares that much what hostname did
>>>> you set up in the system after the VM is created.
>>>>
>>>> At least my OpenStack VM with the FreeIPA demo works this way.
>>>>
>>> I found that simply editing /etc/hostname and rebooting didn't work, because
>>> cloud-init resets the hostname. But if I create the instance with a
>>> cloud-init script to set the hostname to the FQDN, and then reboot the
>>> instance after creation, /etc/hostname contains the FQDN and hostname
>>> returns the FQDN.
>>>
>>> Chris
>> Ah, right. I just remembered I also need to set it up with cloud-init. This is
>> the config I use for the FreeIPA demo:
>>
>> #cloud-config: FreeIPA cloud configuration
>> hostname: ipa.demo1.freeipa.org
>> fqdn: ipa.demo1.freeipa.org
>> manage_etc_hosts: false
>>
> Is it worth a howto? Seems like  a valuable piece of info...

It is, I added a task to my queue about generating howto with this and other 
updates I had to do to make FreeIPA demo run on OpenStack.



From mkosek at redhat.com  Fri Dec 12 13:00:26 2014
From: mkosek at redhat.com (Martin Kosek)
Date: Fri, 12 Dec 2014 14:00:26 +0100
Subject: [Freeipa-users] Replica re-initialization
In-Reply-To: <CACjq759+ZKi+u1nhgztiSPKA7OpSZtaeLRH+U2Bdw3vk8Vs6Yw@mail.gmail.com>
References: <CACjq759+ZKi+u1nhgztiSPKA7OpSZtaeLRH+U2Bdw3vk8Vs6Yw@mail.gmail.com>
Message-ID: <548AE6EA.4030609@redhat.com>

On 12/11/2014 06:19 PM, Matt Chesler wrote:
> I have a cluster of four IPA masters that should be performing fully meshed
> replication.  I discovered yesterday that a recently created user only existed
> on a single master.  After looking through all four masters, it appears that
> several recent updates only exist on one of the masters.  I do not see any
> replication errors in any of the logs, but I'm not 100% sure how far back this
> issue goes.

That's really strange, because AFAIK, DS replication module yells periodically 
if it cannot replicate so you should see it on the last errors log page.

> I do believe the one master with up-to-date data is a reliable
> representation of what the LDAP directory should look like.  I ran a
> reinitialize command (ipa-replica-manage re-initialize --from
> reliable-server.fqdn) on two of the out-of-date masters yesterday around 4pm
> EST.  It's now a little after 12pm EST and the "Update in progress" message is
> still scrolling by once a second on both terminals.  I'd greatly appreciate
> suggestions about a) how to determine the status of the reinitialize command
> and b) any other ideas about how to resolve this issue and monitor for it
> better in the future.  Thanks in advance for your help!

Thierry or Ludwig, any idea?



From leszek.mis at gmail.com  Fri Dec 12 13:51:37 2014
From: leszek.mis at gmail.com (crony)
Date: Fri, 12 Dec 2014 14:51:37 +0100
Subject: [Freeipa-users] IPA with Cross Realm Trust + AIX/Solaris/HPUX
Message-ID: <CAGw5isMg8UG+WZvBLg3ZmMghRcHSKhFxX22DAEP2WzkUOjcsVg@mail.gmail.com>

Hi List!
Our setup is:
?  2 domain controllers with Windows 2008 R2 AD DC
?  2x RHEL7 as IPA server with domain: linux.acme.example.com
?  example.com as Forest Root Domain and acme.example.com as transitive
child domain

We have established a cross realm trust between linux.acme.example.com and
acme.example.com.

It works great on RHEL 6 clients with SSSD1.9.X. The user groups are
assigned correctly and that is fine.

The question is : What about integration Unix systems like AIX6/7, Solaris
10/11 oraz HPUXv3 as IPA clients in such configuration? I found ex. here:
http://docs.fedoraproject.org/en-US/Fedora/15/html-single/FreeIPA_Guide/#Configuring_an_IPA_Client_on_AIX
 that it is possible, but will it  work with cross realm?  We will not find
there a modern sssd daemon.

Have you got any experience?

/l
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141212/a7649da7/attachment.htm>

From lkrispen at redhat.com  Fri Dec 12 13:53:59 2014
From: lkrispen at redhat.com (Ludwig Krispenz)
Date: Fri, 12 Dec 2014 14:53:59 +0100
Subject: [Freeipa-users] Replica re-initialization
In-Reply-To: <548AE6EA.4030609@redhat.com>
References: <CACjq759+ZKi+u1nhgztiSPKA7OpSZtaeLRH+U2Bdw3vk8Vs6Yw@mail.gmail.com>
	<548AE6EA.4030609@redhat.com>
Message-ID: <548AF377.5000209@redhat.com>


On 12/12/2014 02:00 PM, Martin Kosek wrote:
> On 12/11/2014 06:19 PM, Matt Chesler wrote:
>> I have a cluster of four IPA masters that should be performing fully 
>> meshed
>> replication.  I discovered yesterday that a recently created user 
>> only existed
>> on a single master.  After looking through all four masters, it 
>> appears that
>> several recent updates only exist on one of the masters.  I do not 
>> see any
>> replication errors in any of the logs, but I'm not 100% sure how far 
>> back this
>> issue goes.
>
> That's really strange, because AFAIK, DS replication module yells 
> periodically if it cannot replicate so you should see it on the last 
> errors log page.
>
>> I do believe the one master with up-to-date data is a reliable
>> representation of what the LDAP directory should look like.  I ran a
>> reinitialize command (ipa-replica-manage re-initialize --from
>> reliable-server.fqdn) on two of the out-of-date masters yesterday 
>> around 4pm
>> EST.  It's now a little after 12pm EST and the "Update in progress" 
>> message is
>> still scrolling by once a second on both terminals.  I'd greatly 
>> appreciate
>> suggestions about a) how to determine the status of the reinitialize 
>> command
>> and b) any other ideas about how to resolve this issue and monitor 
>> for it
>> better in the future.  Thanks in advance for your help!
you could check the nsds5replicaLastInitStatus: in the replication 
agreement. Is there any info in the DS error logs ?
  If init is not progressing there is a good chance you are running into 
bz 1166265, thierry is working on a fix.
if online initialization is not working, you could still try do it 
offline (export/import ldif files)
>
> Thierry or Ludwig, any idea?



From tbordaz at redhat.com  Fri Dec 12 13:53:12 2014
From: tbordaz at redhat.com (thierry bordaz)
Date: Fri, 12 Dec 2014 14:53:12 +0100
Subject: [Freeipa-users] Replica re-initialization
In-Reply-To: <548AE6EA.4030609@redhat.com>
References: <CACjq759+ZKi+u1nhgztiSPKA7OpSZtaeLRH+U2Bdw3vk8Vs6Yw@mail.gmail.com>
	<548AE6EA.4030609@redhat.com>
Message-ID: <548AF348.7040407@redhat.com>

On 12/12/2014 02:00 PM, Martin Kosek wrote:
> On 12/11/2014 06:19 PM, Matt Chesler wrote:
>> I have a cluster of four IPA masters that should be performing fully 
>> meshed
>> replication.  I discovered yesterday that a recently created user 
>> only existed
>> on a single master.  After looking through all four masters, it 
>> appears that
>> several recent updates only exist on one of the masters.  I do not 
>> see any
>> replication errors in any of the logs, but I'm not 100% sure how far 
>> back this
>> issue goes.
>
> That's really strange, because AFAIK, DS replication module yells 
> periodically if it cannot replicate so you should see it on the last 
> errors log page.

That should not occur. I remember a test case 
(https://fedorahosted.org/389/ticket/47788) where a transient error 
could conduct to an update being skipped.
Do you have access/errors logs since the missing entry was added.
Also would you dump the RUV on each of the masters (ldapsearch -D 
"cn=directory manager" -w xxx -b "<your 
suffix>"(&(objectclass=nstombstone)(nsUniqueId=ffffffff-ffffffff-ffffffff-ffffffff))" 


Are you able to reproduce this problem ?
>
>> I do believe the one master with up-to-date data is a reliable
>> representation of what the LDAP directory should look like.  I ran a
>> reinitialize command (ipa-replica-manage re-initialize --from
>> reliable-server.fqdn) on two of the out-of-date masters yesterday 
>> around 4pm
>> EST.  It's now a little after 12pm EST and the "Update in progress" 
>> message is
>> still scrolling by once a second on both terminals.  I'd greatly 
>> appreciate
>> suggestions about a) how to determine the status of the reinitialize 
>> command
>> and b) any other ideas about how to resolve this issue and monitor 
>> for it
>> better in the future.  Thanks in advance for your help!
>
> Thierry or Ludwig, any idea?

The replica agreement on the master should say when the total update is 
completed. But after 12h it looks very long.
You may monitor the number of sent entries (grep -c 
'2.16.840.1.113730.3.5.6' <replica log>/access) to see if it progressing.
If it is not progressing for several minutes, would you get a pstack of 
the master .

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141212/baee6211/attachment.htm>

From dpal at redhat.com  Fri Dec 12 13:55:20 2014
From: dpal at redhat.com (Dmitri Pal)
Date: Fri, 12 Dec 2014 08:55:20 -0500
Subject: [Freeipa-users] Trusted Realm Across IPA Servers
In-Reply-To: <SNT147-W566C135C7D901E47461DCCF600@phx.gbl>
References: <SNT147-W566C135C7D901E47461DCCF600@phx.gbl>
Message-ID: <548AF3C8.7040205@redhat.com>

On 12/12/2014 12:36 AM, Eldo Joseph wrote:
> Hi All,
>
> I have requirement to access the service under different IPA servers, 
> can some one help me on this...
>
> IPA Servers are running on V3.
>
> -Eldo-
>
>
Are you saying that you have different IPA domains that are not 
connected and you need to be able to log into a host from different domains?

If so you need:
a) Decide which domain is the primary domain for the host.
b) Join the host to the second domain
c) Manually configure the second authentication domain in sssd.
I am not sure whether the IPA back end would work. It might be worth a try.
If you configure the second back end as LDAP or LDAP + Kerberos it 
should be fine.
Ask on SSSD list for more help if needed.

You need to make sure that your:
- UIDs do not overlap between domains
- you use FQDN for users when login


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141212/4ea37735/attachment.htm>

From gianluca.cecchi at gmail.com  Fri Dec 12 13:57:17 2014
From: gianluca.cecchi at gmail.com (Gianluca Cecchi)
Date: Fri, 12 Dec 2014 14:57:17 +0100
Subject: [Freeipa-users] some problems after migrating from 3.0 to 3.3
Message-ID: <CAG2kNCx0Rhu8sRE2urN6_A-HOaL6nBHH5+-GSNuRB9DEikyD2Q@mail.gmail.com>

Hello,
I migrated a CentOS 6.6 system with IPA 3.0 to a CentOS 7.0 system with IPA
3.3.
The workflow was the one to create a replica and then decommission the old
one (that now is with services stopped) with the commands:

on old server:
 ipa-server-install --uninstall

on new server:
 ipa-replica-manage del infra.localdomain.local --force

I notice some things:
- every 5 minutes I get this
in /var/log/dirsrv/slapd-LOCALDOMAIN-LOCAL/errors of new server

[12/Dec/2014:14:29:48 +0100] slapi_ldap_bind - Error: could not send
startTLS request: error -1 (Can't contact LDAP server) errno 0 (Success)

I don't know if the error is related with the old server or anything else.
And if indeed it is a real error, as it writes Error, but there is
ambiguity in message (errno 0 and Success words). Do I have to care and fix?

- in CentOS 6.6 I had IPA with bind (9.8.2-0.23.rc1.el6_5.1), configured
with plain files:
# ll /var/named/data/*zone
-rw-r--r-- 1 root root 1244 Dec  6 14:35 /var/named/data/forward.zone
-rw-r--r-- 1 root root  912 Dec  6 14:35 /var/named/data/reverse.zone

After migration the bind configuration has been put under IPA with these
lines in named.conf:

dynamic-db "ipa" {
        library "ldap.so";
        arg "uri ldapi://%2fvar%2frun%2fslapd-LOCALDOMAIN-LOCAL.socket";
        arg "base cn=dns, dc=localdomain,dc=local";
        arg "fake_mname c7server.localdomain.local.";
        arg "auth_method sasl";
        arg "sasl_mech GSSAPI";
        arg "sasl_user DNS/c7server.localdomain.local";
        arg "serial_autoincrement yes";
};

It works but the old IPA server hostname (with hostname=infra)  is no more
resovable
I have that
nslookup hostname
works for every host that was previously defined inside the zone but the
previous ipa server...
(new ipa and dns server is c7server and has ip 192.168.1.81)

[root at c7server etc]# nslookup infra
Server:         192.168.1.81
Address:        192.168.1.81#53

** server can't find infra: NXDOMAIN

[root at c7server etc]# nslookup vc1
Server:         192.168.1.81
Address:        192.168.1.81#53

Name:   vc1.localdomain.local
Address: 192.168.1.92


- I have great difficulties entering in IPA web gui and so modifying dns
records from there
Many times I get the message that "your session has expired".
I put
KrbMethodK5Passwd on
in /etc/httpd/conf.d/ipa.conf but it seems it doesn't alway fix the
problem...
How to debug?

Thanks in advance
Gianluca
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141212/c7edbe2f/attachment.htm>

From dpal at redhat.com  Fri Dec 12 13:57:34 2014
From: dpal at redhat.com (Dmitri Pal)
Date: Fri, 12 Dec 2014 08:57:34 -0500
Subject: [Freeipa-users] IPA with Cross Realm Trust + AIX/Solaris/HPUX
In-Reply-To: <CAGw5isMg8UG+WZvBLg3ZmMghRcHSKhFxX22DAEP2WzkUOjcsVg@mail.gmail.com>
References: <CAGw5isMg8UG+WZvBLg3ZmMghRcHSKhFxX22DAEP2WzkUOjcsVg@mail.gmail.com>
Message-ID: <548AF44E.2010908@redhat.com>

On 12/12/2014 08:51 AM, crony wrote:
>
> Hi List!
> Our setup is:
> .  2 domain controllers with Windows 2008 R2 AD DC
> .  2x RHEL7 as IPA server with domain: linux.acme.example.com 
> <http://linux.acme.example.com>
> . example.com <http://example.com> as Forest Root Domain and 
> acme.example.com <http://acme.example.com> as transitive child domain
> We have established a cross realm trust between linux.acme.example.com 
> <http://linux.acme.example.com> and acme.example.com 
> <http://acme.example.com>.
>
> It works great on RHEL 6 clients with SSSD1.9.X. The user groups are 
> assigned correctly and that is fine.
>
> The question is : What about integration Unix systems like AIX6/7, 
> Solaris 10/11 oraz HPUXv3 as IPA clients in such configuration? I 
> found ex. here: 
> http://docs.fedoraproject.org/en-US/Fedora/15/html-single/FreeIPA_Guide/#Configuring_an_IPA_Client_on_AIX 
>  that it is possible, but will it  work with cross realm?  We will not 
> find there a modern sssd daemon.
>
> Have you got any experience?
>
> /l
>
>
You need to use this: 
http://www.freeipa.org/images/0/0d/FreeIPA33-legacy-clients.pdf

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141212/f04adcec/attachment.htm>

From mbasti at redhat.com  Fri Dec 12 14:13:56 2014
From: mbasti at redhat.com (Martin Basti)
Date: Fri, 12 Dec 2014 15:13:56 +0100
Subject: [Freeipa-users] some problems after migrating from 3.0 to 3.3
In-Reply-To: <CAG2kNCx0Rhu8sRE2urN6_A-HOaL6nBHH5+-GSNuRB9DEikyD2Q@mail.gmail.com>
References: <CAG2kNCx0Rhu8sRE2urN6_A-HOaL6nBHH5+-GSNuRB9DEikyD2Q@mail.gmail.com>
Message-ID: <548AF824.7030208@redhat.com>

On 12/12/14 14:57, Gianluca Cecchi wrote:

Hello, read inline comments.

> Hello,
> I migrated a CentOS 6.6 system with IPA 3.0 to a CentOS 7.0 system 
> with IPA 3.3.
> The workflow was the one to create a replica and then decommission the 
> old one (that now is with services stopped) with the commands:
>
> on old server:
>  ipa-server-install --uninstall
>
> on new server:
>  ipa-replica-manage del infra.localdomain.local --force
>
<snip>
>
> - in CentOS 6.6 I had IPA with bind (9.8.2-0.23.rc1.el6_5.1), 
> configured with plain files:
> # ll /var/named/data/*zone
> -rw-r--r-- 1 root root 1244 Dec  6 14:35 /var/named/data/forward.zone
> -rw-r--r-- 1 root root  912 Dec  6 14:35 /var/named/data/reverse.zone
>
> After migration the bind configuration has been put under IPA with 
> these lines in named.conf:
>
> dynamic-db "ipa" {
>         library "ldap.so";
>         arg "uri ldapi://%2fvar%2frun%2fslapd-LOCALDOMAIN-LOCAL.socket";
>         arg "base cn=dns, dc=localdomain,dc=local";
>         arg "fake_mname c7server.localdomain.local.";
>         arg "auth_method sasl";
>         arg "sasl_mech GSSAPI";
>         arg "sasl_user DNS/c7server.localdomain.local";
>         arg "serial_autoincrement yes";
> };
>
It is not clear for me, did you use IPA DNS before upgrade, or you just 
install IPA DNS after upgrade?

> It works but the old IPA server hostname (with hostname=infra)  is no 
> more resovable
> I have that
> nslookup hostname
> works for every host that was previously defined inside the zone but 
> the previous ipa server...
> (new ipa and dns server is c7server and has ip 192.168.1.81)
>
> [root at c7server etc]# nslookup infra
> Server:         192.168.1.81
> Address:        192.168.1.81#53
>
> ** server can't find infra: NXDOMAIN
>
> [root at c7server etc]# nslookup vc1
> Server:         192.168.1.81
> Address:        192.168.1.81#53
>
> Name:   vc1.localdomain.local
> Address: 192.168.1.92
>


IMO the behavior is expected, deleting old replica 'infra', should 
remove the DNS record of replica as well

try following command to detect if there is the infra replica record in LDAP

$ ipa dnsrecord-find localdomain.local



-- 
Martin Basti



From gianluca.cecchi at gmail.com  Fri Dec 12 14:37:36 2014
From: gianluca.cecchi at gmail.com (Gianluca Cecchi)
Date: Fri, 12 Dec 2014 15:37:36 +0100
Subject: [Freeipa-users] some problems after migrating from 3.0 to 3.3
In-Reply-To: <548AF824.7030208@redhat.com>
References: <CAG2kNCx0Rhu8sRE2urN6_A-HOaL6nBHH5+-GSNuRB9DEikyD2Q@mail.gmail.com>
	<548AF824.7030208@redhat.com>
Message-ID: <CAG2kNCwfjb9Yr_RBmyMm2pbxF3koffvJRbYuKd8A5fWw9_4BLQ@mail.gmail.com>

On Fri, Dec 12, 2014 at 3:13 PM, Martin Basti <mbasti at redhat.com> wrote:
>
> On 12/12/14 14:57, Gianluca Cecchi wrote:
>
> Hello, read inline comments.
>
>  Hello,
>> I migrated a CentOS 6.6 system with IPA 3.0 to a CentOS 7.0 system with
>> IPA 3.3.
>> The workflow was the one to create a replica and then decommission the
>> old one (that now is with services stopped) with the commands:
>>
>> on old server:
>>  ipa-server-install --uninstall
>>
>> on new server:
>>  ipa-replica-manage del infra.localdomain.local --force
>>
>>
>> [snip]

>
>>  It is not clear for me, did you use IPA DNS before upgrade, or you just
> install IPA DNS after upgrade?


I followed chapter 6 of
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/upgrading.html

In IPA 3.0 I preconfigured DNS and then installed IPA with
# ipa-server-install
and at the end

"
....
Setup complete

Next steps:
1. You must make sure these network ports are open:
TCP Ports:
  * 80, 443: HTTP/HTTPS
  * 389, 636: LDAP/LDAPS
  * 88, 464: kerberos
UDP Ports:
  * 88, 464: kerberos
  * 123: ntp

2. You can now obtain a kerberos ticket using the command: 'kinit admin'
   This ticket will allow you to use the IPA tools (e.g., ipa user-add)
   and the web user interface.

Be sure to back up the CA certificate stored in /root/cacert.p12
This file is required to create replicas. The password for this
file is the Directory Manager password
"

When I updated to 3.3, as part of the suggested documentation I created the
replica file on old server and then used this command on new server:
# ipa-replica-install --setup-ca --ip-address=192.168.1.81 -p my_password
-w my_password -N --setup-dns --forwarder=192.168.1.254 -U
/var/lib/ipa/replica-info-c7server.localdomain.local.gpg

And this way it should automatically embed the dns part into IPA, correct?


>
>  It works but the old IPA server hostname (with hostname=infra)  is no
>> more resovable
>>
>
[snip]


> IMO the behavior is expected, deleting old replica 'infra', should remove
> the DNS record of replica as well
>

OK. I was able to access the web gui (this time..) and in fact the infra
entry was not present neither in forward nor in reverse zone, so I added it
and now it is ok:

[root at c7server etc]# nslookup infra
Server:         192.168.1.81
Address:        192.168.1.81#53

Name:   infra.localdomain.local
Address: 192.168.1.62



> try following command to detect if there is the infra replica record in
> LDAP
>
> $ ipa dnsrecord-find localdomain.local
>
>
It now returns 22 entries and also the added one for infra hostname

 [root at c7server etc]# kinit admin
Password for admin at LOCALDOMAIN.LOCAL:
[root at c7server etc]#  ipa dnsrecord-find localdomain.local
  Record name: @
  NS record: c7server.localdomain.local.

  Record name: _kerberos
  TXT record: LOCALDOMAIN.LOCAL

...

 Record name: infra
  A record: 192.168.1.62

...

Thanks,
I will check if web UI gives again the problem I had yesterday with the
expired session message...

Gianluca
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141212/3508d4fb/attachment.htm>

From sergey57 at gmail.com  Fri Dec 12 18:06:31 2014
From: sergey57 at gmail.com (sergey ivanov)
Date: Fri, 12 Dec 2014 13:06:31 -0500
Subject: [Freeipa-users] Some problems with uninstalling and reinstalling of
	ipa-client.
Message-ID: <CAAv=BDE7LUA-znELKxkvMHVMqmZbCVm5v1DGQ_-1J3cDX9CHnA@mail.gmail.com>

Hi,
I have a few problems with ipa client installations against ipa server.

The history which led to these problems are tho following.

1. I have first installed Freeipa server on Fedora-20, and was testing
and evaluating how it works and what are the features for a while.
2. While I was evaluating, Red Hat published RHEL-7. I tested
ipa-client integration from RHEL-7 destkops to Fedora's FreeIPA
server. It was working fine. Also I noticed that the features I needed
exists in RHEL-7 supported IPA server.
3. Because there was no way to upgrade or migrate data from Fedora's
FreeIPA to RHEL-7 IPA, I made new fresh installation of IPA server on
RHEL-7 and wanted to move clients off Fedora's domain and join new
one, although they had the same domain name for DNS and kerberos.
4. I ran "ipa-client-install --uninstall" on RHEL-7 destkop, and
rebooted it when prompted.
5. I ran "ipa-client-install" to joun new IPA servers, it reported success.

Now I have the following working:
1. I can ssh passwordless and without ssh public keys from hosts which
have good kerberos ticket obtained from RHEL-7 ipa server to this
problematic desktop computer.
2. I can see users there by typing "id <username>".
3. Password sudo authentication against IPA on this computer.

What does not work:
1. local login with IPA credentials: complains about wrong password.
2. SSH from other hosts with password authentication, - the same
"wrong password".

I tried as a temporary workaround and created local user entry in /etc/shadow by
---
getent passwd <username> >> /etc/passwd
pwconv
chpasswd
<username>:<anotherpassword>
^D
---
and was able to login with this password, both local and remotely with
ssh. Interesting, I've verified: IPA password works for sudo but not
for login. But:
1. I was not able to use Gnome desktop environment: all windows were
black rectangles. KDE was working fine.
2. I was not able to point firefox to new IPA server: "Your
certificate contains the same serial number as another certificate
issued by the certificate authority. Please get a new certificate
containing a unique serial number. (Error code:
sec_error_reused_issuer_and_serial)" Where firefox stores these
certificates, and how I can replace the one from Fedora's FreeIPA
server authority by new ones?


-- 
Regards,
Sergey Ivanov | sergey57 at gmail.com
http://www.linkedin.com/pub/sergey-ivanov/8/270/a09



From simo at redhat.com  Fri Dec 12 18:07:56 2014
From: simo at redhat.com (Simo Sorce)
Date: Fri, 12 Dec 2014 13:07:56 -0500
Subject: [Freeipa-users] Host based 2FA ?
In-Reply-To: <548A28FE.7030000@redhat.com>
References: <alpine.DEB.2.02.1412111523250.24600@e.crebbs.net>
	<548A28FE.7030000@redhat.com>
Message-ID: <20141212130756.4ec59d40@willson.usersys.redhat.com>

On Thu, 11 Dec 2014 18:30:06 -0500
Dmitri Pal <dpal at redhat.com> wrote:

> On 12/11/2014 06:32 PM, freeipa at pettyvices.com wrote:
> >
> > I'd like to be able to require 2FA on *certain* hosts and allow
> > just passwords on others.
> >
> > It seems you can check both "passwords" and "2FA" under the user.
> >
> > I was hoping I could create a HBAC such that certain hosts would
> > only allow 2FA, but I can't see an obvious way to do that.
> >
> > Is it possible?  Help on how would be great.  If not, feature
> > request?
> >
> > thanks,
> >
> > -t
> >
> We have several tickets:
> 
> https://fedorahosted.org/freeipa/ticket/433
> 
> https://fedorahosted.org/freeipa/ticket/3659
> 
> https://fedorahosted.org/freeipa/ticket/4498
> 
> If you see https://fedorahosted.org/freeipa/ticket/4498#comment:6 we 
> discussed this use case.
> And I was about to fork it as said but then I realized that there is
> not good way on the KDC to determine the host you are coming from.
> So IMO it should be a policy decision on SSSD.
> There are two options:
> - short term solution: allow SSSD to have a local overwrite to
> require OTP if server offers different options.
> - longer term solution: actually have a per host policy that is 
> centrally managed that is fetched per host and enforced by SSSD.
> 
> Before filing tickets I would like to hear opinions on the matter.

If we are using a FAST channel using the credentials of the host then
you may be able to know (probably requires changes in the KDC to
internally retain/convey the information).
This is possible via SSSD, but will not work via kinit done by a
generic user, so normal kinit's would require 2FA all the time.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York



From dpal at redhat.com  Fri Dec 12 18:17:18 2014
From: dpal at redhat.com (Dmitri Pal)
Date: Fri, 12 Dec 2014 13:17:18 -0500
Subject: [Freeipa-users] Host based 2FA ?
In-Reply-To: <20141212130756.4ec59d40@willson.usersys.redhat.com>
References: <alpine.DEB.2.02.1412111523250.24600@e.crebbs.net>	<548A28FE.7030000@redhat.com>
	<20141212130756.4ec59d40@willson.usersys.redhat.com>
Message-ID: <548B312E.7080703@redhat.com>

On 12/12/2014 01:07 PM, Simo Sorce wrote:
> On Thu, 11 Dec 2014 18:30:06 -0500
> Dmitri Pal <dpal at redhat.com> wrote:
>
>> On 12/11/2014 06:32 PM, freeipa at pettyvices.com wrote:
>>> I'd like to be able to require 2FA on *certain* hosts and allow
>>> just passwords on others.
>>>
>>> It seems you can check both "passwords" and "2FA" under the user.
>>>
>>> I was hoping I could create a HBAC such that certain hosts would
>>> only allow 2FA, but I can't see an obvious way to do that.
>>>
>>> Is it possible?  Help on how would be great.  If not, feature
>>> request?
>>>
>>> thanks,
>>>
>>> -t
>>>
>> We have several tickets:
>>
>> https://fedorahosted.org/freeipa/ticket/433
>>
>> https://fedorahosted.org/freeipa/ticket/3659
>>
>> https://fedorahosted.org/freeipa/ticket/4498
>>
>> If you see https://fedorahosted.org/freeipa/ticket/4498#comment:6 we
>> discussed this use case.
>> And I was about to fork it as said but then I realized that there is
>> not good way on the KDC to determine the host you are coming from.
>> So IMO it should be a policy decision on SSSD.
>> There are two options:
>> - short term solution: allow SSSD to have a local overwrite to
>> require OTP if server offers different options.
>> - longer term solution: actually have a per host policy that is
>> centrally managed that is fetched per host and enforced by SSSD.
>>
>> Before filing tickets I would like to hear opinions on the matter.
> If we are using a FAST channel using the credentials of the host then
> you may be able to know (probably requires changes in the KDC to
> internally retain/convey the information).
> This is possible via SSSD, but will not work via kinit done by a
> generic user, so normal kinit's would require 2FA all the time.
>
> Simo.
>
Can kinit do FAST? Is there some kind of kinit flag to use FAST?
May be in such setup we will require all clients to use FAST for the 
accounts that have several options configured.
Then we will know the principal used to armor the connection and can 
make policy decisions based on it.

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.



From simo at redhat.com  Fri Dec 12 18:27:53 2014
From: simo at redhat.com (Simo Sorce)
Date: Fri, 12 Dec 2014 13:27:53 -0500
Subject: [Freeipa-users] Host based 2FA ?
In-Reply-To: <548B312E.7080703@redhat.com>
References: <alpine.DEB.2.02.1412111523250.24600@e.crebbs.net>
	<548A28FE.7030000@redhat.com>
	<20141212130756.4ec59d40@willson.usersys.redhat.com>
	<548B312E.7080703@redhat.com>
Message-ID: <20141212132753.534b7187@willson.usersys.redhat.com>

On Fri, 12 Dec 2014 13:17:18 -0500
Dmitri Pal <dpal at redhat.com> wrote:

> On 12/12/2014 01:07 PM, Simo Sorce wrote:
> > On Thu, 11 Dec 2014 18:30:06 -0500
> > Dmitri Pal <dpal at redhat.com> wrote:
> >
> >> On 12/11/2014 06:32 PM, freeipa at pettyvices.com wrote:
> >>> I'd like to be able to require 2FA on *certain* hosts and allow
> >>> just passwords on others.
> >>>
> >>> It seems you can check both "passwords" and "2FA" under the user.
> >>>
> >>> I was hoping I could create a HBAC such that certain hosts would
> >>> only allow 2FA, but I can't see an obvious way to do that.
> >>>
> >>> Is it possible?  Help on how would be great.  If not, feature
> >>> request?
> >>>
> >>> thanks,
> >>>
> >>> -t
> >>>
> >> We have several tickets:
> >>
> >> https://fedorahosted.org/freeipa/ticket/433
> >>
> >> https://fedorahosted.org/freeipa/ticket/3659
> >>
> >> https://fedorahosted.org/freeipa/ticket/4498
> >>
> >> If you see https://fedorahosted.org/freeipa/ticket/4498#comment:6
> >> we discussed this use case.
> >> And I was about to fork it as said but then I realized that there
> >> is not good way on the KDC to determine the host you are coming
> >> from. So IMO it should be a policy decision on SSSD.
> >> There are two options:
> >> - short term solution: allow SSSD to have a local overwrite to
> >> require OTP if server offers different options.
> >> - longer term solution: actually have a per host policy that is
> >> centrally managed that is fetched per host and enforced by SSSD.
> >>
> >> Before filing tickets I would like to hear opinions on the matter.
> > If we are using a FAST channel using the credentials of the host
> > then you may be able to know (probably requires changes in the KDC
> > to internally retain/convey the information).
> > This is possible via SSSD, but will not work via kinit done by a
> > generic user, so normal kinit's would require 2FA all the time.
> >
> > Simo.
> >
> Can kinit do FAST? Is there some kind of kinit flag to use FAST?

Yes kinit can do FAST, but is cumbersome to manually do it.

> May be in such setup we will require all clients to use FAST for the 
> accounts that have several options configured.

It won't help, users do not have access to the host keys so they can't
do FAST with *those* keys.

> Then we will know the principal used to armor the connection and can 
> make policy decisions based on it.

We can do this with SSSD because it has access to the host key, being a
privileged process. Normal user's can't.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York



From dpal at redhat.com  Fri Dec 12 18:29:55 2014
From: dpal at redhat.com (Dmitri Pal)
Date: Fri, 12 Dec 2014 13:29:55 -0500
Subject: [Freeipa-users] Some problems with uninstalling and
 reinstalling of ipa-client.
In-Reply-To: <CAAv=BDE7LUA-znELKxkvMHVMqmZbCVm5v1DGQ_-1J3cDX9CHnA@mail.gmail.com>
References: <CAAv=BDE7LUA-znELKxkvMHVMqmZbCVm5v1DGQ_-1J3cDX9CHnA@mail.gmail.com>
Message-ID: <548B3423.2020102@redhat.com>

On 12/12/2014 01:06 PM, sergey ivanov wrote:
> Hi,
> I have a few problems with ipa client installations against ipa server.
>
> The history which led to these problems are tho following.
>
> 1. I have first installed Freeipa server on Fedora-20, and was testing
> and evaluating how it works and what are the features for a while.
> 2. While I was evaluating, Red Hat published RHEL-7. I tested
> ipa-client integration from RHEL-7 destkops to Fedora's FreeIPA
> server. It was working fine. Also I noticed that the features I needed
> exists in RHEL-7 supported IPA server.
> 3. Because there was no way to upgrade or migrate data from Fedora's
> FreeIPA to RHEL-7 IPA, I made new fresh installation of IPA server on
> RHEL-7 and wanted to move clients off Fedora's domain and join new
> one, although they had the same domain name for DNS and kerberos.
> 4. I ran "ipa-client-install --uninstall" on RHEL-7 destkop, and
> rebooted it when prompted.
> 5. I ran "ipa-client-install" to joun new IPA servers, it reported success.
>
> Now I have the following working:
> 1. I can ssh passwordless and without ssh public keys from hosts which
> have good kerberos ticket obtained from RHEL-7 ipa server to this
> problematic desktop computer.
> 2. I can see users there by typing "id <username>".
> 3. Password sudo authentication against IPA on this computer.
>
> What does not work:
> 1. local login with IPA credentials: complains about wrong password.
> 2. SSH from other hosts with password authentication, - the same
> "wrong password".
>
> I tried as a temporary workaround and created local user entry in /etc/shadow by
> ---
> getent passwd <username> >> /etc/passwd
> pwconv
> chpasswd
> <username>:<anotherpassword>
> ^D
> ---
> and was able to login with this password, both local and remotely with
> ssh. Interesting, I've verified: IPA password works for sudo but not
> for login. But:
> 1. I was not able to use Gnome desktop environment: all windows were
> black rectangles. KDE was working fine.
> 2. I was not able to point firefox to new IPA server: "Your
> certificate contains the same serial number as another certificate
> issued by the certificate authority. Please get a new certificate
> containing a unique serial number. (Error code:
> sec_error_reused_issuer_and_serial)" Where firefox stores these
> certificates, and how I can replace the one from Fedora's FreeIPA
> server authority by new ones?
>
>
Preferences -> Advanced -> Certificates tab -> View Certificates button 
-> Servers tab

I think if you delete it and then try accessing IPA with the browser 
again it will do the trick.


As for password authentication I suggest you check your PAM and SSSD 
configuration.
Add debug_level=10 to pam, nss and domain sections and restart SSSD.
I suspect that something is not right there. May be the --uninstall 
actually did not clean everything.

In general it seems like SSSD/PAM is somehow misconfigured.

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.



From dpal at redhat.com  Fri Dec 12 18:32:03 2014
From: dpal at redhat.com (Dmitri Pal)
Date: Fri, 12 Dec 2014 13:32:03 -0500
Subject: [Freeipa-users] Host based 2FA ?
In-Reply-To: <20141212132753.534b7187@willson.usersys.redhat.com>
References: <alpine.DEB.2.02.1412111523250.24600@e.crebbs.net>	<548A28FE.7030000@redhat.com>	<20141212130756.4ec59d40@willson.usersys.redhat.com>	<548B312E.7080703@redhat.com>
	<20141212132753.534b7187@willson.usersys.redhat.com>
Message-ID: <548B34A3.4010603@redhat.com>

On 12/12/2014 01:27 PM, Simo Sorce wrote:
> On Fri, 12 Dec 2014 13:17:18 -0500
> Dmitri Pal <dpal at redhat.com> wrote:
>
>> On 12/12/2014 01:07 PM, Simo Sorce wrote:
>>> On Thu, 11 Dec 2014 18:30:06 -0500
>>> Dmitri Pal <dpal at redhat.com> wrote:
>>>
>>>> On 12/11/2014 06:32 PM, freeipa at pettyvices.com wrote:
>>>>> I'd like to be able to require 2FA on *certain* hosts and allow
>>>>> just passwords on others.
>>>>>
>>>>> It seems you can check both "passwords" and "2FA" under the user.
>>>>>
>>>>> I was hoping I could create a HBAC such that certain hosts would
>>>>> only allow 2FA, but I can't see an obvious way to do that.
>>>>>
>>>>> Is it possible?  Help on how would be great.  If not, feature
>>>>> request?
>>>>>
>>>>> thanks,
>>>>>
>>>>> -t
>>>>>
>>>> We have several tickets:
>>>>
>>>> https://fedorahosted.org/freeipa/ticket/433
>>>>
>>>> https://fedorahosted.org/freeipa/ticket/3659
>>>>
>>>> https://fedorahosted.org/freeipa/ticket/4498
>>>>
>>>> If you see https://fedorahosted.org/freeipa/ticket/4498#comment:6
>>>> we discussed this use case.
>>>> And I was about to fork it as said but then I realized that there
>>>> is not good way on the KDC to determine the host you are coming
>>>> from. So IMO it should be a policy decision on SSSD.
>>>> There are two options:
>>>> - short term solution: allow SSSD to have a local overwrite to
>>>> require OTP if server offers different options.
>>>> - longer term solution: actually have a per host policy that is
>>>> centrally managed that is fetched per host and enforced by SSSD.
>>>>
>>>> Before filing tickets I would like to hear opinions on the matter.
>>> If we are using a FAST channel using the credentials of the host
>>> then you may be able to know (probably requires changes in the KDC
>>> to internally retain/convey the information).
>>> This is possible via SSSD, but will not work via kinit done by a
>>> generic user, so normal kinit's would require 2FA all the time.
>>>
>>> Simo.
>>>
>> Can kinit do FAST? Is there some kind of kinit flag to use FAST?
> Yes kinit can do FAST, but is cumbersome to manually do it.
>
>> May be in such setup we will require all clients to use FAST for the
>> accounts that have several options configured.
> It won't help, users do not have access to the host keys so they can't
> do FAST with *those* keys.
>
>> Then we will know the principal used to armor the connection and can
>> make policy decisions based on it.
> We can do this with SSSD because it has access to the host key, being a
> privileged process. Normal user's can't.
>
> Simo.
>
What about kinit working with GSS proxy in this case?
Can that help?
May be we can convince MIT to add an option to proxy kinit via GSS proxy 
and use GSS proxy to armor?

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.



From dpal at redhat.com  Fri Dec 12 18:37:53 2014
From: dpal at redhat.com (Dmitri Pal)
Date: Fri, 12 Dec 2014 13:37:53 -0500
Subject: [Freeipa-users] Host based 2FA ?
In-Reply-To: <548B34A3.4010603@redhat.com>
References: <alpine.DEB.2.02.1412111523250.24600@e.crebbs.net>	<548A28FE.7030000@redhat.com>	<20141212130756.4ec59d40@willson.usersys.redhat.com>	<548B312E.7080703@redhat.com>	<20141212132753.534b7187@willson.usersys.redhat.com>
	<548B34A3.4010603@redhat.com>
Message-ID: <548B3601.1010701@redhat.com>

On 12/12/2014 01:32 PM, Dmitri Pal wrote:
> On 12/12/2014 01:27 PM, Simo Sorce wrote:
>> On Fri, 12 Dec 2014 13:17:18 -0500
>> Dmitri Pal <dpal at redhat.com> wrote:
>>
>>> On 12/12/2014 01:07 PM, Simo Sorce wrote:
>>>> On Thu, 11 Dec 2014 18:30:06 -0500
>>>> Dmitri Pal <dpal at redhat.com> wrote:
>>>>
>>>>> On 12/11/2014 06:32 PM, freeipa at pettyvices.com wrote:
>>>>>> I'd like to be able to require 2FA on *certain* hosts and allow
>>>>>> just passwords on others.
>>>>>>
>>>>>> It seems you can check both "passwords" and "2FA" under the user.
>>>>>>
>>>>>> I was hoping I could create a HBAC such that certain hosts would
>>>>>> only allow 2FA, but I can't see an obvious way to do that.
>>>>>>
>>>>>> Is it possible?  Help on how would be great.  If not, feature
>>>>>> request?
>>>>>>
>>>>>> thanks,
>>>>>>
>>>>>> -t
>>>>>>
>>>>> We have several tickets:
>>>>>
>>>>> https://fedorahosted.org/freeipa/ticket/433
>>>>>
>>>>> https://fedorahosted.org/freeipa/ticket/3659
>>>>>
>>>>> https://fedorahosted.org/freeipa/ticket/4498
>>>>>
>>>>> If you see https://fedorahosted.org/freeipa/ticket/4498#comment:6
>>>>> we discussed this use case.
>>>>> And I was about to fork it as said but then I realized that there
>>>>> is not good way on the KDC to determine the host you are coming
>>>>> from. So IMO it should be a policy decision on SSSD.
>>>>> There are two options:
>>>>> - short term solution: allow SSSD to have a local overwrite to
>>>>> require OTP if server offers different options.
>>>>> - longer term solution: actually have a per host policy that is
>>>>> centrally managed that is fetched per host and enforced by SSSD.
>>>>>
>>>>> Before filing tickets I would like to hear opinions on the matter.
>>>> If we are using a FAST channel using the credentials of the host
>>>> then you may be able to know (probably requires changes in the KDC
>>>> to internally retain/convey the information).
>>>> This is possible via SSSD, but will not work via kinit done by a
>>>> generic user, so normal kinit's would require 2FA all the time.
>>>>
>>>> Simo.
>>>>
>>> Can kinit do FAST? Is there some kind of kinit flag to use FAST?
>> Yes kinit can do FAST, but is cumbersome to manually do it.
>>
>>> May be in such setup we will require all clients to use FAST for the
>>> accounts that have several options configured.
>> It won't help, users do not have access to the host keys so they can't
>> do FAST with *those* keys.
>>
>>> Then we will know the principal used to armor the connection and can
>>> make policy decisions based on it.
>> We can do this with SSSD because it has access to the host key, being a
>> privileged process. Normal user's can't.
>>
>> Simo.
>>
> What about kinit working with GSS proxy in this case?
> Can that help?
> May be we can convince MIT to add an option to proxy kinit via GSS 
> proxy and use GSS proxy to armor?
>
Also is kinit is a requirement?
AFAIK if kinit is used and not is going via FAST then OTP is not 
possible at all.
So we can have a policy to allow or not allow any authentication without 
FAST.

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.



From simo at redhat.com  Fri Dec 12 18:38:40 2014
From: simo at redhat.com (Simo Sorce)
Date: Fri, 12 Dec 2014 13:38:40 -0500
Subject: [Freeipa-users] Host based 2FA ?
In-Reply-To: <548B34A3.4010603@redhat.com>
References: <alpine.DEB.2.02.1412111523250.24600@e.crebbs.net>
	<548A28FE.7030000@redhat.com>
	<20141212130756.4ec59d40@willson.usersys.redhat.com>
	<548B312E.7080703@redhat.com>
	<20141212132753.534b7187@willson.usersys.redhat.com>
	<548B34A3.4010603@redhat.com>
Message-ID: <20141212133840.6f131695@willson.usersys.redhat.com>

On Fri, 12 Dec 2014 13:32:03 -0500
Dmitri Pal <dpal at redhat.com> wrote:

> On 12/12/2014 01:27 PM, Simo Sorce wrote:
> > On Fri, 12 Dec 2014 13:17:18 -0500
> > Dmitri Pal <dpal at redhat.com> wrote:
> >
> >> On 12/12/2014 01:07 PM, Simo Sorce wrote:
> >>> On Thu, 11 Dec 2014 18:30:06 -0500
> >>> Dmitri Pal <dpal at redhat.com> wrote:
> >>>
> >>>> On 12/11/2014 06:32 PM, freeipa at pettyvices.com wrote:
> >>>>> I'd like to be able to require 2FA on *certain* hosts and allow
> >>>>> just passwords on others.
> >>>>>
> >>>>> It seems you can check both "passwords" and "2FA" under the
> >>>>> user.
> >>>>>
> >>>>> I was hoping I could create a HBAC such that certain hosts would
> >>>>> only allow 2FA, but I can't see an obvious way to do that.
> >>>>>
> >>>>> Is it possible?  Help on how would be great.  If not, feature
> >>>>> request?
> >>>>>
> >>>>> thanks,
> >>>>>
> >>>>> -t
> >>>>>
> >>>> We have several tickets:
> >>>>
> >>>> https://fedorahosted.org/freeipa/ticket/433
> >>>>
> >>>> https://fedorahosted.org/freeipa/ticket/3659
> >>>>
> >>>> https://fedorahosted.org/freeipa/ticket/4498
> >>>>
> >>>> If you see https://fedorahosted.org/freeipa/ticket/4498#comment:6
> >>>> we discussed this use case.
> >>>> And I was about to fork it as said but then I realized that there
> >>>> is not good way on the KDC to determine the host you are coming
> >>>> from. So IMO it should be a policy decision on SSSD.
> >>>> There are two options:
> >>>> - short term solution: allow SSSD to have a local overwrite to
> >>>> require OTP if server offers different options.
> >>>> - longer term solution: actually have a per host policy that is
> >>>> centrally managed that is fetched per host and enforced by SSSD.
> >>>>
> >>>> Before filing tickets I would like to hear opinions on the
> >>>> matter.
> >>> If we are using a FAST channel using the credentials of the host
> >>> then you may be able to know (probably requires changes in the KDC
> >>> to internally retain/convey the information).
> >>> This is possible via SSSD, but will not work via kinit done by a
> >>> generic user, so normal kinit's would require 2FA all the time.
> >>>
> >>> Simo.
> >>>
> >> Can kinit do FAST? Is there some kind of kinit flag to use FAST?
> > Yes kinit can do FAST, but is cumbersome to manually do it.
> >
> >> May be in such setup we will require all clients to use FAST for
> >> the accounts that have several options configured.
> > It won't help, users do not have access to the host keys so they
> > can't do FAST with *those* keys.
> >
> >> Then we will know the principal used to armor the connection and
> >> can make policy decisions based on it.
> > We can do this with SSSD because it has access to the host key,
> > being a privileged process. Normal user's can't.
> >
> > Simo.
> >
> What about kinit working with GSS proxy in this case?
> Can that help?

No, kinit does not use GSSAPI.

Simo.

> May be we can convince MIT to add an option to proxy kinit via GSS
> proxy and use GSS proxy to armor?
> 



-- 
Simo Sorce * Red Hat, Inc * New York



From dpal at redhat.com  Fri Dec 12 18:49:24 2014
From: dpal at redhat.com (Dmitri Pal)
Date: Fri, 12 Dec 2014 13:49:24 -0500
Subject: [Freeipa-users] Host based 2FA ?
In-Reply-To: <20141212133840.6f131695@willson.usersys.redhat.com>
References: <alpine.DEB.2.02.1412111523250.24600@e.crebbs.net>	<548A28FE.7030000@redhat.com>	<20141212130756.4ec59d40@willson.usersys.redhat.com>	<548B312E.7080703@redhat.com>	<20141212132753.534b7187@willson.usersys.redhat.com>	<548B34A3.4010603@redhat.com>
	<20141212133840.6f131695@willson.usersys.redhat.com>
Message-ID: <548B38B4.2070401@redhat.com>

On 12/12/2014 01:38 PM, Simo Sorce wrote:
> On Fri, 12 Dec 2014 13:32:03 -0500
> Dmitri Pal <dpal at redhat.com> wrote:
>
>> On 12/12/2014 01:27 PM, Simo Sorce wrote:
>>> On Fri, 12 Dec 2014 13:17:18 -0500
>>> Dmitri Pal <dpal at redhat.com> wrote:
>>>
>>>> On 12/12/2014 01:07 PM, Simo Sorce wrote:
>>>>> On Thu, 11 Dec 2014 18:30:06 -0500
>>>>> Dmitri Pal <dpal at redhat.com> wrote:
>>>>>
>>>>>> On 12/11/2014 06:32 PM, freeipa at pettyvices.com wrote:
>>>>>>> I'd like to be able to require 2FA on *certain* hosts and allow
>>>>>>> just passwords on others.
>>>>>>>
>>>>>>> It seems you can check both "passwords" and "2FA" under the
>>>>>>> user.
>>>>>>>
>>>>>>> I was hoping I could create a HBAC such that certain hosts would
>>>>>>> only allow 2FA, but I can't see an obvious way to do that.
>>>>>>>
>>>>>>> Is it possible?  Help on how would be great.  If not, feature
>>>>>>> request?
>>>>>>>
>>>>>>> thanks,
>>>>>>>
>>>>>>> -t
>>>>>>>
>>>>>> We have several tickets:
>>>>>>
>>>>>> https://fedorahosted.org/freeipa/ticket/433
>>>>>>
>>>>>> https://fedorahosted.org/freeipa/ticket/3659
>>>>>>
>>>>>> https://fedorahosted.org/freeipa/ticket/4498
>>>>>>
>>>>>> If you see https://fedorahosted.org/freeipa/ticket/4498#comment:6
>>>>>> we discussed this use case.
>>>>>> And I was about to fork it as said but then I realized that there
>>>>>> is not good way on the KDC to determine the host you are coming
>>>>>> from. So IMO it should be a policy decision on SSSD.
>>>>>> There are two options:
>>>>>> - short term solution: allow SSSD to have a local overwrite to
>>>>>> require OTP if server offers different options.
>>>>>> - longer term solution: actually have a per host policy that is
>>>>>> centrally managed that is fetched per host and enforced by SSSD.
>>>>>>
>>>>>> Before filing tickets I would like to hear opinions on the
>>>>>> matter.
>>>>> If we are using a FAST channel using the credentials of the host
>>>>> then you may be able to know (probably requires changes in the KDC
>>>>> to internally retain/convey the information).
>>>>> This is possible via SSSD, but will not work via kinit done by a
>>>>> generic user, so normal kinit's would require 2FA all the time.
>>>>>
>>>>> Simo.
>>>>>
>>>> Can kinit do FAST? Is there some kind of kinit flag to use FAST?
>>> Yes kinit can do FAST, but is cumbersome to manually do it.
>>>
>>>> May be in such setup we will require all clients to use FAST for
>>>> the accounts that have several options configured.
>>> It won't help, users do not have access to the host keys so they
>>> can't do FAST with *those* keys.
>>>
>>>> Then we will know the principal used to armor the connection and
>>>> can make policy decisions based on it.
>>> We can do this with SSSD because it has access to the host key,
>>> being a privileged process. Normal user's can't.
>>>
>>> Simo.
>>>
>> What about kinit working with GSS proxy in this case?
>> Can that help?
> No, kinit does not use GSSAPI.

I know it does not. What I mean is to use GSS proxy to as a proxy for 
kinit to armor the request.
Have an option for kinit to send user credentials to the local socket, 
make GSSproxy or SSSD do the work for him.
If we are paranoid we can use SSL over this socket to pass the user 
credential.
But I am still not convinced we should care about this use case.

>
> Simo.
>
>> May be we can convince MIT to add an option to proxy kinit via GSS
>> proxy and use GSS proxy to armor?
>>
>
>


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.



From manuel.lopes72 at gmail.com  Fri Dec 12 18:51:41 2014
From: manuel.lopes72 at gmail.com (Manuel Lopes)
Date: Fri, 12 Dec 2014 19:51:41 +0100
Subject: [Freeipa-users] Forest trust and AD child domain
In-Reply-To: <20141212093311.GU14057@localhost.localdomain>
References: <CAKFNJrsYA9M1j5cjH5kA4c6U9QGEr5pGd90QVRDWf8ajHk9tqw@mail.gmail.com>
	<20141211190542.GT14057@localhost.localdomain>
	<CAKFNJrt_+GkUwDNuDhZLoGEFNfSV=omb=qCJfbJJq=RkXHxqnQ@mail.gmail.com>
	<20141212093311.GU14057@localhost.localdomain>
Message-ID: <CAKFNJrvBrvRJbxU-zsXhmsek8MZrZdz-b1p1O1MvfmUPv256vg@mail.gmail.com>

[root at support1 ~]# ipa idrange-find
----------------
3 ranges matched
----------------
  Range name: LINUX.COM_id_range
  First Posix ID of the range: 1066000000
  Number of IDs in the range: 200000
  First RID of the corresponding RID range: 1000
  First RID of the secondary RID range: 100000000
  Range type: local domain range

  Range name: WINDOWS.COM_id_range
  First Posix ID of the range: 730200000
  Number of IDs in the range: 200000
  First RID of the corresponding RID range: 0
  Domain SID of the trusted domain:
S-1-5-21-1701591335-3855227394-3044674468
  Range type: Active Directory domain range

  Range name: ACME.WINDOWS.COM_id_range
  First Posix ID of the range: 365600000
  Number of IDs in the range: 200000
  First RID of the corresponding RID range: 0
  Domain SID of the trusted domain:
S-1-5-21-1215373191-1991333051-3772904882
  Range type: Active Directory domain range
----------------------------
Number of entries returned 3
----------------------------


As we can see in the ouput of the command, the range type is "ad POSIX
attributes".
In our case, the gidNumber is not set in the "ACME\Domain Users" AD group,
nor in the " WINDOWS\Domain Users".
With a gidNumber attribute value, the 'wbinfo -n "ACME\Domain Users"' still
command fails.

Thanks


2014-12-12 10:33 GMT+01:00 Sumit Bose <sbose at redhat.com>:
>
> On Fri, Dec 12, 2014 at 02:06:05AM +0100, Manuel Lopes wrote:
> > Hi Sumit,
> >
> > Thank you very much for the prompt reply
> >
> > [root at support1 ~]# ipa trustdomain-find windows.com
> >   Domain name: windows.com
> >   Domain NetBIOS name: WINDOWS
> >   Domain Security Identifier: S-1-5-21-1701591335-3855227394-3044674468
> >   Domain enabled: True
> >
> >   Domain name: acme.windows.com
> >   Domain NetBIOS name: ACME
> >   Domain Security Identifier: S-1-5-21-1215373191-1991333051-3772904882
> >   Domain enabled: True
> > ----------------------------
> > Number of entries returned 2
> > ----------------------------
>
> ok, so ACME was discovered successful, can you check next the output of
>
> ipa idrange-find
>
> The important attribute is the 'Range type' for the AD domains. If it is
> 'Active Directory trust range with POSIX attributes' it is expected that
> users and groups in the AD forest have the POSIX UID and GID attributes
> set and only those users and groups will be available in the IPA domain.
> In this case please check if 'ACME\Domain Users' have the GID attribute
> set.
>
> If this does not help (please mind the negative cache of SSSD) please
> send the SSSD logs in /var/log/sssd on the IPA server. You might need to
> enable logging in sssd.conf by setting 'debug_level = 10' in the
> [domain/..] and [nss] section of sssd.conf.
>
> bye,
> Sumit
>
> >
> > [root at support1 ~]# ipa trust-fetch-domains windows.com
> > -------------------------------
> > No new trust domains were found
> > -------------------------------
> > ----------------------------
> > Number of entries returned 0
> > ----------------------------
> >
> > Regards
> > Le 11 d?c. 2014 20:08, "Sumit Bose" <sbose at redhat.com
> > <javascript:_e(%7B%7D,'cvml','sbose at redhat.com');>> a ?crit :
> >
> > > On Thu, Dec 11, 2014 at 06:45:49PM +0100, Manuel Lopes wrote:
> > > >  Hello,
> > > >
> > > >
> > > > We have been following the AD integration guide for IPAv3:
> > > > http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup
> > > >
> > > >
> > > >
> > > > Our setup is:
> > > >
> > > > ? 2 domain controllers with Windows 2008 R2 AD DC -> windows.com
> > > > <http://example.com/> as Forest Root Domain and acme.windows.com
> > > > <http://acme.example.com/> as transitive child domain
> > > >
> > > > ? RHEL7 as IPA server with domain: linux.com
> > > > <http://linux.acme.example.com/>
> > > >
> > > >
> > > >
> > > > We have established a forest trust between windows.com and linux.com
> and
> > > > everything seems OK from an IPA perspective.
> > > >
> > > >
> > > >
> > > > We can work with Kerberos tickets without any issue from ?windows?
> domain
> > > > or his child domain ?acme?. (kinit, kvno?)
> > > >
> > > >
> > > >
> > > > When we use samba tools, the following command is working fine.
> > > >
> > > > *[root at support1 ]# wbinfo -n 'WINDOWS\Domain Admins'*
> > > >
> > > > *S-1-5-21-1701591335-3855227394-3044674468-512 SID_DOM_GROUP (2)*
> > > >
> > > >
> > > >
> > > > But, the same command against the acme domain returns an error.
> > > >
> > > > *[root at support1 ]# wbinfo -n 'ACME\Domain Admins'*
> > > >
> > > > *failed to call wbcLookupName: WBC_ERR_DOMAIN_NOT_FOUND*
> > > >
> > > > *Could not lookup name ACME\Domain Admins*
> > > >
> > > >
> > > >
> > > > Same problem with the following command:
> > > >
> > > > *[root at support1]# ipa group-add-member ad_users_external --external
> > > > "ACME\Domain Users"*
> > > >
> > > > *[member user]:*
> > > >
> > > > *[member group]:*
> > > >
> > > > *  Group name: ad_users_external*
> > > >
> > > > *  Description: AD users external map*
> > > >
> > > > *  External member: *
> > > >
> > > > *  Member of groups: ad_users*
> > > >
> > > > *  Failed members:*
> > > >
> > > > *    member user:*
> > > >
> > > > *    member group: ACME\Domain Users: Cannot find specified domain or
> > > > server name*
> > > >
> > > > *-------------------------*
> > > >
> > > > *Number of members added 0*
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Any help would be appreciated
> > >
> > > Does
> > >
> > > ipa trustdomain-find windows.com
> > >
> > > show acme.windows.com as well ?
> > >
> > > Does
> > >
> > > ipa trust-fetch-domains ad.devel
> > >
> > > help to retrieve the child domain?
> > >
> > > Please note that if acme.windows.com now shows up you might have to
> wait
> > > 1-2 minutes until SSSD's negative caches are flushed and the new
> domains
> > > is discovered by SSSD, as an alternative you can just restart SSSD.
> > >
> > > HTH
> > >
> > > bye,
> > > Sumit
> > >
> > > >
> > > >
> > > >
> > > > Regards
> > >
> > > > --
> > > > 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
>
> --
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141212/d0dc492a/attachment.htm>

From simo at redhat.com  Fri Dec 12 19:29:10 2014
From: simo at redhat.com (Simo Sorce)
Date: Fri, 12 Dec 2014 14:29:10 -0500
Subject: [Freeipa-users] Host based 2FA ?
In-Reply-To: <548B38B4.2070401@redhat.com>
References: <alpine.DEB.2.02.1412111523250.24600@e.crebbs.net>
	<548A28FE.7030000@redhat.com>
	<20141212130756.4ec59d40@willson.usersys.redhat.com>
	<548B312E.7080703@redhat.com>
	<20141212132753.534b7187@willson.usersys.redhat.com>
	<548B34A3.4010603@redhat.com>
	<20141212133840.6f131695@willson.usersys.redhat.com>
	<548B38B4.2070401@redhat.com>
Message-ID: <20141212142910.36ac15c4@willson.usersys.redhat.com>

On Fri, 12 Dec 2014 13:49:24 -0500
Dmitri Pal <dpal at redhat.com> wrote:

> On 12/12/2014 01:38 PM, Simo Sorce wrote:
> > On Fri, 12 Dec 2014 13:32:03 -0500
> > Dmitri Pal <dpal at redhat.com> wrote:
> >
> >> On 12/12/2014 01:27 PM, Simo Sorce wrote:
> >>> On Fri, 12 Dec 2014 13:17:18 -0500
> >>> Dmitri Pal <dpal at redhat.com> wrote:
> >>>
> >>>> On 12/12/2014 01:07 PM, Simo Sorce wrote:
> >>>>> On Thu, 11 Dec 2014 18:30:06 -0500
> >>>>> Dmitri Pal <dpal at redhat.com> wrote:
> >>>>>
> >>>>>> On 12/11/2014 06:32 PM, freeipa at pettyvices.com wrote:
> >>>>>>> I'd like to be able to require 2FA on *certain* hosts and
> >>>>>>> allow just passwords on others.
> >>>>>>>
> >>>>>>> It seems you can check both "passwords" and "2FA" under the
> >>>>>>> user.
> >>>>>>>
> >>>>>>> I was hoping I could create a HBAC such that certain hosts
> >>>>>>> would only allow 2FA, but I can't see an obvious way to do
> >>>>>>> that.
> >>>>>>>
> >>>>>>> Is it possible?  Help on how would be great.  If not, feature
> >>>>>>> request?
> >>>>>>>
> >>>>>>> thanks,
> >>>>>>>
> >>>>>>> -t
> >>>>>>>
> >>>>>> We have several tickets:
> >>>>>>
> >>>>>> https://fedorahosted.org/freeipa/ticket/433
> >>>>>>
> >>>>>> https://fedorahosted.org/freeipa/ticket/3659
> >>>>>>
> >>>>>> https://fedorahosted.org/freeipa/ticket/4498
> >>>>>>
> >>>>>> If you see
> >>>>>> https://fedorahosted.org/freeipa/ticket/4498#comment:6 we
> >>>>>> discussed this use case. And I was about to fork it as said
> >>>>>> but then I realized that there is not good way on the KDC to
> >>>>>> determine the host you are coming from. So IMO it should be a
> >>>>>> policy decision on SSSD. There are two options:
> >>>>>> - short term solution: allow SSSD to have a local overwrite to
> >>>>>> require OTP if server offers different options.
> >>>>>> - longer term solution: actually have a per host policy that is
> >>>>>> centrally managed that is fetched per host and enforced by
> >>>>>> SSSD.
> >>>>>>
> >>>>>> Before filing tickets I would like to hear opinions on the
> >>>>>> matter.
> >>>>> If we are using a FAST channel using the credentials of the host
> >>>>> then you may be able to know (probably requires changes in the
> >>>>> KDC to internally retain/convey the information).
> >>>>> This is possible via SSSD, but will not work via kinit done by a
> >>>>> generic user, so normal kinit's would require 2FA all the time.
> >>>>>
> >>>>> Simo.
> >>>>>
> >>>> Can kinit do FAST? Is there some kind of kinit flag to use FAST?
> >>> Yes kinit can do FAST, but is cumbersome to manually do it.
> >>>
> >>>> May be in such setup we will require all clients to use FAST for
> >>>> the accounts that have several options configured.
> >>> It won't help, users do not have access to the host keys so they
> >>> can't do FAST with *those* keys.
> >>>
> >>>> Then we will know the principal used to armor the connection and
> >>>> can make policy decisions based on it.
> >>> We can do this with SSSD because it has access to the host key,
> >>> being a privileged process. Normal user's can't.
> >>>
> >>> Simo.
> >>>
> >> What about kinit working with GSS proxy in this case?
> >> Can that help?
> > No, kinit does not use GSSAPI.
> 
> I know it does not. What I mean is to use GSS proxy to as a proxy for 
> kinit to armor the request.
> Have an option for kinit to send user credentials to the local
> socket, make GSSproxy or SSSD do the work for him.

There is no way to convey this request over the GSS-Proxy protocol
either, sorry.

> If we are paranoid we can use SSL over this socket to pass the user 
> credential.
> But I am still not convinced we should care about this use case.

We should not care for the kinit case.

I think it is a potential good thing for the SSSD/pam_krb5 case (being
able to say that in order to log into a specific machine you need 2FA,
but on another less privileged one you can use single factor).

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York



From npmccallum at redhat.com  Fri Dec 12 19:40:22 2014
From: npmccallum at redhat.com (Nathaniel McCallum)
Date: Fri, 12 Dec 2014 14:40:22 -0500
Subject: [Freeipa-users] Host based 2FA ?
In-Reply-To: <20141212130756.4ec59d40@willson.usersys.redhat.com>
References: <alpine.DEB.2.02.1412111523250.24600@e.crebbs.net>
	<548A28FE.7030000@redhat.com>
	<20141212130756.4ec59d40@willson.usersys.redhat.com>
Message-ID: <1418413222.2856.64.camel@redhat.com>

On Fri, 2014-12-12 at 13:07 -0500, Simo Sorce wrote:
> On Thu, 11 Dec 2014 18:30:06 -0500
> Dmitri Pal <dpal at redhat.com> wrote:
> 
> > On 12/11/2014 06:32 PM, freeipa at pettyvices.com wrote:
> > >
> > > I'd like to be able to require 2FA on *certain* hosts and allow
> > > just passwords on others.
> > >
> > > It seems you can check both "passwords" and "2FA" under the user.
> > >
> > > I was hoping I could create a HBAC such that certain hosts would
> > > only allow 2FA, but I can't see an obvious way to do that.
> > >
> > > Is it possible?  Help on how would be great.  If not, feature
> > > request?
> > >
> > > thanks,
> > >
> > > -t
> > >
> > We have several tickets:
> > 
> > https://fedorahosted.org/freeipa/ticket/433
> > 
> > https://fedorahosted.org/freeipa/ticket/3659
> > 
> > https://fedorahosted.org/freeipa/ticket/4498
> > 
> > If you see https://fedorahosted.org/freeipa/ticket/4498#comment:6 we 
> > discussed this use case.
> > And I was about to fork it as said but then I realized that there is
> > not good way on the KDC to determine the host you are coming from.
> > So IMO it should be a policy decision on SSSD.
> > There are two options:
> > - short term solution: allow SSSD to have a local overwrite to
> > require OTP if server offers different options.
> > - longer term solution: actually have a per host policy that is 
> > centrally managed that is fetched per host and enforced by SSSD.
> > 
> > Before filing tickets I would like to hear opinions on the matter.
> 
> If we are using a FAST channel using the credentials of the host then
> you may be able to know (probably requires changes in the KDC to
> internally retain/convey the information).
> This is possible via SSSD, but will not work via kinit done by a
> generic user, so normal kinit's would require 2FA all the time.

This was my exact thought. But this technically isn't HBAC so much as
"choose preauth mechs based upon the principal used to secure the FAST
channel." It would also be somewhat useless if using anonymous pkinit to
secure the FAST channel.

Besides, long-term, we want FAST to go away. It is too cumbersome.

Nathaniel



From manuel.lopes72 at gmail.com  Fri Dec 12 19:41:27 2014
From: manuel.lopes72 at gmail.com (Manuel Lopes)
Date: Fri, 12 Dec 2014 20:41:27 +0100
Subject: [Freeipa-users] Forest trust and AD child domain
In-Reply-To: <CAKFNJrvBrvRJbxU-zsXhmsek8MZrZdz-b1p1O1MvfmUPv256vg@mail.gmail.com>
References: <CAKFNJrsYA9M1j5cjH5kA4c6U9QGEr5pGd90QVRDWf8ajHk9tqw@mail.gmail.com>
	<20141211190542.GT14057@localhost.localdomain>
	<CAKFNJrt_+GkUwDNuDhZLoGEFNfSV=omb=qCJfbJJq=RkXHxqnQ@mail.gmail.com>
	<20141212093311.GU14057@localhost.localdomain>
	<CAKFNJrvBrvRJbxU-zsXhmsek8MZrZdz-b1p1O1MvfmUPv256vg@mail.gmail.com>
Message-ID: <CAKFNJrsJvj8098k9vzScONO4endDE3LGuH1AzUY6_yDRS3MT1Q@mail.gmail.com>

[root at support1 ~]# ipa idrange-find
----------------
3 ranges matched
----------------
Range name: LINUX.COM_id_range
First Posix ID of the range: 1066000000
Number of IDs in the range: 200000
First RID of the corresponding RID range: 1000
First RID of the secondary RID range: 100000000
Range type: local domain range

Range name: WINDOWS.COM_id_range
First Posix ID of the range: 730200000
Number of IDs in the range: 200000
First RID of the corresponding RID range: 0
Domain SID of the trusted domain: S-1-5-21-1701591335-3855227394-3044674468
Range type: Active Directory domain range

Range name: ACME.WINDOWS.COM_id_range
First Posix ID of the range: 365600000
Number of IDs in the range: 200000
First RID of the corresponding RID range: 0
Domain SID of the trusted domain: S-1-5-21-1215373191-1991333051-3772904882
Range type: Active Directory domain range
----------------------------
Number of entries returned 3
----------------------------


As we can see in the ouput of the command, the range type is "ad POSIX
attributes".
In our case, the gidNumber is not set in the "ACME\Domain Users" AD group,
nor in the " WINDOWS\Domain Users".
With a gidNumber attribute value, the 'wbinfo -n "ACME\Domain Users"' still
command fails.

Thanks

2014-12-12 19:51 GMT+01:00 Manuel Lopes <manuel.lopes72 at gmail.com>:
>
> [root at support1 ~]# ipa idrange-find
> ----------------
> 3 ranges matched
> ----------------
>   Range name: LINUX.COM_id_range
>   First Posix ID of the range: 1066000000
>   Number of IDs in the range: 200000
>   First RID of the corresponding RID range: 1000
>   First RID of the secondary RID range: 100000000
>   Range type: local domain range
>
>   Range name: WINDOWS.COM_id_range
>   First Posix ID of the range: 730200000
>   Number of IDs in the range: 200000
>   First RID of the corresponding RID range: 0
>   Domain SID of the trusted domain:
> S-1-5-21-1701591335-3855227394-3044674468
>   Range type: Active Directory domain range
>
>   Range name: ACME.WINDOWS.COM_id_range
>   First Posix ID of the range: 365600000
>   Number of IDs in the range: 200000
>   First RID of the corresponding RID range: 0
>   Domain SID of the trusted domain:
> S-1-5-21-1215373191-1991333051-3772904882
>   Range type: Active Directory domain range
> ----------------------------
> Number of entries returned 3
> ----------------------------
>
>
> As we can see in the ouput of the command, the range type is "ad POSIX
> attributes".
> In our case, the gidNumber is not set in the "ACME\Domain Users" AD group,
> nor in the " WINDOWS\Domain Users".
> With a gidNumber attribute value, the 'wbinfo -n "ACME\Domain Users"'
> still command fails.
>
> Thanks
>
>
> 2014-12-12 10:33 GMT+01:00 Sumit Bose <sbose at redhat.com>:
>>
>> On Fri, Dec 12, 2014 at 02:06:05AM +0100, Manuel Lopes wrote:
>> > Hi Sumit,
>> >
>> > Thank you very much for the prompt reply
>> >
>> > [root at support1 ~]# ipa trustdomain-find windows.com
>> >   Domain name: windows.com
>> >   Domain NetBIOS name: WINDOWS
>> >   Domain Security Identifier: S-1-5-21-1701591335-3855227394-3044674468
>> >   Domain enabled: True
>> >
>> >   Domain name: acme.windows.com
>> >   Domain NetBIOS name: ACME
>> >   Domain Security Identifier: S-1-5-21-1215373191-1991333051-3772904882
>> >   Domain enabled: True
>> > ----------------------------
>> > Number of entries returned 2
>> > ----------------------------
>>
>> ok, so ACME was discovered successful, can you check next the output of
>>
>> ipa idrange-find
>>
>> The important attribute is the 'Range type' for the AD domains. If it is
>> 'Active Directory trust range with POSIX attributes' it is expected that
>> users and groups in the AD forest have the POSIX UID and GID attributes
>> set and only those users and groups will be available in the IPA domain.
>> In this case please check if 'ACME\Domain Users' have the GID attribute
>> set.
>>
>> If this does not help (please mind the negative cache of SSSD) please
>> send the SSSD logs in /var/log/sssd on the IPA server. You might need to
>> enable logging in sssd.conf by setting 'debug_level = 10' in the
>> [domain/..] and [nss] section of sssd.conf.
>>
>> bye,
>> Sumit
>>
>> >
>> > [root at support1 ~]# ipa trust-fetch-domains windows.com
>> > -------------------------------
>> > No new trust domains were found
>> > -------------------------------
>> > ----------------------------
>> > Number of entries returned 0
>> > ----------------------------
>> >
>> > Regards
>> > Le 11 d?c. 2014 20:08, "Sumit Bose" <sbose at redhat.com
>> > <javascript:_e(%7B%7D,'cvml','sbose at redhat.com');>> a ?crit :
>> >
>> > > On Thu, Dec 11, 2014 at 06:45:49PM +0100, Manuel Lopes wrote:
>> > > >  Hello,
>> > > >
>> > > >
>> > > > We have been following the AD integration guide for IPAv3:
>> > > > http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup
>> > > >
>> > > >
>> > > >
>> > > > Our setup is:
>> > > >
>> > > > ? 2 domain controllers with Windows 2008 R2 AD DC -> windows.com
>> > > > <http://example.com/> as Forest Root Domain and acme.windows.com
>> > > > <http://acme.example.com/> as transitive child domain
>> > > >
>> > > > ? RHEL7 as IPA server with domain: linux.com
>> > > > <http://linux.acme.example.com/>
>> > > >
>> > > >
>> > > >
>> > > > We have established a forest trust between windows.com and
>> linux.com and
>> > > > everything seems OK from an IPA perspective.
>> > > >
>> > > >
>> > > >
>> > > > We can work with Kerberos tickets without any issue from ?windows?
>> domain
>> > > > or his child domain ?acme?. (kinit, kvno?)
>> > > >
>> > > >
>> > > >
>> > > > When we use samba tools, the following command is working fine.
>> > > >
>> > > > *[root at support1 ]# wbinfo -n 'WINDOWS\Domain Admins'*
>> > > >
>> > > > *S-1-5-21-1701591335-3855227394-3044674468-512 SID_DOM_GROUP (2)*
>> > > >
>> > > >
>> > > >
>> > > > But, the same command against the acme domain returns an error.
>> > > >
>> > > > *[root at support1 ]# wbinfo -n 'ACME\Domain Admins'*
>> > > >
>> > > > *failed to call wbcLookupName: WBC_ERR_DOMAIN_NOT_FOUND*
>> > > >
>> > > > *Could not lookup name ACME\Domain Admins*
>> > > >
>> > > >
>> > > >
>> > > > Same problem with the following command:
>> > > >
>> > > > *[root at support1]# ipa group-add-member ad_users_external --external
>> > > > "ACME\Domain Users"*
>> > > >
>> > > > *[member user]:*
>> > > >
>> > > > *[member group]:*
>> > > >
>> > > > *  Group name: ad_users_external*
>> > > >
>> > > > *  Description: AD users external map*
>> > > >
>> > > > *  External member: *
>> > > >
>> > > > *  Member of groups: ad_users*
>> > > >
>> > > > *  Failed members:*
>> > > >
>> > > > *    member user:*
>> > > >
>> > > > *    member group: ACME\Domain Users: Cannot find specified domain
>> or
>> > > > server name*
>> > > >
>> > > > *-------------------------*
>> > > >
>> > > > *Number of members added 0*
>> > > >
>> > > >
>> > > >
>> > > >
>> > > >
>> > > > Any help would be appreciated
>> > >
>> > > Does
>> > >
>> > > ipa trustdomain-find windows.com
>> > >
>> > > show acme.windows.com as well ?
>> > >
>> > > Does
>> > >
>> > > ipa trust-fetch-domains ad.devel
>> > >
>> > > help to retrieve the child domain?
>> > >
>> > > Please note that if acme.windows.com now shows up you might have to
>> wait
>> > > 1-2 minutes until SSSD's negative caches are flushed and the new
>> domains
>> > > is discovered by SSSD, as an alternative you can just restart SSSD.
>> > >
>> > > HTH
>> > >
>> > > bye,
>> > > Sumit
>> > >
>> > > >
>> > > >
>> > > >
>> > > > Regards
>> > >
>> > > > --
>> > > > 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
>>
>> --
>> 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
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141212/b9eeee22/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sssd_nss.log
Type: application/octet-stream
Size: 32295 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141212/b9eeee22/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sssd.log
Type: application/octet-stream
Size: 131049 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141212/b9eeee22/attachment-0001.obj>

From dpal at redhat.com  Fri Dec 12 19:46:15 2014
From: dpal at redhat.com (Dmitri Pal)
Date: Fri, 12 Dec 2014 14:46:15 -0500
Subject: [Freeipa-users] Host based 2FA ?
In-Reply-To: <1418413222.2856.64.camel@redhat.com>
References: <alpine.DEB.2.02.1412111523250.24600@e.crebbs.net>	
	<548A28FE.7030000@redhat.com>	
	<20141212130756.4ec59d40@willson.usersys.redhat.com>
	<1418413222.2856.64.camel@redhat.com>
Message-ID: <548B4607.9030501@redhat.com>

On 12/12/2014 02:40 PM, Nathaniel McCallum wrote:
> On Fri, 2014-12-12 at 13:07 -0500, Simo Sorce wrote:
>> On Thu, 11 Dec 2014 18:30:06 -0500
>> Dmitri Pal <dpal at redhat.com> wrote:
>>
>>> On 12/11/2014 06:32 PM, freeipa at pettyvices.com wrote:
>>>> I'd like to be able to require 2FA on *certain* hosts and allow
>>>> just passwords on others.
>>>>
>>>> It seems you can check both "passwords" and "2FA" under the user.
>>>>
>>>> I was hoping I could create a HBAC such that certain hosts would
>>>> only allow 2FA, but I can't see an obvious way to do that.
>>>>
>>>> Is it possible?  Help on how would be great.  If not, feature
>>>> request?
>>>>
>>>> thanks,
>>>>
>>>> -t
>>>>
>>> We have several tickets:
>>>
>>> https://fedorahosted.org/freeipa/ticket/433
>>>
>>> https://fedorahosted.org/freeipa/ticket/3659
>>>
>>> https://fedorahosted.org/freeipa/ticket/4498
>>>
>>> If you see https://fedorahosted.org/freeipa/ticket/4498#comment:6 we
>>> discussed this use case.
>>> And I was about to fork it as said but then I realized that there is
>>> not good way on the KDC to determine the host you are coming from.
>>> So IMO it should be a policy decision on SSSD.
>>> There are two options:
>>> - short term solution: allow SSSD to have a local overwrite to
>>> require OTP if server offers different options.
>>> - longer term solution: actually have a per host policy that is
>>> centrally managed that is fetched per host and enforced by SSSD.
>>>
>>> Before filing tickets I would like to hear opinions on the matter.
>> If we are using a FAST channel using the credentials of the host then
>> you may be able to know (probably requires changes in the KDC to
>> internally retain/convey the information).
>> This is possible via SSSD, but will not work via kinit done by a
>> generic user, so normal kinit's would require 2FA all the time.

I do not understand how kinit will require 2FA if kinit does not use 
FAST (because it does not have access to the host keys).
OTP is possible only over the armored tunnel.

> This was my exact thought. But this technically isn't HBAC so much as
> "choose preauth mechs based upon the principal used to secure the FAST
> channel." It would also be somewhat useless if using anonymous pkinit to
> secure the FAST channel.
>
> Besides, long-term, we want FAST to go away. It is too cumbersome.

But there will be other way to create armor tunnel and you would need 
some other principal in the exchange, right?


So what would be a short term and long term solution?
SSSD override seems like a simple thing to do.
AFAIR we already design it couple years ago but I suspect not 
implemented yet.

>
> Nathaniel
>


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.



From npmccallum at redhat.com  Fri Dec 12 19:52:28 2014
From: npmccallum at redhat.com (Nathaniel McCallum)
Date: Fri, 12 Dec 2014 14:52:28 -0500
Subject: [Freeipa-users] Host based 2FA ?
In-Reply-To: <548B4607.9030501@redhat.com>
References: <alpine.DEB.2.02.1412111523250.24600@e.crebbs.net>
	<548A28FE.7030000@redhat.com>
	<20141212130756.4ec59d40@willson.usersys.redhat.com>
	<1418413222.2856.64.camel@redhat.com> <548B4607.9030501@redhat.com>
Message-ID: <1418413948.2856.74.camel@redhat.com>

On Fri, 2014-12-12 at 14:46 -0500, Dmitri Pal wrote:
> On 12/12/2014 02:40 PM, Nathaniel McCallum wrote:
> > On Fri, 2014-12-12 at 13:07 -0500, Simo Sorce wrote:
> >> On Thu, 11 Dec 2014 18:30:06 -0500
> >> Dmitri Pal <dpal at redhat.com> wrote:
> >>
> >>> On 12/11/2014 06:32 PM, freeipa at pettyvices.com wrote:
> >>>> I'd like to be able to require 2FA on *certain* hosts and allow
> >>>> just passwords on others.
> >>>>
> >>>> It seems you can check both "passwords" and "2FA" under the user.
> >>>>
> >>>> I was hoping I could create a HBAC such that certain hosts would
> >>>> only allow 2FA, but I can't see an obvious way to do that.
> >>>>
> >>>> Is it possible?  Help on how would be great.  If not, feature
> >>>> request?
> >>>>
> >>>> thanks,
> >>>>
> >>>> -t
> >>>>
> >>> We have several tickets:
> >>>
> >>> https://fedorahosted.org/freeipa/ticket/433
> >>>
> >>> https://fedorahosted.org/freeipa/ticket/3659
> >>>
> >>> https://fedorahosted.org/freeipa/ticket/4498
> >>>
> >>> If you see https://fedorahosted.org/freeipa/ticket/4498#comment:6 we
> >>> discussed this use case.
> >>> And I was about to fork it as said but then I realized that there is
> >>> not good way on the KDC to determine the host you are coming from.
> >>> So IMO it should be a policy decision on SSSD.
> >>> There are two options:
> >>> - short term solution: allow SSSD to have a local overwrite to
> >>> require OTP if server offers different options.
> >>> - longer term solution: actually have a per host policy that is
> >>> centrally managed that is fetched per host and enforced by SSSD.
> >>>
> >>> Before filing tickets I would like to hear opinions on the matter.
> >> If we are using a FAST channel using the credentials of the host then
> >> you may be able to know (probably requires changes in the KDC to
> >> internally retain/convey the information).
> >> This is possible via SSSD, but will not work via kinit done by a
> >> generic user, so normal kinit's would require 2FA all the time.
> 
> I do not understand how kinit will require 2FA if kinit does not use 
> FAST (because it does not have access to the host keys).
> OTP is possible only over the armored tunnel.
> 
> > This was my exact thought. But this technically isn't HBAC so much as
> > "choose preauth mechs based upon the principal used to secure the FAST
> > channel." It would also be somewhat useless if using anonymous pkinit to
> > secure the FAST channel.
> >
> > Besides, long-term, we want FAST to go away. It is too cumbersome.
> 
> But there will be other way to create armor tunnel and you would need 
> some other principal in the exchange, right?

No. Long-term, with PAKE preauth, the second factor will be dynamically
encrypted in the session key calculated from two public keys (client and
server) and the long-term shared secret. There will be no other
principal involved.

> So what would be a short term and long term solution?
> SSSD override seems like a simple thing to do.
> AFAIR we already design it couple years ago but I suspect not 
> implemented yet.

Long-term, there is no way to restrict this from the KDC-side.

As I see it, long-term we have auth indicators, optional 2FA and PAKE
+OTP. The user can be configured for password OR password+otp. Then SSSD
can be told via something like an HBAC which it should prompt for. But
this would be purely voluntary since the KDC will allow both logins.

Having different policies based on the source of a message is always bad
security design because such information can never be trusted by the
recipient.

Nathaniel



From sbose at redhat.com  Fri Dec 12 20:32:34 2014
From: sbose at redhat.com (Sumit Bose)
Date: Fri, 12 Dec 2014 21:32:34 +0100
Subject: [Freeipa-users] Forest trust and AD child domain
In-Reply-To: <CAKFNJrsJvj8098k9vzScONO4endDE3LGuH1AzUY6_yDRS3MT1Q@mail.gmail.com>
References: <CAKFNJrsYA9M1j5cjH5kA4c6U9QGEr5pGd90QVRDWf8ajHk9tqw@mail.gmail.com>
	<20141211190542.GT14057@localhost.localdomain>
	<CAKFNJrt_+GkUwDNuDhZLoGEFNfSV=omb=qCJfbJJq=RkXHxqnQ@mail.gmail.com>
	<20141212093311.GU14057@localhost.localdomain>
	<CAKFNJrvBrvRJbxU-zsXhmsek8MZrZdz-b1p1O1MvfmUPv256vg@mail.gmail.com>
	<CAKFNJrsJvj8098k9vzScONO4endDE3LGuH1AzUY6_yDRS3MT1Q@mail.gmail.com>
Message-ID: <20141212203234.GA6877@localhost.localdomain>

On Fri, Dec 12, 2014 at 08:41:27PM +0100, Manuel Lopes wrote:
> [root at support1 ~]# ipa idrange-find
> ----------------
> 3 ranges matched
> ----------------
> Range name: LINUX.COM_id_range
> First Posix ID of the range: 1066000000
> Number of IDs in the range: 200000
> First RID of the corresponding RID range: 1000
> First RID of the secondary RID range: 100000000
> Range type: local domain range
> 
> Range name: WINDOWS.COM_id_range
> First Posix ID of the range: 730200000
> Number of IDs in the range: 200000
> First RID of the corresponding RID range: 0
> Domain SID of the trusted domain: S-1-5-21-1701591335-3855227394-3044674468
> Range type: Active Directory domain range
> 
> Range name: ACME.WINDOWS.COM_id_range
> First Posix ID of the range: 365600000
> Number of IDs in the range: 200000
> First RID of the corresponding RID range: 0
> Domain SID of the trusted domain: S-1-5-21-1215373191-1991333051-3772904882
> Range type: Active Directory domain range
> ----------------------------
> Number of entries returned 3
> ----------------------------
> 
> 
> As we can see in the ouput of the command, the range type is "ad POSIX
> attributes".

no, it's only 'Active Directory domain range', this is good because with
this type we generate the UIDs and GIDs algorithmically.

> In our case, the gidNumber is not set in the "ACME\Domain Users" AD group,
> nor in the " WINDOWS\Domain Users".
> With a gidNumber attribute value, the 'wbinfo -n "ACME\Domain Users"' still
> command fails.

no need to set the ID attributes in AD. But I should have mentioned
that wbinfo is quite useless nowadays with FreeIPA because winbind is
only used to assure some types of communication with AD. All user and
group lookups and IP-mapping is done by SSSD. Please try

getent group 'ACME\Domain Users'


and send the sssd_nss.log and sssd_example.com.log files.

bye,
Sumit

> 
> Thanks
> 
> 2014-12-12 19:51 GMT+01:00 Manuel Lopes <manuel.lopes72 at gmail.com>:
> >
> > [root at support1 ~]# ipa idrange-find
> > ----------------
> > 3 ranges matched
> > ----------------
> >   Range name: LINUX.COM_id_range
> >   First Posix ID of the range: 1066000000
> >   Number of IDs in the range: 200000
> >   First RID of the corresponding RID range: 1000
> >   First RID of the secondary RID range: 100000000
> >   Range type: local domain range
> >
> >   Range name: WINDOWS.COM_id_range
> >   First Posix ID of the range: 730200000
> >   Number of IDs in the range: 200000
> >   First RID of the corresponding RID range: 0
> >   Domain SID of the trusted domain:
> > S-1-5-21-1701591335-3855227394-3044674468
> >   Range type: Active Directory domain range
> >
> >   Range name: ACME.WINDOWS.COM_id_range
> >   First Posix ID of the range: 365600000
> >   Number of IDs in the range: 200000
> >   First RID of the corresponding RID range: 0
> >   Domain SID of the trusted domain:
> > S-1-5-21-1215373191-1991333051-3772904882
> >   Range type: Active Directory domain range
> > ----------------------------
> > Number of entries returned 3
> > ----------------------------
> >
> >
> > As we can see in the ouput of the command, the range type is "ad POSIX
> > attributes".
> > In our case, the gidNumber is not set in the "ACME\Domain Users" AD group,
> > nor in the " WINDOWS\Domain Users".
> > With a gidNumber attribute value, the 'wbinfo -n "ACME\Domain Users"'
> > still command fails.
> >
> > Thanks
> >
> >
> > 2014-12-12 10:33 GMT+01:00 Sumit Bose <sbose at redhat.com>:
> >>
> >> On Fri, Dec 12, 2014 at 02:06:05AM +0100, Manuel Lopes wrote:
> >> > Hi Sumit,
> >> >
> >> > Thank you very much for the prompt reply
> >> >
> >> > [root at support1 ~]# ipa trustdomain-find windows.com
> >> >   Domain name: windows.com
> >> >   Domain NetBIOS name: WINDOWS
> >> >   Domain Security Identifier: S-1-5-21-1701591335-3855227394-3044674468
> >> >   Domain enabled: True
> >> >
> >> >   Domain name: acme.windows.com
> >> >   Domain NetBIOS name: ACME
> >> >   Domain Security Identifier: S-1-5-21-1215373191-1991333051-3772904882
> >> >   Domain enabled: True
> >> > ----------------------------
> >> > Number of entries returned 2
> >> > ----------------------------
> >>
> >> ok, so ACME was discovered successful, can you check next the output of
> >>
> >> ipa idrange-find
> >>
> >> The important attribute is the 'Range type' for the AD domains. If it is
> >> 'Active Directory trust range with POSIX attributes' it is expected that
> >> users and groups in the AD forest have the POSIX UID and GID attributes
> >> set and only those users and groups will be available in the IPA domain.
> >> In this case please check if 'ACME\Domain Users' have the GID attribute
> >> set.
> >>
> >> If this does not help (please mind the negative cache of SSSD) please
> >> send the SSSD logs in /var/log/sssd on the IPA server. You might need to
> >> enable logging in sssd.conf by setting 'debug_level = 10' in the
> >> [domain/..] and [nss] section of sssd.conf.
> >>
> >> bye,
> >> Sumit
> >>
> >> >
> >> > [root at support1 ~]# ipa trust-fetch-domains windows.com
> >> > -------------------------------
> >> > No new trust domains were found
> >> > -------------------------------
> >> > ----------------------------
> >> > Number of entries returned 0
> >> > ----------------------------
> >> >
> >> > Regards
> >> > Le 11 d?c. 2014 20:08, "Sumit Bose" <sbose at redhat.com
> >> > <javascript:_e(%7B%7D,'cvml','sbose at redhat.com');>> a ?crit :
> >> >
> >> > > On Thu, Dec 11, 2014 at 06:45:49PM +0100, Manuel Lopes wrote:
> >> > > >  Hello,
> >> > > >
> >> > > >
> >> > > > We have been following the AD integration guide for IPAv3:
> >> > > > http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup
> >> > > >
> >> > > >
> >> > > >
> >> > > > Our setup is:
> >> > > >
> >> > > > ? 2 domain controllers with Windows 2008 R2 AD DC -> windows.com
> >> > > > <http://example.com/> as Forest Root Domain and acme.windows.com
> >> > > > <http://acme.example.com/> as transitive child domain
> >> > > >
> >> > > > ? RHEL7 as IPA server with domain: linux.com
> >> > > > <http://linux.acme.example.com/>
> >> > > >
> >> > > >
> >> > > >
> >> > > > We have established a forest trust between windows.com and
> >> linux.com and
> >> > > > everything seems OK from an IPA perspective.
> >> > > >
> >> > > >
> >> > > >
> >> > > > We can work with Kerberos tickets without any issue from ?windows?
> >> domain
> >> > > > or his child domain ?acme?. (kinit, kvno?)
> >> > > >
> >> > > >
> >> > > >
> >> > > > When we use samba tools, the following command is working fine.
> >> > > >
> >> > > > *[root at support1 ]# wbinfo -n 'WINDOWS\Domain Admins'*
> >> > > >
> >> > > > *S-1-5-21-1701591335-3855227394-3044674468-512 SID_DOM_GROUP (2)*
> >> > > >
> >> > > >
> >> > > >
> >> > > > But, the same command against the acme domain returns an error.
> >> > > >
> >> > > > *[root at support1 ]# wbinfo -n 'ACME\Domain Admins'*
> >> > > >
> >> > > > *failed to call wbcLookupName: WBC_ERR_DOMAIN_NOT_FOUND*
> >> > > >
> >> > > > *Could not lookup name ACME\Domain Admins*
> >> > > >
> >> > > >
> >> > > >
> >> > > > Same problem with the following command:
> >> > > >
> >> > > > *[root at support1]# ipa group-add-member ad_users_external --external
> >> > > > "ACME\Domain Users"*
> >> > > >
> >> > > > *[member user]:*
> >> > > >
> >> > > > *[member group]:*
> >> > > >
> >> > > > *  Group name: ad_users_external*
> >> > > >
> >> > > > *  Description: AD users external map*
> >> > > >
> >> > > > *  External member: *
> >> > > >
> >> > > > *  Member of groups: ad_users*
> >> > > >
> >> > > > *  Failed members:*
> >> > > >
> >> > > > *    member user:*
> >> > > >
> >> > > > *    member group: ACME\Domain Users: Cannot find specified domain
> >> or
> >> > > > server name*
> >> > > >
> >> > > > *-------------------------*
> >> > > >
> >> > > > *Number of members added 0*
> >> > > >
> >> > > >
> >> > > >
> >> > > >
> >> > > >
> >> > > > Any help would be appreciated
> >> > >
> >> > > Does
> >> > >
> >> > > ipa trustdomain-find windows.com
> >> > >
> >> > > show acme.windows.com as well ?
> >> > >
> >> > > Does
> >> > >
> >> > > ipa trust-fetch-domains ad.devel
> >> > >
> >> > > help to retrieve the child domain?
> >> > >
> >> > > Please note that if acme.windows.com now shows up you might have to
> >> wait
> >> > > 1-2 minutes until SSSD's negative caches are flushed and the new
> >> domains
> >> > > is discovered by SSSD, as an alternative you can just restart SSSD.
> >> > >
> >> > > HTH
> >> > >
> >> > > bye,
> >> > > Sumit
> >> > >
> >> > > >
> >> > > >
> >> > > >
> >> > > > Regards
> >> > >
> >> > > > --
> >> > > > 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
> >>
> >> --
> >> 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
> >>
> >





From manuel.lopes72 at gmail.com  Fri Dec 12 20:51:38 2014
From: manuel.lopes72 at gmail.com (Manuel Lopes)
Date: Fri, 12 Dec 2014 21:51:38 +0100
Subject: [Freeipa-users] Forest trust and AD child domain
In-Reply-To: <20141212203234.GA6877@localhost.localdomain>
References: <CAKFNJrsYA9M1j5cjH5kA4c6U9QGEr5pGd90QVRDWf8ajHk9tqw@mail.gmail.com>
	<20141211190542.GT14057@localhost.localdomain>
	<CAKFNJrt_+GkUwDNuDhZLoGEFNfSV=omb=qCJfbJJq=RkXHxqnQ@mail.gmail.com>
	<20141212093311.GU14057@localhost.localdomain>
	<CAKFNJrvBrvRJbxU-zsXhmsek8MZrZdz-b1p1O1MvfmUPv256vg@mail.gmail.com>
	<CAKFNJrsJvj8098k9vzScONO4endDE3LGuH1AzUY6_yDRS3MT1Q@mail.gmail.com>
	<20141212203234.GA6877@localhost.localdomain>
Message-ID: <CAKFNJrsS1-h8pu+UoWWCwAUu3GA8D8XtGva7J3in7omSGCjiUw@mail.gmail.com>

OK.

Command successful
[root at support1 ~]# getent group  'ACME\Domain Users'
domain users at acme.windows.com:*:365600513:administrator at acme.windows.com

Log files attached

Thanks

2014-12-12 21:32 GMT+01:00 Sumit Bose <sbose at redhat.com>:
>
> On Fri, Dec 12, 2014 at 08:41:27PM +0100, Manuel Lopes wrote:
> > [root at support1 ~]# ipa idrange-find
> > ----------------
> > 3 ranges matched
> > ----------------
> > Range name: LINUX.COM_id_range
> > First Posix ID of the range: 1066000000
> > Number of IDs in the range: 200000
> > First RID of the corresponding RID range: 1000
> > First RID of the secondary RID range: 100000000
> > Range type: local domain range
> >
> > Range name: WINDOWS.COM_id_range
> > First Posix ID of the range: 730200000
> > Number of IDs in the range: 200000
> > First RID of the corresponding RID range: 0
> > Domain SID of the trusted domain:
> S-1-5-21-1701591335-3855227394-3044674468
> > Range type: Active Directory domain range
> >
> > Range name: ACME.WINDOWS.COM_id_range
> > First Posix ID of the range: 365600000
> > Number of IDs in the range: 200000
> > First RID of the corresponding RID range: 0
> > Domain SID of the trusted domain:
> S-1-5-21-1215373191-1991333051-3772904882
> > Range type: Active Directory domain range
> > ----------------------------
> > Number of entries returned 3
> > ----------------------------
> >
> >
> > As we can see in the ouput of the command, the range type is "ad POSIX
> > attributes".
>
> no, it's only 'Active Directory domain range', this is good because with
> this type we generate the UIDs and GIDs algorithmically.
>
> > In our case, the gidNumber is not set in the "ACME\Domain Users" AD
> group,
> > nor in the " WINDOWS\Domain Users".
> > With a gidNumber attribute value, the 'wbinfo -n "ACME\Domain Users"'
> still
> > command fails.
>
> no need to set the ID attributes in AD. But I should have mentioned
> that wbinfo is quite useless nowadays with FreeIPA because winbind is
> only used to assure some types of communication with AD. All user and
> group lookups and IP-mapping is done by SSSD. Please try
>
> getent group 'ACME\Domain Users'
>
>
> and send the sssd_nss.log and sssd_example.com.log files.
>
> bye,
> Sumit
>
> >
> > Thanks
> >
> > 2014-12-12 19:51 GMT+01:00 Manuel Lopes <manuel.lopes72 at gmail.com>:
> > >
> > > [root at support1 ~]# ipa idrange-find
> > > ----------------
> > > 3 ranges matched
> > > ----------------
> > >   Range name: LINUX.COM_id_range
> > >   First Posix ID of the range: 1066000000
> > >   Number of IDs in the range: 200000
> > >   First RID of the corresponding RID range: 1000
> > >   First RID of the secondary RID range: 100000000
> > >   Range type: local domain range
> > >
> > >   Range name: WINDOWS.COM_id_range
> > >   First Posix ID of the range: 730200000
> > >   Number of IDs in the range: 200000
> > >   First RID of the corresponding RID range: 0
> > >   Domain SID of the trusted domain:
> > > S-1-5-21-1701591335-3855227394-3044674468
> > >   Range type: Active Directory domain range
> > >
> > >   Range name: ACME.WINDOWS.COM_id_range
> > >   First Posix ID of the range: 365600000
> > >   Number of IDs in the range: 200000
> > >   First RID of the corresponding RID range: 0
> > >   Domain SID of the trusted domain:
> > > S-1-5-21-1215373191-1991333051-3772904882
> > >   Range type: Active Directory domain range
> > > ----------------------------
> > > Number of entries returned 3
> > > ----------------------------
> > >
> > >
> > > As we can see in the ouput of the command, the range type is "ad POSIX
> > > attributes".
> > > In our case, the gidNumber is not set in the "ACME\Domain Users" AD
> group,
> > > nor in the " WINDOWS\Domain Users".
> > > With a gidNumber attribute value, the 'wbinfo -n "ACME\Domain Users"'
> > > still command fails.
> > >
> > > Thanks
> > >
> > >
> > > 2014-12-12 10:33 GMT+01:00 Sumit Bose <sbose at redhat.com>:
> > >>
> > >> On Fri, Dec 12, 2014 at 02:06:05AM +0100, Manuel Lopes wrote:
> > >> > Hi Sumit,
> > >> >
> > >> > Thank you very much for the prompt reply
> > >> >
> > >> > [root at support1 ~]# ipa trustdomain-find windows.com
> > >> >   Domain name: windows.com
> > >> >   Domain NetBIOS name: WINDOWS
> > >> >   Domain Security Identifier:
> S-1-5-21-1701591335-3855227394-3044674468
> > >> >   Domain enabled: True
> > >> >
> > >> >   Domain name: acme.windows.com
> > >> >   Domain NetBIOS name: ACME
> > >> >   Domain Security Identifier:
> S-1-5-21-1215373191-1991333051-3772904882
> > >> >   Domain enabled: True
> > >> > ----------------------------
> > >> > Number of entries returned 2
> > >> > ----------------------------
> > >>
> > >> ok, so ACME was discovered successful, can you check next the output
> of
> > >>
> > >> ipa idrange-find
> > >>
> > >> The important attribute is the 'Range type' for the AD domains. If it
> is
> > >> 'Active Directory trust range with POSIX attributes' it is expected
> that
> > >> users and groups in the AD forest have the POSIX UID and GID
> attributes
> > >> set and only those users and groups will be available in the IPA
> domain.
> > >> In this case please check if 'ACME\Domain Users' have the GID
> attribute
> > >> set.
> > >>
> > >> If this does not help (please mind the negative cache of SSSD) please
> > >> send the SSSD logs in /var/log/sssd on the IPA server. You might need
> to
> > >> enable logging in sssd.conf by setting 'debug_level = 10' in the
> > >> [domain/..] and [nss] section of sssd.conf.
> > >>
> > >> bye,
> > >> Sumit
> > >>
> > >> >
> > >> > [root at support1 ~]# ipa trust-fetch-domains windows.com
> > >> > -------------------------------
> > >> > No new trust domains were found
> > >> > -------------------------------
> > >> > ----------------------------
> > >> > Number of entries returned 0
> > >> > ----------------------------
> > >> >
> > >> > Regards
> > >> > Le 11 d?c. 2014 20:08, "Sumit Bose" <sbose at redhat.com
> > >> > <javascript:_e(%7B%7D,'cvml','sbose at redhat.com');>> a ?crit :
> > >> >
> > >> > > On Thu, Dec 11, 2014 at 06:45:49PM +0100, Manuel Lopes wrote:
> > >> > > >  Hello,
> > >> > > >
> > >> > > >
> > >> > > > We have been following the AD integration guide for IPAv3:
> > >> > > > http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup
> > >> > > >
> > >> > > >
> > >> > > >
> > >> > > > Our setup is:
> > >> > > >
> > >> > > > ? 2 domain controllers with Windows 2008 R2 AD DC ->
> windows.com
> > >> > > > <http://example.com/> as Forest Root Domain and
> acme.windows.com
> > >> > > > <http://acme.example.com/> as transitive child domain
> > >> > > >
> > >> > > > ? RHEL7 as IPA server with domain: linux.com
> > >> > > > <http://linux.acme.example.com/>
> > >> > > >
> > >> > > >
> > >> > > >
> > >> > > > We have established a forest trust between windows.com and
> > >> linux.com and
> > >> > > > everything seems OK from an IPA perspective.
> > >> > > >
> > >> > > >
> > >> > > >
> > >> > > > We can work with Kerberos tickets without any issue from
> ?windows?
> > >> domain
> > >> > > > or his child domain ?acme?. (kinit, kvno?)
> > >> > > >
> > >> > > >
> > >> > > >
> > >> > > > When we use samba tools, the following command is working fine.
> > >> > > >
> > >> > > > *[root at support1 ]# wbinfo -n 'WINDOWS\Domain Admins'*
> > >> > > >
> > >> > > > *S-1-5-21-1701591335-3855227394-3044674468-512 SID_DOM_GROUP
> (2)*
> > >> > > >
> > >> > > >
> > >> > > >
> > >> > > > But, the same command against the acme domain returns an error.
> > >> > > >
> > >> > > > *[root at support1 ]# wbinfo -n 'ACME\Domain Admins'*
> > >> > > >
> > >> > > > *failed to call wbcLookupName: WBC_ERR_DOMAIN_NOT_FOUND*
> > >> > > >
> > >> > > > *Could not lookup name ACME\Domain Admins*
> > >> > > >
> > >> > > >
> > >> > > >
> > >> > > > Same problem with the following command:
> > >> > > >
> > >> > > > *[root at support1]# ipa group-add-member ad_users_external
> --external
> > >> > > > "ACME\Domain Users"*
> > >> > > >
> > >> > > > *[member user]:*
> > >> > > >
> > >> > > > *[member group]:*
> > >> > > >
> > >> > > > *  Group name: ad_users_external*
> > >> > > >
> > >> > > > *  Description: AD users external map*
> > >> > > >
> > >> > > > *  External member: *
> > >> > > >
> > >> > > > *  Member of groups: ad_users*
> > >> > > >
> > >> > > > *  Failed members:*
> > >> > > >
> > >> > > > *    member user:*
> > >> > > >
> > >> > > > *    member group: ACME\Domain Users: Cannot find specified
> domain
> > >> or
> > >> > > > server name*
> > >> > > >
> > >> > > > *-------------------------*
> > >> > > >
> > >> > > > *Number of members added 0*
> > >> > > >
> > >> > > >
> > >> > > >
> > >> > > >
> > >> > > >
> > >> > > > Any help would be appreciated
> > >> > >
> > >> > > Does
> > >> > >
> > >> > > ipa trustdomain-find windows.com
> > >> > >
> > >> > > show acme.windows.com as well ?
> > >> > >
> > >> > > Does
> > >> > >
> > >> > > ipa trust-fetch-domains ad.devel
> > >> > >
> > >> > > help to retrieve the child domain?
> > >> > >
> > >> > > Please note that if acme.windows.com now shows up you might have
> to
> > >> wait
> > >> > > 1-2 minutes until SSSD's negative caches are flushed and the new
> > >> domains
> > >> > > is discovered by SSSD, as an alternative you can just restart
> SSSD.
> > >> > >
> > >> > > HTH
> > >> > >
> > >> > > bye,
> > >> > > Sumit
> > >> > >
> > >> > > >
> > >> > > >
> > >> > > >
> > >> > > > Regards
> > >> > >
> > >> > > > --
> > >> > > > 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
> > >>
> > >> --
> > >> 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
> > >>
> > >
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141212/3ea41a0d/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sssd_nss.log
Type: application/octet-stream
Size: 32295 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141212/3ea41a0d/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sssd.log
Type: application/octet-stream
Size: 131049 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141212/3ea41a0d/attachment-0001.obj>

From dpal at redhat.com  Fri Dec 12 20:55:17 2014
From: dpal at redhat.com (Dmitri Pal)
Date: Fri, 12 Dec 2014 15:55:17 -0500
Subject: [Freeipa-users] Host based 2FA ?
In-Reply-To: <20141212142910.36ac15c4@willson.usersys.redhat.com>
References: <alpine.DEB.2.02.1412111523250.24600@e.crebbs.net>	<548A28FE.7030000@redhat.com>	<20141212130756.4ec59d40@willson.usersys.redhat.com>	<548B312E.7080703@redhat.com>	<20141212132753.534b7187@willson.usersys.redhat.com>	<548B34A3.4010603@redhat.com>	<20141212133840.6f131695@willson.usersys.redhat.com>	<548B38B4.2070401@redhat.com>
	<20141212142910.36ac15c4@willson.usersys.redhat.com>
Message-ID: <548B5635.1040404@redhat.com>

On 12/12/2014 02:29 PM, Simo Sorce wrote:
> On Fri, 12 Dec 2014 13:49:24 -0500
> Dmitri Pal <dpal at redhat.com> wrote:
>
>> On 12/12/2014 01:38 PM, Simo Sorce wrote:
>>> On Fri, 12 Dec 2014 13:32:03 -0500
>>> Dmitri Pal <dpal at redhat.com> wrote:
>>>
>>>> On 12/12/2014 01:27 PM, Simo Sorce wrote:
>>>>> On Fri, 12 Dec 2014 13:17:18 -0500
>>>>> Dmitri Pal <dpal at redhat.com> wrote:
>>>>>
>>>>>> On 12/12/2014 01:07 PM, Simo Sorce wrote:
>>>>>>> On Thu, 11 Dec 2014 18:30:06 -0500
>>>>>>> Dmitri Pal <dpal at redhat.com> wrote:
>>>>>>>
>>>>>>>> On 12/11/2014 06:32 PM, freeipa at pettyvices.com wrote:
>>>>>>>>> I'd like to be able to require 2FA on *certain* hosts and
>>>>>>>>> allow just passwords on others.
>>>>>>>>>
>>>>>>>>> It seems you can check both "passwords" and "2FA" under the
>>>>>>>>> user.
>>>>>>>>>
>>>>>>>>> I was hoping I could create a HBAC such that certain hosts
>>>>>>>>> would only allow 2FA, but I can't see an obvious way to do
>>>>>>>>> that.
>>>>>>>>>
>>>>>>>>> Is it possible?  Help on how would be great.  If not, feature
>>>>>>>>> request?
>>>>>>>>>
>>>>>>>>> thanks,
>>>>>>>>>
>>>>>>>>> -t
>>>>>>>>>
>>>>>>>> We have several tickets:
>>>>>>>>
>>>>>>>> https://fedorahosted.org/freeipa/ticket/433
>>>>>>>>
>>>>>>>> https://fedorahosted.org/freeipa/ticket/3659
>>>>>>>>
>>>>>>>> https://fedorahosted.org/freeipa/ticket/4498
>>>>>>>>
>>>>>>>> If you see
>>>>>>>> https://fedorahosted.org/freeipa/ticket/4498#comment:6 we
>>>>>>>> discussed this use case. And I was about to fork it as said
>>>>>>>> but then I realized that there is not good way on the KDC to
>>>>>>>> determine the host you are coming from. So IMO it should be a
>>>>>>>> policy decision on SSSD. There are two options:
>>>>>>>> - short term solution: allow SSSD to have a local overwrite to
>>>>>>>> require OTP if server offers different options.
>>>>>>>> - longer term solution: actually have a per host policy that is
>>>>>>>> centrally managed that is fetched per host and enforced by
>>>>>>>> SSSD.
>>>>>>>>
>>>>>>>> Before filing tickets I would like to hear opinions on the
>>>>>>>> matter.
>>>>>>> If we are using a FAST channel using the credentials of the host
>>>>>>> then you may be able to know (probably requires changes in the
>>>>>>> KDC to internally retain/convey the information).
>>>>>>> This is possible via SSSD, but will not work via kinit done by a
>>>>>>> generic user, so normal kinit's would require 2FA all the time.
>>>>>>>
>>>>>>> Simo.
>>>>>>>
>>>>>> Can kinit do FAST? Is there some kind of kinit flag to use FAST?
>>>>> Yes kinit can do FAST, but is cumbersome to manually do it.
>>>>>
>>>>>> May be in such setup we will require all clients to use FAST for
>>>>>> the accounts that have several options configured.
>>>>> It won't help, users do not have access to the host keys so they
>>>>> can't do FAST with *those* keys.
>>>>>
>>>>>> Then we will know the principal used to armor the connection and
>>>>>> can make policy decisions based on it.
>>>>> We can do this with SSSD because it has access to the host key,
>>>>> being a privileged process. Normal user's can't.
>>>>>
>>>>> Simo.
>>>>>
>>>> What about kinit working with GSS proxy in this case?
>>>> Can that help?
>>> No, kinit does not use GSSAPI.
>> I know it does not. What I mean is to use GSS proxy to as a proxy for
>> kinit to armor the request.
>> Have an option for kinit to send user credentials to the local
>> socket, make GSSproxy or SSSD do the work for him.
> There is no way to convey this request over the GSS-Proxy protocol
> either, sorry.

Did I ever said that I mean to use GSS-proxy protocol.
I am more thinking of GSS proxy as a conduit of the things related to 
kerberos that has access to the host key. Now it exposes one socket. It 
can expose another with the completely different protocol.

>
>> If we are paranoid we can use SSL over this socket to pass the user
>> credential.
>> But I am still not convinced we should care about this use case.
> We should not care for the kinit case.
>
> I think it is a potential good thing for the SSSD/pam_krb5 case (being
> able to say that in order to log into a specific machine you need 2FA,
> but on another less privileged one you can use single factor).
>
> Simo.
>


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.



From mchesler at chesent.com  Fri Dec 12 20:59:55 2014
From: mchesler at chesent.com (Matt Chesler)
Date: Fri, 12 Dec 2014 15:59:55 -0500
Subject: [Freeipa-users] Replica Setup Issue
Message-ID: <CACjq758=ybEf2RVcgjnSHh+muCAGV0nUUu_0xTgvqFz8W3CgsA@mail.gmail.com>

1. Create replica ipa-1 from old-ipa-1
2. Followed procedure documented at
http://www.freeipa.org/page/Howto/Promote_CA_to_Renewal_and_CRL_Master to
make ipa-1 the node responsible for CRL generation and CA renewal
3. Prepare ipa-2 to be a replica by running 'ipa-replica-prepare
ipa-2.example.com' on ipa-1 and copying over the resulting gpg
4. Ran ipa-replica-install on ipa-2 and received the following
output/failure:

===================

[root at ipa-2 ~]# ipa-replica-install --setup-ca
/var/lib/ipa/replica-info-ipa-2.example.com.gpg
Directory Manager (existing master) password:

Run connection check to master
Check connection from replica to remote master 'ipa-1.example.com':
   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
   PKI-CA: Directory Service port (7389): 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 at EXAMPLE.COM password:

Execute check on remote master
Check connection from master to remote replica 'ipa-2.example.com':
   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
   PKI-CA: Directory Service port (7389): OK

Connection from master to replica is OK.

Connection check OK
Configuring NTP daemon (ntpd)
  [1/4]: stopping ntpd
  [2/4]: writing configuration
  [3/4]: configuring ntpd to start on boot
  [4/4]: starting ntpd
Done configuring NTP daemon (ntpd).
Configuring directory server for the CA (pkids): Estimated time 30 seconds
  [1/3]: creating directory server user
  [2/3]: creating directory server instance
  [3/3]: restarting directory server
Done configuring directory server for the CA (pkids).
Configuring certificate server (pki-cad): Estimated time 3 minutes 30
seconds
  [1/17]: creating certificate server user
  [2/17]: creating pki-ca instance
  [3/17]: configuring certificate server instance
ipa         : CRITICAL failed to configure ca instance Command
'/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname ipa-2.example.com
-cs_port 9445 -client_certdb_dir /tmp/tmp-ATedaS -client_certdb_pwd
XXXXXXXX -preop_pin SAW89xQS4ICFy5zYWv0m -domain_name IPA -admin_user admin
-admin_email root at localhost -admin_password XXXXXXXX -agent_name
ipa-ca-agent -agent_key_size 2048 -agent_key_type rsa -agent_cert_subject
CN=ipa-ca-agent,O=EXAMPLE.COM -ldap_host ipa-2.example.com -ldap_port 7389
-bind_dn cn=Directory Manager -bind_password XXXXXXXX -base_dn o=ipaca
-db_name ipaca -key_size 2048 -key_type rsa -key_algorithm SHA256withRSA
-save_p12 true -backup_pwd XXXXXXXX -subsystem_name pki-cad -token_name
internal -ca_subsystem_cert_subject_name CN=CA Subsystem,O=EXAMPLE.COM
-ca_subsystem_cert_subject_name CN=CA Subsystem,O=EXAMPLE.COM
-ca_ocsp_cert_subject_name CN=OCSP Subsystem,O=EXAMPLE.COM
-ca_server_cert_subject_name CN=ipa-2.example.com,O=EXAMPLE.COM
-ca_audit_signing_cert_subject_name CN=CA Audit,O=EXAMPLE.COM
-ca_sign_cert_subject_name CN=Certificate Authority,O=EXAMPLE.COM -external
false -clone true -clone_p12_file ca.p12 -clone_p12_password XXXXXXXX
-sd_hostname ipa-1.example.com -sd_admin_port 443 -sd_admin_name admin
-sd_admin_password XXXXXXXX -clone_start_tls true -clone_uri
https://ipa-1.example.com:443' returned non-zero exit status 255

Your system may be partly configured.
Run /usr/sbin/ipa-server-install --uninstall to clean up.

Configuration of CA failed

===================

Found the following in /var/log/ipareplica-install.log:

--snip--
#############################################
Attempting to connect to: ipa-2.example.com:9445
Connected.
Posting Query =
https://ipa-2.example.com:9445//ca/admin/console/config/wizard?p=5&subsystem=CA&session_id=4306304501997072616&xml=true
RESPONSE STATUS:  HTTP/1.1 200 OK
RESPONSE HEADER:  Server: Apache-Coyote/1.1
RESPONSE HEADER:  Content-Type: text/html;charset=UTF-8
RESPONSE HEADER:  Date: Fri, 12 Dec 2014 20:47:08 GMT
RESPONSE HEADER:  Connection: close
Exception in SecurityDomainLoginPanel(): java.lang.Exception: Invalid
clone_uri
ERROR: ConfigureSubCA: SecurityDomainLoginPanel() failure
ERROR: unable to create CA

#######################################################################

2014-12-12T20:47:08Z DEBUG stderr=java.lang.Exception: Invalid clone_uri
at ConfigureCA.SecurityDomainLoginPanel(ConfigureCA.java:392)
at ConfigureCA.ConfigureCAInstance(ConfigureCA.java:1188)
at ConfigureCA.main(ConfigureCA.java:1672)

2014-12-12T20:47:08Z CRITICAL failed to configure ca instance Command
'/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname ipa-2.example.com
-cs_port 9445 -client_certdb_dir /tmp/tmp-ATedaS -client_certdb_pwd
XXXXXXXX -preop_pin SAW89xQS4ICFy5zYWv0m -domain_name IPA -admin_user admin
-admin_email root at localhost -admin_password XXXXXXXX -agent_name
ipa-ca-agent -agent_key_size 2048 -agent_key_type rsa -agent_cert_subject
CN=ipa-ca-agent,O=EXAMPLE.COM -ldap_host ipa-2.example.com -ldap_port 7389
-bind_dn cn=Directory Manager -bind_password XXXXXXXX -base_dn o=ipaca
-db_name ipaca -key_size 2048 -key_type rsa -key_algorithm SHA256withRSA
-save_p12 true -backup_pwd XXXXXXXX -subsystem_name pki-cad -token_name
internal -ca_subsystem_cert_subject_name CN=CA Subsystem,O=EXAMPLE.COM
-ca_subsystem_cert_subject_name CN=CA Subsystem,O=EXAMPLE.COM
-ca_ocsp_cert_subject_name CN=OCSP Subsystem,O=EXAMPLE.COM
-ca_server_cert_subject_name CN=ipa-2.example.com,O=EXAMPLE.COM
-ca_audit_signing_cert_subject_name CN=CA Audit,O=EXAMPLE.COM
-ca_sign_cert_subject_name CN=Certificate Authority,O=EXAMPLE.COM -external
false -clone true -clone_p12_file ca.p12 -clone_p12_password XXXXXXXX
-sd_hostname ipa-1.example.com -sd_admin_port 443 -sd_admin_name admin
-sd_admin_password XXXXXXXX -clone_start_tls true -clone_uri
https://ipa-1.example.com:443' returned non-zero exit status 255
2014-12-12T20:47:08Z INFO   File
"/usr/lib/python2.6/site-packages/ipaserver/install/installutils.py", line
614, in run_script
    return_value = main_function()

  File "/usr/sbin/ipa-replica-install", line 476, in main
    (CA, cs) = cainstance.install_replica_ca(config)

  File "/usr/lib/python2.6/site-packages/ipaserver/install/cainstance.py",
line 1626, in install_replica_ca
    subject_base=config.subject_base)

  File "/usr/lib/python2.6/site-packages/ipaserver/install/cainstance.py",
line 626, in configure_instance
    self.start_creation(runtime=210)

  File "/usr/lib/python2.6/site-packages/ipaserver/install/service.py",
line 358, in start_creation
    method()

  File "/usr/lib/python2.6/site-packages/ipaserver/install/cainstance.py",
line 888, in __configure_instance
    raise RuntimeError('Configuration of CA failed')

2014-12-12T20:47:08Z INFO The ipa-replica-install command failed,
exception: RuntimeError: Configuration of CA failed
--snip--

===================

I've searched high and low for a solution and the closest I've found is
this exchange from Sept 2013 -
http://www.redhat.com/archives/freeipa-users/2013-September/msg00203.html -
which doesn't have a resolution.  My issue is almost identical with the
exception of newer revisions:

Linux ipa-2.example.com 2.6.32-504.1.3.el6.x86_64 #1 SMP Tue Nov 11
17:57:25 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
ipa-server-3.0.0-42.el6.x86_64
pki-selinux-9.0.3-38.el6_6.noarch
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141212/87648923/attachment.htm>

From manuel.lopes72 at gmail.com  Sat Dec 13 13:13:30 2014
From: manuel.lopes72 at gmail.com (Manuel Lopes)
Date: Sat, 13 Dec 2014 14:13:30 +0100
Subject: [Freeipa-users] Forest trust and AD child domain
In-Reply-To: <CAKFNJrsS1-h8pu+UoWWCwAUu3GA8D8XtGva7J3in7omSGCjiUw@mail.gmail.com>
References: <CAKFNJrsYA9M1j5cjH5kA4c6U9QGEr5pGd90QVRDWf8ajHk9tqw@mail.gmail.com>
	<20141211190542.GT14057@localhost.localdomain>
	<CAKFNJrt_+GkUwDNuDhZLoGEFNfSV=omb=qCJfbJJq=RkXHxqnQ@mail.gmail.com>
	<20141212093311.GU14057@localhost.localdomain>
	<CAKFNJrvBrvRJbxU-zsXhmsek8MZrZdz-b1p1O1MvfmUPv256vg@mail.gmail.com>
	<CAKFNJrsJvj8098k9vzScONO4endDE3LGuH1AzUY6_yDRS3MT1Q@mail.gmail.com>
	<20141212203234.GA6877@localhost.localdomain>
	<CAKFNJrsS1-h8pu+UoWWCwAUu3GA8D8XtGva7J3in7omSGCjiUw@mail.gmail.com>
Message-ID: <CAKFNJrsRRZFQmb+4892WPtx2d9jcJVfZeW1LQJmWOJKK7mvsaw@mail.gmail.com>

Hi,

As explained in the previous email, the getent is successful.


*[root at support1 ~]# getent group 'ACME\Domain Users' domain
users at acme.windows.com:*:**365600513:administrator at acme.windows.com
<365600513%3Aadministrator at acme.windows.com>*



In fact, our real problem is not the ?wbinfo ?n? but the following command:

*[root at support1 sssd]# ipa group-add-member ad_users_external --external
"ACME\Domain Users"*

*[member user]:*

*[member group]:*

*  Group name: ad_users_external*

*  Description: AD users external map*

*  External member: *

*  Member of groups: ad_users*

*  Failed members:*

*    member user:*

*    member group: ACME\Domain Users: Cannot find specified domain or
server name*

*-------------------------*

*Number of members added 0*

*-------------------------*



We cannot add ACME?s domain users in the ad_users_external.



I attached the sssd logs.



Regards

2014-12-12 21:51 GMT+01:00 Manuel Lopes <manuel.lopes72 at gmail.com>:
>
> OK.
>
> Command successful
> [root at support1 ~]# getent group  'ACME\Domain Users'
> domain users at acme.windows.com:*:365600513:administrator at acme.windows.com
>
> Log files attached
>
> Thanks
>
> 2014-12-12 21:32 GMT+01:00 Sumit Bose <sbose at redhat.com>:
>>
>> On Fri, Dec 12, 2014 at 08:41:27PM +0100, Manuel Lopes wrote:
>> > [root at support1 ~]# ipa idrange-find
>> > ----------------
>> > 3 ranges matched
>> > ----------------
>> > Range name: LINUX.COM_id_range
>> > First Posix ID of the range: 1066000000
>> > Number of IDs in the range: 200000
>> > First RID of the corresponding RID range: 1000
>> > First RID of the secondary RID range: 100000000
>> > Range type: local domain range
>> >
>> > Range name: WINDOWS.COM_id_range
>> > First Posix ID of the range: 730200000
>> > Number of IDs in the range: 200000
>> > First RID of the corresponding RID range: 0
>> > Domain SID of the trusted domain:
>> S-1-5-21-1701591335-3855227394-3044674468
>> > Range type: Active Directory domain range
>> >
>> > Range name: ACME.WINDOWS.COM_id_range
>> > First Posix ID of the range: 365600000
>> > Number of IDs in the range: 200000
>> > First RID of the corresponding RID range: 0
>> > Domain SID of the trusted domain:
>> S-1-5-21-1215373191-1991333051-3772904882
>> > Range type: Active Directory domain range
>> > ----------------------------
>> > Number of entries returned 3
>> > ----------------------------
>> >
>> >
>> > As we can see in the ouput of the command, the range type is "ad POSIX
>> > attributes".
>>
>> no, it's only 'Active Directory domain range', this is good because with
>> this type we generate the UIDs and GIDs algorithmically.
>>
>> > In our case, the gidNumber is not set in the "ACME\Domain Users" AD
>> group,
>> > nor in the " WINDOWS\Domain Users".
>> > With a gidNumber attribute value, the 'wbinfo -n "ACME\Domain Users"'
>> still
>> > command fails.
>>
>> no need to set the ID attributes in AD. But I should have mentioned
>> that wbinfo is quite useless nowadays with FreeIPA because winbind is
>> only used to assure some types of communication with AD. All user and
>> group lookups and IP-mapping is done by SSSD. Please try
>>
>> getent group 'ACME\Domain Users'
>>
>>
>> and send the sssd_nss.log and sssd_example.com.log files.
>>
>> bye,
>> Sumit
>>
>> >
>> > Thanks
>> >
>> > 2014-12-12 19:51 GMT+01:00 Manuel Lopes <manuel.lopes72 at gmail.com>:
>> > >
>> > > [root at support1 ~]# ipa idrange-find
>> > > ----------------
>> > > 3 ranges matched
>> > > ----------------
>> > >   Range name: LINUX.COM_id_range
>> > >   First Posix ID of the range: 1066000000
>> > >   Number of IDs in the range: 200000
>> > >   First RID of the corresponding RID range: 1000
>> > >   First RID of the secondary RID range: 100000000
>> > >   Range type: local domain range
>> > >
>> > >   Range name: WINDOWS.COM_id_range
>> > >   First Posix ID of the range: 730200000
>> > >   Number of IDs in the range: 200000
>> > >   First RID of the corresponding RID range: 0
>> > >   Domain SID of the trusted domain:
>> > > S-1-5-21-1701591335-3855227394-3044674468
>> > >   Range type: Active Directory domain range
>> > >
>> > >   Range name: ACME.WINDOWS.COM_id_range
>> > >   First Posix ID of the range: 365600000
>> > >   Number of IDs in the range: 200000
>> > >   First RID of the corresponding RID range: 0
>> > >   Domain SID of the trusted domain:
>> > > S-1-5-21-1215373191-1991333051-3772904882
>> > >   Range type: Active Directory domain range
>> > > ----------------------------
>> > > Number of entries returned 3
>> > > ----------------------------
>> > >
>> > >
>> > > As we can see in the ouput of the command, the range type is "ad POSIX
>> > > attributes".
>> > > In our case, the gidNumber is not set in the "ACME\Domain Users" AD
>> group,
>> > > nor in the " WINDOWS\Domain Users".
>> > > With a gidNumber attribute value, the 'wbinfo -n "ACME\Domain Users"'
>> > > still command fails.
>> > >
>> > > Thanks
>> > >
>> > >
>> > > 2014-12-12 10:33 GMT+01:00 Sumit Bose <sbose at redhat.com>:
>> > >>
>> > >> On Fri, Dec 12, 2014 at 02:06:05AM +0100, Manuel Lopes wrote:
>> > >> > Hi Sumit,
>> > >> >
>> > >> > Thank you very much for the prompt reply
>> > >> >
>> > >> > [root at support1 ~]# ipa trustdomain-find windows.com
>> > >> >   Domain name: windows.com
>> > >> >   Domain NetBIOS name: WINDOWS
>> > >> >   Domain Security Identifier:
>> S-1-5-21-1701591335-3855227394-3044674468
>> > >> >   Domain enabled: True
>> > >> >
>> > >> >   Domain name: acme.windows.com
>> > >> >   Domain NetBIOS name: ACME
>> > >> >   Domain Security Identifier:
>> S-1-5-21-1215373191-1991333051-3772904882
>> > >> >   Domain enabled: True
>> > >> > ----------------------------
>> > >> > Number of entries returned 2
>> > >> > ----------------------------
>> > >>
>> > >> ok, so ACME was discovered successful, can you check next the output
>> of
>> > >>
>> > >> ipa idrange-find
>> > >>
>> > >> The important attribute is the 'Range type' for the AD domains. If
>> it is
>> > >> 'Active Directory trust range with POSIX attributes' it is expected
>> that
>> > >> users and groups in the AD forest have the POSIX UID and GID
>> attributes
>> > >> set and only those users and groups will be available in the IPA
>> domain.
>> > >> In this case please check if 'ACME\Domain Users' have the GID
>> attribute
>> > >> set.
>> > >>
>> > >> If this does not help (please mind the negative cache of SSSD) please
>> > >> send the SSSD logs in /var/log/sssd on the IPA server. You might
>> need to
>> > >> enable logging in sssd.conf by setting 'debug_level = 10' in the
>> > >> [domain/..] and [nss] section of sssd.conf.
>> > >>
>> > >> bye,
>> > >> Sumit
>> > >>
>> > >> >
>> > >> > [root at support1 ~]# ipa trust-fetch-domains windows.com
>> > >> > -------------------------------
>> > >> > No new trust domains were found
>> > >> > -------------------------------
>> > >> > ----------------------------
>> > >> > Number of entries returned 0
>> > >> > ----------------------------
>> > >> >
>> > >> > Regards
>> > >> > Le 11 d?c. 2014 20:08, "Sumit Bose" <sbose at redhat.com
>> > >> > <javascript:_e(%7B%7D,'cvml','sbose at redhat.com');>> a ?crit :
>> > >> >
>> > >> > > On Thu, Dec 11, 2014 at 06:45:49PM +0100, Manuel Lopes wrote:
>> > >> > > >  Hello,
>> > >> > > >
>> > >> > > >
>> > >> > > > We have been following the AD integration guide for IPAv3:
>> > >> > > > http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup
>> > >> > > >
>> > >> > > >
>> > >> > > >
>> > >> > > > Our setup is:
>> > >> > > >
>> > >> > > > ? 2 domain controllers with Windows 2008 R2 AD DC ->
>> windows.com
>> > >> > > > <http://example.com/> as Forest Root Domain and
>> acme.windows.com
>> > >> > > > <http://acme.example.com/> as transitive child domain
>> > >> > > >
>> > >> > > > ? RHEL7 as IPA server with domain: linux.com
>> > >> > > > <http://linux.acme.example.com/>
>> > >> > > >
>> > >> > > >
>> > >> > > >
>> > >> > > > We have established a forest trust between windows.com and
>> > >> linux.com and
>> > >> > > > everything seems OK from an IPA perspective.
>> > >> > > >
>> > >> > > >
>> > >> > > >
>> > >> > > > We can work with Kerberos tickets without any issue from
>> ?windows?
>> > >> domain
>> > >> > > > or his child domain ?acme?. (kinit, kvno?)
>> > >> > > >
>> > >> > > >
>> > >> > > >
>> > >> > > > When we use samba tools, the following command is working fine.
>> > >> > > >
>> > >> > > > *[root at support1 ]# wbinfo -n 'WINDOWS\Domain Admins'*
>> > >> > > >
>> > >> > > > *S-1-5-21-1701591335-3855227394-3044674468-512 SID_DOM_GROUP
>> (2)*
>> > >> > > >
>> > >> > > >
>> > >> > > >
>> > >> > > > But, the same command against the acme domain returns an error.
>> > >> > > >
>> > >> > > > *[root at support1 ]# wbinfo -n 'ACME\Domain Admins'*
>> > >> > > >
>> > >> > > > *failed to call wbcLookupName: WBC_ERR_DOMAIN_NOT_FOUND*
>> > >> > > >
>> > >> > > > *Could not lookup name ACME\Domain Admins*
>> > >> > > >
>> > >> > > >
>> > >> > > >
>> > >> > > > Same problem with the following command:
>> > >> > > >
>> > >> > > > *[root at support1]# ipa group-add-member ad_users_external
>> --external
>> > >> > > > "ACME\Domain Users"*
>> > >> > > >
>> > >> > > > *[member user]:*
>> > >> > > >
>> > >> > > > *[member group]:*
>> > >> > > >
>> > >> > > > *  Group name: ad_users_external*
>> > >> > > >
>> > >> > > > *  Description: AD users external map*
>> > >> > > >
>> > >> > > > *  External member: *
>> > >> > > >
>> > >> > > > *  Member of groups: ad_users*
>> > >> > > >
>> > >> > > > *  Failed members:*
>> > >> > > >
>> > >> > > > *    member user:*
>> > >> > > >
>> > >> > > > *    member group: ACME\Domain Users: Cannot find specified
>> domain
>> > >> or
>> > >> > > > server name*
>> > >> > > >
>> > >> > > > *-------------------------*
>> > >> > > >
>> > >> > > > *Number of members added 0*
>> > >> > > >
>> > >> > > >
>> > >> > > >
>> > >> > > >
>> > >> > > >
>> > >> > > > Any help would be appreciated
>> > >> > >
>> > >> > > Does
>> > >> > >
>> > >> > > ipa trustdomain-find windows.com
>> > >> > >
>> > >> > > show acme.windows.com as well ?
>> > >> > >
>> > >> > > Does
>> > >> > >
>> > >> > > ipa trust-fetch-domains ad.devel
>> > >> > >
>> > >> > > help to retrieve the child domain?
>> > >> > >
>> > >> > > Please note that if acme.windows.com now shows up you might
>> have to
>> > >> wait
>> > >> > > 1-2 minutes until SSSD's negative caches are flushed and the new
>> > >> domains
>> > >> > > is discovered by SSSD, as an alternative you can just restart
>> SSSD.
>> > >> > >
>> > >> > > HTH
>> > >> > >
>> > >> > > bye,
>> > >> > > Sumit
>> > >> > >
>> > >> > > >
>> > >> > > >
>> > >> > > >
>> > >> > > > Regards
>> > >> > >
>> > >> > > > --
>> > >> > > > 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
>> > >>
>> > >> --
>> > >> 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
>> > >>
>> > >
>>
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141213/46083678/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sssd_nss.log
Type: application/octet-stream
Size: 44705 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141213/46083678/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sssd.log
Type: application/octet-stream
Size: 156858 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141213/46083678/attachment-0001.obj>

From dbischof at hrz.uni-kassel.de  Mon Dec 15 09:16:01 2014
From: dbischof at hrz.uni-kassel.de (dbischof at hrz.uni-kassel.de)
Date: Mon, 15 Dec 2014 10:16:01 +0100 (CET)
Subject: [Freeipa-users] 3.0.0-42 Replication issue after Centos6.5->6.6
 upgrade
In-Reply-To: <5474FFC0.7030906@redhat.com>
References: <etPan.545c5626.7545e146.144@Drone-3.local>
	<545C602B.90802@redhat.com>
	<etPan.545c65b2.5bd062c2.144@Drone-3.local>
	<545D2B79.7000200@redhat.com>
	<alpine.LSU.2.11.1411181343060.15331@fred>
	<etPan.546b93a6.327b23c6.16f@Drone-5.appnovation.com>
	<546C599B.9090101@redhat.com> <546DBBB9.5030404@redhat.com>
	<alpine.LSU.2.11.1411201152330.18310@fred>
	<546DFF77.7090104@redhat.com>
	<alpine.LSU.2.11.1411211033510.1449@fred>
	<546F193B.4020602@redhat.com> <546F5EF0.2020608@redhat.com>
	<alpine.LSU.2.11.1411252014200.9549@fred> <5474FFC0.7030906@redhat.com>
Message-ID: <alpine.LSU.2.11.1412151011360.12534@fred>

Hi,

On Tue, 25 Nov 2014, Rich Megginson wrote:

> On 11/25/2014 12:32 PM, dbischof at hrz.uni-kassel.de wrote:
>> 
>> with the help of Thierry and Rich I managed to debug the running 
>> ns-slapd on Server1 (see below). The failing attempt of decoding the 
>> SASL data returns a not very fruitful "-1" (SASL_FAIL, "generic 
>> failure").
>> 
>> Any ideas? Short summary:
>> 
>> Server1 = running IPA server
>> Server2 = intended IPA replica
>> 
>> Both machines run the exact same, up-to-date version of CentOS 6.6. 
>> However: I had to run "ipa-replica-install" _without_ the option 
>> "--setup-ca" (didn't work, installation failed with some obscure Perl 
>> error), so there's no ns-slapd instance running for PKI-IPA. May this 
>> be related?
> [...]
> At this point, it's going to take more than a trivial amount of high 
> latency back-and-forth on the mailling lists.  I think we have probably 
> run out of log levels for you to try.  Please open a ticket against IPA. 
> While this may turn out to be a bug in 389, at the moment it is only 
> reproducible in your IPA environment.
> [...]

I've opened Ticket #4807
https://fedorahosted.org/freeipa/ticket/4807
on this issue.

> [...]

Mit freundlichen Gruessen/With best regards,

--Daniel.



From dbischof at hrz.uni-kassel.de  Mon Dec 15 09:34:24 2014
From: dbischof at hrz.uni-kassel.de (dbischof at hrz.uni-kassel.de)
Date: Mon, 15 Dec 2014 10:34:24 +0100 (CET)
Subject: [Freeipa-users] Replica Setup Issue
In-Reply-To: <CACjq758=ybEf2RVcgjnSHh+muCAGV0nUUu_0xTgvqFz8W3CgsA@mail.gmail.com>
References: <CACjq758=ybEf2RVcgjnSHh+muCAGV0nUUu_0xTgvqFz8W3CgsA@mail.gmail.com>
Message-ID: <alpine.LSU.2.11.1412151017340.12534@fred>

Hi Matt,

I ran into this a couple of months ago. I ended up creating the replica 
without "--setup-ca" which first appeared to work, but then it turned out 
that replication is (at least for me) broken, cf. Ticket #4807 
(https://fedorahosted.org/freeipa/ticket/4807).

On Fri, 12 Dec 2014, Matt Chesler wrote:

> 1. Create replica ipa-1 from old-ipa-1
> 2. Followed procedure documented at 
> http://www.freeipa.org/page/Howto/Promote_CA_to_Renewal_and_CRL_Master 
> to make ipa-1 the node responsible for CRL generation and CA renewal
> 3. Prepare ipa-2 to be a replica by running 'ipa-replica-prepare 
> ipa-2.example.com' on ipa-1 and copying over the resulting gpg
> 4. Ran ipa-replica-install on ipa-2 and received the following 
> output/failure:
>
> ===================
> [root at ipa-2 ~]# ipa-replica-install --setup-ca 
> /var/lib/ipa/replica-info-ipa-2.example.com.gpg
> [...]
>  [3/17]: configuring certificate server instance ipa : CRITICAL failed 
> to configure ca instance Command '/usr/bin/perl /usr/bin/pkisilent 
> ConfigureCA -cs_hostname ipa-2.example.com -cs_port 9445 
> -client_certdb_dir /tmp/tmp-ATedaS -client_certdb_pwd XXXXXXXX 
> -preop_pin SAW89xQS4ICFy5zYWv0m -domain_name IPA -admin_user admin 
> -admin_email root at localhost -admin_password XXXXXXXX -agent_name 
> ipa-ca-agent -agent_key_size 2048 -agent_key_type rsa 
> -agent_cert_subject CN=ipa-ca-agent,O=EXAMPLE.COM -ldap_host 
> ipa-2.example.com -ldap_port 7389 -bind_dn cn=Directory Manager 
> -bind_password XXXXXXXX -base_dn o=ipaca -db_name ipaca -key_size 2048 
> -key_type rsa -key_algorithm SHA256withRSA -save_p12 true -backup_pwd 
> XXXXXXXX -subsystem_name pki-cad -token_name internal 
> -ca_subsystem_cert_subject_name CN=CA Subsystem,O=EXAMPLE.COM 
> -ca_subsystem_cert_subject_name CN=CA Subsystem,O=EXAMPLE.COM 
> -ca_ocsp_cert_subject_name CN=OCSP Subsystem,O=EXAMPLE.COM 
> -ca_server_cert_subject_name CN=ipa-2.example.com,O=EXAMPLE.COM 
> -ca_audit_signing_cert_subject_name CN=CA Audit,O=EXAMPLE.COM 
> -ca_sign_cert_subject_name CN=Certificate Authority,O=EXAMPLE.COM 
> -external false -clone true -clone_p12_file ca.p12 -clone_p12_password 
> XXXXXXXX -sd_hostname ipa-1.example.com -sd_admin_port 443 
> -sd_admin_name admin -sd_admin_password XXXXXXXX -clone_start_tls true 
> -clone_uri https://ipa-1.example.com:443' returned non-zero exit status 
> 255
>
> Your system may be partly configured.
> Run /usr/sbin/ipa-server-install --uninstall to clean up.
>
> Configuration of CA failed
>
> ===================
> [...]


Mit freundlichen Gruessen/With best regards,

--Daniel.



From mkosek at redhat.com  Mon Dec 15 11:18:45 2014
From: mkosek at redhat.com (Martin Kosek)
Date: Mon, 15 Dec 2014 12:18:45 +0100
Subject: [Freeipa-users] 3.0.0-42 Replication issue after Centos6.5->6.6
 upgrade
In-Reply-To: <alpine.LSU.2.11.1412151011360.12534@fred>
References: <etPan.545c5626.7545e146.144@Drone-3.local>	<545C602B.90802@redhat.com>	<etPan.545c65b2.5bd062c2.144@Drone-3.local>	<545D2B79.7000200@redhat.com>	<alpine.LSU.2.11.1411181343060.15331@fred>	<etPan.546b93a6.327b23c6.16f@Drone-5.appnovation.com>	<546C599B.9090101@redhat.com>
	<546DBBB9.5030404@redhat.com>	<alpine.LSU.2.11.1411201152330.18310@fred>	<546DFF77.7090104@redhat.com>	<alpine.LSU.2.11.1411211033510.1449@fred>	<546F193B.4020602@redhat.com>
	<546F5EF0.2020608@redhat.com>	<alpine.LSU.2.11.1411252014200.9549@fred>
	<5474FFC0.7030906@redhat.com>
	<alpine.LSU.2.11.1412151011360.12534@fred>
Message-ID: <548EC395.80608@redhat.com>

On 12/15/2014 10:16 AM, dbischof at hrz.uni-kassel.de wrote:
> Hi,
> 
> On Tue, 25 Nov 2014, Rich Megginson wrote:
> 
>> On 11/25/2014 12:32 PM, dbischof at hrz.uni-kassel.de wrote:
>>>
>>> with the help of Thierry and Rich I managed to debug the running ns-slapd on
>>> Server1 (see below). The failing attempt of decoding the SASL data returns a
>>> not very fruitful "-1" (SASL_FAIL, "generic failure").
>>>
>>> Any ideas? Short summary:
>>>
>>> Server1 = running IPA server
>>> Server2 = intended IPA replica
>>>
>>> Both machines run the exact same, up-to-date version of CentOS 6.6. However:
>>> I had to run "ipa-replica-install" _without_ the option "--setup-ca" (didn't
>>> work, installation failed with some obscure Perl error), so there's no
>>> ns-slapd instance running for PKI-IPA. May this be related?
>> [...]
>> At this point, it's going to take more than a trivial amount of high latency
>> back-and-forth on the mailling lists.  I think we have probably run out of
>> log levels for you to try.  Please open a ticket against IPA. While this may
>> turn out to be a bug in 389, at the moment it is only reproducible in your
>> IPA environment.
>> [...]
> 
> I've opened Ticket #4807
> https://fedorahosted.org/freeipa/ticket/4807
> on this issue.

Thanks. See my comment https://fedorahosted.org/freeipa/ticket/4807#comment:1 -
as mentioned in the thread, we will need more data/cooperation to continue with
this one.

Thanks,
Martin



From ctcard at hotmail.com  Mon Dec 15 13:18:31 2014
From: ctcard at hotmail.com (Chris Card)
Date: Mon, 15 Dec 2014 13:18:31 +0000
Subject: [Freeipa-users] freeipa server 4.1 with ipa client 2.2
Message-ID: <DUB125-W5166FD332EC24D1919331CC6F0@phx.gbl>

Should a machine running ipa client version 2.2 (because it's running Centos 6.3) be able to work with a freeipa server version 4.1?The ipa-client-install script works ok and I see client machine listed as one of the hosts in the freeipa admin gui, but I'm not sure if the version of sssd running on the client (1.8) has all the functionality for e.g. ssh key access for users.

Chris 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141215/b34108ef/attachment.htm>

From sbose at redhat.com  Mon Dec 15 14:42:59 2014
From: sbose at redhat.com (Sumit Bose)
Date: Mon, 15 Dec 2014 15:42:59 +0100
Subject: [Freeipa-users] Forest trust and AD child domain
In-Reply-To: <CAKFNJrsRRZFQmb+4892WPtx2d9jcJVfZeW1LQJmWOJKK7mvsaw@mail.gmail.com>
References: <CAKFNJrsYA9M1j5cjH5kA4c6U9QGEr5pGd90QVRDWf8ajHk9tqw@mail.gmail.com>
	<20141211190542.GT14057@localhost.localdomain>
	<CAKFNJrt_+GkUwDNuDhZLoGEFNfSV=omb=qCJfbJJq=RkXHxqnQ@mail.gmail.com>
	<20141212093311.GU14057@localhost.localdomain>
	<CAKFNJrvBrvRJbxU-zsXhmsek8MZrZdz-b1p1O1MvfmUPv256vg@mail.gmail.com>
	<CAKFNJrsJvj8098k9vzScONO4endDE3LGuH1AzUY6_yDRS3MT1Q@mail.gmail.com>
	<20141212203234.GA6877@localhost.localdomain>
	<CAKFNJrsS1-h8pu+UoWWCwAUu3GA8D8XtGva7J3in7omSGCjiUw@mail.gmail.com>
	<CAKFNJrsRRZFQmb+4892WPtx2d9jcJVfZeW1LQJmWOJKK7mvsaw@mail.gmail.com>
Message-ID: <20141215144258.GA2868@localhost.localdomain>

On Sat, Dec 13, 2014 at 02:13:30PM +0100, Manuel Lopes wrote:
> Hi,
> 
> As explained in the previous email, the getent is successful.
> 
> 
> *[root at support1 ~]# getent group 'ACME\Domain Users' domain
> users at acme.windows.com:*:**365600513:administrator at acme.windows.com
> <365600513%3Aadministrator at acme.windows.com>*
> 
> 
> 
> In fact, our real problem is not the ?wbinfo ?n? but the following command:
> 
> *[root at support1 sssd]# ipa group-add-member ad_users_external --external
> "ACME\Domain Users"*
> 
> *[member user]:*
> 
> *[member group]:*
> 
> *  Group name: ad_users_external*
> 
> *  Description: AD users external map*
> 
> *  External member: *
> 
> *  Member of groups: ad_users*
> 
> *  Failed members:*
> 
> *    member user:*
> 
> *    member group: ACME\Domain Users: Cannot find specified domain or
> server name*
> 
> *-------------------------*
> 
> *Number of members added 0*
> 
> *-------------------------*
> 
> 
> 
> We cannot add ACME?s domain users in the ad_users_external.
> 
> 
> 
> I attached the sssd logs.

Can you send the corresponding domain log file as well, it should be
called sssd_linux.com.log or similar.

bye,
Sumit

> 
> 
> 
> Regards
> 
> 2014-12-12 21:51 GMT+01:00 Manuel Lopes <manuel.lopes72 at gmail.com>:
> >
> > OK.
> >
> > Command successful
> > [root at support1 ~]# getent group  'ACME\Domain Users'
> > domain users at acme.windows.com:*:365600513:administrator at acme.windows.com
> >
> > Log files attached
> >
> > Thanks
> >
> > 2014-12-12 21:32 GMT+01:00 Sumit Bose <sbose at redhat.com>:
> >>
> >> On Fri, Dec 12, 2014 at 08:41:27PM +0100, Manuel Lopes wrote:
> >> > [root at support1 ~]# ipa idrange-find
> >> > ----------------
> >> > 3 ranges matched
> >> > ----------------
> >> > Range name: LINUX.COM_id_range
> >> > First Posix ID of the range: 1066000000
> >> > Number of IDs in the range: 200000
> >> > First RID of the corresponding RID range: 1000
> >> > First RID of the secondary RID range: 100000000
> >> > Range type: local domain range
> >> >
> >> > Range name: WINDOWS.COM_id_range
> >> > First Posix ID of the range: 730200000
> >> > Number of IDs in the range: 200000
> >> > First RID of the corresponding RID range: 0
> >> > Domain SID of the trusted domain:
> >> S-1-5-21-1701591335-3855227394-3044674468
> >> > Range type: Active Directory domain range
> >> >
> >> > Range name: ACME.WINDOWS.COM_id_range
> >> > First Posix ID of the range: 365600000
> >> > Number of IDs in the range: 200000
> >> > First RID of the corresponding RID range: 0
> >> > Domain SID of the trusted domain:
> >> S-1-5-21-1215373191-1991333051-3772904882
> >> > Range type: Active Directory domain range
> >> > ----------------------------
> >> > Number of entries returned 3
> >> > ----------------------------
> >> >
> >> >
> >> > As we can see in the ouput of the command, the range type is "ad POSIX
> >> > attributes".
> >>
> >> no, it's only 'Active Directory domain range', this is good because with
> >> this type we generate the UIDs and GIDs algorithmically.
> >>
> >> > In our case, the gidNumber is not set in the "ACME\Domain Users" AD
> >> group,
> >> > nor in the " WINDOWS\Domain Users".
> >> > With a gidNumber attribute value, the 'wbinfo -n "ACME\Domain Users"'
> >> still
> >> > command fails.
> >>
> >> no need to set the ID attributes in AD. But I should have mentioned
> >> that wbinfo is quite useless nowadays with FreeIPA because winbind is
> >> only used to assure some types of communication with AD. All user and
> >> group lookups and IP-mapping is done by SSSD. Please try
> >>
> >> getent group 'ACME\Domain Users'
> >>
> >>
> >> and send the sssd_nss.log and sssd_example.com.log files.
> >>
> >> bye,
> >> Sumit
> >>
> >> >
> >> > Thanks
> >> >
> >> > 2014-12-12 19:51 GMT+01:00 Manuel Lopes <manuel.lopes72 at gmail.com>:
> >> > >
> >> > > [root at support1 ~]# ipa idrange-find
> >> > > ----------------
> >> > > 3 ranges matched
> >> > > ----------------
> >> > >   Range name: LINUX.COM_id_range
> >> > >   First Posix ID of the range: 1066000000
> >> > >   Number of IDs in the range: 200000
> >> > >   First RID of the corresponding RID range: 1000
> >> > >   First RID of the secondary RID range: 100000000
> >> > >   Range type: local domain range
> >> > >
> >> > >   Range name: WINDOWS.COM_id_range
> >> > >   First Posix ID of the range: 730200000
> >> > >   Number of IDs in the range: 200000
> >> > >   First RID of the corresponding RID range: 0
> >> > >   Domain SID of the trusted domain:
> >> > > S-1-5-21-1701591335-3855227394-3044674468
> >> > >   Range type: Active Directory domain range
> >> > >
> >> > >   Range name: ACME.WINDOWS.COM_id_range
> >> > >   First Posix ID of the range: 365600000
> >> > >   Number of IDs in the range: 200000
> >> > >   First RID of the corresponding RID range: 0
> >> > >   Domain SID of the trusted domain:
> >> > > S-1-5-21-1215373191-1991333051-3772904882
> >> > >   Range type: Active Directory domain range
> >> > > ----------------------------
> >> > > Number of entries returned 3
> >> > > ----------------------------
> >> > >
> >> > >
> >> > > As we can see in the ouput of the command, the range type is "ad POSIX
> >> > > attributes".
> >> > > In our case, the gidNumber is not set in the "ACME\Domain Users" AD
> >> group,
> >> > > nor in the " WINDOWS\Domain Users".
> >> > > With a gidNumber attribute value, the 'wbinfo -n "ACME\Domain Users"'
> >> > > still command fails.
> >> > >
> >> > > Thanks
> >> > >
> >> > >
> >> > > 2014-12-12 10:33 GMT+01:00 Sumit Bose <sbose at redhat.com>:
> >> > >>
> >> > >> On Fri, Dec 12, 2014 at 02:06:05AM +0100, Manuel Lopes wrote:
> >> > >> > Hi Sumit,
> >> > >> >
> >> > >> > Thank you very much for the prompt reply
> >> > >> >
> >> > >> > [root at support1 ~]# ipa trustdomain-find windows.com
> >> > >> >   Domain name: windows.com
> >> > >> >   Domain NetBIOS name: WINDOWS
> >> > >> >   Domain Security Identifier:
> >> S-1-5-21-1701591335-3855227394-3044674468
> >> > >> >   Domain enabled: True
> >> > >> >
> >> > >> >   Domain name: acme.windows.com
> >> > >> >   Domain NetBIOS name: ACME
> >> > >> >   Domain Security Identifier:
> >> S-1-5-21-1215373191-1991333051-3772904882
> >> > >> >   Domain enabled: True
> >> > >> > ----------------------------
> >> > >> > Number of entries returned 2
> >> > >> > ----------------------------
> >> > >>
> >> > >> ok, so ACME was discovered successful, can you check next the output
> >> of
> >> > >>
> >> > >> ipa idrange-find
> >> > >>
> >> > >> The important attribute is the 'Range type' for the AD domains. If
> >> it is
> >> > >> 'Active Directory trust range with POSIX attributes' it is expected
> >> that
> >> > >> users and groups in the AD forest have the POSIX UID and GID
> >> attributes
> >> > >> set and only those users and groups will be available in the IPA
> >> domain.
> >> > >> In this case please check if 'ACME\Domain Users' have the GID
> >> attribute
> >> > >> set.
> >> > >>
> >> > >> If this does not help (please mind the negative cache of SSSD) please
> >> > >> send the SSSD logs in /var/log/sssd on the IPA server. You might
> >> need to
> >> > >> enable logging in sssd.conf by setting 'debug_level = 10' in the
> >> > >> [domain/..] and [nss] section of sssd.conf.
> >> > >>
> >> > >> bye,
> >> > >> Sumit
> >> > >>
> >> > >> >
> >> > >> > [root at support1 ~]# ipa trust-fetch-domains windows.com
> >> > >> > -------------------------------
> >> > >> > No new trust domains were found
> >> > >> > -------------------------------
> >> > >> > ----------------------------
> >> > >> > Number of entries returned 0
> >> > >> > ----------------------------
> >> > >> >
> >> > >> > Regards
> >> > >> > Le 11 d?c. 2014 20:08, "Sumit Bose" <sbose at redhat.com
> >> > >> > <javascript:_e(%7B%7D,'cvml','sbose at redhat.com');>> a ?crit :
> >> > >> >
> >> > >> > > On Thu, Dec 11, 2014 at 06:45:49PM +0100, Manuel Lopes wrote:
> >> > >> > > >  Hello,
> >> > >> > > >
> >> > >> > > >
> >> > >> > > > We have been following the AD integration guide for IPAv3:
> >> > >> > > > http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup
> >> > >> > > >
> >> > >> > > >
> >> > >> > > >
> >> > >> > > > Our setup is:
> >> > >> > > >
> >> > >> > > > ? 2 domain controllers with Windows 2008 R2 AD DC ->
> >> windows.com
> >> > >> > > > <http://example.com/> as Forest Root Domain and
> >> acme.windows.com
> >> > >> > > > <http://acme.example.com/> as transitive child domain
> >> > >> > > >
> >> > >> > > > ? RHEL7 as IPA server with domain: linux.com
> >> > >> > > > <http://linux.acme.example.com/>
> >> > >> > > >
> >> > >> > > >
> >> > >> > > >
> >> > >> > > > We have established a forest trust between windows.com and
> >> > >> linux.com and
> >> > >> > > > everything seems OK from an IPA perspective.
> >> > >> > > >
> >> > >> > > >
> >> > >> > > >
> >> > >> > > > We can work with Kerberos tickets without any issue from
> >> ?windows?
> >> > >> domain
> >> > >> > > > or his child domain ?acme?. (kinit, kvno?)
> >> > >> > > >
> >> > >> > > >
> >> > >> > > >
> >> > >> > > > When we use samba tools, the following command is working fine.
> >> > >> > > >
> >> > >> > > > *[root at support1 ]# wbinfo -n 'WINDOWS\Domain Admins'*
> >> > >> > > >
> >> > >> > > > *S-1-5-21-1701591335-3855227394-3044674468-512 SID_DOM_GROUP
> >> (2)*
> >> > >> > > >
> >> > >> > > >
> >> > >> > > >
> >> > >> > > > But, the same command against the acme domain returns an error.
> >> > >> > > >
> >> > >> > > > *[root at support1 ]# wbinfo -n 'ACME\Domain Admins'*
> >> > >> > > >
> >> > >> > > > *failed to call wbcLookupName: WBC_ERR_DOMAIN_NOT_FOUND*
> >> > >> > > >
> >> > >> > > > *Could not lookup name ACME\Domain Admins*
> >> > >> > > >
> >> > >> > > >
> >> > >> > > >
> >> > >> > > > Same problem with the following command:
> >> > >> > > >
> >> > >> > > > *[root at support1]# ipa group-add-member ad_users_external
> >> --external
> >> > >> > > > "ACME\Domain Users"*
> >> > >> > > >
> >> > >> > > > *[member user]:*
> >> > >> > > >
> >> > >> > > > *[member group]:*
> >> > >> > > >
> >> > >> > > > *  Group name: ad_users_external*
> >> > >> > > >
> >> > >> > > > *  Description: AD users external map*
> >> > >> > > >
> >> > >> > > > *  External member: *
> >> > >> > > >
> >> > >> > > > *  Member of groups: ad_users*
> >> > >> > > >
> >> > >> > > > *  Failed members:*
> >> > >> > > >
> >> > >> > > > *    member user:*
> >> > >> > > >
> >> > >> > > > *    member group: ACME\Domain Users: Cannot find specified
> >> domain
> >> > >> or
> >> > >> > > > server name*
> >> > >> > > >
> >> > >> > > > *-------------------------*
> >> > >> > > >
> >> > >> > > > *Number of members added 0*
> >> > >> > > >
> >> > >> > > >
> >> > >> > > >
> >> > >> > > >
> >> > >> > > >
> >> > >> > > > Any help would be appreciated
> >> > >> > >
> >> > >> > > Does
> >> > >> > >
> >> > >> > > ipa trustdomain-find windows.com
> >> > >> > >
> >> > >> > > show acme.windows.com as well ?
> >> > >> > >
> >> > >> > > Does
> >> > >> > >
> >> > >> > > ipa trust-fetch-domains ad.devel
> >> > >> > >
> >> > >> > > help to retrieve the child domain?
> >> > >> > >
> >> > >> > > Please note that if acme.windows.com now shows up you might
> >> have to
> >> > >> wait
> >> > >> > > 1-2 minutes until SSSD's negative caches are flushed and the new
> >> > >> domains
> >> > >> > > is discovered by SSSD, as an alternative you can just restart
> >> SSSD.
> >> > >> > >
> >> > >> > > HTH
> >> > >> > >
> >> > >> > > bye,
> >> > >> > > Sumit
> >> > >> > >
> >> > >> > > >
> >> > >> > > >
> >> > >> > > >
> >> > >> > > > Regards
> >> > >> > >
> >> > >> > > > --
> >> > >> > > > 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
> >> > >>
> >> > >> --
> >> > >> 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
> >> > >>
> >> > >
> >>
> >>
> >>
> >>





From manuel.lopes72 at gmail.com  Mon Dec 15 15:39:29 2014
From: manuel.lopes72 at gmail.com (Manuel Lopes)
Date: Mon, 15 Dec 2014 16:39:29 +0100
Subject: [Freeipa-users] Forest trust and AD child domain
In-Reply-To: <20141215144258.GA2868@localhost.localdomain>
References: <CAKFNJrsYA9M1j5cjH5kA4c6U9QGEr5pGd90QVRDWf8ajHk9tqw@mail.gmail.com>
	<20141211190542.GT14057@localhost.localdomain>
	<CAKFNJrt_+GkUwDNuDhZLoGEFNfSV=omb=qCJfbJJq=RkXHxqnQ@mail.gmail.com>
	<20141212093311.GU14057@localhost.localdomain>
	<CAKFNJrvBrvRJbxU-zsXhmsek8MZrZdz-b1p1O1MvfmUPv256vg@mail.gmail.com>
	<CAKFNJrsJvj8098k9vzScONO4endDE3LGuH1AzUY6_yDRS3MT1Q@mail.gmail.com>
	<20141212203234.GA6877@localhost.localdomain>
	<CAKFNJrsS1-h8pu+UoWWCwAUu3GA8D8XtGva7J3in7omSGCjiUw@mail.gmail.com>
	<CAKFNJrsRRZFQmb+4892WPtx2d9jcJVfZeW1LQJmWOJKK7mvsaw@mail.gmail.com>
	<20141215144258.GA2868@localhost.localdomain>
Message-ID: <CAKFNJruhr6iB6v6qVBqt84oN8hsZRewuhH_YmBBXHc0A7CMUCA@mail.gmail.com>

The file sssd_linux.com.log is empty.



2014-12-15 15:42 GMT+01:00 Sumit Bose <sbose at redhat.com>:
>
> On Sat, Dec 13, 2014 at 02:13:30PM +0100, Manuel Lopes wrote:
> > Hi,
> >
> > As explained in the previous email, the getent is successful.
> >
> >
> > *[root at support1 ~]# getent group 'ACME\Domain Users' domain
> > users at acme.windows.com:*:**365600513:administrator at acme.windows.com
> > <365600513%3Aadministrator at acme.windows.com>*
> >
> >
> >
> > In fact, our real problem is not the ?wbinfo ?n? but the following
> command:
> >
> > *[root at support1 sssd]# ipa group-add-member ad_users_external --external
> > "ACME\Domain Users"*
> >
> > *[member user]:*
> >
> > *[member group]:*
> >
> > *  Group name: ad_users_external*
> >
> > *  Description: AD users external map*
> >
> > *  External member: *
> >
> > *  Member of groups: ad_users*
> >
> > *  Failed members:*
> >
> > *    member user:*
> >
> > *    member group: ACME\Domain Users: Cannot find specified domain or
> > server name*
> >
> > *-------------------------*
> >
> > *Number of members added 0*
> >
> > *-------------------------*
> >
> >
> >
> > We cannot add ACME?s domain users in the ad_users_external.
> >
> >
> >
> > I attached the sssd logs.
>
> Can you send the corresponding domain log file as well, it should be
> called sssd_linux.com.log or similar.
>
> bye,
> Sumit
>
> >
> >
> >
> > Regards
> >
> > 2014-12-12 21:51 GMT+01:00 Manuel Lopes <manuel.lopes72 at gmail.com>:
> > >
> > > OK.
> > >
> > > Command successful
> > > [root at support1 ~]# getent group  'ACME\Domain Users'
> > > domain users at acme.windows.com:*:
> 365600513:administrator at acme.windows.com
> > >
> > > Log files attached
> > >
> > > Thanks
> > >
> > > 2014-12-12 21:32 GMT+01:00 Sumit Bose <sbose at redhat.com>:
> > >>
> > >> On Fri, Dec 12, 2014 at 08:41:27PM +0100, Manuel Lopes wrote:
> > >> > [root at support1 ~]# ipa idrange-find
> > >> > ----------------
> > >> > 3 ranges matched
> > >> > ----------------
> > >> > Range name: LINUX.COM_id_range
> > >> > First Posix ID of the range: 1066000000
> > >> > Number of IDs in the range: 200000
> > >> > First RID of the corresponding RID range: 1000
> > >> > First RID of the secondary RID range: 100000000
> > >> > Range type: local domain range
> > >> >
> > >> > Range name: WINDOWS.COM_id_range
> > >> > First Posix ID of the range: 730200000
> > >> > Number of IDs in the range: 200000
> > >> > First RID of the corresponding RID range: 0
> > >> > Domain SID of the trusted domain:
> > >> S-1-5-21-1701591335-3855227394-3044674468
> > >> > Range type: Active Directory domain range
> > >> >
> > >> > Range name: ACME.WINDOWS.COM_id_range
> > >> > First Posix ID of the range: 365600000
> > >> > Number of IDs in the range: 200000
> > >> > First RID of the corresponding RID range: 0
> > >> > Domain SID of the trusted domain:
> > >> S-1-5-21-1215373191-1991333051-3772904882
> > >> > Range type: Active Directory domain range
> > >> > ----------------------------
> > >> > Number of entries returned 3
> > >> > ----------------------------
> > >> >
> > >> >
> > >> > As we can see in the ouput of the command, the range type is "ad
> POSIX
> > >> > attributes".
> > >>
> > >> no, it's only 'Active Directory domain range', this is good because
> with
> > >> this type we generate the UIDs and GIDs algorithmically.
> > >>
> > >> > In our case, the gidNumber is not set in the "ACME\Domain Users" AD
> > >> group,
> > >> > nor in the " WINDOWS\Domain Users".
> > >> > With a gidNumber attribute value, the 'wbinfo -n "ACME\Domain
> Users"'
> > >> still
> > >> > command fails.
> > >>
> > >> no need to set the ID attributes in AD. But I should have mentioned
> > >> that wbinfo is quite useless nowadays with FreeIPA because winbind is
> > >> only used to assure some types of communication with AD. All user and
> > >> group lookups and IP-mapping is done by SSSD. Please try
> > >>
> > >> getent group 'ACME\Domain Users'
> > >>
> > >>
> > >> and send the sssd_nss.log and sssd_example.com.log files.
> > >>
> > >> bye,
> > >> Sumit
> > >>
> > >> >
> > >> > Thanks
> > >> >
> > >> > 2014-12-12 19:51 GMT+01:00 Manuel Lopes <manuel.lopes72 at gmail.com>:
> > >> > >
> > >> > > [root at support1 ~]# ipa idrange-find
> > >> > > ----------------
> > >> > > 3 ranges matched
> > >> > > ----------------
> > >> > >   Range name: LINUX.COM_id_range
> > >> > >   First Posix ID of the range: 1066000000
> > >> > >   Number of IDs in the range: 200000
> > >> > >   First RID of the corresponding RID range: 1000
> > >> > >   First RID of the secondary RID range: 100000000
> > >> > >   Range type: local domain range
> > >> > >
> > >> > >   Range name: WINDOWS.COM_id_range
> > >> > >   First Posix ID of the range: 730200000
> > >> > >   Number of IDs in the range: 200000
> > >> > >   First RID of the corresponding RID range: 0
> > >> > >   Domain SID of the trusted domain:
> > >> > > S-1-5-21-1701591335-3855227394-3044674468
> > >> > >   Range type: Active Directory domain range
> > >> > >
> > >> > >   Range name: ACME.WINDOWS.COM_id_range
> > >> > >   First Posix ID of the range: 365600000
> > >> > >   Number of IDs in the range: 200000
> > >> > >   First RID of the corresponding RID range: 0
> > >> > >   Domain SID of the trusted domain:
> > >> > > S-1-5-21-1215373191-1991333051-3772904882
> > >> > >   Range type: Active Directory domain range
> > >> > > ----------------------------
> > >> > > Number of entries returned 3
> > >> > > ----------------------------
> > >> > >
> > >> > >
> > >> > > As we can see in the ouput of the command, the range type is "ad
> POSIX
> > >> > > attributes".
> > >> > > In our case, the gidNumber is not set in the "ACME\Domain Users"
> AD
> > >> group,
> > >> > > nor in the " WINDOWS\Domain Users".
> > >> > > With a gidNumber attribute value, the 'wbinfo -n "ACME\Domain
> Users"'
> > >> > > still command fails.
> > >> > >
> > >> > > Thanks
> > >> > >
> > >> > >
> > >> > > 2014-12-12 10:33 GMT+01:00 Sumit Bose <sbose at redhat.com>:
> > >> > >>
> > >> > >> On Fri, Dec 12, 2014 at 02:06:05AM +0100, Manuel Lopes wrote:
> > >> > >> > Hi Sumit,
> > >> > >> >
> > >> > >> > Thank you very much for the prompt reply
> > >> > >> >
> > >> > >> > [root at support1 ~]# ipa trustdomain-find windows.com
> > >> > >> >   Domain name: windows.com
> > >> > >> >   Domain NetBIOS name: WINDOWS
> > >> > >> >   Domain Security Identifier:
> > >> S-1-5-21-1701591335-3855227394-3044674468
> > >> > >> >   Domain enabled: True
> > >> > >> >
> > >> > >> >   Domain name: acme.windows.com
> > >> > >> >   Domain NetBIOS name: ACME
> > >> > >> >   Domain Security Identifier:
> > >> S-1-5-21-1215373191-1991333051-3772904882
> > >> > >> >   Domain enabled: True
> > >> > >> > ----------------------------
> > >> > >> > Number of entries returned 2
> > >> > >> > ----------------------------
> > >> > >>
> > >> > >> ok, so ACME was discovered successful, can you check next the
> output
> > >> of
> > >> > >>
> > >> > >> ipa idrange-find
> > >> > >>
> > >> > >> The important attribute is the 'Range type' for the AD domains.
> If
> > >> it is
> > >> > >> 'Active Directory trust range with POSIX attributes' it is
> expected
> > >> that
> > >> > >> users and groups in the AD forest have the POSIX UID and GID
> > >> attributes
> > >> > >> set and only those users and groups will be available in the IPA
> > >> domain.
> > >> > >> In this case please check if 'ACME\Domain Users' have the GID
> > >> attribute
> > >> > >> set.
> > >> > >>
> > >> > >> If this does not help (please mind the negative cache of SSSD)
> please
> > >> > >> send the SSSD logs in /var/log/sssd on the IPA server. You might
> > >> need to
> > >> > >> enable logging in sssd.conf by setting 'debug_level = 10' in the
> > >> > >> [domain/..] and [nss] section of sssd.conf.
> > >> > >>
> > >> > >> bye,
> > >> > >> Sumit
> > >> > >>
> > >> > >> >
> > >> > >> > [root at support1 ~]# ipa trust-fetch-domains windows.com
> > >> > >> > -------------------------------
> > >> > >> > No new trust domains were found
> > >> > >> > -------------------------------
> > >> > >> > ----------------------------
> > >> > >> > Number of entries returned 0
> > >> > >> > ----------------------------
> > >> > >> >
> > >> > >> > Regards
> > >> > >> > Le 11 d?c. 2014 20:08, "Sumit Bose" <sbose at redhat.com
> > >> > >> > <javascript:_e(%7B%7D,'cvml','sbose at redhat.com');>> a ?crit :
> > >> > >> >
> > >> > >> > > On Thu, Dec 11, 2014 at 06:45:49PM +0100, Manuel Lopes wrote:
> > >> > >> > > >  Hello,
> > >> > >> > > >
> > >> > >> > > >
> > >> > >> > > > We have been following the AD integration guide for IPAv3:
> > >> > >> > > > http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup
> > >> > >> > > >
> > >> > >> > > >
> > >> > >> > > >
> > >> > >> > > > Our setup is:
> > >> > >> > > >
> > >> > >> > > > ? 2 domain controllers with Windows 2008 R2 AD DC ->
> > >> windows.com
> > >> > >> > > > <http://example.com/> as Forest Root Domain and
> > >> acme.windows.com
> > >> > >> > > > <http://acme.example.com/> as transitive child domain
> > >> > >> > > >
> > >> > >> > > > ? RHEL7 as IPA server with domain: linux.com
> > >> > >> > > > <http://linux.acme.example.com/>
> > >> > >> > > >
> > >> > >> > > >
> > >> > >> > > >
> > >> > >> > > > We have established a forest trust between windows.com and
> > >> > >> linux.com and
> > >> > >> > > > everything seems OK from an IPA perspective.
> > >> > >> > > >
> > >> > >> > > >
> > >> > >> > > >
> > >> > >> > > > We can work with Kerberos tickets without any issue from
> > >> ?windows?
> > >> > >> domain
> > >> > >> > > > or his child domain ?acme?. (kinit, kvno?)
> > >> > >> > > >
> > >> > >> > > >
> > >> > >> > > >
> > >> > >> > > > When we use samba tools, the following command is working
> fine.
> > >> > >> > > >
> > >> > >> > > > *[root at support1 ]# wbinfo -n 'WINDOWS\Domain Admins'*
> > >> > >> > > >
> > >> > >> > > > *S-1-5-21-1701591335-3855227394-3044674468-512
> SID_DOM_GROUP
> > >> (2)*
> > >> > >> > > >
> > >> > >> > > >
> > >> > >> > > >
> > >> > >> > > > But, the same command against the acme domain returns an
> error.
> > >> > >> > > >
> > >> > >> > > > *[root at support1 ]# wbinfo -n 'ACME\Domain Admins'*
> > >> > >> > > >
> > >> > >> > > > *failed to call wbcLookupName: WBC_ERR_DOMAIN_NOT_FOUND*
> > >> > >> > > >
> > >> > >> > > > *Could not lookup name ACME\Domain Admins*
> > >> > >> > > >
> > >> > >> > > >
> > >> > >> > > >
> > >> > >> > > > Same problem with the following command:
> > >> > >> > > >
> > >> > >> > > > *[root at support1]# ipa group-add-member ad_users_external
> > >> --external
> > >> > >> > > > "ACME\Domain Users"*
> > >> > >> > > >
> > >> > >> > > > *[member user]:*
> > >> > >> > > >
> > >> > >> > > > *[member group]:*
> > >> > >> > > >
> > >> > >> > > > *  Group name: ad_users_external*
> > >> > >> > > >
> > >> > >> > > > *  Description: AD users external map*
> > >> > >> > > >
> > >> > >> > > > *  External member: *
> > >> > >> > > >
> > >> > >> > > > *  Member of groups: ad_users*
> > >> > >> > > >
> > >> > >> > > > *  Failed members:*
> > >> > >> > > >
> > >> > >> > > > *    member user:*
> > >> > >> > > >
> > >> > >> > > > *    member group: ACME\Domain Users: Cannot find specified
> > >> domain
> > >> > >> or
> > >> > >> > > > server name*
> > >> > >> > > >
> > >> > >> > > > *-------------------------*
> > >> > >> > > >
> > >> > >> > > > *Number of members added 0*
> > >> > >> > > >
> > >> > >> > > >
> > >> > >> > > >
> > >> > >> > > >
> > >> > >> > > >
> > >> > >> > > > Any help would be appreciated
> > >> > >> > >
> > >> > >> > > Does
> > >> > >> > >
> > >> > >> > > ipa trustdomain-find windows.com
> > >> > >> > >
> > >> > >> > > show acme.windows.com as well ?
> > >> > >> > >
> > >> > >> > > Does
> > >> > >> > >
> > >> > >> > > ipa trust-fetch-domains ad.devel
> > >> > >> > >
> > >> > >> > > help to retrieve the child domain?
> > >> > >> > >
> > >> > >> > > Please note that if acme.windows.com now shows up you might
> > >> have to
> > >> > >> wait
> > >> > >> > > 1-2 minutes until SSSD's negative caches are flushed and the
> new
> > >> > >> domains
> > >> > >> > > is discovered by SSSD, as an alternative you can just restart
> > >> SSSD.
> > >> > >> > >
> > >> > >> > > HTH
> > >> > >> > >
> > >> > >> > > bye,
> > >> > >> > > Sumit
> > >> > >> > >
> > >> > >> > > >
> > >> > >> > > >
> > >> > >> > > >
> > >> > >> > > > Regards
> > >> > >> > >
> > >> > >> > > > --
> > >> > >> > > > 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
> > >> > >>
> > >> > >> --
> > >> > >> 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
> > >> > >>
> > >> > >
> > >>
> > >>
> > >>
> > >>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141215/b104201f/attachment.htm>

From sbose at redhat.com  Mon Dec 15 16:03:55 2014
From: sbose at redhat.com (Sumit Bose)
Date: Mon, 15 Dec 2014 17:03:55 +0100
Subject: [Freeipa-users] Forest trust and AD child domain
In-Reply-To: <CAKFNJruhr6iB6v6qVBqt84oN8hsZRewuhH_YmBBXHc0A7CMUCA@mail.gmail.com>
References: <20141211190542.GT14057@localhost.localdomain>
	<CAKFNJrt_+GkUwDNuDhZLoGEFNfSV=omb=qCJfbJJq=RkXHxqnQ@mail.gmail.com>
	<20141212093311.GU14057@localhost.localdomain>
	<CAKFNJrvBrvRJbxU-zsXhmsek8MZrZdz-b1p1O1MvfmUPv256vg@mail.gmail.com>
	<CAKFNJrsJvj8098k9vzScONO4endDE3LGuH1AzUY6_yDRS3MT1Q@mail.gmail.com>
	<20141212203234.GA6877@localhost.localdomain>
	<CAKFNJrsS1-h8pu+UoWWCwAUu3GA8D8XtGva7J3in7omSGCjiUw@mail.gmail.com>
	<CAKFNJrsRRZFQmb+4892WPtx2d9jcJVfZeW1LQJmWOJKK7mvsaw@mail.gmail.com>
	<20141215144258.GA2868@localhost.localdomain>
	<CAKFNJruhr6iB6v6qVBqt84oN8hsZRewuhH_YmBBXHc0A7CMUCA@mail.gmail.com>
Message-ID: <20141215160355.GE2868@localhost.localdomain>

On Mon, Dec 15, 2014 at 04:39:29PM +0100, Manuel Lopes wrote:
> The file sssd_linux.com.log is empty.

please add

debug_level = 10

to the [domain/...] section in sssd.conf to enable logging for this part
of SSSD.

bye,
Sumit
> 
> 
> 
> 2014-12-15 15:42 GMT+01:00 Sumit Bose <sbose at redhat.com>:
> >
> > On Sat, Dec 13, 2014 at 02:13:30PM +0100, Manuel Lopes wrote:
> > > Hi,
> > >
> > > As explained in the previous email, the getent is successful.
> > >
> > >
> > > *[root at support1 ~]# getent group 'ACME\Domain Users' domain
> > > users at acme.windows.com:*:**365600513:administrator at acme.windows.com
> > > <365600513%3Aadministrator at acme.windows.com>*
> > >
> > >
> > >
> > > In fact, our real problem is not the ?wbinfo ?n? but the following
> > command:
> > >
> > > *[root at support1 sssd]# ipa group-add-member ad_users_external --external
> > > "ACME\Domain Users"*
> > >
> > > *[member user]:*
> > >
> > > *[member group]:*
> > >
> > > *  Group name: ad_users_external*
> > >
> > > *  Description: AD users external map*
> > >
> > > *  External member: *
> > >
> > > *  Member of groups: ad_users*
> > >
> > > *  Failed members:*
> > >
> > > *    member user:*
> > >
> > > *    member group: ACME\Domain Users: Cannot find specified domain or
> > > server name*
> > >
> > > *-------------------------*
> > >
> > > *Number of members added 0*
> > >
> > > *-------------------------*
> > >
> > >
> > >
> > > We cannot add ACME?s domain users in the ad_users_external.
> > >
> > >
> > >
> > > I attached the sssd logs.
> >
> > Can you send the corresponding domain log file as well, it should be
> > called sssd_linux.com.log or similar.
> >
> > bye,
> > Sumit
> >
> > >
> > >
> > >
> > > Regards
> > >
> > > 2014-12-12 21:51 GMT+01:00 Manuel Lopes <manuel.lopes72 at gmail.com>:
> > > >
> > > > OK.
> > > >
> > > > Command successful
> > > > [root at support1 ~]# getent group  'ACME\Domain Users'
> > > > domain users at acme.windows.com:*:
> > 365600513:administrator at acme.windows.com
> > > >
> > > > Log files attached
> > > >
> > > > Thanks
> > > >
> > > > 2014-12-12 21:32 GMT+01:00 Sumit Bose <sbose at redhat.com>:
> > > >>
> > > >> On Fri, Dec 12, 2014 at 08:41:27PM +0100, Manuel Lopes wrote:
> > > >> > [root at support1 ~]# ipa idrange-find
> > > >> > ----------------
> > > >> > 3 ranges matched
> > > >> > ----------------
> > > >> > Range name: LINUX.COM_id_range
> > > >> > First Posix ID of the range: 1066000000
> > > >> > Number of IDs in the range: 200000
> > > >> > First RID of the corresponding RID range: 1000
> > > >> > First RID of the secondary RID range: 100000000
> > > >> > Range type: local domain range
> > > >> >
> > > >> > Range name: WINDOWS.COM_id_range
> > > >> > First Posix ID of the range: 730200000
> > > >> > Number of IDs in the range: 200000
> > > >> > First RID of the corresponding RID range: 0
> > > >> > Domain SID of the trusted domain:
> > > >> S-1-5-21-1701591335-3855227394-3044674468
> > > >> > Range type: Active Directory domain range
> > > >> >
> > > >> > Range name: ACME.WINDOWS.COM_id_range
> > > >> > First Posix ID of the range: 365600000
> > > >> > Number of IDs in the range: 200000
> > > >> > First RID of the corresponding RID range: 0
> > > >> > Domain SID of the trusted domain:
> > > >> S-1-5-21-1215373191-1991333051-3772904882
> > > >> > Range type: Active Directory domain range
> > > >> > ----------------------------
> > > >> > Number of entries returned 3
> > > >> > ----------------------------
> > > >> >
> > > >> >
> > > >> > As we can see in the ouput of the command, the range type is "ad
> > POSIX
> > > >> > attributes".
> > > >>
> > > >> no, it's only 'Active Directory domain range', this is good because
> > with
> > > >> this type we generate the UIDs and GIDs algorithmically.
> > > >>
> > > >> > In our case, the gidNumber is not set in the "ACME\Domain Users" AD
> > > >> group,
> > > >> > nor in the " WINDOWS\Domain Users".
> > > >> > With a gidNumber attribute value, the 'wbinfo -n "ACME\Domain
> > Users"'
> > > >> still
> > > >> > command fails.
> > > >>
> > > >> no need to set the ID attributes in AD. But I should have mentioned
> > > >> that wbinfo is quite useless nowadays with FreeIPA because winbind is
> > > >> only used to assure some types of communication with AD. All user and
> > > >> group lookups and IP-mapping is done by SSSD. Please try
> > > >>
> > > >> getent group 'ACME\Domain Users'
> > > >>
> > > >>
> > > >> and send the sssd_nss.log and sssd_example.com.log files.
> > > >>
> > > >> bye,
> > > >> Sumit
> > > >>
> > > >> >
> > > >> > Thanks
> > > >> >
> > > >> > 2014-12-12 19:51 GMT+01:00 Manuel Lopes <manuel.lopes72 at gmail.com>:
> > > >> > >
> > > >> > > [root at support1 ~]# ipa idrange-find
> > > >> > > ----------------
> > > >> > > 3 ranges matched
> > > >> > > ----------------
> > > >> > >   Range name: LINUX.COM_id_range
> > > >> > >   First Posix ID of the range: 1066000000
> > > >> > >   Number of IDs in the range: 200000
> > > >> > >   First RID of the corresponding RID range: 1000
> > > >> > >   First RID of the secondary RID range: 100000000
> > > >> > >   Range type: local domain range
> > > >> > >
> > > >> > >   Range name: WINDOWS.COM_id_range
> > > >> > >   First Posix ID of the range: 730200000
> > > >> > >   Number of IDs in the range: 200000
> > > >> > >   First RID of the corresponding RID range: 0
> > > >> > >   Domain SID of the trusted domain:
> > > >> > > S-1-5-21-1701591335-3855227394-3044674468
> > > >> > >   Range type: Active Directory domain range
> > > >> > >
> > > >> > >   Range name: ACME.WINDOWS.COM_id_range
> > > >> > >   First Posix ID of the range: 365600000
> > > >> > >   Number of IDs in the range: 200000
> > > >> > >   First RID of the corresponding RID range: 0
> > > >> > >   Domain SID of the trusted domain:
> > > >> > > S-1-5-21-1215373191-1991333051-3772904882
> > > >> > >   Range type: Active Directory domain range
> > > >> > > ----------------------------
> > > >> > > Number of entries returned 3
> > > >> > > ----------------------------
> > > >> > >
> > > >> > >
> > > >> > > As we can see in the ouput of the command, the range type is "ad
> > POSIX
> > > >> > > attributes".
> > > >> > > In our case, the gidNumber is not set in the "ACME\Domain Users"
> > AD
> > > >> group,
> > > >> > > nor in the " WINDOWS\Domain Users".
> > > >> > > With a gidNumber attribute value, the 'wbinfo -n "ACME\Domain
> > Users"'
> > > >> > > still command fails.
> > > >> > >
> > > >> > > Thanks
> > > >> > >
> > > >> > >
> > > >> > > 2014-12-12 10:33 GMT+01:00 Sumit Bose <sbose at redhat.com>:
> > > >> > >>
> > > >> > >> On Fri, Dec 12, 2014 at 02:06:05AM +0100, Manuel Lopes wrote:
> > > >> > >> > Hi Sumit,
> > > >> > >> >
> > > >> > >> > Thank you very much for the prompt reply
> > > >> > >> >
> > > >> > >> > [root at support1 ~]# ipa trustdomain-find windows.com
> > > >> > >> >   Domain name: windows.com
> > > >> > >> >   Domain NetBIOS name: WINDOWS
> > > >> > >> >   Domain Security Identifier:
> > > >> S-1-5-21-1701591335-3855227394-3044674468
> > > >> > >> >   Domain enabled: True
> > > >> > >> >
> > > >> > >> >   Domain name: acme.windows.com
> > > >> > >> >   Domain NetBIOS name: ACME
> > > >> > >> >   Domain Security Identifier:
> > > >> S-1-5-21-1215373191-1991333051-3772904882
> > > >> > >> >   Domain enabled: True
> > > >> > >> > ----------------------------
> > > >> > >> > Number of entries returned 2
> > > >> > >> > ----------------------------
> > > >> > >>
> > > >> > >> ok, so ACME was discovered successful, can you check next the
> > output
> > > >> of
> > > >> > >>
> > > >> > >> ipa idrange-find
> > > >> > >>
> > > >> > >> The important attribute is the 'Range type' for the AD domains.
> > If
> > > >> it is
> > > >> > >> 'Active Directory trust range with POSIX attributes' it is
> > expected
> > > >> that
> > > >> > >> users and groups in the AD forest have the POSIX UID and GID
> > > >> attributes
> > > >> > >> set and only those users and groups will be available in the IPA
> > > >> domain.
> > > >> > >> In this case please check if 'ACME\Domain Users' have the GID
> > > >> attribute
> > > >> > >> set.
> > > >> > >>
> > > >> > >> If this does not help (please mind the negative cache of SSSD)
> > please
> > > >> > >> send the SSSD logs in /var/log/sssd on the IPA server. You might
> > > >> need to
> > > >> > >> enable logging in sssd.conf by setting 'debug_level = 10' in the
> > > >> > >> [domain/..] and [nss] section of sssd.conf.
> > > >> > >>
> > > >> > >> bye,
> > > >> > >> Sumit
> > > >> > >>
> > > >> > >> >
> > > >> > >> > [root at support1 ~]# ipa trust-fetch-domains windows.com
> > > >> > >> > -------------------------------
> > > >> > >> > No new trust domains were found
> > > >> > >> > -------------------------------
> > > >> > >> > ----------------------------
> > > >> > >> > Number of entries returned 0
> > > >> > >> > ----------------------------
> > > >> > >> >
> > > >> > >> > Regards
> > > >> > >> > Le 11 d?c. 2014 20:08, "Sumit Bose" <sbose at redhat.com
> > > >> > >> > <javascript:_e(%7B%7D,'cvml','sbose at redhat.com');>> a ?crit :
> > > >> > >> >
> > > >> > >> > > On Thu, Dec 11, 2014 at 06:45:49PM +0100, Manuel Lopes wrote:
> > > >> > >> > > >  Hello,
> > > >> > >> > > >
> > > >> > >> > > >
> > > >> > >> > > > We have been following the AD integration guide for IPAv3:
> > > >> > >> > > > http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup
> > > >> > >> > > >
> > > >> > >> > > >
> > > >> > >> > > >
> > > >> > >> > > > Our setup is:
> > > >> > >> > > >
> > > >> > >> > > > ? 2 domain controllers with Windows 2008 R2 AD DC ->
> > > >> windows.com
> > > >> > >> > > > <http://example.com/> as Forest Root Domain and
> > > >> acme.windows.com
> > > >> > >> > > > <http://acme.example.com/> as transitive child domain
> > > >> > >> > > >
> > > >> > >> > > > ? RHEL7 as IPA server with domain: linux.com
> > > >> > >> > > > <http://linux.acme.example.com/>
> > > >> > >> > > >
> > > >> > >> > > >
> > > >> > >> > > >
> > > >> > >> > > > We have established a forest trust between windows.com and
> > > >> > >> linux.com and
> > > >> > >> > > > everything seems OK from an IPA perspective.
> > > >> > >> > > >
> > > >> > >> > > >
> > > >> > >> > > >
> > > >> > >> > > > We can work with Kerberos tickets without any issue from
> > > >> ?windows?
> > > >> > >> domain
> > > >> > >> > > > or his child domain ?acme?. (kinit, kvno?)
> > > >> > >> > > >
> > > >> > >> > > >
> > > >> > >> > > >
> > > >> > >> > > > When we use samba tools, the following command is working
> > fine.
> > > >> > >> > > >
> > > >> > >> > > > *[root at support1 ]# wbinfo -n 'WINDOWS\Domain Admins'*
> > > >> > >> > > >
> > > >> > >> > > > *S-1-5-21-1701591335-3855227394-3044674468-512
> > SID_DOM_GROUP
> > > >> (2)*
> > > >> > >> > > >
> > > >> > >> > > >
> > > >> > >> > > >
> > > >> > >> > > > But, the same command against the acme domain returns an
> > error.
> > > >> > >> > > >
> > > >> > >> > > > *[root at support1 ]# wbinfo -n 'ACME\Domain Admins'*
> > > >> > >> > > >
> > > >> > >> > > > *failed to call wbcLookupName: WBC_ERR_DOMAIN_NOT_FOUND*
> > > >> > >> > > >
> > > >> > >> > > > *Could not lookup name ACME\Domain Admins*
> > > >> > >> > > >
> > > >> > >> > > >
> > > >> > >> > > >
> > > >> > >> > > > Same problem with the following command:
> > > >> > >> > > >
> > > >> > >> > > > *[root at support1]# ipa group-add-member ad_users_external
> > > >> --external
> > > >> > >> > > > "ACME\Domain Users"*
> > > >> > >> > > >
> > > >> > >> > > > *[member user]:*
> > > >> > >> > > >
> > > >> > >> > > > *[member group]:*
> > > >> > >> > > >
> > > >> > >> > > > *  Group name: ad_users_external*
> > > >> > >> > > >
> > > >> > >> > > > *  Description: AD users external map*
> > > >> > >> > > >
> > > >> > >> > > > *  External member: *
> > > >> > >> > > >
> > > >> > >> > > > *  Member of groups: ad_users*
> > > >> > >> > > >
> > > >> > >> > > > *  Failed members:*
> > > >> > >> > > >
> > > >> > >> > > > *    member user:*
> > > >> > >> > > >
> > > >> > >> > > > *    member group: ACME\Domain Users: Cannot find specified
> > > >> domain
> > > >> > >> or
> > > >> > >> > > > server name*
> > > >> > >> > > >
> > > >> > >> > > > *-------------------------*
> > > >> > >> > > >
> > > >> > >> > > > *Number of members added 0*
> > > >> > >> > > >
> > > >> > >> > > >
> > > >> > >> > > >
> > > >> > >> > > >
> > > >> > >> > > >
> > > >> > >> > > > Any help would be appreciated
> > > >> > >> > >
> > > >> > >> > > Does
> > > >> > >> > >
> > > >> > >> > > ipa trustdomain-find windows.com
> > > >> > >> > >
> > > >> > >> > > show acme.windows.com as well ?
> > > >> > >> > >
> > > >> > >> > > Does
> > > >> > >> > >
> > > >> > >> > > ipa trust-fetch-domains ad.devel
> > > >> > >> > >
> > > >> > >> > > help to retrieve the child domain?
> > > >> > >> > >
> > > >> > >> > > Please note that if acme.windows.com now shows up you might
> > > >> have to
> > > >> > >> wait
> > > >> > >> > > 1-2 minutes until SSSD's negative caches are flushed and the
> > new
> > > >> > >> domains
> > > >> > >> > > is discovered by SSSD, as an alternative you can just restart
> > > >> SSSD.
> > > >> > >> > >
> > > >> > >> > > HTH
> > > >> > >> > >
> > > >> > >> > > bye,
> > > >> > >> > > Sumit
> > > >> > >> > >
> > > >> > >> > > >
> > > >> > >> > > >
> > > >> > >> > > >
> > > >> > >> > > > Regards
> > > >> > >> > >
> > > >> > >> > > > --
> > > >> > >> > > > 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
> > > >> > >>
> > > >> > >> --
> > > >> > >> 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
> > > >> > >>
> > > >> > >
> > > >>
> > > >>
> > > >>
> > > >>
> >
> >
> >
> >



From dpal at redhat.com  Mon Dec 15 16:28:37 2014
From: dpal at redhat.com (Dmitri Pal)
Date: Mon, 15 Dec 2014 11:28:37 -0500
Subject: [Freeipa-users] freeipa server 4.1 with ipa client 2.2
In-Reply-To: <DUB125-W5166FD332EC24D1919331CC6F0@phx.gbl>
References: <DUB125-W5166FD332EC24D1919331CC6F0@phx.gbl>
Message-ID: <548F0C35.6010903@redhat.com>

On 12/15/2014 08:18 AM, Chris Card wrote:
> Should a machine running ipa client version 2.2 (because it's running 
> Centos 6.3) be able to work with a freeipa server version 4.1?

It should work.

> The ipa-client-install script works ok and I see client machine listed 
> as one of the hosts in the freeipa admin gui, but I'm not sure if the 
> version
> of sssd running on the client (1.8) has all the functionality for e.g. 
> ssh key access for users.
The client will be able to use only functionality it knows about and 
capable of.


>
> Chris
>
>


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141215/781c91bd/attachment.htm>

From manuel.lopes72 at gmail.com  Mon Dec 15 16:38:05 2014
From: manuel.lopes72 at gmail.com (Manuel Lopes)
Date: Mon, 15 Dec 2014 17:38:05 +0100
Subject: [Freeipa-users] Forest trust and AD child domain
In-Reply-To: <20141215160355.GE2868@localhost.localdomain>
References: <20141211190542.GT14057@localhost.localdomain>
	<CAKFNJrt_+GkUwDNuDhZLoGEFNfSV=omb=qCJfbJJq=RkXHxqnQ@mail.gmail.com>
	<20141212093311.GU14057@localhost.localdomain>
	<CAKFNJrvBrvRJbxU-zsXhmsek8MZrZdz-b1p1O1MvfmUPv256vg@mail.gmail.com>
	<CAKFNJrsJvj8098k9vzScONO4endDE3LGuH1AzUY6_yDRS3MT1Q@mail.gmail.com>
	<20141212203234.GA6877@localhost.localdomain>
	<CAKFNJrsS1-h8pu+UoWWCwAUu3GA8D8XtGva7J3in7omSGCjiUw@mail.gmail.com>
	<CAKFNJrsRRZFQmb+4892WPtx2d9jcJVfZeW1LQJmWOJKK7mvsaw@mail.gmail.com>
	<20141215144258.GA2868@localhost.localdomain>
	<CAKFNJruhr6iB6v6qVBqt84oN8hsZRewuhH_YmBBXHc0A7CMUCA@mail.gmail.com>
	<20141215160355.GE2868@localhost.localdomain>
Message-ID: <CAKFNJrsDdL1ANRTBxder_eeCWJPtO6e_x643gMvYZQS7XLWaDw@mail.gmail.com>

Attached the sssd_linux.com.log file

Regards

2014-12-15 17:03 GMT+01:00 Sumit Bose <sbose at redhat.com>:
>
> On Mon, Dec 15, 2014 at 04:39:29PM +0100, Manuel Lopes wrote:
> > The file sssd_linux.com.log is empty.
>
> please add
>
> debug_level = 10
>
> to the [domain/...] section in sssd.conf to enable logging for this part
> of SSSD.
>
> bye,
> Sumit
> >
> >
> >
> > 2014-12-15 15:42 GMT+01:00 Sumit Bose <sbose at redhat.com>:
> > >
> > > On Sat, Dec 13, 2014 at 02:13:30PM +0100, Manuel Lopes wrote:
> > > > Hi,
> > > >
> > > > As explained in the previous email, the getent is successful.
> > > >
> > > >
> > > > *[root at support1 ~]# getent group 'ACME\Domain Users' domain
> > > > users at acme.windows.com:*:**365600513:administrator at acme.windows.com
> > > > <365600513%3Aadministrator at acme.windows.com>*
> > > >
> > > >
> > > >
> > > > In fact, our real problem is not the ?wbinfo ?n? but the following
> > > command:
> > > >
> > > > *[root at support1 sssd]# ipa group-add-member ad_users_external
> --external
> > > > "ACME\Domain Users"*
> > > >
> > > > *[member user]:*
> > > >
> > > > *[member group]:*
> > > >
> > > > *  Group name: ad_users_external*
> > > >
> > > > *  Description: AD users external map*
> > > >
> > > > *  External member: *
> > > >
> > > > *  Member of groups: ad_users*
> > > >
> > > > *  Failed members:*
> > > >
> > > > *    member user:*
> > > >
> > > > *    member group: ACME\Domain Users: Cannot find specified domain or
> > > > server name*
> > > >
> > > > *-------------------------*
> > > >
> > > > *Number of members added 0*
> > > >
> > > > *-------------------------*
> > > >
> > > >
> > > >
> > > > We cannot add ACME?s domain users in the ad_users_external.
> > > >
> > > >
> > > >
> > > > I attached the sssd logs.
> > >
> > > Can you send the corresponding domain log file as well, it should be
> > > called sssd_linux.com.log or similar.
> > >
> > > bye,
> > > Sumit
> > >
> > > >
> > > >
> > > >
> > > > Regards
> > > >
> > > > 2014-12-12 21:51 GMT+01:00 Manuel Lopes <manuel.lopes72 at gmail.com>:
> > > > >
> > > > > OK.
> > > > >
> > > > > Command successful
> > > > > [root at support1 ~]# getent group  'ACME\Domain Users'
> > > > > domain users at acme.windows.com:*:
> > > 365600513:administrator at acme.windows.com
> > > > >
> > > > > Log files attached
> > > > >
> > > > > Thanks
> > > > >
> > > > > 2014-12-12 21:32 GMT+01:00 Sumit Bose <sbose at redhat.com>:
> > > > >>
> > > > >> On Fri, Dec 12, 2014 at 08:41:27PM +0100, Manuel Lopes wrote:
> > > > >> > [root at support1 ~]# ipa idrange-find
> > > > >> > ----------------
> > > > >> > 3 ranges matched
> > > > >> > ----------------
> > > > >> > Range name: LINUX.COM_id_range
> > > > >> > First Posix ID of the range: 1066000000
> > > > >> > Number of IDs in the range: 200000
> > > > >> > First RID of the corresponding RID range: 1000
> > > > >> > First RID of the secondary RID range: 100000000
> > > > >> > Range type: local domain range
> > > > >> >
> > > > >> > Range name: WINDOWS.COM_id_range
> > > > >> > First Posix ID of the range: 730200000
> > > > >> > Number of IDs in the range: 200000
> > > > >> > First RID of the corresponding RID range: 0
> > > > >> > Domain SID of the trusted domain:
> > > > >> S-1-5-21-1701591335-3855227394-3044674468
> > > > >> > Range type: Active Directory domain range
> > > > >> >
> > > > >> > Range name: ACME.WINDOWS.COM_id_range
> > > > >> > First Posix ID of the range: 365600000
> > > > >> > Number of IDs in the range: 200000
> > > > >> > First RID of the corresponding RID range: 0
> > > > >> > Domain SID of the trusted domain:
> > > > >> S-1-5-21-1215373191-1991333051-3772904882
> > > > >> > Range type: Active Directory domain range
> > > > >> > ----------------------------
> > > > >> > Number of entries returned 3
> > > > >> > ----------------------------
> > > > >> >
> > > > >> >
> > > > >> > As we can see in the ouput of the command, the range type is "ad
> > > POSIX
> > > > >> > attributes".
> > > > >>
> > > > >> no, it's only 'Active Directory domain range', this is good
> because
> > > with
> > > > >> this type we generate the UIDs and GIDs algorithmically.
> > > > >>
> > > > >> > In our case, the gidNumber is not set in the "ACME\Domain
> Users" AD
> > > > >> group,
> > > > >> > nor in the " WINDOWS\Domain Users".
> > > > >> > With a gidNumber attribute value, the 'wbinfo -n "ACME\Domain
> > > Users"'
> > > > >> still
> > > > >> > command fails.
> > > > >>
> > > > >> no need to set the ID attributes in AD. But I should have
> mentioned
> > > > >> that wbinfo is quite useless nowadays with FreeIPA because
> winbind is
> > > > >> only used to assure some types of communication with AD. All user
> and
> > > > >> group lookups and IP-mapping is done by SSSD. Please try
> > > > >>
> > > > >> getent group 'ACME\Domain Users'
> > > > >>
> > > > >>
> > > > >> and send the sssd_nss.log and sssd_example.com.log files.
> > > > >>
> > > > >> bye,
> > > > >> Sumit
> > > > >>
> > > > >> >
> > > > >> > Thanks
> > > > >> >
> > > > >> > 2014-12-12 19:51 GMT+01:00 Manuel Lopes <
> manuel.lopes72 at gmail.com>:
> > > > >> > >
> > > > >> > > [root at support1 ~]# ipa idrange-find
> > > > >> > > ----------------
> > > > >> > > 3 ranges matched
> > > > >> > > ----------------
> > > > >> > >   Range name: LINUX.COM_id_range
> > > > >> > >   First Posix ID of the range: 1066000000
> > > > >> > >   Number of IDs in the range: 200000
> > > > >> > >   First RID of the corresponding RID range: 1000
> > > > >> > >   First RID of the secondary RID range: 100000000
> > > > >> > >   Range type: local domain range
> > > > >> > >
> > > > >> > >   Range name: WINDOWS.COM_id_range
> > > > >> > >   First Posix ID of the range: 730200000
> > > > >> > >   Number of IDs in the range: 200000
> > > > >> > >   First RID of the corresponding RID range: 0
> > > > >> > >   Domain SID of the trusted domain:
> > > > >> > > S-1-5-21-1701591335-3855227394-3044674468
> > > > >> > >   Range type: Active Directory domain range
> > > > >> > >
> > > > >> > >   Range name: ACME.WINDOWS.COM_id_range
> > > > >> > >   First Posix ID of the range: 365600000
> > > > >> > >   Number of IDs in the range: 200000
> > > > >> > >   First RID of the corresponding RID range: 0
> > > > >> > >   Domain SID of the trusted domain:
> > > > >> > > S-1-5-21-1215373191-1991333051-3772904882
> > > > >> > >   Range type: Active Directory domain range
> > > > >> > > ----------------------------
> > > > >> > > Number of entries returned 3
> > > > >> > > ----------------------------
> > > > >> > >
> > > > >> > >
> > > > >> > > As we can see in the ouput of the command, the range type is
> "ad
> > > POSIX
> > > > >> > > attributes".
> > > > >> > > In our case, the gidNumber is not set in the "ACME\Domain
> Users"
> > > AD
> > > > >> group,
> > > > >> > > nor in the " WINDOWS\Domain Users".
> > > > >> > > With a gidNumber attribute value, the 'wbinfo -n "ACME\Domain
> > > Users"'
> > > > >> > > still command fails.
> > > > >> > >
> > > > >> > > Thanks
> > > > >> > >
> > > > >> > >
> > > > >> > > 2014-12-12 10:33 GMT+01:00 Sumit Bose <sbose at redhat.com>:
> > > > >> > >>
> > > > >> > >> On Fri, Dec 12, 2014 at 02:06:05AM +0100, Manuel Lopes wrote:
> > > > >> > >> > Hi Sumit,
> > > > >> > >> >
> > > > >> > >> > Thank you very much for the prompt reply
> > > > >> > >> >
> > > > >> > >> > [root at support1 ~]# ipa trustdomain-find windows.com
> > > > >> > >> >   Domain name: windows.com
> > > > >> > >> >   Domain NetBIOS name: WINDOWS
> > > > >> > >> >   Domain Security Identifier:
> > > > >> S-1-5-21-1701591335-3855227394-3044674468
> > > > >> > >> >   Domain enabled: True
> > > > >> > >> >
> > > > >> > >> >   Domain name: acme.windows.com
> > > > >> > >> >   Domain NetBIOS name: ACME
> > > > >> > >> >   Domain Security Identifier:
> > > > >> S-1-5-21-1215373191-1991333051-3772904882
> > > > >> > >> >   Domain enabled: True
> > > > >> > >> > ----------------------------
> > > > >> > >> > Number of entries returned 2
> > > > >> > >> > ----------------------------
> > > > >> > >>
> > > > >> > >> ok, so ACME was discovered successful, can you check next the
> > > output
> > > > >> of
> > > > >> > >>
> > > > >> > >> ipa idrange-find
> > > > >> > >>
> > > > >> > >> The important attribute is the 'Range type' for the AD
> domains.
> > > If
> > > > >> it is
> > > > >> > >> 'Active Directory trust range with POSIX attributes' it is
> > > expected
> > > > >> that
> > > > >> > >> users and groups in the AD forest have the POSIX UID and GID
> > > > >> attributes
> > > > >> > >> set and only those users and groups will be available in the
> IPA
> > > > >> domain.
> > > > >> > >> In this case please check if 'ACME\Domain Users' have the GID
> > > > >> attribute
> > > > >> > >> set.
> > > > >> > >>
> > > > >> > >> If this does not help (please mind the negative cache of
> SSSD)
> > > please
> > > > >> > >> send the SSSD logs in /var/log/sssd on the IPA server. You
> might
> > > > >> need to
> > > > >> > >> enable logging in sssd.conf by setting 'debug_level = 10' in
> the
> > > > >> > >> [domain/..] and [nss] section of sssd.conf.
> > > > >> > >>
> > > > >> > >> bye,
> > > > >> > >> Sumit
> > > > >> > >>
> > > > >> > >> >
> > > > >> > >> > [root at support1 ~]# ipa trust-fetch-domains windows.com
> > > > >> > >> > -------------------------------
> > > > >> > >> > No new trust domains were found
> > > > >> > >> > -------------------------------
> > > > >> > >> > ----------------------------
> > > > >> > >> > Number of entries returned 0
> > > > >> > >> > ----------------------------
> > > > >> > >> >
> > > > >> > >> > Regards
> > > > >> > >> > Le 11 d?c. 2014 20:08, "Sumit Bose" <sbose at redhat.com
> > > > >> > >> > <javascript:_e(%7B%7D,'cvml','sbose at redhat.com');>> a
> ?crit :
> > > > >> > >> >
> > > > >> > >> > > On Thu, Dec 11, 2014 at 06:45:49PM +0100, Manuel Lopes
> wrote:
> > > > >> > >> > > >  Hello,
> > > > >> > >> > > >
> > > > >> > >> > > >
> > > > >> > >> > > > We have been following the AD integration guide for
> IPAv3:
> > > > >> > >> > > > http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup
> > > > >> > >> > > >
> > > > >> > >> > > >
> > > > >> > >> > > >
> > > > >> > >> > > > Our setup is:
> > > > >> > >> > > >
> > > > >> > >> > > > ? 2 domain controllers with Windows 2008 R2 AD DC ->
> > > > >> windows.com
> > > > >> > >> > > > <http://example.com/> as Forest Root Domain and
> > > > >> acme.windows.com
> > > > >> > >> > > > <http://acme.example.com/> as transitive child domain
> > > > >> > >> > > >
> > > > >> > >> > > > ? RHEL7 as IPA server with domain: linux.com
> > > > >> > >> > > > <http://linux.acme.example.com/>
> > > > >> > >> > > >
> > > > >> > >> > > >
> > > > >> > >> > > >
> > > > >> > >> > > > We have established a forest trust between windows.com
> and
> > > > >> > >> linux.com and
> > > > >> > >> > > > everything seems OK from an IPA perspective.
> > > > >> > >> > > >
> > > > >> > >> > > >
> > > > >> > >> > > >
> > > > >> > >> > > > We can work with Kerberos tickets without any issue
> from
> > > > >> ?windows?
> > > > >> > >> domain
> > > > >> > >> > > > or his child domain ?acme?. (kinit, kvno?)
> > > > >> > >> > > >
> > > > >> > >> > > >
> > > > >> > >> > > >
> > > > >> > >> > > > When we use samba tools, the following command is
> working
> > > fine.
> > > > >> > >> > > >
> > > > >> > >> > > > *[root at support1 ]# wbinfo -n 'WINDOWS\Domain Admins'*
> > > > >> > >> > > >
> > > > >> > >> > > > *S-1-5-21-1701591335-3855227394-3044674468-512
> > > SID_DOM_GROUP
> > > > >> (2)*
> > > > >> > >> > > >
> > > > >> > >> > > >
> > > > >> > >> > > >
> > > > >> > >> > > > But, the same command against the acme domain returns
> an
> > > error.
> > > > >> > >> > > >
> > > > >> > >> > > > *[root at support1 ]# wbinfo -n 'ACME\Domain Admins'*
> > > > >> > >> > > >
> > > > >> > >> > > > *failed to call wbcLookupName:
> WBC_ERR_DOMAIN_NOT_FOUND*
> > > > >> > >> > > >
> > > > >> > >> > > > *Could not lookup name ACME\Domain Admins*
> > > > >> > >> > > >
> > > > >> > >> > > >
> > > > >> > >> > > >
> > > > >> > >> > > > Same problem with the following command:
> > > > >> > >> > > >
> > > > >> > >> > > > *[root at support1]# ipa group-add-member
> ad_users_external
> > > > >> --external
> > > > >> > >> > > > "ACME\Domain Users"*
> > > > >> > >> > > >
> > > > >> > >> > > > *[member user]:*
> > > > >> > >> > > >
> > > > >> > >> > > > *[member group]:*
> > > > >> > >> > > >
> > > > >> > >> > > > *  Group name: ad_users_external*
> > > > >> > >> > > >
> > > > >> > >> > > > *  Description: AD users external map*
> > > > >> > >> > > >
> > > > >> > >> > > > *  External member: *
> > > > >> > >> > > >
> > > > >> > >> > > > *  Member of groups: ad_users*
> > > > >> > >> > > >
> > > > >> > >> > > > *  Failed members:*
> > > > >> > >> > > >
> > > > >> > >> > > > *    member user:*
> > > > >> > >> > > >
> > > > >> > >> > > > *    member group: ACME\Domain Users: Cannot find
> specified
> > > > >> domain
> > > > >> > >> or
> > > > >> > >> > > > server name*
> > > > >> > >> > > >
> > > > >> > >> > > > *-------------------------*
> > > > >> > >> > > >
> > > > >> > >> > > > *Number of members added 0*
> > > > >> > >> > > >
> > > > >> > >> > > >
> > > > >> > >> > > >
> > > > >> > >> > > >
> > > > >> > >> > > >
> > > > >> > >> > > > Any help would be appreciated
> > > > >> > >> > >
> > > > >> > >> > > Does
> > > > >> > >> > >
> > > > >> > >> > > ipa trustdomain-find windows.com
> > > > >> > >> > >
> > > > >> > >> > > show acme.windows.com as well ?
> > > > >> > >> > >
> > > > >> > >> > > Does
> > > > >> > >> > >
> > > > >> > >> > > ipa trust-fetch-domains ad.devel
> > > > >> > >> > >
> > > > >> > >> > > help to retrieve the child domain?
> > > > >> > >> > >
> > > > >> > >> > > Please note that if acme.windows.com now shows up you
> might
> > > > >> have to
> > > > >> > >> wait
> > > > >> > >> > > 1-2 minutes until SSSD's negative caches are flushed and
> the
> > > new
> > > > >> > >> domains
> > > > >> > >> > > is discovered by SSSD, as an alternative you can just
> restart
> > > > >> SSSD.
> > > > >> > >> > >
> > > > >> > >> > > HTH
> > > > >> > >> > >
> > > > >> > >> > > bye,
> > > > >> > >> > > Sumit
> > > > >> > >> > >
> > > > >> > >> > > >
> > > > >> > >> > > >
> > > > >> > >> > > >
> > > > >> > >> > > > Regards
> > > > >> > >> > >
> > > > >> > >> > > > --
> > > > >> > >> > > > 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
> > > > >> > >>
> > > > >> > >> --
> > > > >> > >> 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
> > > > >> > >>
> > > > >> > >
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > >
> > >
> > >
> > >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141215/2c0918ba/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sssd_linux.com.log
Type: application/octet-stream
Size: 208658 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141215/2c0918ba/attachment.obj>

From sbose at redhat.com  Mon Dec 15 17:34:47 2014
From: sbose at redhat.com (Sumit Bose)
Date: Mon, 15 Dec 2014 18:34:47 +0100
Subject: [Freeipa-users] Forest trust and AD child domain
In-Reply-To: <CAKFNJrsDdL1ANRTBxder_eeCWJPtO6e_x643gMvYZQS7XLWaDw@mail.gmail.com>
References: <20141212093311.GU14057@localhost.localdomain>
	<CAKFNJrvBrvRJbxU-zsXhmsek8MZrZdz-b1p1O1MvfmUPv256vg@mail.gmail.com>
	<CAKFNJrsJvj8098k9vzScONO4endDE3LGuH1AzUY6_yDRS3MT1Q@mail.gmail.com>
	<20141212203234.GA6877@localhost.localdomain>
	<CAKFNJrsS1-h8pu+UoWWCwAUu3GA8D8XtGva7J3in7omSGCjiUw@mail.gmail.com>
	<CAKFNJrsRRZFQmb+4892WPtx2d9jcJVfZeW1LQJmWOJKK7mvsaw@mail.gmail.com>
	<20141215144258.GA2868@localhost.localdomain>
	<CAKFNJruhr6iB6v6qVBqt84oN8hsZRewuhH_YmBBXHc0A7CMUCA@mail.gmail.com>
	<20141215160355.GE2868@localhost.localdomain>
	<CAKFNJrsDdL1ANRTBxder_eeCWJPtO6e_x643gMvYZQS7XLWaDw@mail.gmail.com>
Message-ID: <20141215173447.GG2868@localhost.localdomain>

On Mon, Dec 15, 2014 at 05:38:05PM +0100, Manuel Lopes wrote:
> Attached the sssd_linux.com.log file
> 
> Regards

Thank you, there is no request logged in the logs, did you run ipa
group-add-member after restarting SSSD? Nevertheless I think I know what
is happening, you hit an issue which should be fixed in SSSD 1.12.2,
which version of SSSD are you running on which platform?

bye,
Sumit

> 
> 2014-12-15 17:03 GMT+01:00 Sumit Bose <sbose at redhat.com>:
> >
> > On Mon, Dec 15, 2014 at 04:39:29PM +0100, Manuel Lopes wrote:
> > > The file sssd_linux.com.log is empty.
> >
> > please add
> >
> > debug_level = 10
> >
> > to the [domain/...] section in sssd.conf to enable logging for this part
> > of SSSD.
> >
> > bye,
> > Sumit
> > >
> > >
> > >
> > > 2014-12-15 15:42 GMT+01:00 Sumit Bose <sbose at redhat.com>:
> > > >
> > > > On Sat, Dec 13, 2014 at 02:13:30PM +0100, Manuel Lopes wrote:
> > > > > Hi,
> > > > >
> > > > > As explained in the previous email, the getent is successful.
> > > > >
> > > > >
> > > > > *[root at support1 ~]# getent group 'ACME\Domain Users' domain
> > > > > users at acme.windows.com:*:**365600513:administrator at acme.windows.com
> > > > > <365600513%3Aadministrator at acme.windows.com>*
> > > > >
> > > > >
> > > > >
> > > > > In fact, our real problem is not the ?wbinfo ?n? but the following
> > > > command:
> > > > >
> > > > > *[root at support1 sssd]# ipa group-add-member ad_users_external
> > --external
> > > > > "ACME\Domain Users"*
> > > > >
> > > > > *[member user]:*
> > > > >
> > > > > *[member group]:*
> > > > >
> > > > > *  Group name: ad_users_external*
> > > > >
> > > > > *  Description: AD users external map*
> > > > >
> > > > > *  External member: *
> > > > >
> > > > > *  Member of groups: ad_users*
> > > > >
> > > > > *  Failed members:*
> > > > >
> > > > > *    member user:*
> > > > >
> > > > > *    member group: ACME\Domain Users: Cannot find specified domain or
> > > > > server name*
> > > > >
> > > > > *-------------------------*
> > > > >
> > > > > *Number of members added 0*
> > > > >
> > > > > *-------------------------*
> > > > >
> > > > >
> > > > >
> > > > > We cannot add ACME?s domain users in the ad_users_external.
> > > > >
> > > > >
> > > > >
> > > > > I attached the sssd logs.
> > > >
> > > > Can you send the corresponding domain log file as well, it should be
> > > > called sssd_linux.com.log or similar.
> > > >
> > > > bye,
> > > > Sumit
> > > >
> > > > >
> > > > >
> > > > >
> > > > > Regards
> > > > >
> > > > > 2014-12-12 21:51 GMT+01:00 Manuel Lopes <manuel.lopes72 at gmail.com>:
> > > > > >
> > > > > > OK.
> > > > > >
> > > > > > Command successful
> > > > > > [root at support1 ~]# getent group  'ACME\Domain Users'
> > > > > > domain users at acme.windows.com:*:
> > > > 365600513:administrator at acme.windows.com
> > > > > >
> > > > > > Log files attached
> > > > > >
> > > > > > Thanks
> > > > > >
> > > > > > 2014-12-12 21:32 GMT+01:00 Sumit Bose <sbose at redhat.com>:
> > > > > >>
> > > > > >> On Fri, Dec 12, 2014 at 08:41:27PM +0100, Manuel Lopes wrote:
> > > > > >> > [root at support1 ~]# ipa idrange-find
> > > > > >> > ----------------
> > > > > >> > 3 ranges matched
> > > > > >> > ----------------
> > > > > >> > Range name: LINUX.COM_id_range
> > > > > >> > First Posix ID of the range: 1066000000
> > > > > >> > Number of IDs in the range: 200000
> > > > > >> > First RID of the corresponding RID range: 1000
> > > > > >> > First RID of the secondary RID range: 100000000
> > > > > >> > Range type: local domain range
> > > > > >> >
> > > > > >> > Range name: WINDOWS.COM_id_range
> > > > > >> > First Posix ID of the range: 730200000
> > > > > >> > Number of IDs in the range: 200000
> > > > > >> > First RID of the corresponding RID range: 0
> > > > > >> > Domain SID of the trusted domain:
> > > > > >> S-1-5-21-1701591335-3855227394-3044674468
> > > > > >> > Range type: Active Directory domain range
> > > > > >> >
> > > > > >> > Range name: ACME.WINDOWS.COM_id_range
> > > > > >> > First Posix ID of the range: 365600000
> > > > > >> > Number of IDs in the range: 200000
> > > > > >> > First RID of the corresponding RID range: 0
> > > > > >> > Domain SID of the trusted domain:
> > > > > >> S-1-5-21-1215373191-1991333051-3772904882
> > > > > >> > Range type: Active Directory domain range
> > > > > >> > ----------------------------
> > > > > >> > Number of entries returned 3
> > > > > >> > ----------------------------
> > > > > >> >
> > > > > >> >
> > > > > >> > As we can see in the ouput of the command, the range type is "ad
> > > > POSIX
> > > > > >> > attributes".
> > > > > >>
> > > > > >> no, it's only 'Active Directory domain range', this is good
> > because
> > > > with
> > > > > >> this type we generate the UIDs and GIDs algorithmically.
> > > > > >>
> > > > > >> > In our case, the gidNumber is not set in the "ACME\Domain
> > Users" AD
> > > > > >> group,
> > > > > >> > nor in the " WINDOWS\Domain Users".
> > > > > >> > With a gidNumber attribute value, the 'wbinfo -n "ACME\Domain
> > > > Users"'
> > > > > >> still
> > > > > >> > command fails.
> > > > > >>
> > > > > >> no need to set the ID attributes in AD. But I should have
> > mentioned
> > > > > >> that wbinfo is quite useless nowadays with FreeIPA because
> > winbind is
> > > > > >> only used to assure some types of communication with AD. All user
> > and
> > > > > >> group lookups and IP-mapping is done by SSSD. Please try
> > > > > >>
> > > > > >> getent group 'ACME\Domain Users'
> > > > > >>
> > > > > >>
> > > > > >> and send the sssd_nss.log and sssd_example.com.log files.
> > > > > >>
> > > > > >> bye,
> > > > > >> Sumit
> > > > > >>
> > > > > >> >
> > > > > >> > Thanks
> > > > > >> >
> > > > > >> > 2014-12-12 19:51 GMT+01:00 Manuel Lopes <
> > manuel.lopes72 at gmail.com>:
> > > > > >> > >
> > > > > >> > > [root at support1 ~]# ipa idrange-find
> > > > > >> > > ----------------
> > > > > >> > > 3 ranges matched
> > > > > >> > > ----------------
> > > > > >> > >   Range name: LINUX.COM_id_range
> > > > > >> > >   First Posix ID of the range: 1066000000
> > > > > >> > >   Number of IDs in the range: 200000
> > > > > >> > >   First RID of the corresponding RID range: 1000
> > > > > >> > >   First RID of the secondary RID range: 100000000
> > > > > >> > >   Range type: local domain range
> > > > > >> > >
> > > > > >> > >   Range name: WINDOWS.COM_id_range
> > > > > >> > >   First Posix ID of the range: 730200000
> > > > > >> > >   Number of IDs in the range: 200000
> > > > > >> > >   First RID of the corresponding RID range: 0
> > > > > >> > >   Domain SID of the trusted domain:
> > > > > >> > > S-1-5-21-1701591335-3855227394-3044674468
> > > > > >> > >   Range type: Active Directory domain range
> > > > > >> > >
> > > > > >> > >   Range name: ACME.WINDOWS.COM_id_range
> > > > > >> > >   First Posix ID of the range: 365600000
> > > > > >> > >   Number of IDs in the range: 200000
> > > > > >> > >   First RID of the corresponding RID range: 0
> > > > > >> > >   Domain SID of the trusted domain:
> > > > > >> > > S-1-5-21-1215373191-1991333051-3772904882
> > > > > >> > >   Range type: Active Directory domain range
> > > > > >> > > ----------------------------
> > > > > >> > > Number of entries returned 3
> > > > > >> > > ----------------------------
> > > > > >> > >
> > > > > >> > >
> > > > > >> > > As we can see in the ouput of the command, the range type is
> > "ad
> > > > POSIX
> > > > > >> > > attributes".
> > > > > >> > > In our case, the gidNumber is not set in the "ACME\Domain
> > Users"
> > > > AD
> > > > > >> group,
> > > > > >> > > nor in the " WINDOWS\Domain Users".
> > > > > >> > > With a gidNumber attribute value, the 'wbinfo -n "ACME\Domain
> > > > Users"'
> > > > > >> > > still command fails.
> > > > > >> > >
> > > > > >> > > Thanks
> > > > > >> > >
> > > > > >> > >
> > > > > >> > > 2014-12-12 10:33 GMT+01:00 Sumit Bose <sbose at redhat.com>:
> > > > > >> > >>
> > > > > >> > >> On Fri, Dec 12, 2014 at 02:06:05AM +0100, Manuel Lopes wrote:
> > > > > >> > >> > Hi Sumit,
> > > > > >> > >> >
> > > > > >> > >> > Thank you very much for the prompt reply
> > > > > >> > >> >
> > > > > >> > >> > [root at support1 ~]# ipa trustdomain-find windows.com
> > > > > >> > >> >   Domain name: windows.com
> > > > > >> > >> >   Domain NetBIOS name: WINDOWS
> > > > > >> > >> >   Domain Security Identifier:
> > > > > >> S-1-5-21-1701591335-3855227394-3044674468
> > > > > >> > >> >   Domain enabled: True
> > > > > >> > >> >
> > > > > >> > >> >   Domain name: acme.windows.com
> > > > > >> > >> >   Domain NetBIOS name: ACME
> > > > > >> > >> >   Domain Security Identifier:
> > > > > >> S-1-5-21-1215373191-1991333051-3772904882
> > > > > >> > >> >   Domain enabled: True
> > > > > >> > >> > ----------------------------
> > > > > >> > >> > Number of entries returned 2
> > > > > >> > >> > ----------------------------
> > > > > >> > >>
> > > > > >> > >> ok, so ACME was discovered successful, can you check next the
> > > > output
> > > > > >> of
> > > > > >> > >>
> > > > > >> > >> ipa idrange-find
> > > > > >> > >>
> > > > > >> > >> The important attribute is the 'Range type' for the AD
> > domains.
> > > > If
> > > > > >> it is
> > > > > >> > >> 'Active Directory trust range with POSIX attributes' it is
> > > > expected
> > > > > >> that
> > > > > >> > >> users and groups in the AD forest have the POSIX UID and GID
> > > > > >> attributes
> > > > > >> > >> set and only those users and groups will be available in the
> > IPA
> > > > > >> domain.
> > > > > >> > >> In this case please check if 'ACME\Domain Users' have the GID
> > > > > >> attribute
> > > > > >> > >> set.
> > > > > >> > >>
> > > > > >> > >> If this does not help (please mind the negative cache of
> > SSSD)
> > > > please
> > > > > >> > >> send the SSSD logs in /var/log/sssd on the IPA server. You
> > might
> > > > > >> need to
> > > > > >> > >> enable logging in sssd.conf by setting 'debug_level = 10' in
> > the
> > > > > >> > >> [domain/..] and [nss] section of sssd.conf.
> > > > > >> > >>
> > > > > >> > >> bye,
> > > > > >> > >> Sumit
> > > > > >> > >>
> > > > > >> > >> >
> > > > > >> > >> > [root at support1 ~]# ipa trust-fetch-domains windows.com
> > > > > >> > >> > -------------------------------
> > > > > >> > >> > No new trust domains were found
> > > > > >> > >> > -------------------------------
> > > > > >> > >> > ----------------------------
> > > > > >> > >> > Number of entries returned 0
> > > > > >> > >> > ----------------------------
> > > > > >> > >> >
> > > > > >> > >> > Regards
> > > > > >> > >> > Le 11 d?c. 2014 20:08, "Sumit Bose" <sbose at redhat.com
> > > > > >> > >> > <javascript:_e(%7B%7D,'cvml','sbose at redhat.com');>> a
> > ?crit :
> > > > > >> > >> >
> > > > > >> > >> > > On Thu, Dec 11, 2014 at 06:45:49PM +0100, Manuel Lopes
> > wrote:
> > > > > >> > >> > > >  Hello,
> > > > > >> > >> > > >
> > > > > >> > >> > > >
> > > > > >> > >> > > > We have been following the AD integration guide for
> > IPAv3:
> > > > > >> > >> > > > http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup
> > > > > >> > >> > > >
> > > > > >> > >> > > >
> > > > > >> > >> > > >
> > > > > >> > >> > > > Our setup is:
> > > > > >> > >> > > >
> > > > > >> > >> > > > ? 2 domain controllers with Windows 2008 R2 AD DC ->
> > > > > >> windows.com
> > > > > >> > >> > > > <http://example.com/> as Forest Root Domain and
> > > > > >> acme.windows.com
> > > > > >> > >> > > > <http://acme.example.com/> as transitive child domain
> > > > > >> > >> > > >
> > > > > >> > >> > > > ? RHEL7 as IPA server with domain: linux.com
> > > > > >> > >> > > > <http://linux.acme.example.com/>
> > > > > >> > >> > > >
> > > > > >> > >> > > >
> > > > > >> > >> > > >
> > > > > >> > >> > > > We have established a forest trust between windows.com
> > and
> > > > > >> > >> linux.com and
> > > > > >> > >> > > > everything seems OK from an IPA perspective.
> > > > > >> > >> > > >
> > > > > >> > >> > > >
> > > > > >> > >> > > >
> > > > > >> > >> > > > We can work with Kerberos tickets without any issue
> > from
> > > > > >> ?windows?
> > > > > >> > >> domain
> > > > > >> > >> > > > or his child domain ?acme?. (kinit, kvno?)
> > > > > >> > >> > > >
> > > > > >> > >> > > >
> > > > > >> > >> > > >
> > > > > >> > >> > > > When we use samba tools, the following command is
> > working
> > > > fine.
> > > > > >> > >> > > >
> > > > > >> > >> > > > *[root at support1 ]# wbinfo -n 'WINDOWS\Domain Admins'*
> > > > > >> > >> > > >
> > > > > >> > >> > > > *S-1-5-21-1701591335-3855227394-3044674468-512
> > > > SID_DOM_GROUP
> > > > > >> (2)*
> > > > > >> > >> > > >
> > > > > >> > >> > > >
> > > > > >> > >> > > >
> > > > > >> > >> > > > But, the same command against the acme domain returns
> > an
> > > > error.
> > > > > >> > >> > > >
> > > > > >> > >> > > > *[root at support1 ]# wbinfo -n 'ACME\Domain Admins'*
> > > > > >> > >> > > >
> > > > > >> > >> > > > *failed to call wbcLookupName:
> > WBC_ERR_DOMAIN_NOT_FOUND*
> > > > > >> > >> > > >
> > > > > >> > >> > > > *Could not lookup name ACME\Domain Admins*
> > > > > >> > >> > > >
> > > > > >> > >> > > >
> > > > > >> > >> > > >
> > > > > >> > >> > > > Same problem with the following command:
> > > > > >> > >> > > >
> > > > > >> > >> > > > *[root at support1]# ipa group-add-member
> > ad_users_external
> > > > > >> --external
> > > > > >> > >> > > > "ACME\Domain Users"*
> > > > > >> > >> > > >
> > > > > >> > >> > > > *[member user]:*
> > > > > >> > >> > > >
> > > > > >> > >> > > > *[member group]:*
> > > > > >> > >> > > >
> > > > > >> > >> > > > *  Group name: ad_users_external*
> > > > > >> > >> > > >
> > > > > >> > >> > > > *  Description: AD users external map*
> > > > > >> > >> > > >
> > > > > >> > >> > > > *  External member: *
> > > > > >> > >> > > >
> > > > > >> > >> > > > *  Member of groups: ad_users*
> > > > > >> > >> > > >
> > > > > >> > >> > > > *  Failed members:*
> > > > > >> > >> > > >
> > > > > >> > >> > > > *    member user:*
> > > > > >> > >> > > >
> > > > > >> > >> > > > *    member group: ACME\Domain Users: Cannot find
> > specified
> > > > > >> domain
> > > > > >> > >> or
> > > > > >> > >> > > > server name*
> > > > > >> > >> > > >
> > > > > >> > >> > > > *-------------------------*
> > > > > >> > >> > > >
> > > > > >> > >> > > > *Number of members added 0*
> > > > > >> > >> > > >
> > > > > >> > >> > > >
> > > > > >> > >> > > >
> > > > > >> > >> > > >
> > > > > >> > >> > > >
> > > > > >> > >> > > > Any help would be appreciated
> > > > > >> > >> > >
> > > > > >> > >> > > Does
> > > > > >> > >> > >
> > > > > >> > >> > > ipa trustdomain-find windows.com
> > > > > >> > >> > >
> > > > > >> > >> > > show acme.windows.com as well ?
> > > > > >> > >> > >
> > > > > >> > >> > > Does
> > > > > >> > >> > >
> > > > > >> > >> > > ipa trust-fetch-domains ad.devel
> > > > > >> > >> > >
> > > > > >> > >> > > help to retrieve the child domain?
> > > > > >> > >> > >
> > > > > >> > >> > > Please note that if acme.windows.com now shows up you
> > might
> > > > > >> have to
> > > > > >> > >> wait
> > > > > >> > >> > > 1-2 minutes until SSSD's negative caches are flushed and
> > the
> > > > new
> > > > > >> > >> domains
> > > > > >> > >> > > is discovered by SSSD, as an alternative you can just
> > restart
> > > > > >> SSSD.
> > > > > >> > >> > >
> > > > > >> > >> > > HTH
> > > > > >> > >> > >
> > > > > >> > >> > > bye,
> > > > > >> > >> > > Sumit
> > > > > >> > >> > >
> > > > > >> > >> > > >
> > > > > >> > >> > > >
> > > > > >> > >> > > >
> > > > > >> > >> > > > Regards
> > > > > >> > >> > >
> > > > > >> > >> > > > --
> > > > > >> > >> > > > 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
> > > > > >> > >>
> > > > > >> > >> --
> > > > > >> > >> 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
> > > > > >> > >>
> > > > > >> > >
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >>
> > > >
> > > >
> > > >
> > > >
> >




From janellenicole80 at gmail.com  Mon Dec 15 18:28:56 2014
From: janellenicole80 at gmail.com (Janelle)
Date: Mon, 15 Dec 2014 10:28:56 -0800
Subject: [Freeipa-users] strange problem - IPA related?
Message-ID: <548F2868.5050503@gmail.com>

Hi all..

Not sure if this is IPA related, but here it is:

1. IPA 4.1.2 install on CentOS 7
2. IPA 4.1.2 install on Fedora 21

So both systems are systemd based - the fedora system reboots in less 
than 30 seconds. The CentOS system reboots and has strange timers 
showing that it is waiting on various "targets and servoces" -- having 
trouble tracking it donw, but the bottom line is the CentOS 7 box takes 
almost 10-15 minutes to reboot.

Thoughts? Ideas?? I know there is something in the startup that seems to 
MAYBE be related to the fedora-domain vs rhel-domain settings in some of 
the IPA python scripts -- or maybe not.  Just thought I would see if 
anyone else is seeing something like this.

~J




From manuel.lopes72 at gmail.com  Mon Dec 15 20:35:52 2014
From: manuel.lopes72 at gmail.com (Manuel Lopes)
Date: Mon, 15 Dec 2014 21:35:52 +0100
Subject: [Freeipa-users] Forest trust and AD child domain
In-Reply-To: <20141215173447.GG2868@localhost.localdomain>
References: <20141212093311.GU14057@localhost.localdomain>
	<CAKFNJrvBrvRJbxU-zsXhmsek8MZrZdz-b1p1O1MvfmUPv256vg@mail.gmail.com>
	<CAKFNJrsJvj8098k9vzScONO4endDE3LGuH1AzUY6_yDRS3MT1Q@mail.gmail.com>
	<20141212203234.GA6877@localhost.localdomain>
	<CAKFNJrsS1-h8pu+UoWWCwAUu3GA8D8XtGva7J3in7omSGCjiUw@mail.gmail.com>
	<CAKFNJrsRRZFQmb+4892WPtx2d9jcJVfZeW1LQJmWOJKK7mvsaw@mail.gmail.com>
	<20141215144258.GA2868@localhost.localdomain>
	<CAKFNJruhr6iB6v6qVBqt84oN8hsZRewuhH_YmBBXHc0A7CMUCA@mail.gmail.com>
	<20141215160355.GE2868@localhost.localdomain>
	<CAKFNJrsDdL1ANRTBxder_eeCWJPtO6e_x643gMvYZQS7XLWaDw@mail.gmail.com>
	<20141215173447.GG2868@localhost.localdomain>
Message-ID: <CAKFNJrvo6+AFbCVKJiHL8mYdg5NnHHz9pv4EUgqcey2CSsBDOA@mail.gmail.com>

Hi,

Attached, the good log.

We are running sssd-1.11.2-68.el7_0.6 on RHEL 7.
ipa-server-3.3.3-28.el7_0.3

Regards

2014-12-15 18:34 GMT+01:00 Sumit Bose <sbose at redhat.com>:
>
> On Mon, Dec 15, 2014 at 05:38:05PM +0100, Manuel Lopes wrote:
> > Attached the sssd_linux.com.log file
> >
> > Regards
>
> Thank you, there is no request logged in the logs, did you run ipa
> group-add-member after restarting SSSD? Nevertheless I think I know what
> is happening, you hit an issue which should be fixed in SSSD 1.12.2,
> which version of SSSD are you running on which platform?
>
> bye,
> Sumit
>
> >
> > 2014-12-15 17:03 GMT+01:00 Sumit Bose <sbose at redhat.com>:
> > >
> > > On Mon, Dec 15, 2014 at 04:39:29PM +0100, Manuel Lopes wrote:
> > > > The file sssd_linux.com.log is empty.
> > >
> > > please add
> > >
> > > debug_level = 10
> > >
> > > to the [domain/...] section in sssd.conf to enable logging for this
> part
> > > of SSSD.
> > >
> > > bye,
> > > Sumit
> > > >
> > > >
> > > >
> > > > 2014-12-15 15:42 GMT+01:00 Sumit Bose <sbose at redhat.com>:
> > > > >
> > > > > On Sat, Dec 13, 2014 at 02:13:30PM +0100, Manuel Lopes wrote:
> > > > > > Hi,
> > > > > >
> > > > > > As explained in the previous email, the getent is successful.
> > > > > >
> > > > > >
> > > > > > *[root at support1 ~]# getent group 'ACME\Domain Users' domain
> > > > > > users at acme.windows.com:*:**
> 365600513:administrator at acme.windows.com
> > > > > > <365600513%3Aadministrator at acme.windows.com>*
> > > > > >
> > > > > >
> > > > > >
> > > > > > In fact, our real problem is not the ?wbinfo ?n? but the
> following
> > > > > command:
> > > > > >
> > > > > > *[root at support1 sssd]# ipa group-add-member ad_users_external
> > > --external
> > > > > > "ACME\Domain Users"*
> > > > > >
> > > > > > *[member user]:*
> > > > > >
> > > > > > *[member group]:*
> > > > > >
> > > > > > *  Group name: ad_users_external*
> > > > > >
> > > > > > *  Description: AD users external map*
> > > > > >
> > > > > > *  External member: *
> > > > > >
> > > > > > *  Member of groups: ad_users*
> > > > > >
> > > > > > *  Failed members:*
> > > > > >
> > > > > > *    member user:*
> > > > > >
> > > > > > *    member group: ACME\Domain Users: Cannot find specified
> domain or
> > > > > > server name*
> > > > > >
> > > > > > *-------------------------*
> > > > > >
> > > > > > *Number of members added 0*
> > > > > >
> > > > > > *-------------------------*
> > > > > >
> > > > > >
> > > > > >
> > > > > > We cannot add ACME?s domain users in the ad_users_external.
> > > > > >
> > > > > >
> > > > > >
> > > > > > I attached the sssd logs.
> > > > >
> > > > > Can you send the corresponding domain log file as well, it should
> be
> > > > > called sssd_linux.com.log or similar.
> > > > >
> > > > > bye,
> > > > > Sumit
> > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > Regards
> > > > > >
> > > > > > 2014-12-12 21:51 GMT+01:00 Manuel Lopes <
> manuel.lopes72 at gmail.com>:
> > > > > > >
> > > > > > > OK.
> > > > > > >
> > > > > > > Command successful
> > > > > > > [root at support1 ~]# getent group  'ACME\Domain Users'
> > > > > > > domain users at acme.windows.com:*:
> > > > > 365600513:administrator at acme.windows.com
> > > > > > >
> > > > > > > Log files attached
> > > > > > >
> > > > > > > Thanks
> > > > > > >
> > > > > > > 2014-12-12 21:32 GMT+01:00 Sumit Bose <sbose at redhat.com>:
> > > > > > >>
> > > > > > >> On Fri, Dec 12, 2014 at 08:41:27PM +0100, Manuel Lopes wrote:
> > > > > > >> > [root at support1 ~]# ipa idrange-find
> > > > > > >> > ----------------
> > > > > > >> > 3 ranges matched
> > > > > > >> > ----------------
> > > > > > >> > Range name: LINUX.COM_id_range
> > > > > > >> > First Posix ID of the range: 1066000000
> > > > > > >> > Number of IDs in the range: 200000
> > > > > > >> > First RID of the corresponding RID range: 1000
> > > > > > >> > First RID of the secondary RID range: 100000000
> > > > > > >> > Range type: local domain range
> > > > > > >> >
> > > > > > >> > Range name: WINDOWS.COM_id_range
> > > > > > >> > First Posix ID of the range: 730200000
> > > > > > >> > Number of IDs in the range: 200000
> > > > > > >> > First RID of the corresponding RID range: 0
> > > > > > >> > Domain SID of the trusted domain:
> > > > > > >> S-1-5-21-1701591335-3855227394-3044674468
> > > > > > >> > Range type: Active Directory domain range
> > > > > > >> >
> > > > > > >> > Range name: ACME.WINDOWS.COM_id_range
> > > > > > >> > First Posix ID of the range: 365600000
> > > > > > >> > Number of IDs in the range: 200000
> > > > > > >> > First RID of the corresponding RID range: 0
> > > > > > >> > Domain SID of the trusted domain:
> > > > > > >> S-1-5-21-1215373191-1991333051-3772904882
> > > > > > >> > Range type: Active Directory domain range
> > > > > > >> > ----------------------------
> > > > > > >> > Number of entries returned 3
> > > > > > >> > ----------------------------
> > > > > > >> >
> > > > > > >> >
> > > > > > >> > As we can see in the ouput of the command, the range type
> is "ad
> > > > > POSIX
> > > > > > >> > attributes".
> > > > > > >>
> > > > > > >> no, it's only 'Active Directory domain range', this is good
> > > because
> > > > > with
> > > > > > >> this type we generate the UIDs and GIDs algorithmically.
> > > > > > >>
> > > > > > >> > In our case, the gidNumber is not set in the "ACME\Domain
> > > Users" AD
> > > > > > >> group,
> > > > > > >> > nor in the " WINDOWS\Domain Users".
> > > > > > >> > With a gidNumber attribute value, the 'wbinfo -n
> "ACME\Domain
> > > > > Users"'
> > > > > > >> still
> > > > > > >> > command fails.
> > > > > > >>
> > > > > > >> no need to set the ID attributes in AD. But I should have
> > > mentioned
> > > > > > >> that wbinfo is quite useless nowadays with FreeIPA because
> > > winbind is
> > > > > > >> only used to assure some types of communication with AD. All
> user
> > > and
> > > > > > >> group lookups and IP-mapping is done by SSSD. Please try
> > > > > > >>
> > > > > > >> getent group 'ACME\Domain Users'
> > > > > > >>
> > > > > > >>
> > > > > > >> and send the sssd_nss.log and sssd_example.com.log files.
> > > > > > >>
> > > > > > >> bye,
> > > > > > >> Sumit
> > > > > > >>
> > > > > > >> >
> > > > > > >> > Thanks
> > > > > > >> >
> > > > > > >> > 2014-12-12 19:51 GMT+01:00 Manuel Lopes <
> > > manuel.lopes72 at gmail.com>:
> > > > > > >> > >
> > > > > > >> > > [root at support1 ~]# ipa idrange-find
> > > > > > >> > > ----------------
> > > > > > >> > > 3 ranges matched
> > > > > > >> > > ----------------
> > > > > > >> > >   Range name: LINUX.COM_id_range
> > > > > > >> > >   First Posix ID of the range: 1066000000
> > > > > > >> > >   Number of IDs in the range: 200000
> > > > > > >> > >   First RID of the corresponding RID range: 1000
> > > > > > >> > >   First RID of the secondary RID range: 100000000
> > > > > > >> > >   Range type: local domain range
> > > > > > >> > >
> > > > > > >> > >   Range name: WINDOWS.COM_id_range
> > > > > > >> > >   First Posix ID of the range: 730200000
> > > > > > >> > >   Number of IDs in the range: 200000
> > > > > > >> > >   First RID of the corresponding RID range: 0
> > > > > > >> > >   Domain SID of the trusted domain:
> > > > > > >> > > S-1-5-21-1701591335-3855227394-3044674468
> > > > > > >> > >   Range type: Active Directory domain range
> > > > > > >> > >
> > > > > > >> > >   Range name: ACME.WINDOWS.COM_id_range
> > > > > > >> > >   First Posix ID of the range: 365600000
> > > > > > >> > >   Number of IDs in the range: 200000
> > > > > > >> > >   First RID of the corresponding RID range: 0
> > > > > > >> > >   Domain SID of the trusted domain:
> > > > > > >> > > S-1-5-21-1215373191-1991333051-3772904882
> > > > > > >> > >   Range type: Active Directory domain range
> > > > > > >> > > ----------------------------
> > > > > > >> > > Number of entries returned 3
> > > > > > >> > > ----------------------------
> > > > > > >> > >
> > > > > > >> > >
> > > > > > >> > > As we can see in the ouput of the command, the range type
> is
> > > "ad
> > > > > POSIX
> > > > > > >> > > attributes".
> > > > > > >> > > In our case, the gidNumber is not set in the "ACME\Domain
> > > Users"
> > > > > AD
> > > > > > >> group,
> > > > > > >> > > nor in the " WINDOWS\Domain Users".
> > > > > > >> > > With a gidNumber attribute value, the 'wbinfo -n
> "ACME\Domain
> > > > > Users"'
> > > > > > >> > > still command fails.
> > > > > > >> > >
> > > > > > >> > > Thanks
> > > > > > >> > >
> > > > > > >> > >
> > > > > > >> > > 2014-12-12 10:33 GMT+01:00 Sumit Bose <sbose at redhat.com>:
> > > > > > >> > >>
> > > > > > >> > >> On Fri, Dec 12, 2014 at 02:06:05AM +0100, Manuel Lopes
> wrote:
> > > > > > >> > >> > Hi Sumit,
> > > > > > >> > >> >
> > > > > > >> > >> > Thank you very much for the prompt reply
> > > > > > >> > >> >
> > > > > > >> > >> > [root at support1 ~]# ipa trustdomain-find windows.com
> > > > > > >> > >> >   Domain name: windows.com
> > > > > > >> > >> >   Domain NetBIOS name: WINDOWS
> > > > > > >> > >> >   Domain Security Identifier:
> > > > > > >> S-1-5-21-1701591335-3855227394-3044674468
> > > > > > >> > >> >   Domain enabled: True
> > > > > > >> > >> >
> > > > > > >> > >> >   Domain name: acme.windows.com
> > > > > > >> > >> >   Domain NetBIOS name: ACME
> > > > > > >> > >> >   Domain Security Identifier:
> > > > > > >> S-1-5-21-1215373191-1991333051-3772904882
> > > > > > >> > >> >   Domain enabled: True
> > > > > > >> > >> > ----------------------------
> > > > > > >> > >> > Number of entries returned 2
> > > > > > >> > >> > ----------------------------
> > > > > > >> > >>
> > > > > > >> > >> ok, so ACME was discovered successful, can you check
> next the
> > > > > output
> > > > > > >> of
> > > > > > >> > >>
> > > > > > >> > >> ipa idrange-find
> > > > > > >> > >>
> > > > > > >> > >> The important attribute is the 'Range type' for the AD
> > > domains.
> > > > > If
> > > > > > >> it is
> > > > > > >> > >> 'Active Directory trust range with POSIX attributes' it
> is
> > > > > expected
> > > > > > >> that
> > > > > > >> > >> users and groups in the AD forest have the POSIX UID and
> GID
> > > > > > >> attributes
> > > > > > >> > >> set and only those users and groups will be available in
> the
> > > IPA
> > > > > > >> domain.
> > > > > > >> > >> In this case please check if 'ACME\Domain Users' have
> the GID
> > > > > > >> attribute
> > > > > > >> > >> set.
> > > > > > >> > >>
> > > > > > >> > >> If this does not help (please mind the negative cache of
> > > SSSD)
> > > > > please
> > > > > > >> > >> send the SSSD logs in /var/log/sssd on the IPA server.
> You
> > > might
> > > > > > >> need to
> > > > > > >> > >> enable logging in sssd.conf by setting 'debug_level =
> 10' in
> > > the
> > > > > > >> > >> [domain/..] and [nss] section of sssd.conf.
> > > > > > >> > >>
> > > > > > >> > >> bye,
> > > > > > >> > >> Sumit
> > > > > > >> > >>
> > > > > > >> > >> >
> > > > > > >> > >> > [root at support1 ~]# ipa trust-fetch-domains windows.com
> > > > > > >> > >> > -------------------------------
> > > > > > >> > >> > No new trust domains were found
> > > > > > >> > >> > -------------------------------
> > > > > > >> > >> > ----------------------------
> > > > > > >> > >> > Number of entries returned 0
> > > > > > >> > >> > ----------------------------
> > > > > > >> > >> >
> > > > > > >> > >> > Regards
> > > > > > >> > >> > Le 11 d?c. 2014 20:08, "Sumit Bose" <sbose at redhat.com
> > > > > > >> > >> > <javascript:_e(%7B%7D,'cvml','sbose at redhat.com');>> a
> > > ?crit :
> > > > > > >> > >> >
> > > > > > >> > >> > > On Thu, Dec 11, 2014 at 06:45:49PM +0100, Manuel
> Lopes
> > > wrote:
> > > > > > >> > >> > > >  Hello,
> > > > > > >> > >> > > >
> > > > > > >> > >> > > >
> > > > > > >> > >> > > > We have been following the AD integration guide for
> > > IPAv3:
> > > > > > >> > >> > > >
> http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup
> > > > > > >> > >> > > >
> > > > > > >> > >> > > >
> > > > > > >> > >> > > >
> > > > > > >> > >> > > > Our setup is:
> > > > > > >> > >> > > >
> > > > > > >> > >> > > > ? 2 domain controllers with Windows 2008 R2 AD DC
> ->
> > > > > > >> windows.com
> > > > > > >> > >> > > > <http://example.com/> as Forest Root Domain and
> > > > > > >> acme.windows.com
> > > > > > >> > >> > > > <http://acme.example.com/> as transitive child
> domain
> > > > > > >> > >> > > >
> > > > > > >> > >> > > > ? RHEL7 as IPA server with domain: linux.com
> > > > > > >> > >> > > > <http://linux.acme.example.com/>
> > > > > > >> > >> > > >
> > > > > > >> > >> > > >
> > > > > > >> > >> > > >
> > > > > > >> > >> > > > We have established a forest trust between
> windows.com
> > > and
> > > > > > >> > >> linux.com and
> > > > > > >> > >> > > > everything seems OK from an IPA perspective.
> > > > > > >> > >> > > >
> > > > > > >> > >> > > >
> > > > > > >> > >> > > >
> > > > > > >> > >> > > > We can work with Kerberos tickets without any issue
> > > from
> > > > > > >> ?windows?
> > > > > > >> > >> domain
> > > > > > >> > >> > > > or his child domain ?acme?. (kinit, kvno?)
> > > > > > >> > >> > > >
> > > > > > >> > >> > > >
> > > > > > >> > >> > > >
> > > > > > >> > >> > > > When we use samba tools, the following command is
> > > working
> > > > > fine.
> > > > > > >> > >> > > >
> > > > > > >> > >> > > > *[root at support1 ]# wbinfo -n 'WINDOWS\Domain
> Admins'*
> > > > > > >> > >> > > >
> > > > > > >> > >> > > > *S-1-5-21-1701591335-3855227394-3044674468-512
> > > > > SID_DOM_GROUP
> > > > > > >> (2)*
> > > > > > >> > >> > > >
> > > > > > >> > >> > > >
> > > > > > >> > >> > > >
> > > > > > >> > >> > > > But, the same command against the acme domain
> returns
> > > an
> > > > > error.
> > > > > > >> > >> > > >
> > > > > > >> > >> > > > *[root at support1 ]# wbinfo -n 'ACME\Domain Admins'*
> > > > > > >> > >> > > >
> > > > > > >> > >> > > > *failed to call wbcLookupName:
> > > WBC_ERR_DOMAIN_NOT_FOUND*
> > > > > > >> > >> > > >
> > > > > > >> > >> > > > *Could not lookup name ACME\Domain Admins*
> > > > > > >> > >> > > >
> > > > > > >> > >> > > >
> > > > > > >> > >> > > >
> > > > > > >> > >> > > > Same problem with the following command:
> > > > > > >> > >> > > >
> > > > > > >> > >> > > > *[root at support1]# ipa group-add-member
> > > ad_users_external
> > > > > > >> --external
> > > > > > >> > >> > > > "ACME\Domain Users"*
> > > > > > >> > >> > > >
> > > > > > >> > >> > > > *[member user]:*
> > > > > > >> > >> > > >
> > > > > > >> > >> > > > *[member group]:*
> > > > > > >> > >> > > >
> > > > > > >> > >> > > > *  Group name: ad_users_external*
> > > > > > >> > >> > > >
> > > > > > >> > >> > > > *  Description: AD users external map*
> > > > > > >> > >> > > >
> > > > > > >> > >> > > > *  External member: *
> > > > > > >> > >> > > >
> > > > > > >> > >> > > > *  Member of groups: ad_users*
> > > > > > >> > >> > > >
> > > > > > >> > >> > > > *  Failed members:*
> > > > > > >> > >> > > >
> > > > > > >> > >> > > > *    member user:*
> > > > > > >> > >> > > >
> > > > > > >> > >> > > > *    member group: ACME\Domain Users: Cannot find
> > > specified
> > > > > > >> domain
> > > > > > >> > >> or
> > > > > > >> > >> > > > server name*
> > > > > > >> > >> > > >
> > > > > > >> > >> > > > *-------------------------*
> > > > > > >> > >> > > >
> > > > > > >> > >> > > > *Number of members added 0*
> > > > > > >> > >> > > >
> > > > > > >> > >> > > >
> > > > > > >> > >> > > >
> > > > > > >> > >> > > >
> > > > > > >> > >> > > >
> > > > > > >> > >> > > > Any help would be appreciated
> > > > > > >> > >> > >
> > > > > > >> > >> > > Does
> > > > > > >> > >> > >
> > > > > > >> > >> > > ipa trustdomain-find windows.com
> > > > > > >> > >> > >
> > > > > > >> > >> > > show acme.windows.com as well ?
> > > > > > >> > >> > >
> > > > > > >> > >> > > Does
> > > > > > >> > >> > >
> > > > > > >> > >> > > ipa trust-fetch-domains ad.devel
> > > > > > >> > >> > >
> > > > > > >> > >> > > help to retrieve the child domain?
> > > > > > >> > >> > >
> > > > > > >> > >> > > Please note that if acme.windows.com now shows up
> you
> > > might
> > > > > > >> have to
> > > > > > >> > >> wait
> > > > > > >> > >> > > 1-2 minutes until SSSD's negative caches are flushed
> and
> > > the
> > > > > new
> > > > > > >> > >> domains
> > > > > > >> > >> > > is discovered by SSSD, as an alternative you can just
> > > restart
> > > > > > >> SSSD.
> > > > > > >> > >> > >
> > > > > > >> > >> > > HTH
> > > > > > >> > >> > >
> > > > > > >> > >> > > bye,
> > > > > > >> > >> > > Sumit
> > > > > > >> > >> > >
> > > > > > >> > >> > > >
> > > > > > >> > >> > > >
> > > > > > >> > >> > > >
> > > > > > >> > >> > > > Regards
> > > > > > >> > >> > >
> > > > > > >> > >> > > > --
> > > > > > >> > >> > > > 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
> > > > > > >> > >>
> > > > > > >> > >> --
> > > > > > >> > >> 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
> > > > > > >> > >>
> > > > > > >> > >
> > > > > > >>
> > > > > > >>
> > > > > > >>
> > > > > > >>
> > > > >
> > > > >
> > > > >
> > > > >
> > >
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141215/0a50a9fb/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sssd_linux.com.log
Type: application/octet-stream
Size: 211587 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141215/0a50a9fb/attachment.obj>

From dpal at redhat.com  Tue Dec 16 00:34:22 2014
From: dpal at redhat.com (Dmitri Pal)
Date: Mon, 15 Dec 2014 19:34:22 -0500
Subject: [Freeipa-users] strange problem - IPA related?
In-Reply-To: <548F2868.5050503@gmail.com>
References: <548F2868.5050503@gmail.com>
Message-ID: <548F7E0E.7030402@redhat.com>

On 12/15/2014 01:28 PM, Janelle wrote:
> Hi all..
>
> Not sure if this is IPA related, but here it is:
>
> 1. IPA 4.1.2 install on CentOS 7
> 2. IPA 4.1.2 install on Fedora 21
>
> So both systems are systemd based - the fedora system reboots in less 
> than 30 seconds. The CentOS system reboots and has strange timers 
> showing that it is waiting on various "targets and servoces" -- having 
> trouble tracking it donw, but the bottom line is the CentOS 7 box 
> takes almost 10-15 minutes to reboot.
>
> Thoughts? Ideas?? I know there is something in the startup that seems 
> to MAYBE be related to the fedora-domain vs rhel-domain settings in 
> some of the IPA python scripts -- or maybe not.  Just thought I would 
> see if anyone else is seeing something like this.
>
> ~J
>
>
DNS timeouts?
FW settings?

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.



From sbingram at gmail.com  Tue Dec 16 02:40:58 2014
From: sbingram at gmail.com (Stephen Ingram)
Date: Mon, 15 Dec 2014 18:40:58 -0800
Subject: [Freeipa-users] trust non-IPA certificate client
Message-ID: <CAPsaoBcxW+RXm_N_C_nYMbrsq82A4_qwQtqWjNO3mroy_wyc+A@mail.gmail.com>

I have one client using a certificate issued by a third party provider such
that any secure (TLS) LDAP queries are refused since the certificates were
not issued by IPA. Since there are only a few clients with foreign
certificates, can the CA simply be added to the NSS database used by the
389 directory server so IPA will establish a secure connection with them?

Steve
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141215/12bb038b/attachment.htm>

From janellenicole80 at gmail.com  Tue Dec 16 02:47:53 2014
From: janellenicole80 at gmail.com (Janelle)
Date: Mon, 15 Dec 2014 18:47:53 -0800
Subject: [Freeipa-users] strange problem - IPA related?
In-Reply-To: <548F7E0E.7030402@redhat.com>
References: <548F2868.5050503@gmail.com> <548F7E0E.7030402@redhat.com>
Message-ID: <548F9D59.2090707@gmail.com>

Identical configurations on the same subnet - using same DNS resolvers.. 
Both host-based FWs disabled just because I thought that too.

Time to do some more studying of systemd and all the dependencies.

~J


On 12/15/14 4:34 PM, Dmitri Pal wrote:
> On 12/15/2014 01:28 PM, Janelle wrote:
>> Hi all..
>>
>> Not sure if this is IPA related, but here it is:
>>
>> 1. IPA 4.1.2 install on CentOS 7
>> 2. IPA 4.1.2 install on Fedora 21
>>
>> So both systems are systemd based - the fedora system reboots in less 
>> than 30 seconds. The CentOS system reboots and has strange timers 
>> showing that it is waiting on various "targets and servoces" -- 
>> having trouble tracking it donw, but the bottom line is the CentOS 7 
>> box takes almost 10-15 minutes to reboot.
>>
>> Thoughts? Ideas?? I know there is something in the startup that seems 
>> to MAYBE be related to the fedora-domain vs rhel-domain settings in 
>> some of the IPA python scripts -- or maybe not. Just thought I would 
>> see if anyone else is seeing something like this.
>>
>> ~J
>>
>>
> DNS timeouts?
> FW settings?
>



From eivind at aminor.no  Tue Dec 16 07:24:51 2014
From: eivind at aminor.no (Eivind Olsen)
Date: Tue, 16 Dec 2014 08:24:51 +0100
Subject: [Freeipa-users] Clients in multiple domains, any known issues?
Message-ID: <46719602280df4d57e509cdd798917bc.squirrel@webmail.aminor.no>

Hello.

I have so far been running IPA on RHEL6, with a single domain (and a
matching realm). I now have a use-case where it looks like I'll need to
set up a new IPA realm, with the IPA servers in one DNS domain and the IPA
clients in multiple (2-4) other domains.
The servers will be running RHEL6 or RHEL7 with the bundled IPA.
The clients are running mainly RHEL5 and RHEL6, and have hostnames that
don't exist in DNS.
Are there any known issues with this type of setup? I know, it sounds a
bit hairy, but apart from that? :)

Regards
Eivind Olsen




From ctcard at hotmail.com  Tue Dec 16 08:17:47 2014
From: ctcard at hotmail.com (Chris Card)
Date: Tue, 16 Dec 2014 08:17:47 +0000
Subject: [Freeipa-users] freeipa / sudo
In-Reply-To: <20141216004942.6037651.21762.10902@gmail.com>
References: <mailman.344.1418226905.17291.freeipa-users@redhat.com>,
	<20141216004942.6037651.21762.10902@gmail.com>
Message-ID: <DUB125-W610F6832E2C15418A6F8C5CC6C0@phx.gbl>




> What command did you use to get sudo options working please? 
> 
> I noticed from below mail that you have? 
> Sudo Option: !authenticate
> 
> I am having trouble getting that working
The first issue is what version of FreeIPA you are using. Before version 4 sudo rules don't work without some manual setup on the client:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/config-sudo-clients.html#example-configuring-sudo-sss .

If the client is setup correctly, then I found issues with sssd caching, and in particular the sss_cache command doesn't invalidate the cache of sudo rules yet. Once I reduced the default cache time for sssd I could see my sudo rule changes working on the client.
I also had a problem with using host groups as part of the sudo rule, and this was down to the netgroup seen by the client having fully-qualified host names, while the hostname command on the client was only returning the short hostname - but this was down to the way OpenStack creates instances by default, not an issue with FreeIPA per se.

Chris 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141216/b76ca82f/attachment.htm>

From patrick.hurrelmann at lobster.de  Tue Dec 16 08:19:09 2014
From: patrick.hurrelmann at lobster.de (Patrick Hurrelmann)
Date: Tue, 16 Dec 2014 09:19:09 +0100
Subject: [Freeipa-users] strange problem - IPA related?
In-Reply-To: <548F2868.5050503@gmail.com>
References: <548F2868.5050503@gmail.com>
Message-ID: <548FEAFD.6090500@lobster.de>

On 15.12.2014 19:28, Janelle wrote:
> Hi all..
> 
> Not sure if this is IPA related, but here it is:
> 
> 1. IPA 4.1.2 install on CentOS 7
> 2. IPA 4.1.2 install on Fedora 21
> 
> So both systems are systemd based - the fedora system reboots in less 
> than 30 seconds. The CentOS system reboots and has strange timers 
> showing that it is waiting on various "targets and servoces" -- having 
> trouble tracking it donw, but the bottom line is the CentOS 7 box takes 
> almost 10-15 minutes to reboot.
> 
> Thoughts? Ideas?? I know there is something in the startup that seems to 
> MAYBE be related to the fedora-domain vs rhel-domain settings in some of 
> the IPA python scripts -- or maybe not.  Just thought I would see if 
> anyone else is seeing something like this.
> 
> ~J

You are probably hitting:
https://bugzilla.redhat.com/show_bug.cgi?id=1071969

For me this resulted in symted error messages on bootup and slowed the
boot to 15-20min. Applying the following patch corrected this:
https://git.fedorahosted.org/cgit/initscripts.git/commit/?h=rhel7-branch&id=3deb3b3c177dd24b22cf912cd798aeaa7e35d30b

I guess this is fixed in RHEL 7.1.

Best regards
Patrick

-- 
Lobster SCM GmbH, Hindenburgstra?e 15, D-82343 P?cking
HRB 178831, Amtsgericht M?nchen
Gesch?ftsf?hrer: Dr. Martin Fischer, Rolf Henrich



From genadipost at gmail.com  Tue Dec 16 09:28:47 2014
From: genadipost at gmail.com (Genadi Postrilko)
Date: Tue, 16 Dec 2014 11:28:47 +0200
Subject: [Freeipa-users] Certificate Authorities requirement for Cross realm
	trust?
Message-ID: <CAPP+0v+CTFwo5Dw8ymBFpjzroW3=5GE+ouoEj2AnCJP-cJMDXA@mail.gmail.com>

In the Windows Integration guide the need for CA is mentioned.

"Both Active Directory and Identity Management must be configured with
integrated certificate services."

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/Windows_Integration_Guide/index.html#trust-requirements

I cannot install CA-less IPA if i want to create a Cross realm trust? If
so, why?
As far as i understand the Trust is Kerberos based.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141216/7da35b29/attachment.htm>

From sbose at redhat.com  Tue Dec 16 09:59:30 2014
From: sbose at redhat.com (Sumit Bose)
Date: Tue, 16 Dec 2014 10:59:30 +0100
Subject: [Freeipa-users] Certificate Authorities requirement for Cross
 realm trust?
In-Reply-To: <CAPP+0v+CTFwo5Dw8ymBFpjzroW3=5GE+ouoEj2AnCJP-cJMDXA@mail.gmail.com>
References: <CAPP+0v+CTFwo5Dw8ymBFpjzroW3=5GE+ouoEj2AnCJP-cJMDXA@mail.gmail.com>
Message-ID: <20141216095930.GC27648@localhost.localdomain>

On Tue, Dec 16, 2014 at 11:28:47AM +0200, Genadi Postrilko wrote:
> In the Windows Integration guide the need for CA is mentioned.
> 
> "Both Active Directory and Identity Management must be configured with
> integrated certificate services."
> 
> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/Windows_Integration_Guide/index.html#trust-requirements
> 
> I cannot install CA-less IPA if i want to create a Cross realm trust? If
> so, why?
> As far as i understand the Trust is Kerberos based.

Thank you for the feedback. You are correct, CAs are not needed to
create trust. I guess the CA requirement (at least on the Windows side)
came form a time where we might wanted to look up some data in AD which
required an authenticated connection and we only wanted to use
LDAPS/StartTLS for this.

There is ongoing work to improve the Windows Integration Guide, I added
a note so that you comment won't get lost.

bye,
Sumit

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



From janellenicole80 at gmail.com  Tue Dec 16 14:49:47 2014
From: janellenicole80 at gmail.com (Janelle)
Date: Tue, 16 Dec 2014 06:49:47 -0800
Subject: [Freeipa-users] strange problem - IPA related?
In-Reply-To: <548FEAFD.6090500@lobster.de>
References: <548F2868.5050503@gmail.com> <548FEAFD.6090500@lobster.de>
Message-ID: <5490468B.3080308@gmail.com>

That is indeed what it was -- thank you so much. Now they both boot in 
about 60 seconds.

Gosh, keeping up with all the "little annoyances" is indeed a fulltime 
job.  The team is doing great with the product and I truly appreciate 
all the work and quick responses on the mailing-list.

~J


On 12/16/14 12:19 AM, Patrick Hurrelmann wrote:
> On 15.12.2014 19:28, Janelle wrote:
>> Hi all..
>>
>> Not sure if this is IPA related, but here it is:
>>
>> 1. IPA 4.1.2 install on CentOS 7
>> 2. IPA 4.1.2 install on Fedora 21
>>
>> So both systems are systemd based - the fedora system reboots in less
>> than 30 seconds. The CentOS system reboots and has strange timers
>> showing that it is waiting on various "targets and servoces" -- having
>> trouble tracking it donw, but the bottom line is the CentOS 7 box takes
>> almost 10-15 minutes to reboot.
>>
>> Thoughts? Ideas?? I know there is something in the startup that seems to
>> MAYBE be related to the fedora-domain vs rhel-domain settings in some of
>> the IPA python scripts -- or maybe not.  Just thought I would see if
>> anyone else is seeing something like this.
>>
>> ~J
> You are probably hitting:
> https://bugzilla.redhat.com/show_bug.cgi?id=1071969
>
> For me this resulted in symted error messages on bootup and slowed the
> boot to 15-20min. Applying the following patch corrected this:
> https://git.fedorahosted.org/cgit/initscripts.git/commit/?h=rhel7-branch&id=3deb3b3c177dd24b22cf912cd798aeaa7e35d30b
>
> I guess this is fixed in RHEL 7.1.
>
> Best regards
> Patrick
>



From dbischof at hrz.uni-kassel.de  Tue Dec 16 18:12:04 2014
From: dbischof at hrz.uni-kassel.de (dbischof at hrz.uni-kassel.de)
Date: Tue, 16 Dec 2014 19:12:04 +0100 (CET)
Subject: [Freeipa-users] 3.0.0-42 Replication issue after Centos6.5->6.6
 upgrade
In-Reply-To: <alpine.LSU.2.11.1412151011360.12534@fred>
References: <etPan.545c5626.7545e146.144@Drone-3.local>
	<545C602B.90802@redhat.com>
	<etPan.545c65b2.5bd062c2.144@Drone-3.local>
	<545D2B79.7000200@redhat.com>
	<alpine.LSU.2.11.1411181343060.15331@fred>
	<etPan.546b93a6.327b23c6.16f@Drone-5.appnovation.com>
	<546C599B.9090101@redhat.com> <546DBBB9.5030404@redhat.com>
	<alpine.LSU.2.11.1411201152330.18310@fred>
	<546DFF77.7090104@redhat.com>
	<alpine.LSU.2.11.1411211033510.1449@fred>
	<546F193B.4020602@redhat.com> <546F5EF0.2020608@redhat.com>
	<alpine.LSU.2.11.1411252014200.9549@fred> <5474FFC0.7030906@redhat.com>
	<alpine.LSU.2.11.1412151011360.12534@fred>
Message-ID: <alpine.LSU.2.11.1412161902310.20298@fred>

Hi,

On Mon, 15 Dec 2014, dbischof at hrz.uni-kassel.de wrote:

> On Tue, 25 Nov 2014, Rich Megginson wrote:
>> On 11/25/2014 12:32 PM, dbischof at hrz.uni-kassel.de wrote:
>>> 
>>> with the help of Thierry and Rich I managed to debug the running 
>>> ns-slapd on Server1 (see below). The failing attempt of decoding the 
>>> SASL data returns a not very fruitful "-1" (SASL_FAIL, "generic 
>>> failure").
>>> 
>>> Any ideas? Short summary:
>>> 
>>> Server1 = running IPA server
>>> Server2 = intended IPA replica
>>> 
>>> Both machines run the exact same, up-to-date version of CentOS 6.6. 
>>> However: I had to run "ipa-replica-install" _without_ the option 
>>> "--setup-ca" (didn't work, installation failed with some obscure Perl 
>>> error), so there's no ns-slapd instance running for PKI-IPA. May this 
>>> be related?
>> [...]
>> At this point, it's going to take more than a trivial amount of high 
>> latency back-and-forth on the mailling lists.  I think we have probably 
>> run out of log levels for you to try.  Please open a ticket against 
>> IPA. While this may turn out to be a bug in 389, at the moment it is 
>> only reproducible in your IPA environment.
>> [...]
>
> I've opened Ticket #4807
> https://fedorahosted.org/freeipa/ticket/4807
> on this issue.

problem resolved, increasing nsslapd-sasl-max-buffer-size to 2MB did it. I 
administer 2 very small installations, with ~20 users and ~10 hosts each. 
If this happens with installations like mine, the default for new 
installations should probably be raised in the next 3.0.0 update package.

I've closed the ticket.

Thank you for your support.


Mit freundlichen Gruessen/With best regards,

--Daniel.



From svm2k20 at gmail.com  Tue Dec 16 18:30:44 2014
From: svm2k20 at gmail.com (Shashi M)
Date: Tue, 16 Dec 2014 18:30:44 +0000
Subject: [Freeipa-users] Freeipa-users Digest, Vol 77, Issue 15
In-Reply-To: <mailman.9725.1417782402.15189.freeipa-users@redhat.com>
References: <mailman.9725.1417782402.15189.freeipa-users@redhat.com>
Message-ID: <CAEouxn9z2xsrXhdos0eVfPahC-k0eSdPtFVBOnXrEU1y4v_26A@mail.gmail.com>

On Fri, Dec 5, 2014 at 12:26 PM, <freeipa-users-request at redhat.com> wrote:
>
> Send Freeipa-users mailing list submissions to
>         freeipa-users at redhat.com
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://www.redhat.com/mailman/listinfo/freeipa-users
> or, via email, send a message with subject or body 'help' to
>         freeipa-users-request at redhat.com
>
> You can reach the person managing the list at
>         freeipa-users-owner at redhat.com
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Freeipa-users digest..."
>
>
> Today's Topics:
>
>    1. ad trust and default_domain_suffix (Nicolas Zin)
>    2. Re: ad trust and default_domain_suffix (Nicolas Zin)
>    3. Re: strange error - disconnecting a replica? (Martin Kosek)
>    4. Re: strange error - disconnecting a replica? (thierry bordaz)
>    5. Re: strange error - disconnecting a replica? (thierry bordaz)
>    6. Re: strange error - disconnecting a replica? (Martin Kosek)
>    7. Re: Cross-Realm authentification (Andreas Ladanyi)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 4 Dec 2014 12:49:36 -0500 (EST)
> From: Nicolas Zin <nicolas.zin at savoirfairelinux.com>
> To: freeipa-users at redhat.com
> Subject: [Freeipa-users] ad trust and default_domain_suffix
> Message-ID: <227542639.160677.1417715376443.JavaMail.root at mail>
> Content-Type: text/plain; charset=utf-8
>
> Hi,
>
> I have a IDM (v3.3) installed on a Redhat7.
> I have a IDM realm connected to an AD via trust relationship.
> In the IDM realm there are Redhat6 and Redhat5 clients.
>
>
> My client ask to be able to connect to the Linux machine with their AD
> without entering their domain (just username). On Redhat 6 there is an
> option for sssd (default_domain_suffix=)
> Seems to be exactly what I need, but I have a problem. If I use this
> option, I can indeed login with my AD username with domain name, but I
> cannot login with my Linux IDM username anymore, even if I use my fully
> qualified username at realm. i.e. In the middle of the PAM authentication it
> seems to fails (when ssh to the machine with ssh <server> -l admin@<realm>,
> I get Write failed: Broken pipe). If needed I can send more logs.
>
> I reproduce the problem in a more simple environment: just a Linux realm,
> and default_domain_suffix set to a inexistant domain, and again I cannot
> ssh to my server with my fully qualified username at realm
>
> Here is my sssd.conf:
> [domain/idm1]
> cache_credentials = True
> krb5_store_password_if_offline = True
> ipa_domain = idm1
> id_provider = ipa
> auth_provider = ipa
> access_provider = ipa
> ipa_hostname = dc.idm1
> chpass_provider = ipa
> ipa_server = dc.idm1
> ipa_server_mode = True
> ldap_tls_cacert = /etc/ipa/ca.crt
> [sssd]
> services = nss, pam, ssh
> config_file_version = 2
>
> domains = idm1
>
> default_domain_suffix=toto.com
> [nss]
>
> [pam]
>
> [sudo]
>
> [autofs]
>
> [ssh]
>
> [pac]
>
>
>
> Here is my krb5.conf:
> includedir /var/lib/sss/pubconf/krb5.include.d/
>
> [logging]
>  default = FILE:/var/log/krb5libs.log
>  kdc = FILE:/var/log/krb5kdc.log
>  admin_server = FILE:/var/log/kadmind.log
>
> [libdefaults]
>  default_realm = IDM1
>  dns_lookup_realm = false
>  dns_lookup_kdc = true
>  rdns = false
>  ticket_lifetime = 24h
>  forwardable = yes
>  default_ccache_name = KEYRING:persistent:%{uid}
>  ignore_acceptor_hostname = true
>
> [realms]
>  IDM1 = {
>   kdc = dc.idm1:88
>   master_kdc = dc.idm1:88
>   admin_server = dc.idm1:749
>   default_domain = idm1
>   pkinit_anchors = FILE:/etc/ipa/ca.crt
> }
>
> [domain_realm]
>  .idm1 = IDM1
>  idm1 = IDM1
>
> [dbmodules]
>   IDM1 = {
>     db_library = ipadb.so
>   }
>
>
>
> is there something to add to make it working?
>
>
>
>
> Site note: also with Redhat5 which is configured following ipa-advise
> sssd-before-1.9, the default_domain_suffix is not understood with sssd<1.9.
> Is there a way to connect to force RHEL5 to let my windows user connect
> without entering their domain. I don?t know if there is a way to tune the
> compatibility tree return by the ldap server for example.
>
> Or should I try to compile sssd 1.9 for RHEL5? (but I guess this is easier
> said than done) or it doesn?t worth it? (incompatibility with kerberos, or
> with the RHEL5 kernel?)
>
>
> Regards,
>
>
> Nicolas Zin
>
>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 4 Dec 2014 16:53:00 -0500 (EST)
> From: Nicolas Zin <nicolas.zin at savoirfairelinux.com>
> To: freeipa-users at redhat.com
> Subject: Re: [Freeipa-users] ad trust and default_domain_suffix
> Message-ID: <992955671.305465.1417729980028.JavaMail.root at mail>
> Content-Type: text/plain; charset=utf-8
>
> I answer to myself. (but my problem is not resolved)
>
> > ----- Mail original -----
> > De: "Nicolas Zin" <nicolas.zin at savoirfairelinux.com>
> > ?: freeipa-users at redhat.com
> > Envoy?: Jeudi 4 D?cembre 2014 18:49:36
> > Objet: [Freeipa-users] ad trust and default_domain_suffix
> >
> > Hi,
> >
> > I have a IDM (v3.3) installed on a Redhat7.
> > I have a IDM realm connected to an AD via trust relationship.
> > In the IDM realm there are Redhat6 and Redhat5 clients.
> >
> >
> > My client ask to be able to connect to the Linux machine with their AD
> without entering their domain (just username). On Redhat 6 there is an
> option for sssd (default_domain_suffix=)
> > Seems to be exactly what I need, but I have a problem. If I use this
> option, I can indeed login with my AD username with domain name, but I
> cannot login with my Linux IDM username anymore, even if I use my fully
> qualified username at realm. i.e. In the middle of the PAM authentication it
> seems to fails (when ssh to the machine with ssh <server> -l admin@<realm>,
> I get Write failed: Broken pipe). If needed I can send more logs.
> >
> > I reproduce the problem in a more simple environment: just a Linux
> realm, and default_domain_suffix set to a inexistant domain, and again I
> cannot ssh to my server with my fully qualified username at realm
>
> so when I try to do "ssh localhost -l admin at idm1" (idm is my domain name),
> in the /var/log/sssd/sssd_nss.log I find:
> ...
> (Wed Dec  3 22:44:43 2014) [sssd[nss]] [nss_cmd_getpwnam_search] (0x0100):
> Requesting info for [admin at idm1]
> (Wed Dec  3 22:44:43 2014) [sssd[nss]] [nss_cmd_getbynam] (0x0100):
> Requesting info for [admin] from [idm1]
> (Wed Dec  3 22:44:43 2014) [sssd[nss]] [nss_cmd_getpwnam_search] (0x0100):
> Requesting info for [admin at idm1]
> (Wed Dec  3 22:44:43 2014) [sssd[nss]] [nss_cmd_getbynam] (0x0100):
> Requesting info for [admin] from [idm1]
> (Wed Dec  3 22:44:43 2014) [sssd[nss]] [nss_cmd_getpwnam_search] (0x0100):
> Requesting info for [admin at idm1]
> (Wed Dec  3 22:44:43 2014) [sssd[nss]] [nss_cmd_getbynam] (0x0100):
> Requesting info for [admin] from [idm1]
> (Wed Dec  3 22:44:43 2014) [sssd[nss]] [nss_cmd_getpwnam_search] (0x0100):
> Requesting info for [admin at idm1]
> (Wed Dec  3 22:44:43 2014) [sssd[nss]] [nss_cmd_getbynam] (0x0100):
> Requesting info for [admin] from [idm1]
> (Wed Dec  3 22:44:43 2014) [sssd[nss]] [nss_cmd_getpwnam_search] (0x0100):
> Requesting info for [admin at idm1]
> (Wed Dec  3 22:44:43 2014) [sssd[nss]] [nss_cmd_getbynam_done] (0x0040):
> Invalid name received [admin]
>
>
> So it seems to be a problem with nss not able to find my user.
> Indeed, if I do a "getent passwd admin" it doesn't show anything, but if I
> do a "getent passwd admin at idm1" it works.
>
> I found a "workardound":
> getent passwd admin at idm1 >> /etc/passwd
>
>
> Now I can ssh to my server:
> ssh localhost -l admin at idm1
>
>
>
> Is it a bug? is there a better "workaround"?
>
>
> Regards,
>
>
>
> ------------------------------
>
> Hi,

Did you find any other workaround for this issue?
I am also having same issue. I am looking for migrating existing IPA to
full trust with AD, this might be not acceptable to my end users.

Anyone else has any workaround on using default_domain_suffix for AD users
but without using fully qualified name for IPA users?

I observed that if the IPA user is in sssd cache, id other command works
for IPA user but ssh without @ipadomain does not work in any case.

Regards,
Shashikant
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141216/e11bb1c0/attachment.htm>

From herbert.burnswell at gmail.com  Tue Dec 16 19:31:54 2014
From: herbert.burnswell at gmail.com (Herb Burnswell)
Date: Tue, 16 Dec 2014 11:31:54 -0800
Subject: [Freeipa-users] ldapsearch queries for audit
Message-ID: <CAOuzmw4h0SUaduyppTmTMmiLVyTDeS5kXZ659g=L6zQdV7a+VQ@mail.gmail.com>

All,

We are running the following versions on RHEL 6.6:

ipa-server.x86_64   3.0.0-42.el6
389-ds.noarch        1.2.2-1.el6

I'm not very experienced with the ldapsearch and would greatly appreciate
some guidance.  I'd like to run some ldapsearch's that will return access
information for specific hosts.  For example; I'd like to return what users
have access to 'host x' and what sudo rules are available to these users.

Any assistance is appreciated.

TIA,

Herb
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141216/de916afb/attachment.htm>

From CWhite at skytouchtechnology.com  Tue Dec 16 19:47:42 2014
From: CWhite at skytouchtechnology.com (Craig White)
Date: Tue, 16 Dec 2014 19:47:42 +0000
Subject: [Freeipa-users] ldapsearch queries for audit
In-Reply-To: <CAOuzmw4h0SUaduyppTmTMmiLVyTDeS5kXZ659g=L6zQdV7a+VQ@mail.gmail.com>
References: <CAOuzmw4h0SUaduyppTmTMmiLVyTDeS5kXZ659g=L6zQdV7a+VQ@mail.gmail.com>
Message-ID: <BLUPR08MB488BEA2077A5CC6BC9DEAEEB36C0@BLUPR08MB488.namprd08.prod.outlook.com>

From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Herb Burnswell
Sent: Tuesday, December 16, 2014 12:32 PM
To: freeipa-users at redhat.com
Subject: [Freeipa-users] ldapsearch queries for audit

All,

We are running the following versions on RHEL 6.6:

ipa-server.x86_64   3.0.0-42.el6
389-ds.noarch        1.2.2-1.el6


I'm not very experienced with the ldapsearch and would greatly appreciate some guidance.  I'd like to run some ldapsearch's that will return access information for specific hosts.  For example; I'd like to return what users have access to 'host x' and what sudo rules are available to these users.

Any assistance is appreciated.

TIA,

Herb
Herb, I am sure that some if not all of that can be derived via LDAP but I have found this info is much more easily returned via IPA commands.

ipa hostgroup-show $SOME_HOSTGROUP

Craig
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141216/216348e4/attachment.htm>

From herbert.burnswell at gmail.com  Tue Dec 16 21:29:33 2014
From: herbert.burnswell at gmail.com (Herb Burnswell)
Date: Tue, 16 Dec 2014 13:29:33 -0800
Subject: [Freeipa-users] ldapsearch queries for audit
In-Reply-To: <BLUPR08MB488BEA2077A5CC6BC9DEAEEB36C0@BLUPR08MB488.namprd08.prod.outlook.com>
References: <CAOuzmw4h0SUaduyppTmTMmiLVyTDeS5kXZ659g=L6zQdV7a+VQ@mail.gmail.com>
	<BLUPR08MB488BEA2077A5CC6BC9DEAEEB36C0@BLUPR08MB488.namprd08.prod.outlook.com>
Message-ID: <CAOuzmw4jmnnYZHMu1D51X0y=v1Fo0tgYmgpKdHF0Grz=UFwjaQ@mail.gmail.com>

Craig,

Thank you for the reply.  Running the ipa hostgroup-show does not appear to
provide specific information about individual users.  Also, ideally I'd
like to see if I can gather the actual sudo rules that one would see in an
/etc/sudoers file to the specific hosts.

I'll investigate if the IPA commands can provide more.

Thanks,

Herb

On Tue, Dec 16, 2014 at 11:47 AM, Craig White <CWhite at skytouchtechnology.com
> wrote:
>
>  *From:* freeipa-users-bounces at redhat.com [mailto:
> freeipa-users-bounces at redhat.com] *On Behalf Of *Herb Burnswell
> *Sent:* Tuesday, December 16, 2014 12:32 PM
> *To:* freeipa-users at redhat.com
> *Subject:* [Freeipa-users] ldapsearch queries for audit
>
>
>
> All,
>
>
>
> We are running the following versions on RHEL 6.6:
>
>
>
> ipa-server.x86_64   3.0.0-42.el6
>
> 389-ds.noarch        1.2.2-1.el6
>
>
>
>
>
> I'm not very experienced with the ldapsearch and would greatly appreciate
> some guidance.  I'd like to run some ldapsearch's that will return access
> information for specific hosts.  For example; I'd like to return what users
> have access to 'host x' and what sudo rules are available to these users.
>
>
>
> Any assistance is appreciated.
>
>
>
> TIA,
>
>
>
> Herb
>
> Herb, I am sure that some if not all of that can be derived via LDAP but I
> have found this info is much more easily returned via IPA commands.
>
>
>
> ipa hostgroup-show $SOME_HOSTGROUP
>
>
>
> Craig
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141216/e6d7fb1f/attachment.htm>

From dpal at redhat.com  Wed Dec 17 00:09:40 2014
From: dpal at redhat.com (Dmitri Pal)
Date: Tue, 16 Dec 2014 19:09:40 -0500
Subject: [Freeipa-users] Clients in multiple domains, any known issues?
In-Reply-To: <46719602280df4d57e509cdd798917bc.squirrel@webmail.aminor.no>
References: <46719602280df4d57e509cdd798917bc.squirrel@webmail.aminor.no>
Message-ID: <5490C9C4.7030302@redhat.com>

On 12/16/2014 02:24 AM, Eivind Olsen wrote:
> Hello.
>
> I have so far been running IPA on RHEL6, with a single domain (and a
> matching realm). I now have a use-case where it looks like I'll need to
> set up a new IPA realm, with the IPA servers in one DNS domain and the IPA
> clients in multiple (2-4) other domains.
> The servers will be running RHEL6 or RHEL7 with the bundled IPA.
> The clients are running mainly RHEL5 and RHEL6, and have hostnames that
> don't exist in DNS.

So how would be these hosts resolved?
If you want them to be integrated with IPA using SSSD they need to be 
resolvable by the server which would require some kind of DNS entry.

If you plan to use older tools on those clients like nss-pam-ldap I do 
not think there will be an issue but then you loose a lot of value of 
IPA/SSSD.

> Are there any known issues with this type of setup? I know, it sounds a
> bit hairy, but apart from that? :)
>
> Regards
> Eivind Olsen
>
>


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.



From dpal at redhat.com  Wed Dec 17 00:22:20 2014
From: dpal at redhat.com (Dmitri Pal)
Date: Tue, 16 Dec 2014 19:22:20 -0500
Subject: [Freeipa-users] ldapsearch queries for audit
In-Reply-To: <CAOuzmw4h0SUaduyppTmTMmiLVyTDeS5kXZ659g=L6zQdV7a+VQ@mail.gmail.com>
References: <CAOuzmw4h0SUaduyppTmTMmiLVyTDeS5kXZ659g=L6zQdV7a+VQ@mail.gmail.com>
Message-ID: <5490CCBC.5050307@redhat.com>

On 12/16/2014 02:31 PM, Herb Burnswell wrote:
> All,
>
> We are running the following versions on RHEL 6.6:
>
> ipa-server.x86_64   3.0.0-42.el6
> 389-ds.noarch        1.2.2-1.el6
>
> I'm not very experienced with the ldapsearch and would greatly 
> appreciate some guidance.  I'd like to run some ldapsearch's that will 
> return access information for specific hosts.  For example; I'd like 
> to return what users have access to 'host x' and what sudo rules are 
> available to these users.
>

This would be a pretty complex query.

For users you might want to explore HBAC test. That allows checking if a 
specific user has access to a host.
I do not think there is something reverse meaning which users can access 
a host.

There is an HBAC library used on the client or by the tool that helps to 
collect all the data and do the evaluation.
May be calling it or its bindings would be more helpful.

For sudo I think we need to have a similar tool that would resolve what 
commands a user can run on a given host.
I could not find a ticket. I thought there was one on the IPA side.

In the absence of these tools you would have to join several LDAP searches.

> Any assistance is appreciated.
>
> TIA,
>
> Herb
>
>
>


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141216/42698e01/attachment.htm>

From sbingram at gmail.com  Wed Dec 17 00:52:12 2014
From: sbingram at gmail.com (Stephen Ingram)
Date: Tue, 16 Dec 2014 16:52:12 -0800
Subject: [Freeipa-users] trust non-IPA certificate client
In-Reply-To: <CAPsaoBcxW+RXm_N_C_nYMbrsq82A4_qwQtqWjNO3mroy_wyc+A@mail.gmail.com>
References: <CAPsaoBcxW+RXm_N_C_nYMbrsq82A4_qwQtqWjNO3mroy_wyc+A@mail.gmail.com>
Message-ID: <CAPsaoBcS00DuccFGS7qd8hNwDx2sys0vW=gA51v1phnsWZUSYw@mail.gmail.com>

On Mon, Dec 15, 2014 at 6:40 PM, Stephen Ingram <sbingram at gmail.com> wrote:

> I have one client using a certificate issued by a third party provider
> such that any secure (TLS) LDAP queries are refused since the certificates
> were not issued by IPA. Since there are only a few clients with foreign
> certificates, can the CA simply be added to the NSS database used by the
> 389 directory server so IPA will establish a secure connection with them?
>

I should have added, "or do I have to somehow add the certificate to the
IPA directory?"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141216/a620b0e2/attachment.htm>

From manuel.lopes72 at gmail.com  Wed Dec 17 08:51:26 2014
From: manuel.lopes72 at gmail.com (Manuel Lopes)
Date: Wed, 17 Dec 2014 09:51:26 +0100
Subject: [Freeipa-users] Forest trust and AD child domain
In-Reply-To: <CAKFNJrvo6+AFbCVKJiHL8mYdg5NnHHz9pv4EUgqcey2CSsBDOA@mail.gmail.com>
References: <20141212093311.GU14057@localhost.localdomain>
	<CAKFNJrvBrvRJbxU-zsXhmsek8MZrZdz-b1p1O1MvfmUPv256vg@mail.gmail.com>
	<CAKFNJrsJvj8098k9vzScONO4endDE3LGuH1AzUY6_yDRS3MT1Q@mail.gmail.com>
	<20141212203234.GA6877@localhost.localdomain>
	<CAKFNJrsS1-h8pu+UoWWCwAUu3GA8D8XtGva7J3in7omSGCjiUw@mail.gmail.com>
	<CAKFNJrsRRZFQmb+4892WPtx2d9jcJVfZeW1LQJmWOJKK7mvsaw@mail.gmail.com>
	<20141215144258.GA2868@localhost.localdomain>
	<CAKFNJruhr6iB6v6qVBqt84oN8hsZRewuhH_YmBBXHc0A7CMUCA@mail.gmail.com>
	<20141215160355.GE2868@localhost.localdomain>
	<CAKFNJrsDdL1ANRTBxder_eeCWJPtO6e_x643gMvYZQS7XLWaDw@mail.gmail.com>
	<20141215173447.GG2868@localhost.localdomain>
	<CAKFNJrvo6+AFbCVKJiHL8mYdg5NnHHz9pv4EUgqcey2CSsBDOA@mail.gmail.com>
Message-ID: <CAKFNJrsM5WYJEUWEAWAMd6opJ1fw+Bp+90v21PYn7QhW3-BbMQ@mail.gmail.com>

Thanks Sumit

This is indeed a bug. We encounter this issue when we try to add the group
"domain users" or "domain admin"  but it's working fine with a group that
we have created as "users group".
And only on the acme.windows.com child domain and not the windows.com domain

Regards

2014-12-15 21:35 GMT+01:00 Manuel Lopes <manuel.lopes72 at gmail.com>:
>
> Hi,
>
> Attached, the good log.
>
> We are running sssd-1.11.2-68.el7_0.6 on RHEL 7.
> ipa-server-3.3.3-28.el7_0.3
>
> Regards
>
> 2014-12-15 18:34 GMT+01:00 Sumit Bose <sbose at redhat.com>:
>>
>> On Mon, Dec 15, 2014 at 05:38:05PM +0100, Manuel Lopes wrote:
>> > Attached the sssd_linux.com.log file
>> >
>> > Regards
>>
>> Thank you, there is no request logged in the logs, did you run ipa
>> group-add-member after restarting SSSD? Nevertheless I think I know what
>> is happening, you hit an issue which should be fixed in SSSD 1.12.2,
>> which version of SSSD are you running on which platform?
>>
>> bye,
>> Sumit
>>
>> >
>> > 2014-12-15 17:03 GMT+01:00 Sumit Bose <sbose at redhat.com>:
>> > >
>> > > On Mon, Dec 15, 2014 at 04:39:29PM +0100, Manuel Lopes wrote:
>> > > > The file sssd_linux.com.log is empty.
>> > >
>> > > please add
>> > >
>> > > debug_level = 10
>> > >
>> > > to the [domain/...] section in sssd.conf to enable logging for this
>> part
>> > > of SSSD.
>> > >
>> > > bye,
>> > > Sumit
>> > > >
>> > > >
>> > > >
>> > > > 2014-12-15 15:42 GMT+01:00 Sumit Bose <sbose at redhat.com>:
>> > > > >
>> > > > > On Sat, Dec 13, 2014 at 02:13:30PM +0100, Manuel Lopes wrote:
>> > > > > > Hi,
>> > > > > >
>> > > > > > As explained in the previous email, the getent is successful.
>> > > > > >
>> > > > > >
>> > > > > > *[root at support1 ~]# getent group 'ACME\Domain Users' domain
>> > > > > > users at acme.windows.com:*:**
>> 365600513:administrator at acme.windows.com
>> > > > > > <365600513%3Aadministrator at acme.windows.com>*
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > > > In fact, our real problem is not the ?wbinfo ?n? but the
>> following
>> > > > > command:
>> > > > > >
>> > > > > > *[root at support1 sssd]# ipa group-add-member ad_users_external
>> > > --external
>> > > > > > "ACME\Domain Users"*
>> > > > > >
>> > > > > > *[member user]:*
>> > > > > >
>> > > > > > *[member group]:*
>> > > > > >
>> > > > > > *  Group name: ad_users_external*
>> > > > > >
>> > > > > > *  Description: AD users external map*
>> > > > > >
>> > > > > > *  External member: *
>> > > > > >
>> > > > > > *  Member of groups: ad_users*
>> > > > > >
>> > > > > > *  Failed members:*
>> > > > > >
>> > > > > > *    member user:*
>> > > > > >
>> > > > > > *    member group: ACME\Domain Users: Cannot find specified
>> domain or
>> > > > > > server name*
>> > > > > >
>> > > > > > *-------------------------*
>> > > > > >
>> > > > > > *Number of members added 0*
>> > > > > >
>> > > > > > *-------------------------*
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > > > We cannot add ACME?s domain users in the ad_users_external.
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > > > I attached the sssd logs.
>> > > > >
>> > > > > Can you send the corresponding domain log file as well, it should
>> be
>> > > > > called sssd_linux.com.log or similar.
>> > > > >
>> > > > > bye,
>> > > > > Sumit
>> > > > >
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > > > Regards
>> > > > > >
>> > > > > > 2014-12-12 21:51 GMT+01:00 Manuel Lopes <
>> manuel.lopes72 at gmail.com>:
>> > > > > > >
>> > > > > > > OK.
>> > > > > > >
>> > > > > > > Command successful
>> > > > > > > [root at support1 ~]# getent group  'ACME\Domain Users'
>> > > > > > > domain users at acme.windows.com:*:
>> > > > > 365600513:administrator at acme.windows.com
>> > > > > > >
>> > > > > > > Log files attached
>> > > > > > >
>> > > > > > > Thanks
>> > > > > > >
>> > > > > > > 2014-12-12 21:32 GMT+01:00 Sumit Bose <sbose at redhat.com>:
>> > > > > > >>
>> > > > > > >> On Fri, Dec 12, 2014 at 08:41:27PM +0100, Manuel Lopes wrote:
>> > > > > > >> > [root at support1 ~]# ipa idrange-find
>> > > > > > >> > ----------------
>> > > > > > >> > 3 ranges matched
>> > > > > > >> > ----------------
>> > > > > > >> > Range name: LINUX.COM_id_range
>> > > > > > >> > First Posix ID of the range: 1066000000
>> > > > > > >> > Number of IDs in the range: 200000
>> > > > > > >> > First RID of the corresponding RID range: 1000
>> > > > > > >> > First RID of the secondary RID range: 100000000
>> > > > > > >> > Range type: local domain range
>> > > > > > >> >
>> > > > > > >> > Range name: WINDOWS.COM_id_range
>> > > > > > >> > First Posix ID of the range: 730200000
>> > > > > > >> > Number of IDs in the range: 200000
>> > > > > > >> > First RID of the corresponding RID range: 0
>> > > > > > >> > Domain SID of the trusted domain:
>> > > > > > >> S-1-5-21-1701591335-3855227394-3044674468
>> > > > > > >> > Range type: Active Directory domain range
>> > > > > > >> >
>> > > > > > >> > Range name: ACME.WINDOWS.COM_id_range
>> > > > > > >> > First Posix ID of the range: 365600000
>> > > > > > >> > Number of IDs in the range: 200000
>> > > > > > >> > First RID of the corresponding RID range: 0
>> > > > > > >> > Domain SID of the trusted domain:
>> > > > > > >> S-1-5-21-1215373191-1991333051-3772904882
>> > > > > > >> > Range type: Active Directory domain range
>> > > > > > >> > ----------------------------
>> > > > > > >> > Number of entries returned 3
>> > > > > > >> > ----------------------------
>> > > > > > >> >
>> > > > > > >> >
>> > > > > > >> > As we can see in the ouput of the command, the range type
>> is "ad
>> > > > > POSIX
>> > > > > > >> > attributes".
>> > > > > > >>
>> > > > > > >> no, it's only 'Active Directory domain range', this is good
>> > > because
>> > > > > with
>> > > > > > >> this type we generate the UIDs and GIDs algorithmically.
>> > > > > > >>
>> > > > > > >> > In our case, the gidNumber is not set in the "ACME\Domain
>> > > Users" AD
>> > > > > > >> group,
>> > > > > > >> > nor in the " WINDOWS\Domain Users".
>> > > > > > >> > With a gidNumber attribute value, the 'wbinfo -n
>> "ACME\Domain
>> > > > > Users"'
>> > > > > > >> still
>> > > > > > >> > command fails.
>> > > > > > >>
>> > > > > > >> no need to set the ID attributes in AD. But I should have
>> > > mentioned
>> > > > > > >> that wbinfo is quite useless nowadays with FreeIPA because
>> > > winbind is
>> > > > > > >> only used to assure some types of communication with AD. All
>> user
>> > > and
>> > > > > > >> group lookups and IP-mapping is done by SSSD. Please try
>> > > > > > >>
>> > > > > > >> getent group 'ACME\Domain Users'
>> > > > > > >>
>> > > > > > >>
>> > > > > > >> and send the sssd_nss.log and sssd_example.com.log files.
>> > > > > > >>
>> > > > > > >> bye,
>> > > > > > >> Sumit
>> > > > > > >>
>> > > > > > >> >
>> > > > > > >> > Thanks
>> > > > > > >> >
>> > > > > > >> > 2014-12-12 19:51 GMT+01:00 Manuel Lopes <
>> > > manuel.lopes72 at gmail.com>:
>> > > > > > >> > >
>> > > > > > >> > > [root at support1 ~]# ipa idrange-find
>> > > > > > >> > > ----------------
>> > > > > > >> > > 3 ranges matched
>> > > > > > >> > > ----------------
>> > > > > > >> > >   Range name: LINUX.COM_id_range
>> > > > > > >> > >   First Posix ID of the range: 1066000000
>> > > > > > >> > >   Number of IDs in the range: 200000
>> > > > > > >> > >   First RID of the corresponding RID range: 1000
>> > > > > > >> > >   First RID of the secondary RID range: 100000000
>> > > > > > >> > >   Range type: local domain range
>> > > > > > >> > >
>> > > > > > >> > >   Range name: WINDOWS.COM_id_range
>> > > > > > >> > >   First Posix ID of the range: 730200000
>> > > > > > >> > >   Number of IDs in the range: 200000
>> > > > > > >> > >   First RID of the corresponding RID range: 0
>> > > > > > >> > >   Domain SID of the trusted domain:
>> > > > > > >> > > S-1-5-21-1701591335-3855227394-3044674468
>> > > > > > >> > >   Range type: Active Directory domain range
>> > > > > > >> > >
>> > > > > > >> > >   Range name: ACME.WINDOWS.COM_id_range
>> > > > > > >> > >   First Posix ID of the range: 365600000
>> > > > > > >> > >   Number of IDs in the range: 200000
>> > > > > > >> > >   First RID of the corresponding RID range: 0
>> > > > > > >> > >   Domain SID of the trusted domain:
>> > > > > > >> > > S-1-5-21-1215373191-1991333051-3772904882
>> > > > > > >> > >   Range type: Active Directory domain range
>> > > > > > >> > > ----------------------------
>> > > > > > >> > > Number of entries returned 3
>> > > > > > >> > > ----------------------------
>> > > > > > >> > >
>> > > > > > >> > >
>> > > > > > >> > > As we can see in the ouput of the command, the range
>> type is
>> > > "ad
>> > > > > POSIX
>> > > > > > >> > > attributes".
>> > > > > > >> > > In our case, the gidNumber is not set in the "ACME\Domain
>> > > Users"
>> > > > > AD
>> > > > > > >> group,
>> > > > > > >> > > nor in the " WINDOWS\Domain Users".
>> > > > > > >> > > With a gidNumber attribute value, the 'wbinfo -n
>> "ACME\Domain
>> > > > > Users"'
>> > > > > > >> > > still command fails.
>> > > > > > >> > >
>> > > > > > >> > > Thanks
>> > > > > > >> > >
>> > > > > > >> > >
>> > > > > > >> > > 2014-12-12 10:33 GMT+01:00 Sumit Bose <sbose at redhat.com
>> >:
>> > > > > > >> > >>
>> > > > > > >> > >> On Fri, Dec 12, 2014 at 02:06:05AM +0100, Manuel Lopes
>> wrote:
>> > > > > > >> > >> > Hi Sumit,
>> > > > > > >> > >> >
>> > > > > > >> > >> > Thank you very much for the prompt reply
>> > > > > > >> > >> >
>> > > > > > >> > >> > [root at support1 ~]# ipa trustdomain-find windows.com
>> > > > > > >> > >> >   Domain name: windows.com
>> > > > > > >> > >> >   Domain NetBIOS name: WINDOWS
>> > > > > > >> > >> >   Domain Security Identifier:
>> > > > > > >> S-1-5-21-1701591335-3855227394-3044674468
>> > > > > > >> > >> >   Domain enabled: True
>> > > > > > >> > >> >
>> > > > > > >> > >> >   Domain name: acme.windows.com
>> > > > > > >> > >> >   Domain NetBIOS name: ACME
>> > > > > > >> > >> >   Domain Security Identifier:
>> > > > > > >> S-1-5-21-1215373191-1991333051-3772904882
>> > > > > > >> > >> >   Domain enabled: True
>> > > > > > >> > >> > ----------------------------
>> > > > > > >> > >> > Number of entries returned 2
>> > > > > > >> > >> > ----------------------------
>> > > > > > >> > >>
>> > > > > > >> > >> ok, so ACME was discovered successful, can you check
>> next the
>> > > > > output
>> > > > > > >> of
>> > > > > > >> > >>
>> > > > > > >> > >> ipa idrange-find
>> > > > > > >> > >>
>> > > > > > >> > >> The important attribute is the 'Range type' for the AD
>> > > domains.
>> > > > > If
>> > > > > > >> it is
>> > > > > > >> > >> 'Active Directory trust range with POSIX attributes' it
>> is
>> > > > > expected
>> > > > > > >> that
>> > > > > > >> > >> users and groups in the AD forest have the POSIX UID
>> and GID
>> > > > > > >> attributes
>> > > > > > >> > >> set and only those users and groups will be available
>> in the
>> > > IPA
>> > > > > > >> domain.
>> > > > > > >> > >> In this case please check if 'ACME\Domain Users' have
>> the GID
>> > > > > > >> attribute
>> > > > > > >> > >> set.
>> > > > > > >> > >>
>> > > > > > >> > >> If this does not help (please mind the negative cache of
>> > > SSSD)
>> > > > > please
>> > > > > > >> > >> send the SSSD logs in /var/log/sssd on the IPA server.
>> You
>> > > might
>> > > > > > >> need to
>> > > > > > >> > >> enable logging in sssd.conf by setting 'debug_level =
>> 10' in
>> > > the
>> > > > > > >> > >> [domain/..] and [nss] section of sssd.conf.
>> > > > > > >> > >>
>> > > > > > >> > >> bye,
>> > > > > > >> > >> Sumit
>> > > > > > >> > >>
>> > > > > > >> > >> >
>> > > > > > >> > >> > [root at support1 ~]# ipa trust-fetch-domains
>> windows.com
>> > > > > > >> > >> > -------------------------------
>> > > > > > >> > >> > No new trust domains were found
>> > > > > > >> > >> > -------------------------------
>> > > > > > >> > >> > ----------------------------
>> > > > > > >> > >> > Number of entries returned 0
>> > > > > > >> > >> > ----------------------------
>> > > > > > >> > >> >
>> > > > > > >> > >> > Regards
>> > > > > > >> > >> > Le 11 d?c. 2014 20:08, "Sumit Bose" <sbose at redhat.com
>> > > > > > >> > >> > <javascript:_e(%7B%7D,'cvml','sbose at redhat.com');>> a
>> > > ?crit :
>> > > > > > >> > >> >
>> > > > > > >> > >> > > On Thu, Dec 11, 2014 at 06:45:49PM +0100, Manuel
>> Lopes
>> > > wrote:
>> > > > > > >> > >> > > >  Hello,
>> > > > > > >> > >> > > >
>> > > > > > >> > >> > > >
>> > > > > > >> > >> > > > We have been following the AD integration guide
>> for
>> > > IPAv3:
>> > > > > > >> > >> > > >
>> http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup
>> > > > > > >> > >> > > >
>> > > > > > >> > >> > > >
>> > > > > > >> > >> > > >
>> > > > > > >> > >> > > > Our setup is:
>> > > > > > >> > >> > > >
>> > > > > > >> > >> > > > ? 2 domain controllers with Windows 2008 R2 AD DC
>> ->
>> > > > > > >> windows.com
>> > > > > > >> > >> > > > <http://example.com/> as Forest Root Domain and
>> > > > > > >> acme.windows.com
>> > > > > > >> > >> > > > <http://acme.example.com/> as transitive child
>> domain
>> > > > > > >> > >> > > >
>> > > > > > >> > >> > > > ? RHEL7 as IPA server with domain: linux.com
>> > > > > > >> > >> > > > <http://linux.acme.example.com/>
>> > > > > > >> > >> > > >
>> > > > > > >> > >> > > >
>> > > > > > >> > >> > > >
>> > > > > > >> > >> > > > We have established a forest trust between
>> windows.com
>> > > and
>> > > > > > >> > >> linux.com and
>> > > > > > >> > >> > > > everything seems OK from an IPA perspective.
>> > > > > > >> > >> > > >
>> > > > > > >> > >> > > >
>> > > > > > >> > >> > > >
>> > > > > > >> > >> > > > We can work with Kerberos tickets without any
>> issue
>> > > from
>> > > > > > >> ?windows?
>> > > > > > >> > >> domain
>> > > > > > >> > >> > > > or his child domain ?acme?. (kinit, kvno?)
>> > > > > > >> > >> > > >
>> > > > > > >> > >> > > >
>> > > > > > >> > >> > > >
>> > > > > > >> > >> > > > When we use samba tools, the following command is
>> > > working
>> > > > > fine.
>> > > > > > >> > >> > > >
>> > > > > > >> > >> > > > *[root at support1 ]# wbinfo -n 'WINDOWS\Domain
>> Admins'*
>> > > > > > >> > >> > > >
>> > > > > > >> > >> > > > *S-1-5-21-1701591335-3855227394-3044674468-512
>> > > > > SID_DOM_GROUP
>> > > > > > >> (2)*
>> > > > > > >> > >> > > >
>> > > > > > >> > >> > > >
>> > > > > > >> > >> > > >
>> > > > > > >> > >> > > > But, the same command against the acme domain
>> returns
>> > > an
>> > > > > error.
>> > > > > > >> > >> > > >
>> > > > > > >> > >> > > > *[root at support1 ]# wbinfo -n 'ACME\Domain
>> Admins'*
>> > > > > > >> > >> > > >
>> > > > > > >> > >> > > > *failed to call wbcLookupName:
>> > > WBC_ERR_DOMAIN_NOT_FOUND*
>> > > > > > >> > >> > > >
>> > > > > > >> > >> > > > *Could not lookup name ACME\Domain Admins*
>> > > > > > >> > >> > > >
>> > > > > > >> > >> > > >
>> > > > > > >> > >> > > >
>> > > > > > >> > >> > > > Same problem with the following command:
>> > > > > > >> > >> > > >
>> > > > > > >> > >> > > > *[root at support1]# ipa group-add-member
>> > > ad_users_external
>> > > > > > >> --external
>> > > > > > >> > >> > > > "ACME\Domain Users"*
>> > > > > > >> > >> > > >
>> > > > > > >> > >> > > > *[member user]:*
>> > > > > > >> > >> > > >
>> > > > > > >> > >> > > > *[member group]:*
>> > > > > > >> > >> > > >
>> > > > > > >> > >> > > > *  Group name: ad_users_external*
>> > > > > > >> > >> > > >
>> > > > > > >> > >> > > > *  Description: AD users external map*
>> > > > > > >> > >> > > >
>> > > > > > >> > >> > > > *  External member: *
>> > > > > > >> > >> > > >
>> > > > > > >> > >> > > > *  Member of groups: ad_users*
>> > > > > > >> > >> > > >
>> > > > > > >> > >> > > > *  Failed members:*
>> > > > > > >> > >> > > >
>> > > > > > >> > >> > > > *    member user:*
>> > > > > > >> > >> > > >
>> > > > > > >> > >> > > > *    member group: ACME\Domain Users: Cannot find
>> > > specified
>> > > > > > >> domain
>> > > > > > >> > >> or
>> > > > > > >> > >> > > > server name*
>> > > > > > >> > >> > > >
>> > > > > > >> > >> > > > *-------------------------*
>> > > > > > >> > >> > > >
>> > > > > > >> > >> > > > *Number of members added 0*
>> > > > > > >> > >> > > >
>> > > > > > >> > >> > > >
>> > > > > > >> > >> > > >
>> > > > > > >> > >> > > >
>> > > > > > >> > >> > > >
>> > > > > > >> > >> > > > Any help would be appreciated
>> > > > > > >> > >> > >
>> > > > > > >> > >> > > Does
>> > > > > > >> > >> > >
>> > > > > > >> > >> > > ipa trustdomain-find windows.com
>> > > > > > >> > >> > >
>> > > > > > >> > >> > > show acme.windows.com as well ?
>> > > > > > >> > >> > >
>> > > > > > >> > >> > > Does
>> > > > > > >> > >> > >
>> > > > > > >> > >> > > ipa trust-fetch-domains ad.devel
>> > > > > > >> > >> > >
>> > > > > > >> > >> > > help to retrieve the child domain?
>> > > > > > >> > >> > >
>> > > > > > >> > >> > > Please note that if acme.windows.com now shows up
>> you
>> > > might
>> > > > > > >> have to
>> > > > > > >> > >> wait
>> > > > > > >> > >> > > 1-2 minutes until SSSD's negative caches are
>> flushed and
>> > > the
>> > > > > new
>> > > > > > >> > >> domains
>> > > > > > >> > >> > > is discovered by SSSD, as an alternative you can
>> just
>> > > restart
>> > > > > > >> SSSD.
>> > > > > > >> > >> > >
>> > > > > > >> > >> > > HTH
>> > > > > > >> > >> > >
>> > > > > > >> > >> > > bye,
>> > > > > > >> > >> > > Sumit
>> > > > > > >> > >> > >
>> > > > > > >> > >> > > >
>> > > > > > >> > >> > > >
>> > > > > > >> > >> > > >
>> > > > > > >> > >> > > > Regards
>> > > > > > >> > >> > >
>> > > > > > >> > >> > > > --
>> > > > > > >> > >> > > > 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
>> > > > > > >> > >>
>> > > > > > >> > >> --
>> > > > > > >> > >> 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
>> > > > > > >> > >>
>> > > > > > >> > >
>> > > > > > >>
>> > > > > > >>
>> > > > > > >>
>> > > > > > >>
>> > > > >
>> > > > >
>> > > > >
>> > > > >
>> > >
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141217/270074e0/attachment.htm>

From herbert.burnswell at gmail.com  Wed Dec 17 18:05:49 2014
From: herbert.burnswell at gmail.com (Herb Burnswell)
Date: Wed, 17 Dec 2014 10:05:49 -0800
Subject: [Freeipa-users] ldapsearch queries for audit
In-Reply-To: <CAOuzmw4h0SUaduyppTmTMmiLVyTDeS5kXZ659g=L6zQdV7a+VQ@mail.gmail.com>
References: <CAOuzmw4h0SUaduyppTmTMmiLVyTDeS5kXZ659g=L6zQdV7a+VQ@mail.gmail.com>
Message-ID: <CAOuzmw6L+oCspA7G+x9jrzQSpnr=gxjPHPRJJMEH8uVgSbBFtw@mail.gmail.com>

Dimitry,

Thank you for your response.  I don't necessarily need to do everything in
a single query.  I'm just interested in understanding how to output the
information I need and I can adjust the queries accordingly.  I.E. where is
the information saved: cn=sudoers, where sudo info is saved, etc.

For example; Does anyone know how I can do an ldapsearch to output all the
sudo rules in the format we would see in /etc/sudoers file?  I have to
imagine that the rules are just saved in the database to allow for sudo on
the local systems to read.

Thanks,

Herb

On Tue, Dec 16, 2014 at 11:31 AM, Herb Burnswell <
herbert.burnswell at gmail.com> wrote:
>
> All,
>
> We are running the following versions on RHEL 6.6:
>
> ipa-server.x86_64   3.0.0-42.el6
> 389-ds.noarch        1.2.2-1.el6
>
> I'm not very experienced with the ldapsearch and would greatly appreciate
> some guidance.  I'd like to run some ldapsearch's that will return access
> information for specific hosts.  For example; I'd like to return what users
> have access to 'host x' and what sudo rules are available to these users.
>
> Any assistance is appreciated.
>
> TIA,
>
> Herb
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141217/0931c631/attachment.htm>

From dpal at redhat.com  Wed Dec 17 18:22:58 2014
From: dpal at redhat.com (Dmitri Pal)
Date: Wed, 17 Dec 2014 13:22:58 -0500
Subject: [Freeipa-users] ldapsearch queries for audit
In-Reply-To: <CAOuzmw6L+oCspA7G+x9jrzQSpnr=gxjPHPRJJMEH8uVgSbBFtw@mail.gmail.com>
References: <CAOuzmw4h0SUaduyppTmTMmiLVyTDeS5kXZ659g=L6zQdV7a+VQ@mail.gmail.com>
	<CAOuzmw6L+oCspA7G+x9jrzQSpnr=gxjPHPRJJMEH8uVgSbBFtw@mail.gmail.com>
Message-ID: <5491CA02.7030404@redhat.com>

On 12/17/2014 01:05 PM, Herb Burnswell wrote:
> Dimitry,
>
> Thank you for your response.  I don't necessarily need to do 
> everything in a single query.  I'm just interested in understanding 
> how to output the information I need and I can adjust the queries 
> accordingly.  I.E. where is the information saved: cn=sudoers, where 
> sudo info is saved, etc.
>
> For example; Does anyone know how I can do an ldapsearch to output all 
> the sudo rules in the format we would see in /etc/sudoers file?  I 
> have to imagine that the rules are just saved in the database to allow 
> for sudo on the local systems to read.

Hi,

There is internal schema and external schema. The external one is 
visible via ou=sudoers,...


The overall design of SUDO support is here:
http://www.freeipa.org/page/FreeIPAv2:SUDO_integration_plans
The schema design is here: 
http://www.freeipa.org/page/FreeIPAv2:SUDO_Schema_Design


Slides
http://www.freeipa.org/images/7/77/Freeipa30_SSSD_SUDO_Integration.pdf


>
> Thanks,
>
> Herb
>
> On Tue, Dec 16, 2014 at 11:31 AM, Herb Burnswell 
> <herbert.burnswell at gmail.com <mailto:herbert.burnswell at gmail.com>> wrote:
>
>     All,
>
>     We are running the following versions on RHEL 6.6:
>
>     ipa-server.x86_64   3.0.0-42.el6
>     389-ds.noarch        1.2.2-1.el6
>
>     I'm not very experienced with the ldapsearch and would greatly
>     appreciate some guidance.  I'd like to run some ldapsearch's that
>     will return access information for specific hosts.  For example;
>     I'd like to return what users have access to 'host x' and what
>     sudo rules are available to these users.
>
>     Any assistance is appreciated.
>
>     TIA,
>
>     Herb
>
>
>


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141217/ab890a0e/attachment.htm>

From janellenicole80 at gmail.com  Thu Dec 18 16:49:37 2014
From: janellenicole80 at gmail.com (Janelle)
Date: Thu, 18 Dec 2014 08:49:37 -0800
Subject: [Freeipa-users] dirsrv password incorrect on replicas?
Message-ID: <549305A1.6050806@gmail.com>

Good morning/evening All,

So, another strange thing I see with 4.1.2 running on FC21 (server).  On 
some replicas if I attempt to modify the 389-ds backend, I get 
credential errors.  Even ldapsearch fails - which as me baffled.  I am 
trying to tune the servers but this has me confused as to what might 
cause something like this and where to start looking for a solution?

Here is the interesting part - when the server was intially replicated, 
I was able to make changes to 389-ds, but after a few days, credentials 
now show errors:

ldapsearch -x -LLL -D "cn=directory manager"  -b "cn=monitor" 
"(objectclass=*)" -W
Enter LDAP Password:
ldap_bind: Invalid credentials (49)

Thoughts?
~J



From rmeggins at redhat.com  Thu Dec 18 18:28:52 2014
From: rmeggins at redhat.com (Rich Megginson)
Date: Thu, 18 Dec 2014 11:28:52 -0700
Subject: [Freeipa-users] dirsrv password incorrect on replicas?
In-Reply-To: <549305A1.6050806@gmail.com>
References: <549305A1.6050806@gmail.com>
Message-ID: <54931CE4.60602@redhat.com>

On 12/18/2014 09:49 AM, Janelle wrote:
> Good morning/evening All,
>
> So, another strange thing I see with 4.1.2 running on FC21 (server).  
> On some replicas if I attempt to modify the 389-ds backend, I get 
> credential errors.  Even ldapsearch fails - which as me baffled.  I am 
> trying to tune the servers but this has me confused as to what might 
> cause something like this and where to start looking for a solution?
>
> Here is the interesting part - when the server was intially 
> replicated, I was able to make changes to 389-ds, but after a few 
> days, credentials now show errors:
>
> ldapsearch -x -LLL -D "cn=directory manager"  -b "cn=monitor" 
> "(objectclass=*)" -W
> Enter LDAP Password:
> ldap_bind: Invalid credentials (49)

This doesn't make any sense.  Directory manager passwords are not 
replicated, they are local to each machine.  Directory manager passwords 
do not expire, and the error message is definitely "incorrect password" 
not "password expired".  There are no internal processes that touch 
directory manager or its password (unless there is something in ipa but 
I doubt it).  So I have no idea how "all of a sudden" directory manager 
password stops working.

You can't recover it, you can only reset it.
http://www.port389.org/docs/389ds/howto/howto-resetdirmgrpassword.html

>
> Thoughts?
> ~J
>



From janellenicole80 at gmail.com  Thu Dec 18 18:59:48 2014
From: janellenicole80 at gmail.com (Janelle)
Date: Thu, 18 Dec 2014 10:59:48 -0800
Subject: [Freeipa-users] dirsrv password incorrect on replicas?
In-Reply-To: <54931CE4.60602@redhat.com>
References: <549305A1.6050806@gmail.com> <54931CE4.60602@redhat.com>
Message-ID: <54932424.8020001@gmail.com>

I am looking at the 2 entries in dse.ldif - and indeed they are 
different.  If I replace the one in question with the one from the 
working system, it works again.

I did find - replica was created on Dec 11 at noon -- and the dse.ldif 
file CHANGED a day later?!?  Going to have OSSEC monitor the folders for 
changes in files to see what the heck is going on and WHAT changed it 
and if it happens again.

thanks for the help
~J


On 12/18/14 10:28 AM, Rich Megginson wrote:
> On 12/18/2014 09:49 AM, Janelle wrote:
>> Good morning/evening All,
>>
>> So, another strange thing I see with 4.1.2 running on FC21 (server).  
>> On some replicas if I attempt to modify the 389-ds backend, I get 
>> credential errors.  Even ldapsearch fails - which as me baffled.  I 
>> am trying to tune the servers but this has me confused as to what 
>> might cause something like this and where to start looking for a 
>> solution?
>>
>> Here is the interesting part - when the server was intially 
>> replicated, I was able to make changes to 389-ds, but after a few 
>> days, credentials now show errors:
>>
>> ldapsearch -x -LLL -D "cn=directory manager"  -b "cn=monitor" 
>> "(objectclass=*)" -W
>> Enter LDAP Password:
>> ldap_bind: Invalid credentials (49)
>
> This doesn't make any sense.  Directory manager passwords are not 
> replicated, they are local to each machine.  Directory manager 
> passwords do not expire, and the error message is definitely 
> "incorrect password" not "password expired".  There are no internal 
> processes that touch directory manager or its password (unless there 
> is something in ipa but I doubt it).  So I have no idea how "all of a 
> sudden" directory manager password stops working.
>
> You can't recover it, you can only reset it.
> http://www.port389.org/docs/389ds/howto/howto-resetdirmgrpassword.html
>
>>
>> Thoughts?
>> ~J
>>
>



From rmeggins at redhat.com  Thu Dec 18 19:16:44 2014
From: rmeggins at redhat.com (Rich Megginson)
Date: Thu, 18 Dec 2014 12:16:44 -0700
Subject: [Freeipa-users] dirsrv password incorrect on replicas?
In-Reply-To: <54932424.8020001@gmail.com>
References: <549305A1.6050806@gmail.com> <54931CE4.60602@redhat.com>
	<54932424.8020001@gmail.com>
Message-ID: <5493281C.5030903@redhat.com>

On 12/18/2014 11:59 AM, Janelle wrote:
> I am looking at the 2 entries in dse.ldif - and indeed they are 
> different.  If I replace the one in question with the one from the 
> working system, it works again.

I'm assuming by "entry" you are referring to nsslapd-rootpw in cn=config.

>
> I did find - replica was created on Dec 11 at noon -- and the dse.ldif 
> file CHANGED a day later?!?

The dse.ldif file changes all the time - unique id generator state, csn 
generator state, replication state, etc. etc.

BUT - nsslapd-rootpw SHOULD NOT CHANGE

> Going to have OSSEC monitor the folders for changes in files to see 
> what the heck is going on and WHAT changed it and if it happens again.
>
> thanks for the help
> ~J
>
>
> On 12/18/14 10:28 AM, Rich Megginson wrote:
>> On 12/18/2014 09:49 AM, Janelle wrote:
>>> Good morning/evening All,
>>>
>>> So, another strange thing I see with 4.1.2 running on FC21 
>>> (server).  On some replicas if I attempt to modify the 389-ds 
>>> backend, I get credential errors.  Even ldapsearch fails - which as 
>>> me baffled.  I am trying to tune the servers but this has me 
>>> confused as to what might cause something like this and where to 
>>> start looking for a solution?
>>>
>>> Here is the interesting part - when the server was intially 
>>> replicated, I was able to make changes to 389-ds, but after a few 
>>> days, credentials now show errors:
>>>
>>> ldapsearch -x -LLL -D "cn=directory manager"  -b "cn=monitor" 
>>> "(objectclass=*)" -W
>>> Enter LDAP Password:
>>> ldap_bind: Invalid credentials (49)
>>
>> This doesn't make any sense.  Directory manager passwords are not 
>> replicated, they are local to each machine.  Directory manager 
>> passwords do not expire, and the error message is definitely 
>> "incorrect password" not "password expired".  There are no internal 
>> processes that touch directory manager or its password (unless there 
>> is something in ipa but I doubt it).  So I have no idea how "all of a 
>> sudden" directory manager password stops working.
>>
>> You can't recover it, you can only reset it.
>> http://www.port389.org/docs/389ds/howto/howto-resetdirmgrpassword.html
>>
>>>
>>> Thoughts?
>>> ~J
>>>
>>
>



From lkrispen at redhat.com  Fri Dec 19 08:14:23 2014
From: lkrispen at redhat.com (Ludwig Krispenz)
Date: Fri, 19 Dec 2014 09:14:23 +0100
Subject: [Freeipa-users] dirsrv password incorrect on replicas?
In-Reply-To: <5493281C.5030903@redhat.com>
References: <549305A1.6050806@gmail.com> <54931CE4.60602@redhat.com>
	<54932424.8020001@gmail.com> <5493281C.5030903@redhat.com>
Message-ID: <5493DE5F.8060603@redhat.com>


On 12/18/2014 08:16 PM, Rich Megginson wrote:
> On 12/18/2014 11:59 AM, Janelle wrote:
>> I am looking at the 2 entries in dse.ldif - and indeed they are 
>> different.  If I replace the one in question with the one from the 
>> working system, it works again.
>
> I'm assuming by "entry" you are referring to nsslapd-rootpw in cn=config.
>
>>
>> I did find - replica was created on Dec 11 at noon -- and the 
>> dse.ldif file CHANGED a day later?!?
>
> The dse.ldif file changes all the time - unique id generator state, 
> csn generator state, replication state, etc. etc.
>
> BUT - nsslapd-rootpw SHOULD NOT CHANGE
no, except someone follows the steps to change it.
Janelle, could it be that someone else was working on that server, not 
knowing the root pw and changing it in dse.ldif ?
>
>> Going to have OSSEC monitor the folders for changes in files to see 
>> what the heck is going on and WHAT changed it and if it happens again.
>>
>> thanks for the help
>> ~J
>>
>>
>> On 12/18/14 10:28 AM, Rich Megginson wrote:
>>> On 12/18/2014 09:49 AM, Janelle wrote:
>>>> Good morning/evening All,
>>>>
>>>> So, another strange thing I see with 4.1.2 running on FC21 
>>>> (server).  On some replicas if I attempt to modify the 389-ds 
>>>> backend, I get credential errors.  Even ldapsearch fails - which as 
>>>> me baffled.  I am trying to tune the servers but this has me 
>>>> confused as to what might cause something like this and where to 
>>>> start looking for a solution?
>>>>
>>>> Here is the interesting part - when the server was intially 
>>>> replicated, I was able to make changes to 389-ds, but after a few 
>>>> days, credentials now show errors:
>>>>
>>>> ldapsearch -x -LLL -D "cn=directory manager"  -b "cn=monitor" 
>>>> "(objectclass=*)" -W
>>>> Enter LDAP Password:
>>>> ldap_bind: Invalid credentials (49)
>>>
>>> This doesn't make any sense.  Directory manager passwords are not 
>>> replicated, they are local to each machine.  Directory manager 
>>> passwords do not expire, and the error message is definitely 
>>> "incorrect password" not "password expired".  There are no internal 
>>> processes that touch directory manager or its password (unless there 
>>> is something in ipa but I doubt it). So I have no idea how "all of a 
>>> sudden" directory manager password stops working.
>>>
>>> You can't recover it, you can only reset it.
>>> http://www.port389.org/docs/389ds/howto/howto-resetdirmgrpassword.html
>>>
>>>>
>>>> Thoughts?
>>>> ~J
>>>>
>>>
>>
>



From bentech4you at gmail.com  Fri Dec 19 10:07:54 2014
From: bentech4you at gmail.com (Ben .T.George)
Date: Fri, 19 Dec 2014 13:07:54 +0300
Subject: [Freeipa-users] while doing ipa-getkeytab ,
 getting Operation failed! PrincipalName not found.
Message-ID: <CA+C_GOVN5xQuVsv95xs14VWhP6YVN-67YAmY4nCEvo4x+ympLg@mail.gmail.com>

Hi List

i was trying to add linux machine manually as client. iwas following this
http://docs.fedoraproject.org/en-US/Fedora/15/html/FreeIPA_Guide/linux-manual.html

while doing ipa-getkeytab on FreeIpa server, i am getting error like
" Operation failed! PrincipalName not found."

please help me to solve this issue.


thanks & Regards,
Ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141219/12262d22/attachment.htm>

From Adam.Serafini at dmc.amcnetworks.com  Fri Dec 19 13:54:53 2014
From: Adam.Serafini at dmc.amcnetworks.com (Serafini, Adam)
Date: Fri, 19 Dec 2014 13:54:53 +0000
Subject: [Freeipa-users] KRB5CCNAME not defined in HTTP request environment
Message-ID: <2116090DBC1208469C5CA7CD3509B8EA15E43CB4@AMCMEXDB01.chellomedia.com>

Hi,

I am trying to write some software that communicates with the FreeIPA server from a remote client.

Using Adam Young's helpful blog (
http://adam.younglogic.com/2010/07/talking-to-freeipa-json-web-api-via-curl/), I am successfully able to run this curl on the FreeIPA server itself:

curl -v -H referer:https://myserver.net/ipa -H "Content-Type:application/json" -H "Accept:application/json" --negotiate -u : --cacert /etc/ipa/ca.crt -d '{"method":"user_find","params":[[""],{}],"id":0}' -X POST https://myserver.net/ipa/json

But when I try and run an similar curl from my client workstation (with pre-requisite Kerberos setup):

curl -v -H referer:https://myworkstation.net/ipa -H "Content-Type:application/json" -H "Accept:application/json" --negotiate -u : --cacert /tmp/ca.crt -d '{"method":"user_find","params":[[""],{}],"id":0}' -X POST https://myserver.net/ipa/json

The following error is generated in the Apache logs:

KerberosWSGIExecutioner.__call__: KRB5CCNAME not defined in HTTP request environment

Would anyone have any pointers to fix, or a place to start investigating? I am assuming there is configuration problem but I have no idea where to begin. I believe I've done all the Kerberos setup correctly, but it's hard to tell.

Kind regards,
Adam




This message (including any attachments) may contain information that is privileged or confidential. If you are not the intended recipient, please notify the sender and delete this email immediately from your systems and destroy all copies of it. You may not, directly or indirectly, use, disclose, distribute, print or copy this email or any part of it if you are not the intended recipient
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141219/6cf43512/attachment.htm>

From dpal at redhat.com  Fri Dec 19 16:15:06 2014
From: dpal at redhat.com (Dmitri Pal)
Date: Fri, 19 Dec 2014 11:15:06 -0500
Subject: [Freeipa-users] KRB5CCNAME not defined in HTTP request
	environment
In-Reply-To: <2116090DBC1208469C5CA7CD3509B8EA15E43CB4@AMCMEXDB01.chellomedia.com>
References: <2116090DBC1208469C5CA7CD3509B8EA15E43CB4@AMCMEXDB01.chellomedia.com>
Message-ID: <54944F0A.6030409@redhat.com>

On 12/19/2014 08:54 AM, Serafini, Adam wrote:
> Hi,
>
> I am trying to write some software that communicates with the FreeIPA 
> server from a remote client.
>
> Using Adam Young's helpful blog (
> http://adam.younglogic.com/2010/07/talking-to-freeipa-json-web-api-via-curl/), 
> I am successfully able to run this curl on the FreeIPA server itself:
>
> curl -v -H referer:https://myserver.net/ipa -H 
> "Content-Type:application/json" -H "Accept:application/json" 
> --negotiate -u : --cacert /etc/ipa/ca.crt -d 
> '{"method":"user_find","params":[[""],{}],"id":0}' -X POST 
> https://myserver.net/ipa/json
>
> But when I try and run an similar curl from my client workstation 
> (with pre-requisite Kerberos setup):
>
> curl -v -H referer:https://myworkstation.net/ipa -H 
> "Content-Type:application/json" -H "Accept:application/json" 
> --negotiate -u : --cacert /tmp/ca.crt -d 
> '{"method":"user_find","params":[[""],{}],"id":0}' -X POST 
> https://myserver.net/ipa/json
>
> The following error is generated in the Apache logs:
>
> KerberosWSGIExecutioner.__call__: KRB5CCNAME not defined in HTTP 
> request environment
>
> Would anyone have any pointers to fix, or a place to start 
> investigating? I am assuming there is configuration problem but I have 
> no idea where to begin. I believe I've done all the Kerberos setup 
> correctly, but it's hard to tell.

It seems that curl can't find kerberos ticket cache.
KRB5CCNAME is an environment variable that points to the location of the 
ticket cache.
Try defining it for curl and see what happens. I suppose knit works fine 
from the client you try it on.

>
> Kind regards,
> Adam
>
>
>
>
> This message (including any attachments) may contain information that 
> is privileged or confidential. If you are not the intended recipient, 
> please notify the sender and delete this email immediately from your 
> systems and destroy all copies of it. You may not, directly or 
> indirectly, use, disclose, distribute, print or copy this email or any 
> part of it if you are not the intended recipient
>
>


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141219/95766e48/attachment.htm>

From dpal at redhat.com  Fri Dec 19 16:21:39 2014
From: dpal at redhat.com (Dmitri Pal)
Date: Fri, 19 Dec 2014 11:21:39 -0500
Subject: [Freeipa-users] while doing ipa-getkeytab ,
 getting Operation failed! PrincipalName not found.
In-Reply-To: <CA+C_GOVN5xQuVsv95xs14VWhP6YVN-67YAmY4nCEvo4x+ympLg@mail.gmail.com>
References: <CA+C_GOVN5xQuVsv95xs14VWhP6YVN-67YAmY4nCEvo4x+ympLg@mail.gmail.com>
Message-ID: <54945093.3050204@redhat.com>

On 12/19/2014 05:07 AM, Ben .T.George wrote:
> Hi List
>
> i was trying to add linux machine manually as client. iwas following 
> this 
> http://docs.fedoraproject.org/en-US/Fedora/15/html/FreeIPA_Guide/linux-manual.html
>
> while doing ipa-getkeytab on FreeIpa server, i am getting error like 
> " Operation failed! PrincipalName not found."
>
> please help me to solve this issue.

When you do client enrollment using ipa-client you can run it in several 
ways:
- high level admin that has full privileges in IPA (recommended just for 
demo and POC purposes)
- low level admin that has permission to provision systems. Such admin 
does not have privilege to create the host entry during registration. 
The entry must be there. The error you see above indicates that the host 
entry does not exist.
- automated system. In this case the entry has to be precereated and one 
can set or request IPA to generate a registration code that can be used 
once as an OTP to register client.

So if you do things manually you need to create host entry first 
manually on the server side.

>
>
> thanks & Regards,
> Ben
>
>
>


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141219/df754260/attachment.htm>

From Duncan.Innes at virginmoney.com  Fri Dec 19 16:35:25 2014
From: Duncan.Innes at virginmoney.com (Innes, Duncan)
Date: Fri, 19 Dec 2014 16:35:25 -0000
Subject: [Freeipa-users] Logging: IPA to Rsyslog to Logstash
In-Reply-To: <20141216095930.GC27648@localhost.localdomain>
References: <CAPP+0v+CTFwo5Dw8ymBFpjzroW3=5GE+ouoEj2AnCJP-cJMDXA@mail.gmail.com>
	<20141216095930.GC27648@localhost.localdomain>
Message-ID: <56343345B145C043AE990701E3D193950478E330@EXVS2.nrplc.localnet>

Earlier this year I said I'd feed back how my IPA to Rsyslog to Logstash
experiments went.

They went badly.  And I didn't get much time.  Today, however, I managed
to get over my imaginary finishing line:

All systems are RHEL 6.6.

Rsyslog (rsyslog7-7.4.10) is configured to import logs from some dirsrv
files:

# cat /etc/rsyslog.d/dirsrv.conf 
module(load="imfile" PollingInterval="2")

input(type="imfile"
      File="/var/log/dirsrv/slapd-EXAMPLE-COM/access"
      Tag="dirsrv"
      StateFile="statedirsrv"
      Facility="local0")

input(type="imfile"
      File="/var/log/dirsrv/slapd-EXAMPLE-COM/errors"
      Tag="dirsrv"
      StateFile="statedirsrverr"
      Severity="error"
      Facility="local0")

#

This pulls in those log entries on a regular basis.  Rsyslog8 allows you
to use inotify for file changes, but that's not available to me.

Rsyslog is then also configured to push all logs to my Logstash servers:

# cat /etc/rsyslog.d/logstash.conf 
template(name="ls_json" type="list" option.json="on")
{ constant(value="{")
constant(value="\"@timestamp\":\"") property(name="timegenerated"
dateFormat="rfc3339")
constant(value="\",\"@version\":\"1")
constant(value="\",\"message\":\"") property(name="msg")
constant(value="\",\"host\":\"") property(name="hostname")
constant(value="\",\"my_environment\":\"dev")
constant(value="\",\"my_project\":\"Infrastructure")
constant(value="\",\"my_use\":\"IPA")
constant(value="\",\"logsource\":\"") property(name="fromhost")
constant(value="\",\"severity_label\":\"")
property(name="syslogseverity-text")
constant(value="\",\"severity\":\"") property(name="syslogseverity")
constant(value="\",\"facility_label\":\"")
property(name="syslogfacility-text")
constant(value="\",\"facility\":\"") property(name="syslogfacility")
constant(value="\",\"program\":\"") property(name="programname")
constant(value="\",\"pid\":\"") property(name="procid")
constant(value="\",\"rawmsg\":\"") property(name="rawmsg")
constant(value="\",\"syslogtag\":\"") property(name="syslogtag")
constant(value="\"}\n")
}

*.* @@logstash01.example.com:5500;ls_json
$ActionExecOnlyWhenPreviousIsSuspended on
& @@logstash02.example.com:5500;ls_json
& /var/log/localbuffer
$ActionExecOnlyWhenPreviousIsSuspended off

[root at lvdlvldap02 ~]#

Which pushes all logs to my logstash servers in JSON format.  Failover
is built in by using 2 logstash servers.
The client needs to have SELinux managed to allow rsyslog to write to
port 5500:

# semanage port -a -t syslogd_port_t -p tcp 5500
# semanage port -l | grep 5500

The Logstash servers are then configured to listen on this port and do
some simple groking, before sending everything to the ElasticSearch
cluster:

# cat /etc/logstash/conf.d/syslog.conf 
input {
  tcp {
    type => syslogjson
    port => 5500
    codec => "json"
  }
}

filter {
  # This replaces the host field (UDP source) with the host that
generated the message (sysloghost)
  if [sysloghost] {
    mutate {
      replace => [ "host", "%{sysloghost}" ]
      remove_field => "sysloghost" # prune the field after successfully
replacing "host"
    }
  }
  if [type] == "syslogjson" {
    grok {
      patterns_dir => "/opt/logstash/patterns"
      match => { "message" => "%{VIRGINFW}" }
      match => { "message" => "%{AUDITAVC}" }
      match => { "message" => "%{COMMONAPACHELOG}" }
      tag_on_failure => []
    }
  }

  # This filter populates the @timestamp field with the timestamp that's
in the actual message
  # dirsrv logs are currently pulled in every 2 minutes, so @timestamp
is wrong
  if [syslogtag] == "dirsrv" {
    mutate {
      remove_field => [ 'rawmsg' ]
    }
    grok {
      match => [ "message", "%{HTTPDATE:log_timestamp}" ]
    }
    date {
      match => [ "log_timestamp", "dd/MMM/YYY:HH:mm:ss Z"]
      locale => "en"
      remove_field => [ "log_timestamp" ]
    }
  }
}

output {
  elasticsearch {
    protocol => node
    node_name => "Indexer01"
  }
}
#

It works well for the most part.  I'm not performing any groking of the
actual message line as yet to pull out various bits of data into their
own separate fields, but at least I'm managing to log the access and
errors from multiple IPA servers.

The @timestamp field ends up with the timestamp from the actual message
line, so it's only down to second accuracy.  This means that multiple
log lines on the same second lose their ordering when viewed in the
Logstash/Kibana interface.  But the important thing at this point is
that they're now held centrally.

Is it feasible to alter the timestamp resolution that dirsrv uses?  This
would help separate log lines properly.

Cheers & Merry Festive Holiday thing

Duncan

This message has been checked for viruses and spam by the Virgin Money email scanning system powered by Messagelabs.

This e-mail is intended to be confidential to the recipient. If you receive a copy in error, please inform the sender and then delete this message.

Virgin Money plc - Registered in England and Wales (Company no. 6952311). Registered office - Jubilee House, Gosforth, Newcastle upon Tyne NE3 4PL. Virgin Money plc is authorised by the Prudential Regulation Authority and regulated by the Financial Conduct Authority and the Prudential Regulation Authority.

The following companies also trade as Virgin Money. They are both authorised and regulated by the Financial Conduct Authority, are registered in England and Wales and have their registered office at Jubilee House, Gosforth, Newcastle upon Tyne NE3 4PL: Virgin Money Personal Financial Service Limited (Company no. 3072766) and Virgin Money Unit Trust Managers Limited (Company no. 3000482).

For further details of Virgin Money group companies please visit our website at virginmoney.com



From janellenicole80 at gmail.com  Fri Dec 19 16:59:33 2014
From: janellenicole80 at gmail.com (Janelle)
Date: Fri, 19 Dec 2014 08:59:33 -0800
Subject: [Freeipa-users] dirsrv password incorrect on replicas?
In-Reply-To: <5493DE5F.8060603@redhat.com>
References: <549305A1.6050806@gmail.com>
	<54931CE4.60602@redhat.com>	<54932424.8020001@gmail.com>
	<5493281C.5030903@redhat.com> <5493DE5F.8060603@redhat.com>
Message-ID: <54945975.6070108@gmail.com>

I am the only one who has access to these systems, so unless I did it in 
my sleep.. :-)

~J

On 12/19/14 12:14 AM, Ludwig Krispenz wrote:
>
> On 12/18/2014 08:16 PM, Rich Megginson wrote:
>> On 12/18/2014 11:59 AM, Janelle wrote:
>>> I am looking at the 2 entries in dse.ldif - and indeed they are 
>>> different.  If I replace the one in question with the one from the 
>>> working system, it works again.
>>
>> I'm assuming by "entry" you are referring to nsslapd-rootpw in 
>> cn=config.
>>
>>>
>>> I did find - replica was created on Dec 11 at noon -- and the 
>>> dse.ldif file CHANGED a day later?!?
>>
>> The dse.ldif file changes all the time - unique id generator state, 
>> csn generator state, replication state, etc. etc.
>>
>> BUT - nsslapd-rootpw SHOULD NOT CHANGE
> no, except someone follows the steps to change it.
> Janelle, could it be that someone else was working on that server, not 
> knowing the root pw and changing it in dse.ldif ?



From dpal at redhat.com  Sat Dec 20 03:37:29 2014
From: dpal at redhat.com (Dmitri Pal)
Date: Fri, 19 Dec 2014 22:37:29 -0500
Subject: [Freeipa-users] Logging: IPA to Rsyslog to Logstash
In-Reply-To: <56343345B145C043AE990701E3D193950478E330@EXVS2.nrplc.localnet>
References: <CAPP+0v+CTFwo5Dw8ymBFpjzroW3=5GE+ouoEj2AnCJP-cJMDXA@mail.gmail.com>	<20141216095930.GC27648@localhost.localdomain>
	<56343345B145C043AE990701E3D193950478E330@EXVS2.nrplc.localnet>
Message-ID: <5494EEF9.1060801@redhat.com>

On 12/19/2014 11:35 AM, Innes, Duncan wrote:
> Earlier this year I said I'd feed back how my IPA to Rsyslog to Logstash
> experiments went.
>
> They went badly.  And I didn't get much time.  Today, however, I managed
> to get over my imaginary finishing line:
>
> All systems are RHEL 6.6.
>
> Rsyslog (rsyslog7-7.4.10) is configured to import logs from some dirsrv
> files:
>
> # cat /etc/rsyslog.d/dirsrv.conf
> module(load="imfile" PollingInterval="2")
>
> input(type="imfile"
>        File="/var/log/dirsrv/slapd-EXAMPLE-COM/access"
>        Tag="dirsrv"
>        StateFile="statedirsrv"
>        Facility="local0")
>
> input(type="imfile"
>        File="/var/log/dirsrv/slapd-EXAMPLE-COM/errors"
>        Tag="dirsrv"
>        StateFile="statedirsrverr"
>        Severity="error"
>        Facility="local0")
>
> #
>
> This pulls in those log entries on a regular basis.  Rsyslog8 allows you
> to use inotify for file changes, but that's not available to me.
>
> Rsyslog is then also configured to push all logs to my Logstash servers:
>
> # cat /etc/rsyslog.d/logstash.conf
> template(name="ls_json" type="list" option.json="on")
> { constant(value="{")
> constant(value="\"@timestamp\":\"") property(name="timegenerated"
> dateFormat="rfc3339")
> constant(value="\",\"@version\":\"1")
> constant(value="\",\"message\":\"") property(name="msg")
> constant(value="\",\"host\":\"") property(name="hostname")
> constant(value="\",\"my_environment\":\"dev")
> constant(value="\",\"my_project\":\"Infrastructure")
> constant(value="\",\"my_use\":\"IPA")
> constant(value="\",\"logsource\":\"") property(name="fromhost")
> constant(value="\",\"severity_label\":\"")
> property(name="syslogseverity-text")
> constant(value="\",\"severity\":\"") property(name="syslogseverity")
> constant(value="\",\"facility_label\":\"")
> property(name="syslogfacility-text")
> constant(value="\",\"facility\":\"") property(name="syslogfacility")
> constant(value="\",\"program\":\"") property(name="programname")
> constant(value="\",\"pid\":\"") property(name="procid")
> constant(value="\",\"rawmsg\":\"") property(name="rawmsg")
> constant(value="\",\"syslogtag\":\"") property(name="syslogtag")
> constant(value="\"}\n")
> }
>
> *.* @@logstash01.example.com:5500;ls_json
> $ActionExecOnlyWhenPreviousIsSuspended on
> & @@logstash02.example.com:5500;ls_json
> & /var/log/localbuffer
> $ActionExecOnlyWhenPreviousIsSuspended off
>
> [root at lvdlvldap02 ~]#
>
> Which pushes all logs to my logstash servers in JSON format.  Failover
> is built in by using 2 logstash servers.
> The client needs to have SELinux managed to allow rsyslog to write to
> port 5500:
>
> # semanage port -a -t syslogd_port_t -p tcp 5500
> # semanage port -l | grep 5500
>
> The Logstash servers are then configured to listen on this port and do
> some simple groking, before sending everything to the ElasticSearch
> cluster:
>
> # cat /etc/logstash/conf.d/syslog.conf
> input {
>    tcp {
>      type => syslogjson
>      port => 5500
>      codec => "json"
>    }
> }
>
> filter {
>    # This replaces the host field (UDP source) with the host that
> generated the message (sysloghost)
>    if [sysloghost] {
>      mutate {
>        replace => [ "host", "%{sysloghost}" ]
>        remove_field => "sysloghost" # prune the field after successfully
> replacing "host"
>      }
>    }
>    if [type] == "syslogjson" {
>      grok {
>        patterns_dir => "/opt/logstash/patterns"
>        match => { "message" => "%{VIRGINFW}" }
>        match => { "message" => "%{AUDITAVC}" }
>        match => { "message" => "%{COMMONAPACHELOG}" }
>        tag_on_failure => []
>      }
>    }
>
>    # This filter populates the @timestamp field with the timestamp that's
> in the actual message
>    # dirsrv logs are currently pulled in every 2 minutes, so @timestamp
> is wrong
>    if [syslogtag] == "dirsrv" {
>      mutate {
>        remove_field => [ 'rawmsg' ]
>      }
>      grok {
>        match => [ "message", "%{HTTPDATE:log_timestamp}" ]
>      }
>      date {
>        match => [ "log_timestamp", "dd/MMM/YYY:HH:mm:ss Z"]
>        locale => "en"
>        remove_field => [ "log_timestamp" ]
>      }
>    }
> }
>
> output {
>    elasticsearch {
>      protocol => node
>      node_name => "Indexer01"
>    }
> }
> #
>
> It works well for the most part.  I'm not performing any groking of the
> actual message line as yet to pull out various bits of data into their
> own separate fields, but at least I'm managing to log the access and
> errors from multiple IPA servers.
>
> The @timestamp field ends up with the timestamp from the actual message
> line, so it's only down to second accuracy.  This means that multiple
> log lines on the same second lose their ordering when viewed in the
> Logstash/Kibana interface.  But the important thing at this point is
> that they're now held centrally.
>
> Is it feasible to alter the timestamp resolution that dirsrv uses?  This
> would help separate log lines properly.

Please file a 389 RFE.

>
> Cheers & Merry Festive Holiday thing
>
> Duncan
>
> This message has been checked for viruses and spam by the Virgin Money email scanning system powered by Messagelabs.
>
> This e-mail is intended to be confidential to the recipient. If you receive a copy in error, please inform the sender and then delete this message.
>
> Virgin Money plc - Registered in England and Wales (Company no. 6952311). Registered office - Jubilee House, Gosforth, Newcastle upon Tyne NE3 4PL. Virgin Money plc is authorised by the Prudential Regulation Authority and regulated by the Financial Conduct Authority and the Prudential Regulation Authority.
>
> The following companies also trade as Virgin Money. They are both authorised and regulated by the Financial Conduct Authority, are registered in England and Wales and have their registered office at Jubilee House, Gosforth, Newcastle upon Tyne NE3 4PL: Virgin Money Personal Financial Service Limited (Company no. 3072766) and Virgin Money Unit Trust Managers Limited (Company no. 3000482).
>
> For further details of Virgin Money group companies please visit our website at virginmoney.com
>


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.



From bentech4you at gmail.com  Sat Dec 20 10:02:38 2014
From: bentech4you at gmail.com (Ben .T.George)
Date: Sat, 20 Dec 2014 13:02:38 +0300
Subject: [Freeipa-users] how to configure Linux Cent Os as ipa client manual
	installation
Message-ID: <CA+C_GOUYUPE6E6+JWQn5kb3b8VGj7U9xpWmvNgs4Tqh4xYYjQw@mail.gmail.com>

Hi

I was trying to configure centos as ipa client and got failed with that,.

anyone please help me to configure centos as ipa client through manual
configuration.


Regards,
Ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141220/8e6ae7d6/attachment.htm>

From bentech4you at gmail.com  Sun Dec 21 06:03:17 2014
From: bentech4you at gmail.com (Ben .T.George)
Date: Sun, 21 Dec 2014 09:03:17 +0300
Subject: [Freeipa-users] how can i configure solaris 10 sparc and x86 as ipa
	clients
Message-ID: <CA+C_GOVJp94wVJZ=Ku_d5s3r0iRFSGAEqM68=2XRdBtO85o9pQ@mail.gmail.com>

Hi List

how can i configure solaris 10 sparc and x86 as ipa clients.

Regards,
Ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141221/659482e9/attachment.htm>

From ftweedal at redhat.com  Mon Dec 22 00:50:25 2014
From: ftweedal at redhat.com (Fraser Tweedale)
Date: Mon, 22 Dec 2014 10:50:25 +1000
Subject: [Freeipa-users] how can i configure solaris 10 sparc and x86 as
 ipa clients
In-Reply-To: <CA+C_GOVJp94wVJZ=Ku_d5s3r0iRFSGAEqM68=2XRdBtO85o9pQ@mail.gmail.com>
References: <CA+C_GOVJp94wVJZ=Ku_d5s3r0iRFSGAEqM68=2XRdBtO85o9pQ@mail.gmail.com>
Message-ID: <20141222005025.GP4163@dhcp-40-8.bne.redhat.com>

On Sun, Dec 21, 2014 at 09:03:17AM +0300, Ben .T.George wrote:
> Hi List
> 
> how can i configure solaris 10 sparc and x86 as ipa clients.
> 
> Regards,
> Ben

Hi Ben,

Please follow the Solaris 8/9/10 instructions on the wiki:
http://www.freeipa.org/page/ConfiguringUnixClients#Solaris_8.2F9.2F10

Let us know if run into difficulties or if there are error or
omissions in the instructions.

Cheers,

Fraser

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



From bentech4you at gmail.com  Mon Dec 22 03:16:40 2014
From: bentech4you at gmail.com (Ben .T.George)
Date: Mon, 22 Dec 2014 06:16:40 +0300
Subject: [Freeipa-users] how can i configure solaris 10 sparc and x86 as
 ipa clients
Message-ID: <CA+C_GOWipQmRXKytV0D+Ng8GrWHSKB=CQDrgQGQa-ZbD9JSd7A@mail.gmail.com>

Hi Sir,

many thanks for replaying me.

i am having some doubt related to

   - ldap_client_file <http://www.freeipa.org/page/SolarisLdapClientFile>

anyway i will try to configure that and let you the status.

once again thanks for your guidelines


Thanks & Regards,
Ben


On Mon, Dec 22, 2014 at 3:50 AM, Fraser Tweedale <ftweedal at redhat.com>
wrote:

> On Sun, Dec 21, 2014 at 09:03:17AM +0300, Ben .T.George wrote:
> > Hi List
> >
> > how can i configure solaris 10 sparc and x86 as ipa clients.
> >
> > Regards,
> > Ben
>
> Hi Ben,
>
> Please follow the Solaris 8/9/10 instructions on the wiki:
> http://www.freeipa.org/page/ConfiguringUnixClients#Solaris_8.2F9.2F10
>
> Let us know if run into difficulties or if there are error or
> omissions in the instructions.
>
> Cheers,
>
> Fraser
>
> > --
> > 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141222/223ceaac/attachment.htm>

From andrew.holway at gmail.com  Mon Dec 22 15:38:08 2014
From: andrew.holway at gmail.com (Andrew Holway)
Date: Mon, 22 Dec 2014 16:38:08 +0100
Subject: [Freeipa-users] Practical and theoretical limits of FreeIPA
Message-ID: <CAEiui-uddQjmjyCOD6PsSSmpn2xNXwt3+10w1858wM1vgE9m+A@mail.gmail.com>

So I am looking at ways of building a distributed user database for
millions of users (specifically 5 million at the moment) and I am thinking
that freeIPA might be a good thing to test for this kind of use case. I
would assume that at least a third of these users would want to
authenticate every day however updates of data held in the database would
probably be quite rare.

We need to have endpoints in a few regions and the Multi Master Replication
would take care of the back end problem for us quite well.

Does anyone have any data on using freeIPA for this kind of thing. What
would be the caveats?

Thanks,

Andrew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141222/fadfe79d/attachment.htm>

From genadipost at gmail.com  Mon Dec 22 20:37:44 2014
From: genadipost at gmail.com (Genadi Postrilko)
Date: Mon, 22 Dec 2014 22:37:44 +0200
Subject: [Freeipa-users] Importing /etc/sudoers into IPA.
Message-ID: <CAPP+0vLQVd-m9ihRkRe1arbM+T7RpML51xT2rNutwzDvLLXZaw@mail.gmail.com>

Hello All.

I'm planning to migrate the /etc/sudoers into the IPA.
I have read that sudoers2ldif should be used to import /etc/sudoers into
LDAP.
http://www.sudo.ws/sudo/readme_ldap.html
The script will work as is? or changes should be add?
Should the users and group mentioned in sudoers be created beforehand?

Thanks,
Genadi.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141222/d1d60ec1/attachment.htm>

From CWhite at skytouchtechnology.com  Mon Dec 22 20:50:38 2014
From: CWhite at skytouchtechnology.com (Craig White)
Date: Mon, 22 Dec 2014 20:50:38 +0000
Subject: [Freeipa-users] Importing /etc/sudoers into IPA.
In-Reply-To: <CAPP+0vLQVd-m9ihRkRe1arbM+T7RpML51xT2rNutwzDvLLXZaw@mail.gmail.com>
References: <CAPP+0vLQVd-m9ihRkRe1arbM+T7RpML51xT2rNutwzDvLLXZaw@mail.gmail.com>
Message-ID: <BLUPR08MB48883A57BBC9C0F2AECCFECB3560@BLUPR08MB488.namprd08.prod.outlook.com>

I would not recommend that path with FreeIPA.

This is clearly the way to go with FreeIPA

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/sudo.html

Craig White
System Administrator
O 623-201-8179   M 602-377-9752

[cid:image001.png at 01CF86FE.42D51630]

SkyTouch Technology     4225 E. Windrose Dr.     Phoenix, AZ 85032

From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Genadi Postrilko
Sent: Monday, December 22, 2014 1:38 PM
To: freeipa-users at redhat.com
Subject: [Freeipa-users] Importing /etc/sudoers into IPA.

Hello All.

I'm planning to migrate the /etc/sudoers into the IPA.
I have read that sudoers2ldif should be used to import /etc/sudoers into LDAP.
http://www.sudo.ws/sudo/readme_ldap.html
The script will work as is? or changes should be add?
Should the users and group mentioned in sudoers be created beforehand?

Thanks,
Genadi.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141222/8c8338e0/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 7660 bytes
Desc: image001.png
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141222/8c8338e0/attachment.png>

From genadipost at gmail.com  Mon Dec 22 21:49:29 2014
From: genadipost at gmail.com (Genadi Postrilko)
Date: Mon, 22 Dec 2014 23:49:29 +0200
Subject: [Freeipa-users] Importing /etc/sudoers into IPA.
In-Reply-To: <BLUPR08MB48883A57BBC9C0F2AECCFECB3560@BLUPR08MB488.namprd08.prod.outlook.com>
References: <CAPP+0vLQVd-m9ihRkRe1arbM+T7RpML51xT2rNutwzDvLLXZaw@mail.gmail.com>
	<BLUPR08MB48883A57BBC9C0F2AECCFECB3560@BLUPR08MB488.namprd08.prod.outlook.com>
Message-ID: <CAPP+0v+Ej6xPzY=-_XRG+4DcX2=rJZoNYRj1Pr82KLyeVCAW2Q@mail.gmail.com>

I'm not sure i understand what you mean.

2014-12-22 22:50 GMT+02:00 Craig White <CWhite at skytouchtechnology.com>:

>  I would not recommend that path with FreeIPA.
>
>
>
> This is clearly the way to go with FreeIPA
>
>
>
>
> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/sudo.html
>
>
>
> Craig White
>
> System Administrator
>
> O 623-201-8179   M 602-377-9752
>
>
>
> [image: cid:image001.png at 01CF86FE.42D51630]
>
>
>
> SkyTouch Technology     4225 E. Windrose Dr.     Phoenix, AZ 85032
>
>
>
> *From:* freeipa-users-bounces at redhat.com [mailto:
> freeipa-users-bounces at redhat.com] *On Behalf Of *Genadi Postrilko
> *Sent:* Monday, December 22, 2014 1:38 PM
> *To:* freeipa-users at redhat.com
> *Subject:* [Freeipa-users] Importing /etc/sudoers into IPA.
>
>
>
> Hello All.
>
>
>
> I'm planning to migrate the /etc/sudoers into the IPA.
>
> I have read that sudoers2ldif should be used to import /etc/sudoers into
> LDAP.
>
> http://www.sudo.ws/sudo/readme_ldap.html
>
> The script will work as is? or changes should be add?
>
> Should the users and group mentioned in sudoers be created beforehand?
>
>
>
> Thanks,
>
> Genadi.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141222/284a8686/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 7660 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141222/284a8686/attachment.png>

From abokovoy at redhat.com  Tue Dec 23 21:28:25 2014
From: abokovoy at redhat.com (Alexander Bokovoy)
Date: Tue, 23 Dec 2014 16:28:25 -0500 (EST)
Subject: [Freeipa-users] Importing /etc/sudoers into IPA.
In-Reply-To: <CAPP+0vLQVd-m9ihRkRe1arbM+T7RpML51xT2rNutwzDvLLXZaw@mail.gmail.com>
References: <CAPP+0vLQVd-m9ihRkRe1arbM+T7RpML51xT2rNutwzDvLLXZaw@mail.gmail.com>
Message-ID: <373908477.1495796.1419370105519.JavaMail.zimbra@redhat.com>

Hi, 

----- Original Message -----

> Hello All.

> I'm planning to migrate the /etc/sudoers into the IPA.
> I have read that sudoers2ldif should be used to import /etc/sudoers into
> LDAP.
> http://www.sudo.ws/sudo/readme_ldap.html
> The script will work as is? or changes should be add?
> Should the users and group mentioned in sudoers be created beforehand?

FreeIPA schema for sudo is different from what the script expects and produces so it will not be helpful. 
You can instead write own script that converts existing /etc/sudoers into a series of calls of IPA command line. 

I have no handy examples of how to do it. 
-- 
/ Alexander Bokovoy 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141223/0ef89fad/attachment.htm>

From traiano at gmail.com  Wed Dec 24 06:04:12 2014
From: traiano at gmail.com (Traiano Welcome)
Date: Wed, 24 Dec 2014 09:04:12 +0300
Subject: [Freeipa-users] IPA/Kerberos5 and Upper Case/Lower-case Hostnames
Message-ID: <CAFKCRV+GBrW=L64CzfT2eWtvReg9ADVVePKezxUKKghsBn-A1w@mail.gmail.com>

Hi List

I have a large number of legacy hosts with upper-case host names, that
I'd like to configure as IPA clients. However ipa client refuses to
accept upper case hostnames during configuration time.

I think this derives from the fact that the kerberos5 database stores
host names in a case sensitive way and requires that the DNS hostname
matches the server hostname case.

My question is: Is it mandatory that the hostname be lower-cased, or
is there a safe workaround that will allow IPA client to work with
hosts that have upper case host names ?

Thanks in advance!
Traiano



From genadipost at gmail.com  Wed Dec 24 08:44:38 2014
From: genadipost at gmail.com (Genadi Postrilko)
Date: Wed, 24 Dec 2014 10:44:38 +0200
Subject: [Freeipa-users] Importing /etc/sudoers into IPA.
In-Reply-To: <373908477.1495796.1419370105519.JavaMail.zimbra@redhat.com>
References: <CAPP+0vLQVd-m9ihRkRe1arbM+T7RpML51xT2rNutwzDvLLXZaw@mail.gmail.com>
	<373908477.1495796.1419370105519.JavaMail.zimbra@redhat.com>
Message-ID: <CAPP+0vKNgc-zVqtUHPYkN07T=y7XD5qkFqCu=-QAztwqnGH6Ow@mail.gmail.com>

OK, I will try and brew something.
Thank you for the response.

2014-12-23 23:28 GMT+02:00 Alexander Bokovoy <abokovoy at redhat.com>:

> Hi,
>
>
> ------------------------------
>
> Hello All.
>
> I'm planning to migrate the /etc/sudoers into the IPA.
> I have read that sudoers2ldif should be used to import /etc/sudoers into
> LDAP.
> http://www.sudo.ws/sudo/readme_ldap.html
> The script will work as is? or changes should be add?
> Should the users and group mentioned in sudoers be created beforehand?
>
> FreeIPA schema for sudo is different from what the script expects and
> produces so it will not be helpful.
> You can instead write own script that converts existing /etc/sudoers into
> a series of calls of IPA command line.
>
> I have no handy examples of how to do it.
> --
> / Alexander Bokovoy
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141224/ec6e00f5/attachment.htm>

From outbackdingo at gmail.com  Sat Dec 27 02:25:12 2014
From: outbackdingo at gmail.com (Outback Dingo)
Date: Sat, 27 Dec 2014 13:25:12 +1100
Subject: [Freeipa-users] IPA UI Internal Server Error
Message-ID: <CAKYr3zzjoYkpA9teO+FFWqJoSW1W_JZHGy8o9mNAx7uCJ4Js_g@mail.gmail.com>

So Ive installed a new IPA today on Fedora 21 the gui is throwing internal
server errors
uname -a
Linux ipa.optimcloud.com 3.17.7-300.fc21.x86_64 #1 SMP Wed Dec 17 03:08:44
UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
cat /etc/redhat-release
Fedora release 21 (Twenty One)
anyone seen this before? is there a fix ?

[Sat Dec 27 13:21:01.443607 2014] [wsgi:error] [pid 6508] [client
192.168.70.22:39545] Truncated or oversized response headers received from
daemon process 'ipa': /usr/share/ipa/wsgi.py, referer:
https://ipa.optimcloud.com/ipa/ui/
[Sat Dec 27 13:21:02.159216 2014] [core:notice] [pid 6499] AH00052: child
pid 6544 exit signal Segmentation fault (11)
[Sat Dec 27 13:21:02.161311 2014] [core:notice] [pid 6499] AH00052: child
pid 6574 exit signal Segmentation fault (11)
[Sat Dec 27 13:21:03.384996 2014] [wsgi:error] [pid 7288] ipa: INFO: ***
PROCESS START ***
[Sat Dec 27 13:21:03.385754 2014] [wsgi:error] [pid 7287] ipa: INFO: ***
PROCESS START ***
[Sat Dec 27 13:21:10.286973 2014] [wsgi:error] [pid 7286] [client
192.168.70.22:39978] Truncated or oversized response headers received from
daemon process 'ipa': /usr/share/ipa/wsgi.py, referer:
https://ipa.optimcloud.com/ipa/ui/
[Sat Dec 27 13:21:11.172689 2014] [core:notice] [pid 6499] AH00052: child
pid 7288 exit signal Segmentation fault (11)
[Sat Dec 27 13:21:12.543688 2014] [wsgi:error] [pid 7301] ipa: INFO: ***
PROCESS START ***
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141227/87b2163d/attachment.htm>

From prashant at apigee.com  Sat Dec 27 06:19:26 2014
From: prashant at apigee.com (Prashant Bapat)
Date: Sat, 27 Dec 2014 11:49:26 +0530
Subject: [Freeipa-users] Read Only LDAP Replicas
Message-ID: <CAN9aUrhZGmoTParWEQCKP6dymKbWVWNCTvS00LRg2c0bu6GLpg@mail.gmail.com>

Hi All,

I'm trying to implement FreeIPA for Users and SSH pub keys management in
our infra. We have a setup that spans multiple geographies. What we are
thinking is something like below.

1. Have 2 full FreeIPA servers with multi master replicas in one region.
2. In other regions just have a LDAP read-only replica.
3. Use the AuthorizedKeysCommand in SSH to look for a users pub key in the
respective region's LDAP.

Has anyone tried something on these lines?

Please share your experiences.

Thanks.
--Prashant
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141227/93c13a92/attachment.htm>

From rcritten at redhat.com  Sat Dec 27 21:22:08 2014
From: rcritten at redhat.com (Rob Crittenden)
Date: Sat, 27 Dec 2014 16:22:08 -0500
Subject: [Freeipa-users] IPA UI Internal Server Error
In-Reply-To: <CAKYr3zzjoYkpA9teO+FFWqJoSW1W_JZHGy8o9mNAx7uCJ4Js_g@mail.gmail.com>
References: <CAKYr3zzjoYkpA9teO+FFWqJoSW1W_JZHGy8o9mNAx7uCJ4Js_g@mail.gmail.com>
Message-ID: <549F2300.5080702@redhat.com>

Outback Dingo wrote:
> So Ive installed a new IPA today on Fedora 21 the gui is throwing
> internal server errors
> uname -a
> Linux ipa.optimcloud.com <http://ipa.optimcloud.com>
> 3.17.7-300.fc21.x86_64 #1 SMP Wed Dec 17 03:08:44 UTC 2014 x86_64 x86_64
> x86_64 GNU/Linux
> cat /etc/redhat-release 
> Fedora release 21 (Twenty One)
> anyone seen this before? is there a fix ?
> 
> [Sat Dec 27 13:21:01.443607 2014] [wsgi:error] [pid 6508] [client
> 192.168.70.22:39545 <http://192.168.70.22:39545>] Truncated or oversized
> response headers received from daemon process 'ipa':
> /usr/share/ipa/wsgi.py, referer: https://ipa.optimcloud.com/ipa/ui/
> [Sat Dec 27 13:21:02.159216 2014] [core:notice] [pid 6499] AH00052:
> child pid 6544 exit signal Segmentation fault (11)
> [Sat Dec 27 13:21:02.161311 2014] [core:notice] [pid 6499] AH00052:
> child pid 6574 exit signal Segmentation fault (11)
> [Sat Dec 27 13:21:03.384996 2014] [wsgi:error] [pid 7288] ipa: INFO: ***
> PROCESS START ***
> [Sat Dec 27 13:21:03.385754 2014] [wsgi:error] [pid 7287] ipa: INFO: ***
> PROCESS START ***
> [Sat Dec 27 13:21:10.286973 2014] [wsgi:error] [pid 7286] [client
> 192.168.70.22:39978 <http://192.168.70.22:39978>] Truncated or oversized
> response headers received from daemon process 'ipa':
> /usr/share/ipa/wsgi.py, referer: https://ipa.optimcloud.com/ipa/ui/
> [Sat Dec 27 13:21:11.172689 2014] [core:notice] [pid 6499] AH00052:
> child pid 7288 exit signal Segmentation fault (11)
> [Sat Dec 27 13:21:12.543688 2014] [wsgi:error] [pid 7301] ipa: INFO: ***
> PROCESS START ***

That's a new one to me. Getting a backtrace from the core would be very
useful.

rob



From rcritten at redhat.com  Sat Dec 27 21:28:34 2014
From: rcritten at redhat.com (Rob Crittenden)
Date: Sat, 27 Dec 2014 16:28:34 -0500
Subject: [Freeipa-users] Importing /etc/sudoers into IPA.
In-Reply-To: <CAPP+0v+Ej6xPzY=-_XRG+4DcX2=rJZoNYRj1Pr82KLyeVCAW2Q@mail.gmail.com>
References: <CAPP+0vLQVd-m9ihRkRe1arbM+T7RpML51xT2rNutwzDvLLXZaw@mail.gmail.com>	<BLUPR08MB48883A57BBC9C0F2AECCFECB3560@BLUPR08MB488.namprd08.prod.outlook.com>
	<CAPP+0v+Ej6xPzY=-_XRG+4DcX2=rJZoNYRj1Pr82KLyeVCAW2Q@mail.gmail.com>
Message-ID: <549F2482.9090408@redhat.com>

Genadi Postrilko wrote:
> I'm not sure i understand what you mean.

IPA uses its own schema for sudo so the script will not work. I haven't
looked at it so don't know what amount of effort would be needed to make
it work.

You can create the sudo commands and rules but in order to associate
user and groups with the rules they will need to exist.

How many rules are we talking about?

rob

>
> 2014-12-22 22:50 GMT+02:00 Craig White <CWhite at skytouchtechnology.com
> <mailto:CWhite at skytouchtechnology.com>>:
> 
>     I would not recommend that path with FreeIPA.____
> 
>     __ __
> 
>     This is clearly the way to go with FreeIPA____
> 
>     __ __
> 
>     https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/sudo.html____
> 
>     __ __
> 
>     Craig White____
> 
>     System Administrator____
> 
>     O623-201-8179   M602-377-9752____
> 
>     __ __
> 
>     cid:image001.png at 01CF86FE.42D51630____
> 
>     __ __
> 
>     SkyTouch Technology     4225 E. Windrose Dr.     Phoenix, AZ 85032____
> 
>     __ __
> 
>     *From:*freeipa-users-bounces at redhat.com
>     <mailto:freeipa-users-bounces at redhat.com>
>     [mailto:freeipa-users-bounces at redhat.com
>     <mailto:freeipa-users-bounces at redhat.com>] *On Behalf Of *Genadi
>     Postrilko
>     *Sent:* Monday, December 22, 2014 1:38 PM
>     *To:* freeipa-users at redhat.com <mailto:freeipa-users at redhat.com>
>     *Subject:* [Freeipa-users] Importing /etc/sudoers into IPA.____
> 
>     __ __
> 
>     Hello All.____
> 
>     __ __
> 
>     I'm planning to migrate the /etc/sudoers into the IPA.____
> 
>     I have read that sudoers2ldif should be used to import /etc/sudoers
>     into LDAP.____
> 
>     http://www.sudo.ws/sudo/readme_ldap.html ____
> 
>     The script will work as is? or changes should be add?____
> 
>     Should the users and group mentioned in sudoers be created
>     beforehand?____
> 
>     __ __
> 
>     Thanks,____
> 
>     Genadi.____
> 
> 
> 
> 



From outbackdingo at gmail.com  Sat Dec 27 23:34:31 2014
From: outbackdingo at gmail.com (Outback Dingo)
Date: Sun, 28 Dec 2014 10:34:31 +1100
Subject: [Freeipa-users] IPA UI Internal Server Error
In-Reply-To: <549F2300.5080702@redhat.com>
References: <CAKYr3zzjoYkpA9teO+FFWqJoSW1W_JZHGy8o9mNAx7uCJ4Js_g@mail.gmail.com>
	<549F2300.5080702@redhat.com>
Message-ID: <CAKYr3zxgcmZvtZCAT=5eoT2yBGbrFSTXU2JNLkSCMXLgJeBqYQ@mail.gmail.com>

On Sun, Dec 28, 2014 at 8:22 AM, Rob Crittenden <rcritten at redhat.com> wrote:

> Outback Dingo wrote:
> > So Ive installed a new IPA today on Fedora 21 the gui is throwing
> > internal server errors
> > uname -a
> > Linux ipa.optimcloud.com <http://ipa.optimcloud.com>
> > 3.17.7-300.fc21.x86_64 #1 SMP Wed Dec 17 03:08:44 UTC 2014 x86_64 x86_64
> > x86_64 GNU/Linux
> > cat /etc/redhat-release
> > Fedora release 21 (Twenty One)
> > anyone seen this before? is there a fix ?
> >
> > [Sat Dec 27 13:21:01.443607 2014] [wsgi:error] [pid 6508] [client
> > 192.168.70.22:39545 <http://192.168.70.22:39545>] Truncated or oversized
> > response headers received from daemon process 'ipa':
> > /usr/share/ipa/wsgi.py, referer: https://ipa.optimcloud.com/ipa/ui/
> > [Sat Dec 27 13:21:02.159216 2014] [core:notice] [pid 6499] AH00052:
> > child pid 6544 exit signal Segmentation fault (11)
> > [Sat Dec 27 13:21:02.161311 2014] [core:notice] [pid 6499] AH00052:
> > child pid 6574 exit signal Segmentation fault (11)
> > [Sat Dec 27 13:21:03.384996 2014] [wsgi:error] [pid 7288] ipa: INFO: ***
> > PROCESS START ***
> > [Sat Dec 27 13:21:03.385754 2014] [wsgi:error] [pid 7287] ipa: INFO: ***
> > PROCESS START ***
> > [Sat Dec 27 13:21:10.286973 2014] [wsgi:error] [pid 7286] [client
> > 192.168.70.22:39978 <http://192.168.70.22:39978>] Truncated or oversized
> > response headers received from daemon process 'ipa':
> > /usr/share/ipa/wsgi.py, referer: https://ipa.optimcloud.com/ipa/ui/
> > [Sat Dec 27 13:21:11.172689 2014] [core:notice] [pid 6499] AH00052:
> > child pid 7288 exit signal Segmentation fault (11)
> > [Sat Dec 27 13:21:12.543688 2014] [wsgi:error] [pid 7301] ipa: INFO: ***
> > PROCESS START ***
>
> That's a new one to me. Getting a backtrace from the core would be very
> useful.
>
>
Question is wheres the core file... i dont see one



> rob
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141228/8251af57/attachment.htm>

From abokovoy at redhat.com  Sun Dec 28 07:25:13 2014
From: abokovoy at redhat.com (Alexander Bokovoy)
Date: Sun, 28 Dec 2014 02:25:13 -0500 (EST)
Subject: [Freeipa-users] IPA UI Internal Server Error
In-Reply-To: <549F2300.5080702@redhat.com>
References: <CAKYr3zzjoYkpA9teO+FFWqJoSW1W_JZHGy8o9mNAx7uCJ4Js_g@mail.gmail.com>
	<549F2300.5080702@redhat.com>
Message-ID: <1778982189.2087034.1419751513820.JavaMail.zimbra@redhat.com>



----- Original Message -----
> Outback Dingo wrote:
> > So Ive installed a new IPA today on Fedora 21 the gui is throwing
> > internal server errors
> > uname -a
> > Linux ipa.optimcloud.com <http://ipa.optimcloud.com>
> > 3.17.7-300.fc21.x86_64 #1 SMP Wed Dec 17 03:08:44 UTC 2014 x86_64 x86_64
> > x86_64 GNU/Linux
> > cat /etc/redhat-release
> > Fedora release 21 (Twenty One)
> > anyone seen this before? is there a fix ?
> > 
> > [Sat Dec 27 13:21:01.443607 2014] [wsgi:error] [pid 6508] [client
> > 192.168.70.22:39545 <http://192.168.70.22:39545>] Truncated or oversized
> > response headers received from daemon process 'ipa':
> > /usr/share/ipa/wsgi.py, referer: https://ipa.optimcloud.com/ipa/ui/
> > [Sat Dec 27 13:21:02.159216 2014] [core:notice] [pid 6499] AH00052:
> > child pid 6544 exit signal Segmentation fault (11)
> > [Sat Dec 27 13:21:02.161311 2014] [core:notice] [pid 6499] AH00052:
> > child pid 6574 exit signal Segmentation fault (11)
> > [Sat Dec 27 13:21:03.384996 2014] [wsgi:error] [pid 7288] ipa: INFO: ***
> > PROCESS START ***
> > [Sat Dec 27 13:21:03.385754 2014] [wsgi:error] [pid 7287] ipa: INFO: ***
> > PROCESS START ***
> > [Sat Dec 27 13:21:10.286973 2014] [wsgi:error] [pid 7286] [client
> > 192.168.70.22:39978 <http://192.168.70.22:39978>] Truncated or oversized
> > response headers received from daemon process 'ipa':
> > /usr/share/ipa/wsgi.py, referer: https://ipa.optimcloud.com/ipa/ui/
> > [Sat Dec 27 13:21:11.172689 2014] [core:notice] [pid 6499] AH00052:
> > child pid 7288 exit signal Segmentation fault (11)
> > [Sat Dec 27 13:21:12.543688 2014] [wsgi:error] [pid 7301] ipa: INFO: ***
> > PROCESS START ***
> 
> That's a new one to me. Getting a backtrace from the core would be very
> useful.
If this is with httpd 2.4.10-15 from testing, then downgrade httpd to 2.4.10-9 from stable.
I've encountered it as well, 2.4.10-15.fc21 breaks mod_wsgi.
https://admin.fedoraproject.org/updates/FEDORA-2014-17195/httpd-2.4.10-15.fc21

-- 
/ Alexander Bokovoy



From genadipost at gmail.com  Sun Dec 28 09:04:42 2014
From: genadipost at gmail.com (Genadi Postrilko)
Date: Sun, 28 Dec 2014 11:04:42 +0200
Subject: [Freeipa-users] Importing /etc/sudoers into IPA.
In-Reply-To: <549F2482.9090408@redhat.com>
References: <CAPP+0vLQVd-m9ihRkRe1arbM+T7RpML51xT2rNutwzDvLLXZaw@mail.gmail.com>
	<BLUPR08MB48883A57BBC9C0F2AECCFECB3560@BLUPR08MB488.namprd08.prod.outlook.com>
	<CAPP+0v+Ej6xPzY=-_XRG+4DcX2=rJZoNYRj1Pr82KLyeVCAW2Q@mail.gmail.com>
	<549F2482.9090408@redhat.com>
Message-ID: <CAPP+0vKG6HBWrSmkx9mky9QtGOYEC2iA9pZQCBH2_gwgiJ7VNw@mail.gmail.com>

Thanks you for the response.

The amount of rules is :
50+ Host_Alias
50+ User_Alias
10+ Runas_Alias
450+ Cmnd_Alias

The user/groups --> command mapping itself is about 50 more rules.

2014-12-27 23:28 GMT+02:00 Rob Crittenden <rcritten at redhat.com>:

> Genadi Postrilko wrote:
> > I'm not sure i understand what you mean.
>
> IPA uses its own schema for sudo so the script will not work. I haven't
> looked at it so don't know what amount of effort would be needed to make
> it work.
>
> You can create the sudo commands and rules but in order to associate
> user and groups with the rules they will need to exist.
>
> How many rules are we talking about?
>
> rob
>
> >
> > 2014-12-22 22:50 GMT+02:00 Craig White <CWhite at skytouchtechnology.com
> > <mailto:CWhite at skytouchtechnology.com>>:
> >
> >     I would not recommend that path with FreeIPA.____
> >
> >     __ __
> >
> >     This is clearly the way to go with FreeIPA____
> >
> >     __ __
> >
> >
> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/sudo.html____
> >
> >     __ __
> >
> >     Craig White____
> >
> >     System Administrator____
> >
> >     O623-201-8179   M602-377-9752____
> >
> >     __ __
> >
> >     cid:image001.png at 01CF86FE.42D51630____
> >
> >     __ __
> >
> >     SkyTouch Technology     4225 E. Windrose Dr.     Phoenix, AZ
> 85032____
> >
> >     __ __
> >
> >     *From:*freeipa-users-bounces at redhat.com
> >     <mailto:freeipa-users-bounces at redhat.com>
> >     [mailto:freeipa-users-bounces at redhat.com
> >     <mailto:freeipa-users-bounces at redhat.com>] *On Behalf Of *Genadi
> >     Postrilko
> >     *Sent:* Monday, December 22, 2014 1:38 PM
> >     *To:* freeipa-users at redhat.com <mailto:freeipa-users at redhat.com>
> >     *Subject:* [Freeipa-users] Importing /etc/sudoers into IPA.____
> >
> >     __ __
> >
> >     Hello All.____
> >
> >     __ __
> >
> >     I'm planning to migrate the /etc/sudoers into the IPA.____
> >
> >     I have read that sudoers2ldif should be used to import /etc/sudoers
> >     into LDAP.____
> >
> >     http://www.sudo.ws/sudo/readme_ldap.html ____
> >
> >     The script will work as is? or changes should be add?____
> >
> >     Should the users and group mentioned in sudoers be created
> >     beforehand?____
> >
> >     __ __
> >
> >     Thanks,____
> >
> >     Genadi.____
> >
> >
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141228/dafeb6f9/attachment.htm>

From outbackdingo at gmail.com  Sun Dec 28 11:17:12 2014
From: outbackdingo at gmail.com (Outback Dingo)
Date: Sun, 28 Dec 2014 22:17:12 +1100
Subject: [Freeipa-users] IPA UI Internal Server Error
In-Reply-To: <1778982189.2087034.1419751513820.JavaMail.zimbra@redhat.com>
References: <CAKYr3zzjoYkpA9teO+FFWqJoSW1W_JZHGy8o9mNAx7uCJ4Js_g@mail.gmail.com>
	<549F2300.5080702@redhat.com>
	<1778982189.2087034.1419751513820.JavaMail.zimbra@redhat.com>
Message-ID: <CAKYr3zw2FZJ-ANHaKLLc8cXwUc20crM1djLjjrEWvEW7u4c2Aw@mail.gmail.com>

On Sun, Dec 28, 2014 at 6:25 PM, Alexander Bokovoy <abokovoy at redhat.com>
wrote:

>
>
> ----- Original Message -----
> > Outback Dingo wrote:
> > > So Ive installed a new IPA today on Fedora 21 the gui is throwing
> > > internal server errors
> > > uname -a
> > > Linux ipa.optimcloud.com <http://ipa.optimcloud.com>
> > > 3.17.7-300.fc21.x86_64 #1 SMP Wed Dec 17 03:08:44 UTC 2014 x86_64
> x86_64
> > > x86_64 GNU/Linux
> > > cat /etc/redhat-release
> > > Fedora release 21 (Twenty One)
> > > anyone seen this before? is there a fix ?
> > >
> > > [Sat Dec 27 13:21:01.443607 2014] [wsgi:error] [pid 6508] [client
> > > 192.168.70.22:39545 <http://192.168.70.22:39545>] Truncated or
> oversized
> > > response headers received from daemon process 'ipa':
> > > /usr/share/ipa/wsgi.py, referer: https://ipa.optimcloud.com/ipa/ui/
> > > [Sat Dec 27 13:21:02.159216 2014] [core:notice] [pid 6499] AH00052:
> > > child pid 6544 exit signal Segmentation fault (11)
> > > [Sat Dec 27 13:21:02.161311 2014] [core:notice] [pid 6499] AH00052:
> > > child pid 6574 exit signal Segmentation fault (11)
> > > [Sat Dec 27 13:21:03.384996 2014] [wsgi:error] [pid 7288] ipa: INFO:
> ***
> > > PROCESS START ***
> > > [Sat Dec 27 13:21:03.385754 2014] [wsgi:error] [pid 7287] ipa: INFO:
> ***
> > > PROCESS START ***
> > > [Sat Dec 27 13:21:10.286973 2014] [wsgi:error] [pid 7286] [client
> > > 192.168.70.22:39978 <http://192.168.70.22:39978>] Truncated or
> oversized
> > > response headers received from daemon process 'ipa':
> > > /usr/share/ipa/wsgi.py, referer: https://ipa.optimcloud.com/ipa/ui/
> > > [Sat Dec 27 13:21:11.172689 2014] [core:notice] [pid 6499] AH00052:
> > > child pid 7288 exit signal Segmentation fault (11)
> > > [Sat Dec 27 13:21:12.543688 2014] [wsgi:error] [pid 7301] ipa: INFO:
> ***
> > > PROCESS START ***
> >
> > That's a new one to me. Getting a backtrace from the core would be very
> > useful.
> If this is with httpd 2.4.10-15 from testing, then downgrade httpd to
> 2.4.10-9 from stable.
> I've encountered it as well, 2.4.10-15.fc21 breaks mod_wsgi.
>
> https://admin.fedoraproject.org/updates/FEDORA-2014-17195/httpd-2.4.10-15.fc21


Yupp that did in fact correct my issue also.... IPA appaears okay so far
now after the downgrade


>
>
> --
> / Alexander Bokovoy
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141228/8d57f573/attachment.htm>

From Dan.Watson at bcferries.com  Mon Dec 29 20:40:39 2014
From: Dan.Watson at bcferries.com (Watson, Dan)
Date: Mon, 29 Dec 2014 13:40:39 -0700
Subject: [Freeipa-users] Integration with Solaris 10
Message-ID: <D05BDFB6A6F4EE43ABE62D1A7170AF372960EFCBCA@HEXBCFMBVS01.exchange.bcferries.corp>

Hi All,

I've lurked in the list history and cannot find anyone saying they have gotten login restrictions working with Solaris 10 u8. Has anyone on here successfully configured login restrictions on Solaris 10 u8 through u11? I'm looking for specific instructions from someone who has gotten this to work before.

The two main routes to login restrictions I could find online are Netgroups or conditional ldap queries in ldapclient

I initially tried netgroups but wasn't sure how to trouble shoot when it didn't work. There don't seem to be any user-land tools to query netgroups and further investigation turned up an issue with OpenLDAP. It seems the built-in Solaris 10 ldap client expects schema RFC2307bis and not the OpenLDAP standard RFC2307 (explanation here http://www.openldap.org/lists/openldap-software/200501/msg00309.html). does anyone know if this issue applies to IPA?  Or how I check?

The alternative of passing a restrictive query to ldapclient seems like a good route but doesn't seem to work. The common solution when using the old SunOne directory server was to pass the ldapclient (command line ldap configuration tool) an option like "passwd:ou=people,o=myorg,c=de?one?(isMemberof=cn=unixadmins,ou=groups,o=myorg,c=de)" (from here https://community.oracle.com/thread/2014224?start=0&tstart=0)  which is supposed to restrict account checking to only people in ou=people,p=myorg,c=de who are also members of cn=unixadmins,ou=groups,o=myorg,c=de. Unfortunately this doesn't seem to work in IPA, first of all because there is no "isMemberof" attribute to a user, but also doesn't work on other attributes like uid or uidNumber. One possible explanation I've found is that these attributes are not indexed, but I have no idea if this is correct or how to add them to be indexed.

Has anyone else solved this? I just need to be able to allow only a specific user group to log in to the host, unfortunately the ssh directive "AllowGroups" is not good enough, this has to be system wide as we also have samba and some other services that rely on system authentication.

Can anyone be of some help?

Thanks!
Dan



From dpal at redhat.com  Mon Dec 29 20:54:15 2014
From: dpal at redhat.com (Dmitri Pal)
Date: Mon, 29 Dec 2014 15:54:15 -0500
Subject: [Freeipa-users] how to configure Linux Cent Os as ipa client
 manual installation
In-Reply-To: <CA+C_GOUYUPE6E6+JWQn5kb3b8VGj7U9xpWmvNgs4Tqh4xYYjQw@mail.gmail.com>
References: <CA+C_GOUYUPE6E6+JWQn5kb3b8VGj7U9xpWmvNgs4Tqh4xYYjQw@mail.gmail.com>
Message-ID: <54A1BF77.9040008@redhat.com>

On 12/20/2014 05:02 AM, Ben .T.George wrote:
>
> Hi
>
> I was trying to configure centos as ipa client and got failed with that,.
>
> anyone please help me to configure centos as ipa client through manual 
> configuration.
>
> Regards,
> Ben
>
>
Sorry for a delayed response.
What version of CentOS? What version of the server?
Why manually? On CentOS you can use ipa-client-install and it will do 
the work for you.
What did you do and what did not work?

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141229/1a37315a/attachment.htm>

From dpal at redhat.com  Mon Dec 29 20:59:18 2014
From: dpal at redhat.com (Dmitri Pal)
Date: Mon, 29 Dec 2014 15:59:18 -0500
Subject: [Freeipa-users] how can i configure solaris 10 sparc and x86 as
 ipa clients
In-Reply-To: <20141222005025.GP4163@dhcp-40-8.bne.redhat.com>
References: <CA+C_GOVJp94wVJZ=Ku_d5s3r0iRFSGAEqM68=2XRdBtO85o9pQ@mail.gmail.com>
	<20141222005025.GP4163@dhcp-40-8.bne.redhat.com>
Message-ID: <54A1C0A6.1080006@redhat.com>

On 12/21/2014 07:50 PM, Fraser Tweedale wrote:
> On Sun, Dec 21, 2014 at 09:03:17AM +0300, Ben .T.George wrote:
>> Hi List
>>
>> how can i configure solaris 10 sparc and x86 as ipa clients.
>>
>> Regards,
>> Ben
> Hi Ben,
>
> Please follow the Solaris 8/9/10 instructions on the wiki:
> http://www.freeipa.org/page/ConfiguringUnixClients#Solaris_8.2F9.2F10
>
> Let us know if run into difficulties or if there are error or
> omissions in the instructions.

Also see https://fedorahosted.org/freeipa/ticket/4633

>
> Cheers,
>
> Fraser
>
>> -- 
>> 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


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.



From dpal at redhat.com  Mon Dec 29 21:11:47 2014
From: dpal at redhat.com (Dmitri Pal)
Date: Mon, 29 Dec 2014 16:11:47 -0500
Subject: [Freeipa-users] Practical and theoretical limits of FreeIPA
In-Reply-To: <CAEiui-uddQjmjyCOD6PsSSmpn2xNXwt3+10w1858wM1vgE9m+A@mail.gmail.com>
References: <CAEiui-uddQjmjyCOD6PsSSmpn2xNXwt3+10w1858wM1vgE9m+A@mail.gmail.com>
Message-ID: <54A1C393.6030705@redhat.com>

TOn 12/22/2014 10:38 AM, Andrew Holway wrote:
> So I am looking at ways of building a distributed user database for 
> millions of users (specifically 5 million at the moment) and I am 
> thinking that freeIPA might be a good thing to test for this kind of 
> use case. I would assume that at least a third of these users would 
> want to authenticate every day however updates of data held in the 
> database would probably be quite rare.
>
> We need to have endpoints in a few regions and the Multi Master 
> Replication would take care of the back end problem for us quite well.
>
> Does anyone have any data on using freeIPA for this kind of thing. 
> What would be the caveats?

LDAP will be able to handle this amount of data however there are 
several recommendation other than what you can find here:
http://www.freeipa.org/page/Deployment_Recommendations

1. User account creation and modification.
If users are enrolled automatically and is expected to operate right 
away after the account is created you need to make sure you understand 
the latency of the LDAP replication.
Think about keeping affinity to a single server for the first user 
session. For modifications consider also keeping affinity to a separate 
server and not allow modifications to random replicas.
This approach will prevent random failures and negative user experience 
due to replication latency.
It is not an IPA recommendation BTW but rather a general LDAP related 
wizardry.
2. Make sure you have enough replicas but not too many. You would need 
to test your environment depending on the number of data centers across 
the globe and how users are distributed around the world.

Seems like a big project for some kind of online community. Any chance 
you can share more details?

We would not be surprised if there would be issues as you ramp up the 
environment.
To address environments like this we plan to change LDAP DB from BDB to 
MDB some time next year.
I suspect that as you grow your environment over time you should 
consider upgrading to the version that would implement this change.

>
> Thanks,
>
> Andrew
>
>


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141229/82306418/attachment.htm>

From dpal at redhat.com  Mon Dec 29 21:17:34 2014
From: dpal at redhat.com (Dmitri Pal)
Date: Mon, 29 Dec 2014 16:17:34 -0500
Subject: [Freeipa-users] IPA/Kerberos5 and Upper Case/Lower-case
	Hostnames
In-Reply-To: <CAFKCRV+GBrW=L64CzfT2eWtvReg9ADVVePKezxUKKghsBn-A1w@mail.gmail.com>
References: <CAFKCRV+GBrW=L64CzfT2eWtvReg9ADVVePKezxUKKghsBn-A1w@mail.gmail.com>
Message-ID: <54A1C4EE.3070106@redhat.com>

On 12/24/2014 01:04 AM, Traiano Welcome wrote:
> Hi List
>
> I have a large number of legacy hosts with upper-case host names, that
> I'd like to configure as IPA clients. However ipa client refuses to
> accept upper case hostnames during configuration time.
>
> I think this derives from the fact that the kerberos5 database stores
> host names in a case sensitive way and requires that the DNS hostname
> matches the server hostname case.
>
> My question is: Is it mandatory that the hostname be lower-cased, or
> is there a safe workaround that will allow IPA client to work with
> hosts that have upper case host names ?
>
> Thanks in advance!
> Traiano
>
See man sssd-ipa

        ipa_hostname (string)
            Optional. May be set on machines where the hostname(5) does 
not reflect the fully qualified name used in the IPA domain to identify this
            host.

AFAIR you use this setting for the cases when you want the actual 
machine name be different than the one IPA has.

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.



From dpal at redhat.com  Mon Dec 29 21:19:23 2014
From: dpal at redhat.com (Dmitri Pal)
Date: Mon, 29 Dec 2014 16:19:23 -0500
Subject: [Freeipa-users] Read Only LDAP Replicas
In-Reply-To: <CAN9aUrhZGmoTParWEQCKP6dymKbWVWNCTvS00LRg2c0bu6GLpg@mail.gmail.com>
References: <CAN9aUrhZGmoTParWEQCKP6dymKbWVWNCTvS00LRg2c0bu6GLpg@mail.gmail.com>
Message-ID: <54A1C55B.7050606@redhat.com>

On 12/27/2014 01:19 AM, Prashant Bapat wrote:
> Hi All,
>
> I'm trying to implement FreeIPA for Users and SSH pub keys management 
> in our infra. We have a setup that spans multiple geographies. What we 
> are thinking is something like below.
>
> 1. Have 2 full FreeIPA servers with multi master replicas in one region.
> 2. In other regions just have a LDAP read-only replica.
> 3. Use the AuthorizedKeysCommand in SSH to look for a users pub key in 
> the respective region's LDAP.
>
> Has anyone tried something on these lines?
>
> Please share your experiences.
>
> Thanks.
> --Prashant
>
>

IPA does not support read only replicas at this time.
This would be a significant effort that we probably would not have time 
to focus on till 2016-2017.

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141229/c05f4057/attachment.htm>

From dpal at redhat.com  Mon Dec 29 21:22:18 2014
From: dpal at redhat.com (Dmitri Pal)
Date: Mon, 29 Dec 2014 16:22:18 -0500
Subject: [Freeipa-users] Integration with Solaris 10
In-Reply-To: <D05BDFB6A6F4EE43ABE62D1A7170AF372960EFCBCA@HEXBCFMBVS01.exchange.bcferries.corp>
References: <D05BDFB6A6F4EE43ABE62D1A7170AF372960EFCBCA@HEXBCFMBVS01.exchange.bcferries.corp>
Message-ID: <54A1C60A.2010705@redhat.com>

On 12/29/2014 03:40 PM, Watson, Dan wrote:
> Hi All,
>
> I've lurked in the list history and cannot find anyone saying they have gotten login restrictions working with Solaris 10 u8. Has anyone on here successfully configured login restrictions on Solaris 10 u8 through u11? I'm looking for specific instructions from someone who has gotten this to work before.
>
> The two main routes to login restrictions I could find online are Netgroups or conditional ldap queries in ldapclient
>
> I initially tried netgroups but wasn't sure how to trouble shoot when it didn't work. There don't seem to be any user-land tools to query netgroups and further investigation turned up an issue with OpenLDAP. It seems the built-in Solaris 10 ldap client expects schema RFC2307bis and not the OpenLDAP standard RFC2307 (explanation here http://www.openldap.org/lists/openldap-software/200501/msg00309.html). does anyone know if this issue applies to IPA?  Or how I check?
>
> The alternative of passing a restrictive query to ldapclient seems like a good route but doesn't seem to work. The common solution when using the old SunOne directory server was to pass the ldapclient (command line ldap configuration tool) an option like "passwd:ou=people,o=myorg,c=de?one?(isMemberof=cn=unixadmins,ou=groups,o=myorg,c=de)" (from here https://community.oracle.com/thread/2014224?start=0&tstart=0)  which is supposed to restrict account checking to only people in ou=people,p=myorg,c=de who are also members of cn=unixadmins,ou=groups,o=myorg,c=de. Unfortunately this doesn't seem to work in IPA, first of all because there is no "isMemberof" attribute to a user, but also doesn't work on other attributes like uid or uidNumber. One possible explanation I've found is that these attributes are not indexed, but I have no idea if this is correct or how to add them to be indexed.
>
> Has anyone else solved this? I just need to be able to allow only a specific user group to log in to the host, unfortunately the ssh directive "AllowGroups" is not good enough, this has to be system wide as we also have samba and some other services that rely on system authentication.
>
> Can anyone be of some help?
>
> Thanks!
> Dan
>
Did you try this?
https://fedorahosted.org/freeipa/ticket/4633

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.



From bpk678 at gmail.com  Mon Dec 29 21:47:23 2014
From: bpk678 at gmail.com (Brendan Kearney)
Date: Mon, 29 Dec 2014 16:47:23 -0500
Subject: [Freeipa-users] bind-dyndb-ldap and ddns updates from dhcp
Message-ID: <1419889643.23227.22.camel@desktop.bpk2.com>

where can i find howto info around setting up bind-dyndb-ldap to accept
ddns updates from dhcp?  usually, i have a shared key defined in dns and
dhcp, and the updates are authenticated.  where are the docs for setting
this up in bind-dyndb-ldap?



From dpal at redhat.com  Mon Dec 29 21:53:18 2014
From: dpal at redhat.com (Dmitri Pal)
Date: Mon, 29 Dec 2014 16:53:18 -0500
Subject: [Freeipa-users] bind-dyndb-ldap and ddns updates from dhcp
In-Reply-To: <1419889643.23227.22.camel@desktop.bpk2.com>
References: <1419889643.23227.22.camel@desktop.bpk2.com>
Message-ID: <54A1CD4E.9020704@redhat.com>

On 12/29/2014 04:47 PM, Brendan Kearney wrote:
> where can i find howto info around setting up bind-dyndb-ldap to accept
> ddns updates from dhcp?  usually, i have a shared key defined in dns and
> dhcp, and the updates are authenticated.  where are the docs for setting
> this up in bind-dyndb-ldap?
>
I am not sure I understand the use case correctly.
bind-dyndb-ldap isa back end driver for BIND to get data from an LDAP 
storage.
The updates are done by BIND. The IPA BIND accepts kerberos based updates.

http://www.freeipa.org/page/FreeIPAv2:Dynamic_updates_with_GSS-TSIG

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.



From yamakasi.014 at gmail.com  Mon Dec 29 22:09:07 2014
From: yamakasi.014 at gmail.com (Matt .)
Date: Mon, 29 Dec 2014 23:09:07 +0100
Subject: [Freeipa-users] KDC has no support for encryption type
Message-ID: <CAPNQp07PeB0bZd_Q3Z3mDV8P+BQsmf0ek2hOfvT+KMAHkR=cXg@mail.gmail.com>

Hi All,

Why doing some IPA commands on my 4.1.2 install I get the following error:


ipa: ERROR: Kerberos error: Kerberos error: ('Unspecified GSS failure.
Minor code may provide more
                  information', 851968)/('KDC has no support for
encryption type', -1765328370)/

I already tried to add this to my [libdefaults] in my krb5.conf:


[libdefaults]
 ...
allow_weak_crypto = yes
default_tkt_enctypes = RC4-HMAC, DES-CBC-CRC, DES3-CBC-SHA1,DES-CBC-MD5
default_tgs_enctypes = RC4-HMAC, DES-CBC-CRC, DES3-CBC-SHA1, DES-CBC-MD5

But this doesn't seem to fix it.

Is this still the known bug in 4.x ?

And can I fix it ?

Thanks!

Matt



From dpal at redhat.com  Mon Dec 29 22:23:35 2014
From: dpal at redhat.com (Dmitri Pal)
Date: Mon, 29 Dec 2014 17:23:35 -0500
Subject: [Freeipa-users] KDC has no support for encryption type
In-Reply-To: <CAPNQp07PeB0bZd_Q3Z3mDV8P+BQsmf0ek2hOfvT+KMAHkR=cXg@mail.gmail.com>
References: <CAPNQp07PeB0bZd_Q3Z3mDV8P+BQsmf0ek2hOfvT+KMAHkR=cXg@mail.gmail.com>
Message-ID: <54A1D467.5040800@redhat.com>

On 12/29/2014 05:09 PM, Matt . wrote:
> Hi All,
>
> Why doing some IPA commands on my 4.1.2 install I get the following error:
>
>
> ipa: ERROR: Kerberos error: Kerberos error: ('Unspecified GSS failure.
> Minor code may provide more
>                    information', 851968)/('KDC has no support for
> encryption type', -1765328370)/
>
> I already tried to add this to my [libdefaults] in my krb5.conf:
>
>
> [libdefaults]
>   ...
> allow_weak_crypto = yes
> default_tkt_enctypes = RC4-HMAC, DES-CBC-CRC, DES3-CBC-SHA1,DES-CBC-MD5
> default_tgs_enctypes = RC4-HMAC, DES-CBC-CRC, DES3-CBC-SHA1, DES-CBC-MD5

I am not sure about spaces but I suspect it is OK.
What is not OK is probably that you not listed all other encryption 
types that IPA assumes.
If you need weaker ciphers you need to list them in addition to the 
strong ones.

http://web.mit.edu/kerberos/krb5-1.13/doc/admin/conf_files/krb5_conf.html

>
> But this doesn't seem to fix it.
>
> Is this still the known bug in 4.x ?
>
> And can I fix it ?
>
> Thanks!
>
> Matt
>


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.



From yamakasi.014 at gmail.com  Mon Dec 29 22:31:49 2014
From: yamakasi.014 at gmail.com (Matt .)
Date: Mon, 29 Dec 2014 23:31:49 +0100
Subject: [Freeipa-users] KDC has no support for encryption type
In-Reply-To: <54A1D467.5040800@redhat.com>
References: <CAPNQp07PeB0bZd_Q3Z3mDV8P+BQsmf0ek2hOfvT+KMAHkR=cXg@mail.gmail.com>
	<54A1D467.5040800@redhat.com>
Message-ID: <CAPNQp06gouNBHS_y7VKbrdjA4pBc692o9-R9TOacdA2QYTtn9w@mail.gmail.com>

OK, thank for that.

But should an IPA install not add them by default ? Maybe this is some
4.x dev which is still needed ?

I need to look what I exactly need.



From Dan.Watson at bcferries.com  Tue Dec 30 00:08:14 2014
From: Dan.Watson at bcferries.com (Watson, Dan)
Date: Mon, 29 Dec 2014 17:08:14 -0700
Subject: [Freeipa-users] Integration with Solaris 10
Message-ID: <D05BDFB6A6F4EE43ABE62D1A7170AF372960EFCD2F@HEXBCFMBVS01.exchange.bcferries.corp>

On 12/29/2014 4:22 PM, Pal, Dmitri wrote:
>On 12/29/2014 03:40 PM, Watson, Dan wrote:
>> Hi All,
>>
>> I've lurked in the list history and cannot find anyone saying they have gotten login restrictions working with Solaris 10 u8. Has anyone on here successfully configured login restrictions on Solaris 10 u8 through u11? I'm looking for specific instructions from someone who has gotten this to work before.
>>
>> The two main routes to login restrictions I could find online are Netgroups or conditional ldap queries in ldapclient
>>
>> I initially tried netgroups but wasn't sure how to trouble shoot when it didn't work. There don't seem to be any user-land tools to query netgroups and further investigation turned up an issue with OpenLDAP. It seems the built-in Solaris 10 ldap client expects schema RFC2307bis and not the OpenLDAP standard RFC2307 (explanation here http://www.openldap.org/lists/openldap-software/200501/msg00309.html). does anyone know if this issue applies to IPA?  Or how I check?
>>
>> The alternative of passing a restrictive query to ldapclient seems like a good route but doesn't seem to work. The common solution when using the old SunOne directory server was to pass the ldapclient (command line ldap configuration tool) an option like "passwd:ou=people,o=myorg,c=de?one?(isMemberof=cn=unixadmins,ou=groups,o=myorg,c=de)" (from here https://community.oracle.com/thread/2014224?start=0&tstart=0)  which is supposed to restrict account checking to only people in ou=people,p=myorg,c=de who are also members of cn=unixadmins,ou=groups,o=myorg,c=de. Unfortunately this doesn't seem to work in IPA, first of all because there is no "isMemberof" attribute to a user, but also doesn't work on other attributes like uid or uidNumber. One possible explanation I've found is that these attributes are not indexed, but I have no idea if this is correct or how to add them to be indexed.
>>
>> Has anyone else solved this? I just need to be able to allow only a specific user group to log in to the host, unfortunately the ssh directive "AllowGroups" is not good enough, this has to be system wide as we also have samba and some other services that rely on system authentication.
>>
>> Can anyone be of some help?
>>
>> Thanks!
>> Dan
>>
>Did you try this?
>https://fedorahosted.org/freeipa/ticket/4633
That ticket and all the ones referenced in it are all about setting up basic connectivity to IPA, including secure connections. They do not deal with login restrictions at all. I am already logging in and authenticating fine, but I am lacking any way to restrict logins to a subset of all user accounts in IPA.

>
>-- 
>Thank you,
>Dmitri Pal
>
>Sr. Engineering Manager IdM portfolio
>Red Hat, Inc.

Can you direct me to finding out if the schema matches RFC2307bis? Or how to modify it to work with RFC2307bis?

Has anyone gotten LDAP restrictions working? Or netgroups?

Thanks!
Dan



From bpk678 at gmail.com  Tue Dec 30 00:12:26 2014
From: bpk678 at gmail.com (Brendan Kearney)
Date: Mon, 29 Dec 2014 19:12:26 -0500
Subject: [Freeipa-users] bind-dyndb-ldap and ddns updates from dhcp
In-Reply-To: <54A1CD4E.9020704@redhat.com>
References: <1419889643.23227.22.camel@desktop.bpk2.com>
	<54A1CD4E.9020704@redhat.com>
Message-ID: <1419898346.23227.33.camel@desktop.bpk2.com>

On Mon, 2014-12-29 at 16:53 -0500, Dmitri Pal wrote:
> On 12/29/2014 04:47 PM, Brendan Kearney wrote:
> > where can i find howto info around setting up bind-dyndb-ldap to accept
> > ddns updates from dhcp?  usually, i have a shared key defined in dns and
> > dhcp, and the updates are authenticated.  where are the docs for setting
> > this up in bind-dyndb-ldap?
> >
> I am not sure I understand the use case correctly.
> bind-dyndb-ldap isa back end driver for BIND to get data from an LDAP 
> storage.
> The updates are done by BIND. The IPA BIND accepts kerberos based updates.
> 
> http://www.freeipa.org/page/FreeIPAv2:Dynamic_updates_with_GSS-TSIG
> 
> -- 
> Thank you,
> Dmitri Pal
> 
> Sr. Engineering Manager IdM portfolio
> Red Hat, Inc.
> 

this allows for a ticketed client to update DNS records directly, which
is not a best practice and is a huge security risk.  clients should not
be able to manipulate DNS zones.

dynamic updates to DNS zones should come from DHCP, where dynamic
addressing is managed.  as such, i have directives in DHCP and DNS to
establish authenticated updates between DHCP and DNS.  for example:

/etc/named.conf:

key "dhcp" {
        algorithm hmac-md5;
        secret SomeRandomString;
};
...
zone "1.168.192.in-addr.arpa" IN {
	type master;
	file "dynamic/1.168.192.in-addr.arpa.db";
	allow-update { key dhcp; };
};

zone "bpk2.com" IN {
	type master;
	file "dynamic/bpk2.com.db";
	check-names ignore;
	allow-update { key dhcp; };
};

/etc/dhcp/dhcpd.conf

key "dhcp"{
        algorithm hmac-md5;
        secret SomeRandomString;
};

zone 1.168.192.in-addr.arpa {
        primary 192.168.1.1;
        key dhcp;
}

zone bpk2.com {
        primary 192.168.1.1;
        key dhcp;
}

because the DHCP daemon is not kerberized, the update policies do not
seem to cover the situation where clients are not allowed to update DNS
zones themselves.

i am wondering how to manage DDNS updates from DHCP, where kerberized
updates are not likely going to happen.



From yamakasi.014 at gmail.com  Tue Dec 30 11:06:40 2014
From: yamakasi.014 at gmail.com (Matt .)
Date: Tue, 30 Dec 2014 12:06:40 +0100
Subject: [Freeipa-users] KDC has no support for encryption type
In-Reply-To: <CAPNQp06gouNBHS_y7VKbrdjA4pBc692o9-R9TOacdA2QYTtn9w@mail.gmail.com>
References: <CAPNQp07PeB0bZd_Q3Z3mDV8P+BQsmf0ek2hOfvT+KMAHkR=cXg@mail.gmail.com>
	<54A1D467.5040800@redhat.com>
	<CAPNQp06gouNBHS_y7VKbrdjA4pBc692o9-R9TOacdA2QYTtn9w@mail.gmail.com>
Message-ID: <CAPNQp06YiZGR3OKm_qCDA=P1pk41jWHoSQzU-9+kdW3a3TfvyQ@mail.gmail.com>

Readin up on this the weak password setting should work, but it doesn't.

What are my chances here as I need to do a "ipa pwpolicy-mod --maxlife 200"

Or can this be done from a ldap browser too ?

2014-12-29 23:31 GMT+01:00 Matt . <yamakasi.014 at gmail.com>:
> OK, thank for that.
>
> But should an IPA install not add them by default ? Maybe this is some
> 4.x dev which is still needed ?
>
> I need to look what I exactly need.



From martin.minkus at corp.sonic.net  Mon Dec 29 22:02:22 2014
From: martin.minkus at corp.sonic.net (Martin Minkus)
Date: Mon, 29 Dec 2014 14:02:22 -0800
Subject: [Freeipa-users] Freeipa 3.3.3 and --external-ca
Message-ID: <54A1CF6E.9080200@corp.sonic.net>

Hi all,

I'm running Freeipa 3.3.3 on CentOS 7.0.

It worked fine self signed but I am having difficulty getting it to work
with --exernal-ca. I've seen a few other reports of this on the list
with no resolution, so I'm not sure whether this is simply broken in
this version or what? Maybe I'm just doing something wrong. :)

>From /var/log/ipaserver-install.log


2014-12-29T21:25:19Z DEBUG Starting external process
2014-12-29T21:25:19Z DEBUG args=/usr/sbin/pkispawn -s CA -f /tmp/tmp00n3qN
2014-12-29T21:25:21Z DEBUG Process finished, return code=1
2014-12-29T21:25:21Z DEBUG stdout=Loading deployment configuration from
/tmp/tmp00n3qN.
Installing CA into /var/lib/pki/pki-tomcat.
loading external CA signing certificate from file: '/root/ipa.crt'
loading external CA signing certificate chain from file: '/tmp/tmpnVtMl7'
Installation failed.


2014-12-29T21:25:21Z DEBUG stderr=pkispawn    : ERROR    .......
Exception from Java Configuration Servlet: Error in creating pkcs12 to
backup keys and certs: org.mozilla.jss.crypto.ObjectNotFoundException

2014-12-29T21:25:21Z CRITICAL failed to configure ca instance Command
'/usr/sbin/pkispawn -s CA -f /tmp/tmp00n3qN' returned non-zero exit status 1
2014-12-29T21:25:21Z DEBUG   File
"/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py",
line 638, in run_script
    return_value = main_function()

  File "/sbin/ipa-server-install", line 1094, in main
    subject_base=options.subject)

  File
"/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line
478, in configure_instance
    self.start_creation(runtime=210)

  File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py",
line 364, in start_creation
    method()

  File
"/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line
615, in __spawn_instance
    raise RuntimeError('Configuration of CA failed')

2014-12-29T21:25:21Z DEBUG The ipa-server-install command failed,
exception: RuntimeError: Configuration of CA failed


>From /var/log/pki/pki-ca-spawn.20141229132519.log

2014-12-29 13:25:19 pkispawn    : INFO     ... skip populating
'pki.deployment.infrastructure_layout'
2014-12-29 13:25:19 pkispawn    : INFO     ... skip populating
'pki.deployment.instance_layout'
2014-12-29 13:25:19 pkispawn    : INFO     ... skip populating
'pki.deployment.subsystem_layout'
2014-12-29 13:25:19 pkispawn    : INFO     ... skip populating
'pki.deployment.selinux_setup'
2014-12-29 13:25:19 pkispawn    : INFO     ... skip deploying
'pki.deployment.webapp_deployment'
2014-12-29 13:25:19 pkispawn    : INFO     ... skip assigning slots for
'pki.deployment.slot_substitution'
2014-12-29 13:25:19 pkispawn    : INFO     ... skip generating
'pki.deployment.security_databases'
2014-12-29 13:25:19 pkispawn    : INFO     ... configuring
'pki.deployment.configuration'
2014-12-29 13:25:19 pkispawn    : INFO     ....... modifying
'/root/.dogtag/pki-tomcat/ca/password.conf'
2014-12-29 13:25:19 pkispawn    : DEBUG    ........... chmod 660
/root/.dogtag/pki-tomcat/ca/password.conf
2014-12-29 13:25:19 pkispawn    : DEBUG    ........... chown 0:0
/root/.dogtag/pki-tomcat/ca/password.conf
2014-12-29 13:25:19 pkispawn    : INFO     ....... modifying
'/root/.dogtag/pki-tomcat/ca/pkcs12_password.conf'
2014-12-29 13:25:19 pkispawn    : DEBUG    ........... chmod 660
/root/.dogtag/pki-tomcat/ca/pkcs12_password.conf
2014-12-29 13:25:19 pkispawn    : DEBUG    ........... chown 992:991
/root/.dogtag/pki-tomcat/ca/pkcs12_password.conf
2014-12-29 13:25:19 pkispawn    : INFO     ....... executing 'certutil
-N -d /tmp/tmp-s1tfK9 -f /root/.dogtag/pki-tomcat/ca/password.conf'
2014-12-29 13:25:19 pkispawn    : INFO     ....... executing 'systemctl
start pki-tomcatd at pki-tomcat.service'
2014-12-29 13:25:19 pkispawn    : DEBUG    ........... <?xml
version="1.0" encoding="UTF-8"
standalone="no"?><XMLResponse><State>0</State><Type>CA</Type><Status>running</Status><Version>10.0.5-3.el7</Version></XMLResponse>
2014-12-29 13:25:20 pkispawn    : INFO     ....... constructing PKI
configuration data.
2014-12-29 13:25:20 pkispawn    : INFO     ....... generating noise file
called '/tmp/tmp-s1tfK9/noise' and filling it with '2048' random bytes
2014-12-29 13:25:20 pkispawn    : DEBUG    ........... chmod 660
/tmp/tmp-s1tfK9/noise
2014-12-29 13:25:20 pkispawn    : DEBUG    ........... chown 992:991
/tmp/tmp-s1tfK9/noise
2014-12-29 13:25:20 pkispawn    : INFO     ....... executing
'['certutil', '-R', '-d', '/tmp/tmp-s1tfK9', '-s',
'cn=ipa-ca-agent,O=IPA.SONIC.NET', '-g', '2048', '-z',
'/tmp/tmp-s1tfK9/noise', '-f',
'/root/.dogtag/pki-tomcat/ca/password.conf', '-o',
'/tmp/tmp-s1tfK9/admin_pkcs10.bin']'
2014-12-29 13:25:20 pkispawn    : INFO     ....... ['BtoA',
'/tmp/tmp-s1tfK9/admin_pkcs10.bin', '/tmp/tmp-s1tfK9/admin_pkcs10.bin.asc']
2014-12-29 13:25:21 pkispawn    : INFO     ....... configuring PKI
configuration data.
2014-12-29 13:25:21 pkispawn    : ERROR    ....... Exception from Java
Configuration Servlet: Error in creating pkcs12 to backup keys and
certs: org.mozilla.jss.crypto.ObjectNotFoundException
2014-12-29 13:25:21 pkispawn    : DEBUG    ....... Error Type: HTTPError
2014-12-29 13:25:21 pkispawn    : DEBUG    ....... Error Message: 500
Server Error: Internal Server Error
2014-12-29 13:25:21 pkispawn    : DEBUG    .......   File
"/usr/sbin/pkispawn", line 374, in main
    rv = instance.spawn()
  File
"/usr/lib/python2.7/site-packages/pki/deployment/configuration.py", line
128, in spawn
    json.dumps(data, cls=pki.encoder.CustomTypeEncoder))
  File "/usr/lib/python2.7/site-packages/pki/deployment/pkihelper.py",
line 2998, in configure_pki_data
    response = client.configure(data)
  File "/usr/lib/python2.7/site-packages/pki/system.py", line 80, in
configure
    r = self.connection.post('/rest/installer/configure', data, headers)
  File "/usr/lib/python2.7/site-packages/pki/client.py", line 64, in post
    r.raise_for_status()
  File "/usr/lib/python2.7/site-packages/requests/models.py", line 638,
in raise_for_status
    raise http_error


>From /var/log/pki/pki-tomcat/catalina.out

SSLAuthenticatorWithFallback: Creating SSL authenticator with fallback
SSLAuthenticatorWithFallback: Setting container
SSLAuthenticatorWithFallback: Initializing authenticators
SSLAuthenticatorWithFallback: Starting authenticators
CMS Warning: FAILURE: Cannot build CA chain. Error
java.security.cert.CertificateException: Certificate is not a PKCS #11
certificate|FAILURE: authz instance DirAclAut
hz initialization failed and skipped, error=Property
internaldb.ldapconn.port missing value|
Server is started.
Dec 29, 2014 1:16:00 PM org.apache.coyote.AbstractProtocol start
INFO: Starting ProtocolHandler ["http-bio-8080"]
Dec 29, 2014 1:16:00 PM org.apache.coyote.AbstractProtocol start
INFO: Starting ProtocolHandler ["http-bio-8443"]
Dec 29, 2014 1:16:00 PM org.apache.coyote.AbstractProtocol start
INFO: Starting ProtocolHandler ["ajp-bio-127.0.0.1-8009"]
Dec 29, 2014 1:16:00 PM org.apache.catalina.startup.Catalina start
INFO: Server startup in 6906 ms
13:16:02,887  INFO
(org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher:82) -
Deploying javax.ws.rs.core.Application: class com.netscape.ca.Certificat
eAuthorityApplication
13:16:02,900  INFO
(org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher:82) -
Adding singleton provider com.netscape.certsrv.acls.ACLInterceptor from
Application javax.ws.rs.core.Application
13:16:02,901  INFO
(org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher:82) -
Adding singleton provider com.netscape.certsrv.authentication.AuthMethod
Interceptor from Application javax.ws.rs.core.Application
13:16:03,161 DEBUG (org.jboss.resteasy.core.SynchronousDispatcher:60) -
PathInfo: /installer/configure
AuthInterceptor: SystemConfigResource.configure()
AuthInterceptor: mapping name: default
AuthInterceptor: required auth methods: [*]
AuthInterceptor: anonymous access allowed
13:25:21,125 DEBUG (org.jboss.resteasy.core.SynchronousDispatcher:60) -
PathInfo: /installer/configure
AuthInterceptor: SystemConfigResource.configure()
AuthInterceptor: mapping name: default
AuthInterceptor: required auth methods: [*]
AuthInterceptor: anonymous access allowed
java.security.cert.CertificateEncodingException: Security library failed
to decode certificate package: (-8183) security library: improperly
formatted DER-encoded message.
        at org.mozilla.jss.CryptoManager.importCertPackageNative(Native
Method)
        at
org.mozilla.jss.CryptoManager.importCertPackage(CryptoManager.java:1042)


And so on.

openssl x509 -text -in ipa.crt
and
openssl x509 -text -in cacert.pem

Both work and display the signed cert as well as the CA's cert.

I've tried the process a couple times on different lab environments and
always get the exact same result.

I saw an error above about imporperly formatted DER message so I thought
I'd try converting the cacert's certificate from PEM to DER using
something like this:

openssl x509 -in cert.crt -outform der -out cert.der

But this did not fix the problem. In fact, ipa-server-install throws an
error immediately and does not seem to like DER formatted certificates.

Thanks,
Martin.



From Daniel.Hjorth at octanner.com  Tue Dec 30 18:02:45 2014
From: Daniel.Hjorth at octanner.com (Daniel Hjorth)
Date: Tue, 30 Dec 2014 18:02:45 +0000
Subject: [Freeipa-users] Freeipa 3.3.3 and --external-ca
In-Reply-To: <54A1CF6E.9080200@corp.sonic.net>
References: <54A1CF6E.9080200@corp.sonic.net>
Message-ID: <D0C82303.1885%daniel.hjorth@octanner.com>

Hi Martin,

I think I ran into the same problem.  Do you know which signing algorithm
your external CA used?  In my case the external CA is on Server 2003 which
only allowed SHA1 but IPA 3.3.3 seems to require SHA256.

I was not able to get my CA to use SHA256 so I applied the diff from the
commit below:

https://git.fedorahosted.org/cgit/freeipa.git/commit/?id=081580779b2609c3a4
53077042f7d3fc7b25a57d

I then used the "--ca-signing-algorithm=" option when installing IPA.
This may not be the best solution but it worked and I haven?t seen any
issues.

Hope this helps,

Daniel

On 12/29/14, 3:02 PM, "Martin Minkus" <martin.minkus at corp.sonic.net> wrote:

>Hi all,
>
>I'm running Freeipa 3.3.3 on CentOS 7.0.
>
>It worked fine self signed but I am having difficulty getting it to work
>with --exernal-ca. I've seen a few other reports of this on the list
>with no resolution, so I'm not sure whether this is simply broken in
>this version or what? Maybe I'm just doing something wrong. :)
>
>>From /var/log/ipaserver-install.log
>
>
>2014-12-29T21:25:19Z DEBUG Starting external process
>2014-12-29T21:25:19Z DEBUG args=/usr/sbin/pkispawn -s CA -f /tmp/tmp00n3qN
>2014-12-29T21:25:21Z DEBUG Process finished, return code=1
>2014-12-29T21:25:21Z DEBUG stdout=Loading deployment configuration from
>/tmp/tmp00n3qN.
>Installing CA into /var/lib/pki/pki-tomcat.
>loading external CA signing certificate from file: '/root/ipa.crt'
>loading external CA signing certificate chain from file: '/tmp/tmpnVtMl7'
>Installation failed.
>
>
>2014-12-29T21:25:21Z DEBUG stderr=pkispawn    : ERROR    .......
>Exception from Java Configuration Servlet: Error in creating pkcs12 to
>backup keys and certs: org.mozilla.jss.crypto.ObjectNotFoundException
>
>2014-12-29T21:25:21Z CRITICAL failed to configure ca instance Command
>'/usr/sbin/pkispawn -s CA -f /tmp/tmp00n3qN' returned non-zero exit
>status 1
>2014-12-29T21:25:21Z DEBUG   File
>"/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py",
>line 638, in run_script
>    return_value = main_function()
>
>  File "/sbin/ipa-server-install", line 1094, in main
>    subject_base=options.subject)
>
>  File
>"/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line
>478, in configure_instance
>    self.start_creation(runtime=210)
>
>  File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py",
>line 364, in start_creation
>    method()
>
>  File
>"/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line
>615, in __spawn_instance
>    raise RuntimeError('Configuration of CA failed')
>
>2014-12-29T21:25:21Z DEBUG The ipa-server-install command failed,
>exception: RuntimeError: Configuration of CA failed
>
>
>>From /var/log/pki/pki-ca-spawn.20141229132519.log
>
>2014-12-29 13:25:19 pkispawn    : INFO     ... skip populating
>'pki.deployment.infrastructure_layout'
>2014-12-29 13:25:19 pkispawn    : INFO     ... skip populating
>'pki.deployment.instance_layout'
>2014-12-29 13:25:19 pkispawn    : INFO     ... skip populating
>'pki.deployment.subsystem_layout'
>2014-12-29 13:25:19 pkispawn    : INFO     ... skip populating
>'pki.deployment.selinux_setup'
>2014-12-29 13:25:19 pkispawn    : INFO     ... skip deploying
>'pki.deployment.webapp_deployment'
>2014-12-29 13:25:19 pkispawn    : INFO     ... skip assigning slots for
>'pki.deployment.slot_substitution'
>2014-12-29 13:25:19 pkispawn    : INFO     ... skip generating
>'pki.deployment.security_databases'
>2014-12-29 13:25:19 pkispawn    : INFO     ... configuring
>'pki.deployment.configuration'
>2014-12-29 13:25:19 pkispawn    : INFO     ....... modifying
>'/root/.dogtag/pki-tomcat/ca/password.conf'
>2014-12-29 13:25:19 pkispawn    : DEBUG    ........... chmod 660
>/root/.dogtag/pki-tomcat/ca/password.conf
>2014-12-29 13:25:19 pkispawn    : DEBUG    ........... chown 0:0
>/root/.dogtag/pki-tomcat/ca/password.conf
>2014-12-29 13:25:19 pkispawn    : INFO     ....... modifying
>'/root/.dogtag/pki-tomcat/ca/pkcs12_password.conf'
>2014-12-29 13:25:19 pkispawn    : DEBUG    ........... chmod 660
>/root/.dogtag/pki-tomcat/ca/pkcs12_password.conf
>2014-12-29 13:25:19 pkispawn    : DEBUG    ........... chown 992:991
>/root/.dogtag/pki-tomcat/ca/pkcs12_password.conf
>2014-12-29 13:25:19 pkispawn    : INFO     ....... executing 'certutil
>-N -d /tmp/tmp-s1tfK9 -f /root/.dogtag/pki-tomcat/ca/password.conf'
>2014-12-29 13:25:19 pkispawn    : INFO     ....... executing 'systemctl
>start pki-tomcatd at pki-tomcat.service'
>2014-12-29 13:25:19 pkispawn    : DEBUG    ........... <?xml
>version="1.0" encoding="UTF-8"
>standalone="no"?><XMLResponse><State>0</State><Type>CA</Type><Status>runni
>ng</Status><Version>10.0.5-3.el7</Version></XMLResponse>
>2014-12-29 13:25:20 pkispawn    : INFO     ....... constructing PKI
>configuration data.
>2014-12-29 13:25:20 pkispawn    : INFO     ....... generating noise file
>called '/tmp/tmp-s1tfK9/noise' and filling it with '2048' random bytes
>2014-12-29 13:25:20 pkispawn    : DEBUG    ........... chmod 660
>/tmp/tmp-s1tfK9/noise
>2014-12-29 13:25:20 pkispawn    : DEBUG    ........... chown 992:991
>/tmp/tmp-s1tfK9/noise
>2014-12-29 13:25:20 pkispawn    : INFO     ....... executing
>'['certutil', '-R', '-d', '/tmp/tmp-s1tfK9', '-s',
>'cn=ipa-ca-agent,O=IPA.SONIC.NET', '-g', '2048', '-z',
>'/tmp/tmp-s1tfK9/noise', '-f',
>'/root/.dogtag/pki-tomcat/ca/password.conf', '-o',
>'/tmp/tmp-s1tfK9/admin_pkcs10.bin']'
>2014-12-29 13:25:20 pkispawn    : INFO     ....... ['BtoA',
>'/tmp/tmp-s1tfK9/admin_pkcs10.bin',
>'/tmp/tmp-s1tfK9/admin_pkcs10.bin.asc']
>2014-12-29 13:25:21 pkispawn    : INFO     ....... configuring PKI
>configuration data.
>2014-12-29 13:25:21 pkispawn    : ERROR    ....... Exception from Java
>Configuration Servlet: Error in creating pkcs12 to backup keys and
>certs: org.mozilla.jss.crypto.ObjectNotFoundException
>2014-12-29 13:25:21 pkispawn    : DEBUG    ....... Error Type: HTTPError
>2014-12-29 13:25:21 pkispawn    : DEBUG    ....... Error Message: 500
>Server Error: Internal Server Error
>2014-12-29 13:25:21 pkispawn    : DEBUG    .......   File
>"/usr/sbin/pkispawn", line 374, in main
>    rv = instance.spawn()
>  File
>"/usr/lib/python2.7/site-packages/pki/deployment/configuration.py", line
>128, in spawn
>    json.dumps(data, cls=pki.encoder.CustomTypeEncoder))
>  File "/usr/lib/python2.7/site-packages/pki/deployment/pkihelper.py",
>line 2998, in configure_pki_data
>    response = client.configure(data)
>  File "/usr/lib/python2.7/site-packages/pki/system.py", line 80, in
>configure
>    r = self.connection.post('/rest/installer/configure', data, headers)
>  File "/usr/lib/python2.7/site-packages/pki/client.py", line 64, in post
>    r.raise_for_status()
>  File "/usr/lib/python2.7/site-packages/requests/models.py", line 638,
>in raise_for_status
>    raise http_error
>
>
>>From /var/log/pki/pki-tomcat/catalina.out
>
>SSLAuthenticatorWithFallback: Creating SSL authenticator with fallback
>SSLAuthenticatorWithFallback: Setting container
>SSLAuthenticatorWithFallback: Initializing authenticators
>SSLAuthenticatorWithFallback: Starting authenticators
>CMS Warning: FAILURE: Cannot build CA chain. Error
>java.security.cert.CertificateException: Certificate is not a PKCS #11
>certificate|FAILURE: authz instance DirAclAut
>hz initialization failed and skipped, error=Property
>internaldb.ldapconn.port missing value|
>Server is started.
>Dec 29, 2014 1:16:00 PM org.apache.coyote.AbstractProtocol start
>INFO: Starting ProtocolHandler ["http-bio-8080"]
>Dec 29, 2014 1:16:00 PM org.apache.coyote.AbstractProtocol start
>INFO: Starting ProtocolHandler ["http-bio-8443"]
>Dec 29, 2014 1:16:00 PM org.apache.coyote.AbstractProtocol start
>INFO: Starting ProtocolHandler ["ajp-bio-127.0.0.1-8009"]
>Dec 29, 2014 1:16:00 PM org.apache.catalina.startup.Catalina start
>INFO: Server startup in 6906 ms
>13:16:02,887  INFO
>(org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher:82)
>-
>Deploying javax.ws.rs.core.Application: class com.netscape.ca.Certificat
>eAuthorityApplication
>13:16:02,900  INFO
>(org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher:82)
>-
>Adding singleton provider com.netscape.certsrv.acls.ACLInterceptor from
>Application javax.ws.rs.core.Application
>13:16:02,901  INFO
>(org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher:82)
>-
>Adding singleton provider com.netscape.certsrv.authentication.AuthMethod
>Interceptor from Application javax.ws.rs.core.Application
>13:16:03,161 DEBUG (org.jboss.resteasy.core.SynchronousDispatcher:60) -
>PathInfo: /installer/configure
>AuthInterceptor: SystemConfigResource.configure()
>AuthInterceptor: mapping name: default
>AuthInterceptor: required auth methods: [*]
>AuthInterceptor: anonymous access allowed
>13:25:21,125 DEBUG (org.jboss.resteasy.core.SynchronousDispatcher:60) -
>PathInfo: /installer/configure
>AuthInterceptor: SystemConfigResource.configure()
>AuthInterceptor: mapping name: default
>AuthInterceptor: required auth methods: [*]
>AuthInterceptor: anonymous access allowed
>java.security.cert.CertificateEncodingException: Security library failed
>to decode certificate package: (-8183) security library: improperly
>formatted DER-encoded message.
>        at org.mozilla.jss.CryptoManager.importCertPackageNative(Native
>Method)
>        at
>org.mozilla.jss.CryptoManager.importCertPackage(CryptoManager.java:1042)
>
>
>And so on.
>
>openssl x509 -text -in ipa.crt
>and
>openssl x509 -text -in cacert.pem
>
>Both work and display the signed cert as well as the CA's cert.
>
>I've tried the process a couple times on different lab environments and
>always get the exact same result.
>
>I saw an error above about imporperly formatted DER message so I thought
>I'd try converting the cacert's certificate from PEM to DER using
>something like this:
>
>openssl x509 -in cert.crt -outform der -out cert.der
>
>But this did not fix the problem. In fact, ipa-server-install throws an
>error immediately and does not seem to like DER formatted certificates.
>
>Thanks,
>Martin.
>
>-- 
>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




From jpazdziora at redhat.com  Wed Dec 31 18:06:16 2014
From: jpazdziora at redhat.com (Jan Pazdziora)
Date: Wed, 31 Dec 2014 19:06:16 +0100
Subject: [Freeipa-users] bind-dyndb-ldap and ddns updates from dhcp
In-Reply-To: <1419898346.23227.33.camel@desktop.bpk2.com>
References: <1419889643.23227.22.camel@desktop.bpk2.com>
	<54A1CD4E.9020704@redhat.com>
	<1419898346.23227.33.camel@desktop.bpk2.com>
Message-ID: <20141231180616.GA3669@redhat.com>

On Mon, Dec 29, 2014 at 07:12:26PM -0500, Brendan Kearney wrote:
> On Mon, 2014-12-29 at 16:53 -0500, Dmitri Pal wrote:
> > bind-dyndb-ldap isa back end driver for BIND to get data from an LDAP 
> > storage.
> > The updates are done by BIND. The IPA BIND accepts kerberos based updates.
> > 
> > http://www.freeipa.org/page/FreeIPAv2:Dynamic_updates_with_GSS-TSIG
> 
> this allows for a ticketed client to update DNS records directly, which
> is not a best practice and is a huge security risk.  clients should not
> be able to manipulate DNS zones.

Only if you configure that. But you don't have to grant krb5-self,
you can grant the

	SERVICE\047ipaserver.example.com at EXAMPLE.COM wildcard * ANY;

and just have the DHCP service call nsupdate -g.

> dynamic updates to DNS zones should come from DHCP, where dynamic
> addressing is managed.  as such, i have directives in DHCP and DNS to
> establish authenticated updates between DHCP and DNS.  for example:
> 
> /etc/named.conf:
> 
> key "dhcp" {
>         algorithm hmac-md5;
>         secret SomeRandomString;
> };

With FreeIPA, Kerberos authentication is really the preferred way
of integrating pieces together because it provides the identity of
the service running the action, not just some shared secret / password.

> because the DHCP daemon is not kerberized, the update policies do not

[...]

> i am wondering how to manage DDNS updates from DHCP, where kerberized
> updates are not likely going to happen.

What DHCP software is that and how hard would it be to Kerberize it?

-- 
Jan Pazdziora
Principal Software Engineer, Identity Management Engineering, Red Hat



From bpk678 at gmail.com  Wed Dec 31 18:59:32 2014
From: bpk678 at gmail.com (Brendan Kearney)
Date: Wed, 31 Dec 2014 13:59:32 -0500
Subject: [Freeipa-users] bind-dyndb-ldap and ddns updates from dhcp
In-Reply-To: <20141231180616.GA3669@redhat.com>
References: <1419889643.23227.22.camel@desktop.bpk2.com>
	<54A1CD4E.9020704@redhat.com>
	<1419898346.23227.33.camel@desktop.bpk2.com>
	<20141231180616.GA3669@redhat.com>
Message-ID: <1420052372.5698.15.camel@desktop.bpk2.com>

On Wed, 2014-12-31 at 19:06 +0100, Jan Pazdziora wrote:
> On Mon, Dec 29, 2014 at 07:12:26PM -0500, Brendan Kearney wrote:
> > On Mon, 2014-12-29 at 16:53 -0500, Dmitri Pal wrote:
> > > bind-dyndb-ldap isa back end driver for BIND to get data from an LDAP 
> > > storage.
> > > The updates are done by BIND. The IPA BIND accepts kerberos based updates.
> > > 
> > > http://www.freeipa.org/page/FreeIPAv2:Dynamic_updates_with_GSS-TSIG
> > 
> > this allows for a ticketed client to update DNS records directly, which
> > is not a best practice and is a huge security risk.  clients should not
> > be able to manipulate DNS zones.
> 
> Only if you configure that. But you don't have to grant krb5-self,
> you can grant the
> 
> 	SERVICE\047ipaserver.example.com at EXAMPLE.COM wildcard * ANY;
> 
> and just have the DHCP service call nsupdate -g.
> 
> > dynamic updates to DNS zones should come from DHCP, where dynamic
> > addressing is managed.  as such, i have directives in DHCP and DNS to
> > establish authenticated updates between DHCP and DNS.  for example:
> > 
> > /etc/named.conf:
> > 
> > key "dhcp" {
> >         algorithm hmac-md5;
> >         secret SomeRandomString;
> > };
> 
> With FreeIPA, Kerberos authentication is really the preferred way
> of integrating pieces together because it provides the identity of
> the service running the action, not just some shared secret / password.
> 
> > because the DHCP daemon is not kerberized, the update policies do not
> 
> [...]
> 
> > i am wondering how to manage DDNS updates from DHCP, where kerberized
> > updates are not likely going to happen.
> 
> What DHCP software is that and how hard would it be to Kerberize it?
> 

i have played with nsupdate, and it does look like updates will be
allowed if i remove the access restriction, but i am losing the
authenticity of the update, since the TSIG shared secret signs the
update.

regardless of authentication, client updates to DNS zones are still a
risk and a rogue app or user can still perform direct updates to zones,
leading to impersonation/interception of services, denial of service
attacks and more.  endpoints, or their users, should not be trusted to
make updates to DNS zones.  TSIG signed updates from servers are still
preferred over authenticated updates from endpoints or users.

i am using ISC DHCP, and cannot speak to any level of effort required to
incorporate Kerberos into the code.



From loris at lgs.com.ve  Wed Dec 31 21:12:10 2014
From: loris at lgs.com.ve (Loris Santamaria)
Date: Wed, 31 Dec 2014 16:42:10 -0430
Subject: [Freeipa-users] bind-dyndb-ldap and ddns updates from dhcp
In-Reply-To: <1420052372.5698.15.camel@desktop.bpk2.com>
References: <1419889643.23227.22.camel@desktop.bpk2.com>
	<54A1CD4E.9020704@redhat.com>
	<1419898346.23227.33.camel@desktop.bpk2.com>
	<20141231180616.GA3669@redhat.com>
	<1420052372.5698.15.camel@desktop.bpk2.com>
Message-ID: <1420060330.20801.14.camel@lgs.com.ve>

El mi?, 31-12-2014 a las 13:59 -0500, Brendan Kearney escribi?:

> regardless of authentication, client updates to DNS zones are still a
> risk and a rogue app or user can still perform direct updates to zones,
> leading to impersonation/interception of services, denial of service
> attacks and more.  endpoints, or their users, should not be trusted to
> make updates to DNS zones.  TSIG signed updates from servers are still
> preferred over authenticated updates from endpoints or users.

Not really. With the default ipa configuration (grant ZONE.COM krb5-self
* A) the worst that could do the administrator of a workstation, with
access to the host keytab, is point the A record of her workstation to a
wrong address. 

Please note that someone able to read the host keytab (root on the
workstation) could simply skip dhcp negotiation and assign to her
workstation any address she likes.

With the default ipa configuration a workstation can only set _its_ A,
AAAA and SSHFP records. No less and no more.

Best regards
-- 
Loris Santamaria   linux user #70506   xmpp:loris at lgs.com.ve
Links Global Services, C.A.            http://www.lgs.com.ve
Tel: 0286 952.06.87  Cel: 0414 095.00.10  sip:103 at lgs.com.ve
------------------------------------------------------------
"If I'd asked my customers what they wanted, they'd have said
a faster horse" - Henry Ford
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5693 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141231/c9bc69e1/attachment.bin>

From jpazdziora at redhat.com  Wed Dec 31 21:34:37 2014
From: jpazdziora at redhat.com (Jan Pazdziora)
Date: Wed, 31 Dec 2014 22:34:37 +0100
Subject: [Freeipa-users] bind-dyndb-ldap and ddns updates from dhcp
In-Reply-To: <1420052372.5698.15.camel@desktop.bpk2.com>
References: <1419889643.23227.22.camel@desktop.bpk2.com>
	<54A1CD4E.9020704@redhat.com>
	<1419898346.23227.33.camel@desktop.bpk2.com>
	<20141231180616.GA3669@redhat.com>
	<1420052372.5698.15.camel@desktop.bpk2.com>
Message-ID: <20141231213437.GA12182@redhat.com>

On Wed, Dec 31, 2014 at 01:59:32PM -0500, Brendan Kearney wrote:
> 
> i have played with nsupdate, and it does look like updates will be
> allowed if i remove the access restriction, but i am losing the
> authenticity of the update, since the TSIG shared secret signs the
> update.

The goal is not to remove the access restriction. The goal is to use
something like

	update-policy {
		grant DHCP\047dhcp-server.example.com at EXAMPLE.COM wildcard * ANY;
	};

create service

	DHCP/dhcp-server.example.com at EXAMPLE.COM

or some similar principal for your DHCP server, retrieve its keytab
(possibly with ipa-getkeytab), and then do

	kinit -kt /the/path/to/the/dhcp/service.keytab
	nsupdate -g

> regardless of authentication, client updates to DNS zones are still a
> risk and a rogue app or user can still perform direct updates to zones,
> leading to impersonation/interception of services, denial of service
> attacks and more.

In case of your DHCP use case, you certainly might not want to enable
the client updates. However, client updates are something different
than allowing a particular service (and only that service) to update
the zone records.

Also, note that how you enable the client updates matter. The wiki page

	http://www.freeipa.org/page/FreeIPAv2:Dynamic_updates_with_GSS-TSIG

suggests

	grant EXAMPLE.COM krb5-self * A;

which means that authenticated host can only change its own A record
-- it cannot impersonate another hostname like you suggest.

> endpoints, or their users, should not be trusted to
> make updates to DNS zones.  TSIG signed updates from servers are still
> preferred over authenticated updates from endpoints or users.

Server has identity just like service, just like user. You can have
unimportant server and you can have important (admin) user. Ruling
out authentication

> i am using ISC DHCP, and cannot speak to any level of effort required to
> incorporate Kerberos into the code.

The page

	http://blog.michael.kuron-germany.de/2011/02/isc-dhcpd-dynamic-dns-updates-against-secure-microsoft-dns/

shows how ISC DHCP's execute can be used to send the changes to
an external command, and that command can include the
kinit -kt + nsupdate -g combo.

-- 
Jan Pazdziora
Principal Software Engineer, Identity Management Engineering, Red Hat



From jpazdziora at redhat.com  Wed Dec 31 21:40:19 2014
From: jpazdziora at redhat.com (Jan Pazdziora)
Date: Wed, 31 Dec 2014 22:40:19 +0100
Subject: [Freeipa-users] bind-dyndb-ldap and ddns updates from dhcp
In-Reply-To: <20141231213437.GA12182@redhat.com>
References: <1419889643.23227.22.camel@desktop.bpk2.com>
	<54A1CD4E.9020704@redhat.com>
	<1419898346.23227.33.camel@desktop.bpk2.com>
	<20141231180616.GA3669@redhat.com>
	<1420052372.5698.15.camel@desktop.bpk2.com>
	<20141231213437.GA12182@redhat.com>
Message-ID: <20141231214019.GB12182@redhat.com>

On Wed, Dec 31, 2014 at 10:34:37PM +0100, Jan Pazdziora wrote:
> 
> > endpoints, or their users, should not be trusted to
> > make updates to DNS zones.  TSIG signed updates from servers are still
> > preferred over authenticated updates from endpoints or users.
> 
> Server has identity just like service, just like user. You can have
> unimportant server and you can have important (admin) user. Ruling
> out authentication

... oops, I seem to have failed to finish this paragraph.

Ruling out authentication of identities means that you give up on
centrally controlled access policies -- something that FreeIPA is
good at, besides just storing identities.

In other words, instead of having increasing number of shared
secrets around your network, it might be useful to adopt the
approach when idenities can get created without many restrictions,
and what you allow those identities to do is what matters.

-- 
Jan Pazdziora
Principal Software Engineer, Identity Management Engineering, Red Hat



From martin.minkus at corp.sonic.net  Tue Dec 30 18:50:39 2014
From: martin.minkus at corp.sonic.net (Martin Minkus)
Date: Tue, 30 Dec 2014 10:50:39 -0800
Subject: [Freeipa-users] Freeipa 3.3.3 and --external-ca
In-Reply-To: <D0C82303.1885%daniel.hjorth@octanner.com>
References: <54A1CF6E.9080200@corp.sonic.net>
	<D0C82303.1885%daniel.hjorth@octanner.com>
Message-ID: <54A2F3FF.3060805@corp.sonic.net>

Hi Daniel,

Oh wow, you might be right!

I just checked the CA cert and the signed IPA cert, and openssl shows:

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 33 (0x21)
    Signature Algorithm: sha1WithRSAEncryption

Now that we know what the problem most likely is, we'll figure out how
we want to move forward from here. That might be to upgrade to SHA256
for our internal CA, apply the patch you provided, or go self-signed...

But good to know.

Thanks,
Martin.


On 12/30/2014 10:02 AM, Daniel Hjorth wrote:
> Hi Martin,
> 
> I think I ran into the same problem.  Do you know which signing algorithm
> your external CA used?  In my case the external CA is on Server 2003 which
> only allowed SHA1 but IPA 3.3.3 seems to require SHA256.
> 
> I was not able to get my CA to use SHA256 so I applied the diff from the
> commit below:
> 
> https://git.fedorahosted.org/cgit/freeipa.git/commit/?id=081580779b2609c3a4
> 53077042f7d3fc7b25a57d
> 
> I then used the "--ca-signing-algorithm=" option when installing IPA.
> This may not be the best solution but it worked and I haven?t seen any
> issues.
> 
> Hope this helps,
> 
> Daniel
> 
> On 12/29/14, 3:02 PM, "Martin Minkus" <martin.minkus at corp.sonic.net> wrote:
> 
>> Hi all,
>>
>> I'm running Freeipa 3.3.3 on CentOS 7.0.
>>
>> It worked fine self signed but I am having difficulty getting it to work
>> with --exernal-ca. I've seen a few other reports of this on the list
>> with no resolution, so I'm not sure whether this is simply broken in
>> this version or what? Maybe I'm just doing something wrong. :)
>>
>> >From /var/log/ipaserver-install.log
>>
>>
>> 2014-12-29T21:25:19Z DEBUG Starting external process
>> 2014-12-29T21:25:19Z DEBUG args=/usr/sbin/pkispawn -s CA -f /tmp/tmp00n3qN
>> 2014-12-29T21:25:21Z DEBUG Process finished, return code=1
>> 2014-12-29T21:25:21Z DEBUG stdout=Loading deployment configuration from
>> /tmp/tmp00n3qN.
>> Installing CA into /var/lib/pki/pki-tomcat.
>> loading external CA signing certificate from file: '/root/ipa.crt'
>> loading external CA signing certificate chain from file: '/tmp/tmpnVtMl7'
>> Installation failed.
>>
>>
>> 2014-12-29T21:25:21Z DEBUG stderr=pkispawn    : ERROR    .......
>> Exception from Java Configuration Servlet: Error in creating pkcs12 to
>> backup keys and certs: org.mozilla.jss.crypto.ObjectNotFoundException
>>
>> 2014-12-29T21:25:21Z CRITICAL failed to configure ca instance Command
>> '/usr/sbin/pkispawn -s CA -f /tmp/tmp00n3qN' returned non-zero exit
>> status 1
>> 2014-12-29T21:25:21Z DEBUG   File
>> "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py",
>> line 638, in run_script
>>    return_value = main_function()
>>
>>  File "/sbin/ipa-server-install", line 1094, in main
>>    subject_base=options.subject)
>>
>>  File
>> "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line
>> 478, in configure_instance
>>    self.start_creation(runtime=210)
>>
>>  File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py",
>> line 364, in start_creation
>>    method()
>>
>>  File
>> "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line
>> 615, in __spawn_instance
>>    raise RuntimeError('Configuration of CA failed')
>>
>> 2014-12-29T21:25:21Z DEBUG The ipa-server-install command failed,
>> exception: RuntimeError: Configuration of CA failed
>>
>>
>> >From /var/log/pki/pki-ca-spawn.20141229132519.log
>>
>> 2014-12-29 13:25:19 pkispawn    : INFO     ... skip populating
>> 'pki.deployment.infrastructure_layout'
>> 2014-12-29 13:25:19 pkispawn    : INFO     ... skip populating
>> 'pki.deployment.instance_layout'
>> 2014-12-29 13:25:19 pkispawn    : INFO     ... skip populating
>> 'pki.deployment.subsystem_layout'
>> 2014-12-29 13:25:19 pkispawn    : INFO     ... skip populating
>> 'pki.deployment.selinux_setup'
>> 2014-12-29 13:25:19 pkispawn    : INFO     ... skip deploying
>> 'pki.deployment.webapp_deployment'
>> 2014-12-29 13:25:19 pkispawn    : INFO     ... skip assigning slots for
>> 'pki.deployment.slot_substitution'
>> 2014-12-29 13:25:19 pkispawn    : INFO     ... skip generating
>> 'pki.deployment.security_databases'
>> 2014-12-29 13:25:19 pkispawn    : INFO     ... configuring
>> 'pki.deployment.configuration'
>> 2014-12-29 13:25:19 pkispawn    : INFO     ....... modifying
>> '/root/.dogtag/pki-tomcat/ca/password.conf'
>> 2014-12-29 13:25:19 pkispawn    : DEBUG    ........... chmod 660
>> /root/.dogtag/pki-tomcat/ca/password.conf
>> 2014-12-29 13:25:19 pkispawn    : DEBUG    ........... chown 0:0
>> /root/.dogtag/pki-tomcat/ca/password.conf
>> 2014-12-29 13:25:19 pkispawn    : INFO     ....... modifying
>> '/root/.dogtag/pki-tomcat/ca/pkcs12_password.conf'
>> 2014-12-29 13:25:19 pkispawn    : DEBUG    ........... chmod 660
>> /root/.dogtag/pki-tomcat/ca/pkcs12_password.conf
>> 2014-12-29 13:25:19 pkispawn    : DEBUG    ........... chown 992:991
>> /root/.dogtag/pki-tomcat/ca/pkcs12_password.conf
>> 2014-12-29 13:25:19 pkispawn    : INFO     ....... executing 'certutil
>> -N -d /tmp/tmp-s1tfK9 -f /root/.dogtag/pki-tomcat/ca/password.conf'
>> 2014-12-29 13:25:19 pkispawn    : INFO     ....... executing 'systemctl
>> start pki-tomcatd at pki-tomcat.service'
>> 2014-12-29 13:25:19 pkispawn    : DEBUG    ........... <?xml
>> version="1.0" encoding="UTF-8"
>> standalone="no"?><XMLResponse><State>0</State><Type>CA</Type><Status>runni
>> ng</Status><Version>10.0.5-3.el7</Version></XMLResponse>
>> 2014-12-29 13:25:20 pkispawn    : INFO     ....... constructing PKI
>> configuration data.
>> 2014-12-29 13:25:20 pkispawn    : INFO     ....... generating noise file
>> called '/tmp/tmp-s1tfK9/noise' and filling it with '2048' random bytes
>> 2014-12-29 13:25:20 pkispawn    : DEBUG    ........... chmod 660
>> /tmp/tmp-s1tfK9/noise
>> 2014-12-29 13:25:20 pkispawn    : DEBUG    ........... chown 992:991
>> /tmp/tmp-s1tfK9/noise
>> 2014-12-29 13:25:20 pkispawn    : INFO     ....... executing
>> '['certutil', '-R', '-d', '/tmp/tmp-s1tfK9', '-s',
>> 'cn=ipa-ca-agent,O=IPA.SONIC.NET', '-g', '2048', '-z',
>> '/tmp/tmp-s1tfK9/noise', '-f',
>> '/root/.dogtag/pki-tomcat/ca/password.conf', '-o',
>> '/tmp/tmp-s1tfK9/admin_pkcs10.bin']'
>> 2014-12-29 13:25:20 pkispawn    : INFO     ....... ['BtoA',
>> '/tmp/tmp-s1tfK9/admin_pkcs10.bin',
>> '/tmp/tmp-s1tfK9/admin_pkcs10.bin.asc']
>> 2014-12-29 13:25:21 pkispawn    : INFO     ....... configuring PKI
>> configuration data.
>> 2014-12-29 13:25:21 pkispawn    : ERROR    ....... Exception from Java
>> Configuration Servlet: Error in creating pkcs12 to backup keys and
>> certs: org.mozilla.jss.crypto.ObjectNotFoundException
>> 2014-12-29 13:25:21 pkispawn    : DEBUG    ....... Error Type: HTTPError
>> 2014-12-29 13:25:21 pkispawn    : DEBUG    ....... Error Message: 500
>> Server Error: Internal Server Error
>> 2014-12-29 13:25:21 pkispawn    : DEBUG    .......   File
>> "/usr/sbin/pkispawn", line 374, in main
>>    rv = instance.spawn()
>>  File
>> "/usr/lib/python2.7/site-packages/pki/deployment/configuration.py", line
>> 128, in spawn
>>    json.dumps(data, cls=pki.encoder.CustomTypeEncoder))
>>  File "/usr/lib/python2.7/site-packages/pki/deployment/pkihelper.py",
>> line 2998, in configure_pki_data
>>    response = client.configure(data)
>>  File "/usr/lib/python2.7/site-packages/pki/system.py", line 80, in
>> configure
>>    r = self.connection.post('/rest/installer/configure', data, headers)
>>  File "/usr/lib/python2.7/site-packages/pki/client.py", line 64, in post
>>    r.raise_for_status()
>>  File "/usr/lib/python2.7/site-packages/requests/models.py", line 638,
>> in raise_for_status
>>    raise http_error
>>
>>
>> >From /var/log/pki/pki-tomcat/catalina.out
>>
>> SSLAuthenticatorWithFallback: Creating SSL authenticator with fallback
>> SSLAuthenticatorWithFallback: Setting container
>> SSLAuthenticatorWithFallback: Initializing authenticators
>> SSLAuthenticatorWithFallback: Starting authenticators
>> CMS Warning: FAILURE: Cannot build CA chain. Error
>> java.security.cert.CertificateException: Certificate is not a PKCS #11
>> certificate|FAILURE: authz instance DirAclAut
>> hz initialization failed and skipped, error=Property
>> internaldb.ldapconn.port missing value|
>> Server is started.
>> Dec 29, 2014 1:16:00 PM org.apache.coyote.AbstractProtocol start
>> INFO: Starting ProtocolHandler ["http-bio-8080"]
>> Dec 29, 2014 1:16:00 PM org.apache.coyote.AbstractProtocol start
>> INFO: Starting ProtocolHandler ["http-bio-8443"]
>> Dec 29, 2014 1:16:00 PM org.apache.coyote.AbstractProtocol start
>> INFO: Starting ProtocolHandler ["ajp-bio-127.0.0.1-8009"]
>> Dec 29, 2014 1:16:00 PM org.apache.catalina.startup.Catalina start
>> INFO: Server startup in 6906 ms
>> 13:16:02,887  INFO
>> (org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher:82)
>> -
>> Deploying javax.ws.rs.core.Application: class com.netscape.ca.Certificat
>> eAuthorityApplication
>> 13:16:02,900  INFO
>> (org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher:82)
>> -
>> Adding singleton provider com.netscape.certsrv.acls.ACLInterceptor from
>> Application javax.ws.rs.core.Application
>> 13:16:02,901  INFO
>> (org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher:82)
>> -
>> Adding singleton provider com.netscape.certsrv.authentication.AuthMethod
>> Interceptor from Application javax.ws.rs.core.Application
>> 13:16:03,161 DEBUG (org.jboss.resteasy.core.SynchronousDispatcher:60) -
>> PathInfo: /installer/configure
>> AuthInterceptor: SystemConfigResource.configure()
>> AuthInterceptor: mapping name: default
>> AuthInterceptor: required auth methods: [*]
>> AuthInterceptor: anonymous access allowed
>> 13:25:21,125 DEBUG (org.jboss.resteasy.core.SynchronousDispatcher:60) -
>> PathInfo: /installer/configure
>> AuthInterceptor: SystemConfigResource.configure()
>> AuthInterceptor: mapping name: default
>> AuthInterceptor: required auth methods: [*]
>> AuthInterceptor: anonymous access allowed
>> java.security.cert.CertificateEncodingException: Security library failed
>> to decode certificate package: (-8183) security library: improperly
>> formatted DER-encoded message.
>>        at org.mozilla.jss.CryptoManager.importCertPackageNative(Native
>> Method)
>>        at
>> org.mozilla.jss.CryptoManager.importCertPackage(CryptoManager.java:1042)
>>
>>
>> And so on.
>>
>> openssl x509 -text -in ipa.crt
>> and
>> openssl x509 -text -in cacert.pem
>>
>> Both work and display the signed cert as well as the CA's cert.
>>
>> I've tried the process a couple times on different lab environments and
>> always get the exact same result.
>>
>> I saw an error above about imporperly formatted DER message so I thought
>> I'd try converting the cacert's certificate from PEM to DER using
>> something like this:
>>
>> openssl x509 -in cert.crt -outform der -out cert.der
>>
>> But this did not fix the problem. In fact, ipa-server-install throws an
>> error immediately and does not seem to like DER formatted certificates.
>>
>> Thanks,
>> Martin.
>>
>> -- 
>> 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
> 
> 

-- 
Martin Minkus
Sonic.net, Inc.
Senior Systems Engineer
2260 Apollo Way | Santa Rosa, CA 95407
Office: 707.522.1000 Extn. 2384



From j.astrego at netbulae.eu  Wed Dec 31 15:56:38 2014
From: j.astrego at netbulae.eu (Jorick Astrego)
Date: Wed, 31 Dec 2014 16:56:38 +0100
Subject: [Freeipa-users]  firewalld management
In-Reply-To: <CAL6rijTFVWqRO9MKXMHeJjpNnrpcwGEWAu0QPCazMuP1JhfN6g@mail.gmail.com>
References: <CAL6rijTFVWqRO9MKXMHeJjpNnrpcwGEWAu0QPCazMuP1JhfN6g@mail.gmail.com>
Message-ID: <54A41CB6.3040307@netbulae.eu>

Hi,

FreeIPA is great! One thing I'm missing though is management of
firewalld services and ports.

Is that something that would fit in FreeIPA?

Currently we are using puppet scripts through katello/the foreman, but
as this is very error prone we'd like to have it centrally managed a
different way.

The firewall rules are very essential IMHO and I thought the whole point
of firewalld is to have make it more manageable...

I already asked the katello guys but they don't appear very interested
in implementing something there, then I started thinking it would maybe
fit a lot better in freeIPA as it has more overlap with the other
network/authentication stuff.

It would be wasteful to have another project just for firewalld management.

Happy new year everybody!

Jorick








Met vriendelijke groet, With kind regards,

Jorick Astrego

Netbulae Virtualization Experts 

----------------

	Tel: 053 20 30 270 	info at netbulae.eu 	Staalsteden 4-3A 	KvK 08198180
 	Fax: 053 20 30 271 	www.netbulae.eu 	7547 TA Enschede 	BTW NL821234584B01

----------------

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141231/39283d35/attachment.htm>