Re: [Freeipa-users] Replica issue / Certificate Authority

[Fraser Tweedale]

On Wed, Jan 04, 2017 at 01:19:19PM +, Christophe TREFOIS wrote:
> Hi Florence,
> 
> I did what you said, and then the status went to CA_WORKING. Then I restart 
> ipa and certmonger and the status went to CA_UNREACHABLE.
> Then i did “resubmit” again and now the status is back to MONITORING, but the 
> cookie error is back.
> 
> Any advice?
> 
I have encountered the cookie error before. IIRC it was caused by
authn certs in Dogtag user entries not matching the client certs
used.

Check the following entries:

1. ``ldapsearch -LLL -D cn=directory\ manager -w4me2Test \
   -b uid=pkidbuser,ou=people,o=ipaca userCertificate``

   should match

   ``certutil -d /etc/pki/pki-tomcat/alias -L -n "subsystemCert cert-pki-ca"``

2. ``ldapsearch -LLL -D cn=directory\ manager -w4me2Test \
   -b uid=ipara,ou=people,o=ipaca userCertificate``

   should match

   ``certutil -d /etc/httpd/alias -L -n "ipaCert"``

If either of these do not match, update LDAP with what is in the
certificate databases (a.k.a. NSSDBs).  Ensure all certs are
non-expired, etc.

HTH,
Fraser


> [root@lums3 ~]# getcert list -n ipaCert
> Number of certificates and requests being tracked: 8.
> Request ID '20161216025136':
>   status: MONITORING
>   ca-error: Invalid cookie: ''
>   stuck: no
>   key pair storage: 
> type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS 
> Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt'
>   certificate: 
> type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS 
> Certificate DB'
>   CA: dogtag-ipa-ca-renew-agent
>   issuer: CN=Certificate Authority,O=UNI.LU
>   subject: CN=IPA RA,O=UNI.LU
>   expires: 2018-12-16 03:13:48 UTC
>   key usage: 
> digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
>   eku: id-kp-serverAuth,id-kp-clientAuth
>   pre-save command: /usr/libexec/ipa/certmonger/renew_ra_cert_pre
>   post-save command: /usr/libexec/ipa/certmonger/renew_ra_cert
>   track: yes
>   auto-renew: yes
> 
> -- 
> 
> Dr Christophe Trefois, Dipl.-Ing.  
> Technical Specialist / Post-Doc
> 
> UNIVERSITÉ DU LUXEMBOURG
> 
> LUXEMBOURG CENTRE FOR SYSTEMS BIOMEDICINE
> Campus Belval | House of Biomedicine  
> 6, avenue du Swing 
> L-4367 Belvaux  
> T: +352 46 66 44 6124 
> F: +352 46 66 44 6949  
> http://www.uni.lu/lcsb 
>        
>    
>    
> 
> This message is confidential and may contain privileged information. 
> It is intended for the named recipient only. 
> If you receive it in error please notify me and permanently delete the 
> original message and any copies. 
> 
> 
>   
> 
> > On 4 Jan 2017, at 13:49, Florence Blanc-Renaud  wrote:
> > 
> > getcert resubmit -i 
> 


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

Re: [Freeipa-users] ipa replica installation help

[Ben .T.George]

HI

yes i did the same and still port is not listening.

[root@zkwipamstr01 ~]# cat /etc/hosts
127.0.0.1   localhost localhost.localdomain localhost4
localhost4.localdomain4
::1 localhost localhost.localdomain localhost6
localhost6.localdomain6
10.151.4.64 zkwipamstr01.kw.example.comzkwipamstr01
10.151.4.65 zkwiparepa01.kw.example.comzkwiparepa01
[root@zkwipamstr01 ~]# systemctl restart pki-tomcatd@pki-tomcat
[root@zkwipamstr01 ~]# netstat -tunap | grep 8009


Regards
Ben

On Thu, Jan 5, 2017 at 9:03 AM, Fraser Tweedale  wrote:

> On Wed, Jan 04, 2017 at 03:12:12PM +0300, Ben .T.George wrote:
> > HI
> >
> > port 8009 is not listening in master server
> >
> > and i added ::1 localhost localhost.localdomain localhost6
> > localhost6.localdomain6 in hosts file.
> >
>
> Did you add this to the host file on the master (then `systemctl
> restart pki-tomcatd@pki-tomcat` and confirm it is listening on port
> 8009)?  Or just the client you are trying to promote?
>
> It is needed on the master.  Won't hurt to make this change to
> /etc/hosts on both machines, though.
>
> HTH,
> Fraser
>
> > still getting same error
> >
> >  [28/44]: restarting directory server
> > ipa : CRITICAL Failed to restart the directory server (Command
> > '/bin/systemctl restart dirsrv@KW-EXAMPLE-COM.service' returned non-zero
> > exit status 1). See the installation log for details.
> >   [29/44]: setting up initial replication
> >   [error] error: [Errno 111] Connection refused
> > Your system may be partly configured.
> > Run /usr/sbin/ipa-server-install --uninstall to clean up.
> >
> > ipa.ipapython.install.cli.install_tool(Replica): ERROR[Errno 111]
> > Connection refused
> > ipa.ipapython.install.cli.install_tool(Replica): ERRORThe
> > ipa-replica-install command failed. See /var/log/ipareplica-install.log
> for
> > more information
> >
> >
> > Also  ipv6 is disabled on both nodes
> >
> > Regards,
> > Ben
> >
> > On Wed, Jan 4, 2017 at 2:05 PM, Petr Vobornik 
> wrote:
> >
> > > On 01/04/2017 10:59 AM, Ben .T.George wrote:
> > > > HI
> > > >
> > > > i tried the method mentioned on that document and it end up with
> below
> > > error. My
> > > > DNS is managed by external box and i dont want to create any DNS
> record
> > > on these
> > > > servers.
> > > >
> > > > and the command which i tried is(non client server)
> > > >
> > > > ipa-replica-install --principal admin --admin-password P@ssw0rd
> --domain
> > > > kw.example.com  --server
> > > zkwipamstr01.kw.example.com
> > > > 
> > > >
> > > >
> > > >
> > > > ipa : CRITICAL Failed to restart the directory server
> (Command
> > > > '/bin/systemctl restart dirsrv@KW-EXAMPLE-COM.service' returned
> > > non-zero exit
> > > > status 1). See the installation log for details.
> > > >[29/44]: setting up initial replication
> > > >[error] error: [Errno 111] Connection refused
> > > > Your system may be partly configured.
> > > > Run /usr/sbin/ipa-server-install --uninstall to clean up.
> > > >
> > > > ipa.ipapython.install.cli.install_tool(Replica): ERROR[Errno
> 111]
> > > Connection
> > > > refused
> > > > ipa.ipapython.install.cli.install_tool(Replica): ERRORThe
> > > > ipa-replica-install command failed. See /var/log/ipareplica-install.
> log
> > > for more
> > > > information
> > >
> > > This looks like bug https://fedorahosted.org/freeipa/ticket/6575
> > >
> > > To verify that, could you check if master server internally listens on
> > > port 8009 or if ipareplica-install.log contains CA_UNREACHABLE string
> > > near  step 27.
> > >
> > > Usual fix is to add following line to /etc/hosts
> > >   ::1 localhost localhost.localdomain localhost6
> > > localhost6.localdomain6
> > >
> > >
> > > > [root@zkwiparepa01 ~]# /bin/systemctl restart
> > > dirsrv@KW-EXAMPLE-COM.service
> > > > Job for dirsrv@KW-EXAMPLE-COM.service failed because the control
> > > process exited
> > > > with error code. See "systemctl status dirsrv@KW-EXAMPLE-COM.service
> "
> > > and
> > > > "journalctl -xe" for details.
> > > >
> > > > [root@zkwiparepa01 ~]# systemctl status
> dirsrv@KW-EXAMPLE-COM.service
> > > > ● dirsrv@KW-EXAMPLE-COM.service - 389 Directory Server
> KW-EXAMPLE-COM.
> > > > Loaded: loaded (/usr/lib/systemd/system/dirsrv@.service;
> enabled;
> > > vendor
> > > > preset: disabled)
> > > > Active: failed (Result: exit-code) since Wed 2017-01-04 12:54:46
> > > AST; 13s ago
> > > >Process: 14893 ExecStart=/usr/sbin/ns-slapd -D
> /etc/dirsrv/slapd-%i -i
> > > > /var/run/dirsrv/slapd-%i.pid (code=exited, status=1/FAILURE)
> > > >Process: 14887 ExecStartPre=/usr/sbin/ds_systemd_ask_password_acl
> > > > /etc/dirsrv/slapd-%i/dse.ldif (code=exited, status=0/SUCCESS)
> > > >   Main PID: 14893 (code=exited, status=1/FAILURE)
> > > >
> > > > Jan 04 12:54:46 zkwiparepa01.kw.example.com  

Re: [Freeipa-users] ipa replica installation help

[Fraser Tweedale]

On Wed, Jan 04, 2017 at 03:12:12PM +0300, Ben .T.George wrote:
> HI
> 
> port 8009 is not listening in master server
> 
> and i added ::1 localhost localhost.localdomain localhost6
> localhost6.localdomain6 in hosts file.
> 

Did you add this to the host file on the master (then `systemctl
restart pki-tomcatd@pki-tomcat` and confirm it is listening on port
8009)?  Or just the client you are trying to promote?

It is needed on the master.  Won't hurt to make this change to
/etc/hosts on both machines, though.

HTH,
Fraser

> still getting same error
> 
>  [28/44]: restarting directory server
> ipa : CRITICAL Failed to restart the directory server (Command
> '/bin/systemctl restart dirsrv@KW-EXAMPLE-COM.service' returned non-zero
> exit status 1). See the installation log for details.
>   [29/44]: setting up initial replication
>   [error] error: [Errno 111] Connection refused
> Your system may be partly configured.
> Run /usr/sbin/ipa-server-install --uninstall to clean up.
> 
> ipa.ipapython.install.cli.install_tool(Replica): ERROR[Errno 111]
> Connection refused
> ipa.ipapython.install.cli.install_tool(Replica): ERRORThe
> ipa-replica-install command failed. See /var/log/ipareplica-install.log for
> more information
> 
> 
> Also  ipv6 is disabled on both nodes
> 
> Regards,
> Ben
> 
> On Wed, Jan 4, 2017 at 2:05 PM, Petr Vobornik  wrote:
> 
> > On 01/04/2017 10:59 AM, Ben .T.George wrote:
> > > HI
> > >
> > > i tried the method mentioned on that document and it end up with below
> > error. My
> > > DNS is managed by external box and i dont want to create any DNS record
> > on these
> > > servers.
> > >
> > > and the command which i tried is(non client server)
> > >
> > > ipa-replica-install --principal admin --admin-password P@ssw0rd --domain
> > > kw.example.com  --server
> > zkwipamstr01.kw.example.com
> > > 
> > >
> > >
> > >
> > > ipa : CRITICAL Failed to restart the directory server (Command
> > > '/bin/systemctl restart dirsrv@KW-EXAMPLE-COM.service' returned
> > non-zero exit
> > > status 1). See the installation log for details.
> > >[29/44]: setting up initial replication
> > >[error] error: [Errno 111] Connection refused
> > > Your system may be partly configured.
> > > Run /usr/sbin/ipa-server-install --uninstall to clean up.
> > >
> > > ipa.ipapython.install.cli.install_tool(Replica): ERROR[Errno 111]
> > Connection
> > > refused
> > > ipa.ipapython.install.cli.install_tool(Replica): ERRORThe
> > > ipa-replica-install command failed. See /var/log/ipareplica-install.log
> > for more
> > > information
> >
> > This looks like bug https://fedorahosted.org/freeipa/ticket/6575
> >
> > To verify that, could you check if master server internally listens on
> > port 8009 or if ipareplica-install.log contains CA_UNREACHABLE string
> > near  step 27.
> >
> > Usual fix is to add following line to /etc/hosts
> >   ::1 localhost localhost.localdomain localhost6
> > localhost6.localdomain6
> >
> >
> > > [root@zkwiparepa01 ~]# /bin/systemctl restart
> > dirsrv@KW-EXAMPLE-COM.service
> > > Job for dirsrv@KW-EXAMPLE-COM.service failed because the control
> > process exited
> > > with error code. See "systemctl status dirsrv@KW-EXAMPLE-COM.service"
> > and
> > > "journalctl -xe" for details.
> > >
> > > [root@zkwiparepa01 ~]# systemctl status dirsrv@KW-EXAMPLE-COM.service
> > > ● dirsrv@KW-EXAMPLE-COM.service - 389 Directory Server KW-EXAMPLE-COM.
> > > Loaded: loaded (/usr/lib/systemd/system/dirsrv@.service; enabled;
> > vendor
> > > preset: disabled)
> > > Active: failed (Result: exit-code) since Wed 2017-01-04 12:54:46
> > AST; 13s ago
> > >Process: 14893 ExecStart=/usr/sbin/ns-slapd -D /etc/dirsrv/slapd-%i -i
> > > /var/run/dirsrv/slapd-%i.pid (code=exited, status=1/FAILURE)
> > >Process: 14887 ExecStartPre=/usr/sbin/ds_systemd_ask_password_acl
> > > /etc/dirsrv/slapd-%i/dse.ldif (code=exited, status=0/SUCCESS)
> > >   Main PID: 14893 (code=exited, status=1/FAILURE)
> > >
> > > Jan 04 12:54:46 zkwiparepa01.kw.example.com  > example.com>
> > > ns-slapd[14893]: [04/Jan/2017:12:54:46.177617891 +0300] Error:
> > > betxnpostoperation plu...arted
> > > Jan 04 12:54:46 zkwiparepa01.kw.example.com  > example.com>
> > > ns-slapd[14893]: [04/Jan/2017:12:54:46.178379752 +0300] Error: object
> > plugin
> > > Roles Pl...arted
> > > Jan 04 12:54:46 zkwiparepa01.kw.example.com  > example.com>
> > > ns-slapd[14893]: [04/Jan/2017:12:54:46.179162340 +0300] Error:
> > preoperation
> > > plugin su...arted
> > > Jan 04 12:54:46 zkwiparepa01.kw.example.com  > example.com>
> > > ns-slapd[14893]: [04/Jan/2017:12:54:46.179993432 +0300] Error: object
> > plugin USN
> > > is n...arted
> > > Jan 04 12:54:46 zkwiparepa01.kw.example.com  > example.com>
> > > 

Re: [Freeipa-users] ipa replica installation help

[Ben .T.George]

HI

anyone please help me to fix this.

Regards,
Ben

On Wed, Jan 4, 2017 at 3:12 PM, Ben .T.George  wrote:

> HI
>
> port 8009 is not listening in master server
>
> and i added ::1 localhost localhost.localdomain localhost6
> localhost6.localdomain6 in hosts file.
>
> still getting same error
>
>  [28/44]: restarting directory server
> ipa : CRITICAL Failed to restart the directory server (Command
> '/bin/systemctl restart dirsrv@KW-EXAMPLE-COM.service' returned non-zero
> exit status 1). See the installation log for details.
>   [29/44]: setting up initial replication
>   [error] error: [Errno 111] Connection refused
> Your system may be partly configured.
> Run /usr/sbin/ipa-server-install --uninstall to clean up.
>
> ipa.ipapython.install.cli.install_tool(Replica): ERROR[Errno 111]
> Connection refused
> ipa.ipapython.install.cli.install_tool(Replica): ERRORThe
> ipa-replica-install command failed. See /var/log/ipareplica-install.log
> for more information
>
>
> Also  ipv6 is disabled on both nodes
>
> Regards,
> Ben
>
> On Wed, Jan 4, 2017 at 2:05 PM, Petr Vobornik  wrote:
>
>> On 01/04/2017 10:59 AM, Ben .T.George wrote:
>> > HI
>> >
>> > i tried the method mentioned on that document and it end up with below
>> error. My
>> > DNS is managed by external box and i dont want to create any DNS record
>> on these
>> > servers.
>> >
>> > and the command which i tried is(non client server)
>> >
>> > ipa-replica-install --principal admin --admin-password P@ssw0rd
>> --domain
>> > kw.example.com  --server
>> zkwipamstr01.kw.example.com
>> > 
>> >
>> >
>> >
>> > ipa : CRITICAL Failed to restart the directory server (Command
>> > '/bin/systemctl restart dirsrv@KW-EXAMPLE-COM.service' returned
>> non-zero exit
>> > status 1). See the installation log for details.
>> >[29/44]: setting up initial replication
>> >[error] error: [Errno 111] Connection refused
>> > Your system may be partly configured.
>> > Run /usr/sbin/ipa-server-install --uninstall to clean up.
>> >
>> > ipa.ipapython.install.cli.install_tool(Replica): ERROR[Errno 111]
>> Connection
>> > refused
>> > ipa.ipapython.install.cli.install_tool(Replica): ERRORThe
>> > ipa-replica-install command failed. See /var/log/ipareplica-install.log
>> for more
>> > information
>>
>> This looks like bug https://fedorahosted.org/freeipa/ticket/6575
>>
>> To verify that, could you check if master server internally listens on
>> port 8009 or if ipareplica-install.log contains CA_UNREACHABLE string
>> near  step 27.
>>
>> Usual fix is to add following line to /etc/hosts
>>   ::1 localhost localhost.localdomain localhost6
>> localhost6.localdomain6
>>
>>
>> > [root@zkwiparepa01 ~]# /bin/systemctl restart
>> dirsrv@KW-EXAMPLE-COM.service
>> > Job for dirsrv@KW-EXAMPLE-COM.service failed because the control
>> process exited
>> > with error code. See "systemctl status dirsrv@KW-EXAMPLE-COM.service"
>> and
>> > "journalctl -xe" for details.
>> >
>> > [root@zkwiparepa01 ~]# systemctl status dirsrv@KW-EXAMPLE-COM.service
>> > ● dirsrv@KW-EXAMPLE-COM.service - 389 Directory Server KW-EXAMPLE-COM.
>> > Loaded: loaded (/usr/lib/systemd/system/dirsrv@.service; enabled;
>> vendor
>> > preset: disabled)
>> > Active: failed (Result: exit-code) since Wed 2017-01-04 12:54:46
>> AST; 13s ago
>> >Process: 14893 ExecStart=/usr/sbin/ns-slapd -D /etc/dirsrv/slapd-%i
>> -i
>> > /var/run/dirsrv/slapd-%i.pid (code=exited, status=1/FAILURE)
>> >Process: 14887 ExecStartPre=/usr/sbin/ds_systemd_ask_password_acl
>> > /etc/dirsrv/slapd-%i/dse.ldif (code=exited, status=0/SUCCESS)
>> >   Main PID: 14893 (code=exited, status=1/FAILURE)
>> >
>> > Jan 04 12:54:46 zkwiparepa01.kw.example.com <
>> http://zkwiparepa01.kw.example.com>
>> > ns-slapd[14893]: [04/Jan/2017:12:54:46.177617891 +0300] Error:
>> > betxnpostoperation plu...arted
>> > Jan 04 12:54:46 zkwiparepa01.kw.example.com <
>> http://zkwiparepa01.kw.example.com>
>> > ns-slapd[14893]: [04/Jan/2017:12:54:46.178379752 +0300] Error: object
>> plugin
>> > Roles Pl...arted
>> > Jan 04 12:54:46 zkwiparepa01.kw.example.com <
>> http://zkwiparepa01.kw.example.com>
>> > ns-slapd[14893]: [04/Jan/2017:12:54:46.179162340 +0300] Error:
>> preoperation
>> > plugin su...arted
>> > Jan 04 12:54:46 zkwiparepa01.kw.example.com <
>> http://zkwiparepa01.kw.example.com>
>> > ns-slapd[14893]: [04/Jan/2017:12:54:46.179993432 +0300] Error: object
>> plugin USN
>> > is n...arted
>> > Jan 04 12:54:46 zkwiparepa01.kw.example.com <
>> http://zkwiparepa01.kw.example.com>
>> > ns-slapd[14893]: [04/Jan/2017:12:54:46.181305209 +0300] Error: object
>> plugin
>> > Views is...arted
>> > Jan 04 12:54:46 zkwiparepa01.kw.example.com <
>> http://zkwiparepa01.kw.example.com>
>> > ns-slapd[14893]: [04/Jan/2017:12:54:46.182094981 +0300] Error:
>> extendedop plugin
>> > whoa...arted
>> > Jan 04 12:54:46 

[Freeipa-users] IPA to IPA migration

[Timothy Geier]

This is something I’ve looked at lately and a manual proof of concept I just 
did (using ideas from 
https://www.freeipa.org/page/Howto/Migration#Migrating_from_other_FreeIPA_to_FreeIPA)
 makes it seem theoretically possible (though it looks like, barring the 
migration of the kerberos master key, all enrolled hosts would need to use 
ipa-getkeytab to get a replacement keytab from the new server and copy it to 
/etc/krb5.keytab so that sssd will work properly..the alternative is 
re-enrollment.  All other keytabs in use by other applications would have to be 
similarly replaced).

Is https://fedorahosted.org/freeipa/ticket/3656 something that’s coming sooner 
or later to a future version of FreeIPA?  Has anyone done a manual migration on 
a moderate-to-large setup?
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

[Freeipa-users] Lookups Failing With AD Forwarder (and DNSSEC)

[Jason B. Nance]

Hello everyone,

I have a pair of FreeIPA 4.4.0 servers setup whose forwarders are each set to 
an Active Directory domain controller.  When a client attempts to lookup any 
DNS record other than those to which FreeIPA is authoritative the client 
reports NXDOMAIN and the FreeIPA server has the following in its logs:

(first lookup)
Jan 04 16:05:21 sl1mmgplidm0001.ipa.tkc.gen.zone named-pkcs11[1632]: error (no 
valid RRSIG) resolving 'zone/DS/IN': 10.48.8.18#53
Jan 04 16:05:21 sl1mmgplidm0001.ipa.tkc.gen.zone named-pkcs11[1632]: error (no 
valid DS) resolving 'sl1mmgpwtdc0001.tkc.gen.zone/A/IN': 10.48.8.18#53

(subsequent lookups)
Jan 04 16:10:57 sl1mmgplidm0001.ipa.tkc.gen.zone named-pkcs11[1632]: validating 
@0x7f7a40983ea0: sl1mmgpwtdc0001.tkc.gen.zone A: bad cache hit (zone/DS)
Jan 04 16:10:57 sl1mmgplidm0001.ipa.tkc.gen.zone named-pkcs11[1632]: error 
(broken trust chain) resolving 'sl1mmgpwtdc0001.tkc.gen.zone/A/IN': 
10.48.8.18#53

In my case, ipa.tkc.gen.zone is served by FreeIPA and tkc.gen.zone is served by 
AD (as is gen.zone).  10.48.8.18 is an AD domain controller for tkc.gen.zone 
(and the forwarder the FreeIPA servers are pointed at).

I've tried "rndc flush" and "rndc flushname ." on the FreeIPA boxes.  We've 
tried both NSEC3 and NSEC.

Anyone have guidance as to what may be going on?

Thanks,

j

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

Re: [Freeipa-users] nfsv4+kerberos: group ID not mapped on newly create users, however user id is correct

[Lukas Slebodnik]

On (08/12/16 10:24), Bjarne Blichfeldt wrote:
>> -Original Message-
>> From: David Kupka [mailto:dku...@redhat.com]
>> Sent: 8. december 2016 09:40
>> To: Bjarne Blichfeldt ; freeipa-users@redhat.com
>> Subject: Re: [Freeipa-users] nfsv4+kerberos: group ID not mapped on newly
>> create users, however user id is correct
>> 
>> On 08/12/16 08:57, Bjarne Blichfeldt wrote:
>> > Anybody have any suggestion as how to continue debugging this? The nfs 
>> > server
>> resolves usernames by loopkup in free-ipa lda.
>> >
>> > After a lot of digging, I see the 4.4 introduced "krbcanonicalname", no 
>> > idea if that
>> is relevant. Are there some update ldap procedure I am missing? Just in case 
>> I ran
>> a ipa-server-upgrade, which did not resolve the issue.
>> >
>> >
>:snip
>> >
>> >
>> 
>> Hello,
>> I'm almost sure that 'krbcanonicalname' has nothing to do with this.
>> Adding krbcanonicalname attribute was done to allow principal aliases 
>> (multiple
>> kerberos principals for one user/host/service), see [1] for details.
>> 
>> Unfortunately, I don't know what's wrong. SSSD is taking care of resolving 
>> users
>> and groups on enrolled systems. "id mgm" should output something like
>> "id=1414(mgm) gid=1414(mgm) groups=1414(mgm)" if it works properly.
>> 
>> [1] http://www.freeipa.org/page/V4/Kerberos_principal_aliases
>> 
>> --
>> David Kupka
>
>Thank you for that info. That led me somewhat further by increasing the debug 
>on sssd which led me to :
>
>Dec  8 10:42:48 client nfsidmap[6663]: key: 0xae72f5 type: uid value: 
>m...@realm.com timeout 600
>Dec  8 10:42:48 client nfsidmap[6663]: nfs4_name_to_uid: calling 
>nsswitch->name_to_uid
>Dec  8 10:42:48 client nfsidmap[6663]: nss_getpwnam: name 'm...@realm.com' 
>domain 'REALM.COM': resulting localname 'mqm2'
>Dec  8 10:42:48 client nfsidmap[6663]: nfs4_name_to_uid: nsswitch->name_to_uid 
>returned 0
>Dec  8 10:42:48 client nfsidmap[6663]: nfs4_name_to_uid: final return value is >0
>
>Dec  8 10:42:48 client nfsidmap[6665]: key: 0xf56593 type: gid value: Null 
>timeout 600
>   
> ^
>Dec  8 10:42:48 client nfsidmap[6665]: nfs4_name_to_gid: calling 
>nsswitch->name_to_gid
>Dec  8 10:42:48 client nfsidmap[6665]: nfs4_name_to_gid: nsswitch->name_to_gid 
>returned -22
>Dec  8 10:42:48 client nfsidmap[6665]: nfs4_name_to_gid: final return value is 
>-22Seems nfsidmap is not called with a gid value.
>
>It seems nfsidmap is not called with a proper gid.
>hm, the saga continues...
>
You might want to use sss nfsidmap plugin.
* set method in /etc/idmap.conf to sss
* restart nfsidmapd

BTW In fedora and sssd-1.14 + it is part of recomended
package sssd-nfs-idmap (weak dependency)
older versions and other distributions might have packages in sssd-common
   /usr/lib64/libnfsidmap/sss.so

LS

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

Re: [Freeipa-users] ipa-dnskeysyncd ipa : ERROR Login to LDAP server failed: {'desc': 'Invalid credentials'}

[Jeff Goddard]

I don't want to hijack someone else's thread but I'm having what appears to
be the same problem and have not seen a solution presented yet.

Here is the output of journalctl -xe after having tried to start named:

Jan 04 15:48:42 id-management-2.internal.emerlyn.com named-pkcs11[3948]:
loading configuration from '/etc/named.conf'
Jan 04 15:48:42 id-management-2.internal.emerlyn.com named-pkcs11[3948]:
reading built-in trusted keys from file '/etc/named.iscdlv.key'
Jan 04 15:48:42 id-management-2.internal.emerlyn.com named-pkcs11[3948]:
using default UDP/IPv4 port range: [1024, 65535]
Jan 04 15:48:42 id-management-2.internal.emerlyn.com named-pkcs11[3948]:
using default UDP/IPv6 port range: [1024, 65535]
Jan 04 15:48:42 id-management-2.internal.emerlyn.com named-pkcs11[3948]:
listening on IPv6 interfaces, port 53
Jan 04 15:48:42 id-management-2.internal.emerlyn.com named-pkcs11[3948]:
listening on IPv4 interface lo, 127.0.0.1#53
Jan 04 15:48:42 id-management-2.internal.emerlyn.com named-pkcs11[3948]:
listening on IPv4 interface ens32, 10.73.100.31#53
Jan 04 15:48:42 id-management-2.internal.emerlyn.com named-pkcs11[3948]:
generating session key for dynamic DNS
Jan 04 15:48:42 id-management-2.internal.emerlyn.com named-pkcs11[3948]:
sizing zone task pool based on 6 zones
Jan 04 15:48:42 id-management-2.internal.emerlyn.com named-pkcs11[3948]:
set up managed keys zone for view _default, file
'/var/named/dynamic/managed-keys.bind'
Jan 04 15:48:42 id-management-2.internal.emerlyn.com named-pkcs11[3948]:
bind-dyndb-ldap version 10.0 compiled at 18:06:06 Nov 11 2016, compiler
4.8.5 20150623 (Red Hat 4.8.5-11)
Jan 04 15:48:42 id-management-2.internal.emerlyn.com named-pkcs11[3948]:
option 'serial_autoincrement' is not supported, ignoring
Jan 04 15:48:42 id-management-2.internal.emerlyn.com named-pkcs11[3948]:
GSSAPI client step 1
Jan 04 15:48:42 id-management-2.internal.emerlyn.com named-pkcs11[3948]:
GSSAPI client step 1
Jan 04 15:48:42 id-management-2.internal.emerlyn.com ns-slapd[2596]: GSSAPI
server step 1
Jan 04 15:48:42 id-management-2.internal.emerlyn.com named-pkcs11[3948]:
GSSAPI client step 1
Jan 04 15:48:42 id-management-2.internal.emerlyn.com ns-slapd[2596]: GSSAPI
server step 2
Jan 04 15:48:42 id-management-2.internal.emerlyn.com named-pkcs11[3948]:
GSSAPI client step 2
Jan 04 15:48:42 id-management-2.internal.emerlyn.com ns-slapd[2596]: GSSAPI
server step 3
Jan 04 15:48:42 id-management-2.internal.emerlyn.com named-pkcs11[3948]:
LDAP error: Invalid credentials: bind to LDAP server failed
Jan 04 15:48:42 id-management-2.internal.emerlyn.com named-pkcs11[3948]:
couldn't establish connection in LDAP connection pool: permission denied
Jan 04 15:48:42 id-management-2.internal.emerlyn.com named-pkcs11[3948]:
dynamic database 'ipa' configuration failed: permission denied
Jan 04 15:48:42 id-management-2.internal.emerlyn.com named-pkcs11[3948]:
loading configuration: permission denied
Jan 04 15:48:42 id-management-2.internal.emerlyn.com named-pkcs11[3948]:
exiting (due to fatal error)
Jan 04 15:48:42 id-management-2.internal.emerlyn.com systemd[1]:
named-pkcs11.service: control process exited, code=exited status=1
Jan 04 15:48:42 id-management-2.internal.emerlyn.com systemd[1]: Failed to
start Berkeley Internet Name Domain (DNS) with native PKCS#11.
-- Subject: Unit named-pkcs11.service has failed
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit named-pkcs11.service has failed.
--
-- The result is failed.
Jan 04 15:48:42 id-management-2.internal.emerlyn.com systemd[1]: Unit
named-pkcs11.service entered failed state.
Jan 04 15:48:42 id-management-2.internal.emerlyn.com systemd[1]:
named-pkcs11.service failed.
Jan 04 15:48:42 id-management-2.internal.emerlyn.com polkitd[949]:
Unregistered Authentication Agent for unix-process:3936:380486 (system bus
name :1.59, object path /org/freedesktop/Policy

Here are the last four entries of /var/log/dirsrv/slapd-*/access |grep
ipa-dnskeysyncdcat:

[04/Jan/2017:15:28:37.463224739 -0500] conn=5 op=1129 SRCH
base="dc=internal,dc=emerlyn,dc=com" scope=2
filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal)(objectClass=ipakrbprincipal))(|(ipaKrbPrincipalAlias=ipa-dnskeysyncd/
id-management-2.internal.emerlyn@internal.emerlyn.com
)(krbPrincipalName:caseIgnoreIA5Match:=ipa-dnskeysyncd/
id-management-2.internal.emerlyn@internal.emerlyn.com)))"
attrs="krbPrincipalName krbCanonicalName krbUPEnabled krbPrincipalKey
krbTicketPolicyReference krbPrincipalExpiration krbPasswordExpiration
krbPwdPolicyReference krbPrincipalType krbPwdHistory krbLastPwdChange
krbPrincipalAliases krbLastSuccessfulAuth krbLastFailedAuth
krbLoginFailedCount krbPrincipalAuthInd krbExtraData krbLastAdminUnlock
krbObjectReferences krbTicketFlags krbMaxTicketLife krbMaxRenewableAge
nsAccountLock passwordHistory ipaKrbAuthzData ipaUserAuthType
ipatokenRadiusConfigLink objectClass"
[04/Jan/2017:15:28:37.464739661 -0500] conn=5 op=1133 

Re: [Freeipa-users] Asking for help with crashed freeIPA istance

[Daniel Schimpfoessl]

>From the logs:
/var/log/dirsrv/slapd-DOMAIN-COM/errors
... a few warnings about cache size, NSACLPLugin and schema-compat-plugin
[04/Jan/2017:12:14:21.392642021 -0600] slapd started.  Listening on All
Interfaces port 389 for LDAP requests

/var/log/dirsrv/slapd-DOMAIN-COM/access
... lots of entries, not sure what to look for some lines contain RESULT
with err!=0
[04/Jan/2017:12:18:01.753400307 -0600] conn=5 op=243 RESULT err=32 tag=101
nentries=0 etime=0
[04/Jan/2017:12:18:01.786928085 -0600] conn=44 op=1 RESULT err=14 tag=97
nentries=0 etime=0, SASL bind in progress

/var/log/dirsrv/slapd-DOMAIN-COM/errors
[04/Jan/2017:12:19:25.566022098 -0600] slapd shutting down - signaling
operation threads - op stack size 5 max work q size 2 max work q stack size
2
[04/Jan/2017:12:19:25.572566622 -0600] slapd shutting down - closing down
internal subsystems and plugins


2017-01-04 8:38 GMT-06:00 Daniel Schimpfoessl :

> Do you have a list of all log files involved in IPA?
> Would be good to consolidate them into ELK for analysis.
>
> 2017-01-04 2:48 GMT-06:00 Florence Blanc-Renaud :
>
>> On 01/02/2017 07:24 PM, Daniel Schimpfoessl wrote:
>>
>>> Thanks for your reply.
>>>
>>> This was the initial error I asked for help a while ago and did not get
>>> resolved. Further digging showed the recent errors.
>>> The service was running (using ipactl start --force) and only after a
>>> restart I am getting a stack trace for two primary messages:
>>>
>>> Could not connect to LDAP server host wwgwho01.webwim.com
>>>  port 636 Error netscape.ldap.LDAPException:
>>> Authentication failed (48)
>>> ...
>>>
>>> Internal Database Error encountered: Could not connect to LDAP server
>>> host wwgwho01.webwim.com  port 636 Error
>>> netscape.ldap.LDAPException: Authentication failed (48)
>>> ...
>>>
>>> and finally:
>>> [02/Jan/2017:12:20:34][localhost-startStop-1]: CMSEngine.shutdown()
>>>
>>>
>>> 2017-01-02 3:45 GMT-06:00 Florence Blanc-Renaud >> >:
>>>
>>> systemctl start pki-tomcatd@pki-tomcat.service
>>>
>>>
>>>
>>> Hi Daniel,
>>
>> the next step would be to understand the root cause of this
>> "Authentication failed (48)" error. Note the exact time of this log and
>> look for a corresponding log in the LDAP server logs
>> (/var/log/dirsrv/slapd-DOMAIN-COM/access), probably a failing BIND with
>> err=48. This may help diagnose the issue (if we can see which certificate
>> is used for the bind or if there is a specific error message).
>>
>> For the record, a successful bind over SSL would produce this type of log
>> where we can see the certificate subject and the user mapped to this
>> certificate:
>> [...] conn=47 fd=84 slot=84 SSL connection from 10.34.58.150 to
>> 10.34.58.150
>> [...] conn=47 TLS1.2 128-bit AES; client CN=CA Subsystem,O=DOMAIN.COM;
>> issuer CN=Certificate Authority,O=DOMAIN.COM
>> [...] conn=47 TLS1.2 client bound as uid=pkidbuser,ou=people,o=ipaca
>> [...] conn=47 op=0 BIND dn="" method=sasl version=3 mech=EXTERNAL
>> [...] conn=47 op=0 RESULT err=0 tag=97 nentries=0 etime=0
>> dn="uid=pkidbuser,ou=people,o=ipaca"
>>
>> Flo
>>
>
>
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Replica issue / Certificate Authority

[Christophe TREFOIS]

To all,

So to recap, if I hit resubmit once, I get a CA_WORKING, if I do it immediately 
after again, I get a MONITORING, but the “ca-error: Invalid cookie” comes back.

How can I get a valid cookie back?

Thanks for your help,
Christophe

> On 4 Jan 2017, at 14:19, Christophe TREFOIS  wrote:
> 
> Hi Florence,
> 
> I did what you said, and then the status went to CA_WORKING. Then I restart 
> ipa and certmonger and the status went to CA_UNREACHABLE.
> Then i did “resubmit” again and now the status is back to MONITORING, but the 
> cookie error is back.
> 
> Any advice?
> 
> [root@lums3 ~]# getcert list -n ipaCert
> Number of certificates and requests being tracked: 8.
> Request ID '20161216025136':
>   status: MONITORING
>   ca-error: Invalid cookie: ''
>   stuck: no
>   key pair storage: 
> type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS 
> Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt'
>   certificate: 
> type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS 
> Certificate DB'
>   CA: dogtag-ipa-ca-renew-agent
>   issuer: CN=Certificate Authority,O=UNI.LU
>   subject: CN=IPA RA,O=UNI.LU
>   expires: 2018-12-16 03:13:48 UTC
>   key usage: 
> digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
>   eku: id-kp-serverAuth,id-kp-clientAuth
>   pre-save command: /usr/libexec/ipa/certmonger/renew_ra_cert_pre
>   post-save command: /usr/libexec/ipa/certmonger/renew_ra_cert
>   track: yes
>   auto-renew: yes
> 
> -- 
> 
> Dr Christophe Trefois, Dipl.-Ing.  
> Technical Specialist / Post-Doc
> 
> UNIVERSITÉ DU LUXEMBOURG
> 
> LUXEMBOURG CENTRE FOR SYSTEMS BIOMEDICINE
> Campus Belval | House of Biomedicine  
> 6, avenue du Swing 
> L-4367 Belvaux  
> T: +352 46 66 44 6124 
> F: +352 46 66 44 6949  
> http://www.uni.lu/lcsb 
>        
>    
>    
> 
> 
> This message is confidential and may contain privileged information. 
> It is intended for the named recipient only. 
> If you receive it in error please notify me and permanently delete the 
> original message and any copies. 
> 
> 
>   
> 
>> On 4 Jan 2017, at 13:49, Florence Blanc-Renaud > > wrote:
>> 
>> getcert resubmit -i 
> 
> -- 
> 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



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

[Freeipa-users] CA crt renew -- encoding mismatch

[Jan Orel]

Hello,

recently we renewed our CA crt. Later we noticed the new CA certificate
uses different encoding in Issuer and Subject:

subject=
organizationName  = UTF8STRING:INTGDC.COM
commonName= UTF8STRING:Certificate Authority
issuer=
organizationName  = PRINTABLESTRING:INTGDC.COM
commonName= PRINTABLESTRING:Certificate Authority

The former CA certificate is PRINTABLESTRING in both fields, as well as all
the older certs.

Since the renewal we have issues with trusting newly issued certificates,
which also have different encoding in subject and issuer.

What should be the default (correct) encoding for the certificates?

According to the: http://www.freeipa.org/page/Troubleshooting seems it
should be UTF8

but from the certmonger:
https://git.fedorahosted.org/cgit/certmonger.git/commit/?id=e6ecd5d8df3413a9717c57ee7fb8702ece23afd6

seems PRINTABLESTRING is used.

How to fix? Do we need to re-new the CA certificate once again?

Thank you
Jan Orel

We run:
ipa-server-4.2.0-15.0.1.el7.centos.19.x86_64
certmonger-0.78.4-1.el7.x86_64
nuxwdog-1.0.3-4.el7_2.x86_64
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

[Freeipa-users] Fwd: Unspecified GSS failure. Minor code may provide more information KDC has no support for encryption type

[tarak sinha]

Hi Team,

My other node's are working fine. It's not asking any password. Please let
me know to fix this issue. thanks to reach out me
Here it is output from working node:---

debug1: Authentications that can continue: publickey,gssapi-with-mic,
password
debug1: Next authentication method: gssapi-with-mic
debug1: Delegating credentials
debug1: Delegating credentials
debug1: Authentication succeeded (gssapi-with-mic).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
Last login: Wed Jan  4 07:31:27 2017 from 10.229.67.109

###

logs from failure node while do ssh

ebug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure.  Minor code may provide more information
KDC has no support for encryption type

debug1: Unspecified GSS failure.  Minor code may provide more information
KDC has no support for encryption type

debug1: Unspecified GSS failure.  Minor code may provide more information


debug1: Authentications that can continue: publickey,gssapi-with-mic,
password
debug1: Next authentication method: publickey
debug1: Offering public key: /uhome/tsinha/.ssh/id_rsa
debug1: Authentications that can continue: publickey,gssapi-with-mic,
password
debug1: Trying private key: /uhome/tsinha/.ssh/id_dsa
debug1: Trying private key: /uhome/tsinha/.ssh/id_ecdsa
debug1: Next authentication method: password


@@@


Thanks,

Tarak


On Wed, Jan 4, 2017 at 8:35 PM, tarak sinha  wrote:

> It showing below encryption type..
>
> Etype (skey, tkt): AES-256 CTS mode with 96-bit SHA-1 HMAC, AES-256 CTS
> mode with 96-bit SHA-1 HMAC
>
> On Wed, Jan 4, 2017 at 8:28 PM, Sumit Bose  wrote:
>
>> On Wed, Jan 04, 2017 at 08:01:54PM +0530, tarak sinha wrote:
>> > Hi Sumit.
>> >
>> > I am getting this error on host .
>>
>> In which log file do you see the message? Can you send the full message
>> and a bit of context from the log file?
>>
>> What encryption types does 'klist -k -e' show for the host key on the
>> host?  What encryption types does 'klist -e' show on the client after
>> calling ssh?
>>
>> bye,
>> Sumit
>>
>> >
>> > Thanks
>> >
>> > On Wed, Jan 4, 2017 at 4:28 PM, Sumit Bose  wrote:
>> >
>> > > On Mon, Jan 02, 2017 at 11:03:36PM +0530, tarak sinha wrote:
>> > > > Hi Team,
>> > > >
>> > > > I am getting below error while trying to ssh my host without
>> password.
>> > > >
>> > > > Unspecified GSS failure. Minor code may provide more information
>> KDC has
>> > > no
>> > > > support for encryption type
>> > >
>> > > Where do you see this error, on the client where you call ssh or in
>> the
>> > > logs on the host you try to log in to? Are you using IPA user or do
>> you
>> > > use trust and AD users from a trusted domain?
>> > >
>> > > Do you see any related messages in the KDC logs?
>> > >
>> > > bye,
>> > > Sumit
>> > >
>> > > >
>> > > > Thanks in advance
>> > > >
>> > > > *Thanks,*
>> > > >
>> > > > *Tarak Nath Sinha*
>> > >
>> > > > --
>> > > > 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
>> > >
>> >
>> >
>> >
>> > --
>> >
>> > *Thanks,*
>> >
>> > *Tarak Nath Sinha*
>> >
>> > *Mobile: **+91 8197522750*
>>
>
>
>
> --
>
> *Thanks,*
>
> *Tarak Nath Sinha*
>
> *Mobile: **+91 8197522750*
>



-- 

*Thanks,*

*Tarak Nath Sinha*

*Mobile: **+91 8197522750*



-- 

*Thanks,*

*Tarak Nath Sinha*

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

Re: [Freeipa-users] Asking for help with crashed freeIPA istance

[Daniel Schimpfoessl]

Do you have a list of all log files involved in IPA?
Would be good to consolidate them into ELK for analysis.

2017-01-04 2:48 GMT-06:00 Florence Blanc-Renaud :

> On 01/02/2017 07:24 PM, Daniel Schimpfoessl wrote:
>
>> Thanks for your reply.
>>
>> This was the initial error I asked for help a while ago and did not get
>> resolved. Further digging showed the recent errors.
>> The service was running (using ipactl start --force) and only after a
>> restart I am getting a stack trace for two primary messages:
>>
>> Could not connect to LDAP server host wwgwho01.webwim.com
>>  port 636 Error netscape.ldap.LDAPException:
>> Authentication failed (48)
>> ...
>>
>> Internal Database Error encountered: Could not connect to LDAP server
>> host wwgwho01.webwim.com  port 636 Error
>> netscape.ldap.LDAPException: Authentication failed (48)
>> ...
>>
>> and finally:
>> [02/Jan/2017:12:20:34][localhost-startStop-1]: CMSEngine.shutdown()
>>
>>
>> 2017-01-02 3:45 GMT-06:00 Florence Blanc-Renaud > >:
>>
>> systemctl start pki-tomcatd@pki-tomcat.service
>>
>>
>>
>> Hi Daniel,
>
> the next step would be to understand the root cause of this
> "Authentication failed (48)" error. Note the exact time of this log and
> look for a corresponding log in the LDAP server logs
> (/var/log/dirsrv/slapd-DOMAIN-COM/access), probably a failing BIND with
> err=48. This may help diagnose the issue (if we can see which certificate
> is used for the bind or if there is a specific error message).
>
> For the record, a successful bind over SSL would produce this type of log
> where we can see the certificate subject and the user mapped to this
> certificate:
> [...] conn=47 fd=84 slot=84 SSL connection from 10.34.58.150 to
> 10.34.58.150
> [...] conn=47 TLS1.2 128-bit AES; client CN=CA Subsystem,O=DOMAIN.COM;
> issuer CN=Certificate Authority,O=DOMAIN.COM
> [...] conn=47 TLS1.2 client bound as uid=pkidbuser,ou=people,o=ipaca
> [...] conn=47 op=0 BIND dn="" method=sasl version=3 mech=EXTERNAL
> [...] conn=47 op=0 RESULT err=0 tag=97 nentries=0 etime=0
> dn="uid=pkidbuser,ou=people,o=ipaca"
>
> Flo
>
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Kerberos authentication failed: kinit: Included profile directory could not be read while initializing Kerberos 5 library

[Rob Crittenden]

Alan Latteri wrote:
> Well on new installs of Cent 7.2, when I do `yum install ipa-client`, that is 
> the version provided.
> Unfortunately, most of our systems have to be on Cent 7.2, not 7.3, and it is 
> out of our control.

Either way it's a bug somewhere in ipa-client, it should require a
minimum version of krb5-libs which provides this file (or explicitly
check for existence of this directory). I opened a ticket on it,
https://fedorahosted.org/freeipa/ticket/6589

rob

> 
> Alan
> 
>> On Jan 3, 2017, at 8:33 PM, Rob Crittenden  wrote:
>>
>> Alan Latteri wrote:
>>> Further investigation.
>>>
>>> On a clean install of CentOS 7.2 with IPA Client 4.4, /etc/krb5.conf.d/ is 
>>> missing, and therefore initial setup will fail unless manual creation of 
>>> /etc/krb5.conf.d/
>>> Maybe the install script for the client can be updated to check for and 
>>> create?
>>
>> Is there a reason you're running 7.3 packages on a 7.2 system? I suspect
>> that is the problem. AFAIU in 7.3 this directory is provided by krb5-libs.
>>
>> Is there some feature you need in the 4.4 client installer on 7.2?
>>
>> rob
>>
>>>
>>> Thanks,
>>> Alan
>>>
 On Jan 3, 2017, at 1:44 PM, Alan Latteri  
 wrote:

 Thanks Rob.

 /etc/krb5.conf.d/  was in fact missing from the client, which is still on 
 CentOS 7.2 for reasons out of our control.
 Other hosts that are CentOS 7.2 running IPA Client 4.2.0 also do not have 
 the /etc/krb5.conf.d/ directory, but are running fine.  So maybe the 4.4 
 client requires that dir but is not making it on upgrade and the cause of 
 the failure?

 Alan

> On Jan 3, 2017, at 1:25 PM, Rob Crittenden  wrote:
>
> Alan Latteri wrote:
>> Log is attached.
>
> Look and see if /etc/krb5.conf.d/ and
> /var/lib/sss/pubconf/krb5.include.d exist and are readable (and check
> for SELinux AVCs). I'm pretty sure this all runs as root so I doubt
> filesystem perms are an issue but who knows.
>
> You can also brute force things using strace -f to find out exactly what
> can't be read.
>
> rob
>


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

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

Re: [Freeipa-users] Valid Sender ? - Re: Using Privacyidea with FreeIPA - part 1/n

[Cornelius Kölbel]

Hi Jochen,

this is a very important point.
Every application is adopting two factor authentication with OTP. This is 
great - we always hoped for such a security awareness.
But the important difference is: 
The common webapplication that finally will implement TOTP ("this cloudy 
algorithm which was invented by the Google Authenticator" ;-) ) manages the 
seeds/keys for these tokens. If the user uses a smartphone app the user 
will end up with an "OTP token" or "profile" in his App for every 
application.

Or he has to share the seeds one seed between all applications. And then he 
runs into the troubles mentioned earlier.

You perfectly pointed out, why you need a central authentication system for 
managing the second factors.
>From a user experience point fo view the applications could also go for 
U2F. Then the user again will only have one device, which he needs tor 
register with each application...
...but there will be no "syncing" problem.

Kind regards
Cornelius


Am Donnerstag, 29. Dezember 2016 20:45:34 UTC+1 schrieb Jochen Hein:
>
> Martin Basti > writes: 
>
>
> >>But providing access to a Yubico Token via privacyidea works for all 
> >>cases I have in mind. 
> > 
> > How they are checking the valid tokes if they don't use its counter? 
>
> Privacyidea is the "owner" of the token and has the secret and the 
> counter stored. Every other system (e.g. pam_yubico or FreeIPA) is 
> checking the validation against privacyiadea, either with the yubico 
> protocol, the privacyidey validation, or RADIUS. 
>
> Does this clarify the architecture of my system? 
>
> Jochen 
>
> -- 
> The only problem with troubleshooting is that the trouble shoots back. 
>
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Valid Sender ? - Re: Using Privacyidea with FreeIPA - part 1/n

[Cornelius Kölbel]

...by the way. This is probably the reason, why Red Hat uses the 
predecessor of privacyIDEA as central 2FA authentication system for the OTP 
authentication.

Kind regards
Cornelius

Am Freitag, 30. Dezember 2016 08:21:36 UTC+1 schrieb Cornelius Kölbel:
>
> Hi Jochen,
>
> this is a very important point.
> Every application is adopting two factor authentication with OTP. This is 
> great - we always hoped for such a security awareness.
> But the important difference is: 
> The common webapplication that finally will implement TOTP ("this cloudy 
> algorithm which was invented by the Google Authenticator" ;-) ) manages the 
> seeds/keys for these tokens. If the user uses a smartphone app the user 
> will end up with an "OTP token" or "profile" in his App for every 
> application.
>
> Or he has to share the seeds one seed between all applications. And then 
> he runs into the troubles mentioned earlier.
>
> You perfectly pointed out, why you need a central authentication system 
> for managing the second factors.
> From a user experience point fo view the applications could also go for 
> U2F. Then the user again will only have one device, which he needs tor 
> register with each application...
> ...but there will be no "syncing" problem.
>
> Kind regards
> Cornelius
>
>
> Am Donnerstag, 29. Dezember 2016 20:45:34 UTC+1 schrieb Jochen Hein:
>>
>> Martin Basti > writes: 
>>
>>
>> >>But providing access to a Yubico Token via privacyidea works for 
>> all 
>> >>cases I have in mind. 
>> > 
>> > How they are checking the valid tokes if they don't use its counter? 
>>
>> Privacyidea is the "owner" of the token and has the secret and the 
>> counter stored. Every other system (e.g. pam_yubico or FreeIPA) is 
>> checking the validation against privacyiadea, either with the yubico 
>> protocol, the privacyidey validation, or RADIUS. 
>>
>> Does this clarify the architecture of my system? 
>>
>> Jochen 
>>
>> -- 
>> The only problem with troubleshooting is that the trouble shoots back. 
>>
>-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] LDAP replication conflicts, but no apparent data damage

[Martin Basti]

Then you have to update cn=ipaservers entry with correct values and 
remove the others



On 04.01.2017 14:27, dan.finkelst...@high5games.com wrote:


Yes, along with two name-conflicted "duplicates":

id:image001.jpg@01D1C26F.0E28FA60 

*Daniel Alex Finkelstein*| Lead Dev Ops Engineer

_dan.finkelst...@h5g.com _| 212.604.3447

One World Trade Center, New York, NY 10007

www.high5games.com 

Play High 5 Casino  and 
Shake the Sky 


Follow us on: Facebook , Twitter 
, YouTube 
, Linkedin 



//

/This message and any attachments may contain confidential or 
privileged information and are only for the use of the intended 
recipient of this message. If you are not the intended recipient, 
please notify the sender by return email, and delete or destroy this 
and all copies of this message and all attachments. Any unauthorized 
disclosure, use, distribution, or reproduction of this message or any 
attachments is prohibited and may be unlawful./


*From: *Martin Basti 
*Date: *Wednesday, January 4, 2017 at 06:28
*To: *Dan Finkelstein , 
"freeipa-users@redhat.com" 
*Subject: *Re: [Freeipa-users] LDAP replication conflicts, but no 
apparent data damage


Probably entries already exists

for example foripaserversdo you have following entry 
cn=ipaservers,cn=hostgroups,cn=accounts,dc=test,dc=local  on the replica?


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

Re: [Freeipa-users] LDAP replication conflicts, but no apparent data damage

[Dan.Finkelstein]

Yes, along with two name-conflicted "duplicates":

[cid:image001.png@01D26664.649DC670]


[id:image001.jpg@01D1C26F.0E28FA60]
Daniel Alex Finkelstein| Lead Dev Ops Engineer
dan.finkelst...@h5g.com | 212.604.3447
One World Trade Center, New York, NY 10007

www.high5games.com
Play High 5 Casino and Shake the 
Sky
Follow us on: Facebook, 
Twitter, 
YouTube, 
Linkedin

This message and any attachments may contain confidential or privileged 
information and are only for the use of the intended recipient of this message. 
If you are not the intended recipient, please notify the sender by return 
email, and delete or destroy this and all copies of this message and all 
attachments. Any unauthorized disclosure, use, distribution, or reproduction of 
this message or any attachments is prohibited and may be unlawful.

From: Martin Basti 
Date: Wednesday, January 4, 2017 at 06:28
To: Dan Finkelstein , 
"freeipa-users@redhat.com" 
Subject: Re: [Freeipa-users] LDAP replication conflicts, but no apparent data 
damage


Probably entries already exists
for example for ipaservers do you have following entry 
cn=ipaservers,cn=hostgroups,cn=accounts,dc=test,dc=local  on the replica?

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

Re: [Freeipa-users] Replica issue / Certificate Authority

[Christophe TREFOIS]

Hi Florence,

I did what you said, and then the status went to CA_WORKING. Then I restart ipa 
and certmonger and the status went to CA_UNREACHABLE.
Then i did “resubmit” again and now the status is back to MONITORING, but the 
cookie error is back.

Any advice?

[root@lums3 ~]# getcert list -n ipaCert
Number of certificates and requests being tracked: 8.
Request ID '20161216025136':
status: MONITORING
ca-error: Invalid cookie: ''
stuck: no
key pair storage: 
type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS 
Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt'
certificate: 
type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS 
Certificate DB'
CA: dogtag-ipa-ca-renew-agent
issuer: CN=Certificate Authority,O=UNI.LU
subject: CN=IPA RA,O=UNI.LU
expires: 2018-12-16 03:13:48 UTC
key usage: 
digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
eku: id-kp-serverAuth,id-kp-clientAuth
pre-save command: /usr/libexec/ipa/certmonger/renew_ra_cert_pre
post-save command: /usr/libexec/ipa/certmonger/renew_ra_cert
track: yes
auto-renew: yes

-- 

Dr Christophe Trefois, Dipl.-Ing.  
Technical Specialist / Post-Doc

UNIVERSITÉ DU LUXEMBOURG

LUXEMBOURG CENTRE FOR SYSTEMS BIOMEDICINE
Campus Belval | House of Biomedicine  
6, avenue du Swing 
L-4367 Belvaux  
T: +352 46 66 44 6124 
F: +352 46 66 44 6949  
http://www.uni.lu/lcsb 
       
   
   

This message is confidential and may contain privileged information. 
It is intended for the named recipient only. 
If you receive it in error please notify me and permanently delete the original 
message and any copies. 


  

> On 4 Jan 2017, at 13:49, Florence Blanc-Renaud  wrote:
> 
> getcert resubmit -i 



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

Re: [Freeipa-users] Replica issue / Certificate Authority

[Christophe TREFOIS]

Hi Flo,

The id needed to execute that command would come from where exactly? Is it the 
one from getcert list -n ipaCert?

Thanks
Christophe 

Sent from my iPhone

> On 4 Jan 2017, at 13:49, Florence Blanc-Renaud  wrote:
> 
>> On 01/04/2017 12:41 PM, Christophe TREFOIS wrote:
>> Hi Fraser,
>> 
>> We encountered the same issue. We exported the certificate from a "good"
>> replica, using certutil.
>> We then used certutil -A -n ipaCert -d /etc/httpd/alias/ -i
>> /opt/sysadmin/cacert.crt -a -t CT,C on the bad server and then restarted
>> ipa, and certmonger.
>> 
>> Now, the certificate is correct both using the certutil command and the
>> getcert list -n ipaCert command.
>> 
>> However, we see an "ca-error: Invalid cookie: ''  "  in the output of
>> getcert list -n ipaCert.
>> 
> Hi Christophe,
> 
> is this error displayed on the renewal master? If not, you can run
> $ getcert resubmit -i 
> and the error should go away. On non-renewal master, resubmit downloads the 
> certificate from LDAP (it does not ask for renewal), meaning that this 
> operation cannot be harmful.
> 
> To know which server is the renewal master:
> $ ldapsearch -h localhost -p 389 -D 'cn=Directory Manager' -w password -b 
> "cn=masters,cn=ipa,cn=etc,$BASEDN" 
> '(&(cn=CA)(ipaConfigString=caRenewalMaster))' dn
> dn: cn=CA,cn=server.example.com,cn=masters,cn=ipa,cn=etc,$BASEDN
> 
> => the renewal master is server.example.com
> 
> HTH,
> Flo
> 
>> Did we import the certificate correctly and should we worry about this
>> ca-error?
>> It seems replication is going fine, and also ipa-server-upgrade completes
>> successfully when run manually (whereas it failed previously from the same
>> error as in this thread)
>> 
>> Thanks for any pointers on how to clean the issue up properly,
>> Kind regards,
>> 
>> Christophe
>> 
>>> -Original Message-
>>> From: freeipa-users-boun...@redhat.com [mailto:freeipa-users-
>>> boun...@redhat.com] On Behalf Of Fraser Tweedale
>>> Sent: lundi 19 décembre 2016 00:11
>>> To: Christopher Young 
>>> Cc: freeipa-users@redhat.com
>>> Subject: Re: [Freeipa-users] Replica issue / Certificate Authority
>>> 
 On Fri, Dec 16, 2016 at 05:29:18PM -0500, Rob Crittenden wrote:
 Christopher Young wrote:
> Ok.  I think I have a 'hint' here, but I could use some help getting
>> this fixed.
> 
> Comparing the two IPA servers, I found the following (modified SOME
> of the output myself):
 
 You're right about the ipaCert. I'd export the renewed cert from your
 working server using the same certutil command, just direct it to a
 file instead. Then import it into the non-working server and restart
 the httpd service. That should do it.
 
>>> I agree that this should fix it.
>>> 
>>> You could also try running `ipa-certupdate' as root, if the correct
>> certificate is
>>> to be found in cn=certificates,cn=ipa,cn=etc,{basedn}
>>> 
>>> Once everything is working again, you should check:
>>> 
>>> 1. renewal master configuration is correct
>>> 
>>> 2. certmonger tracking requests for the IPA RA cert are correct on
>>>   both servers
>>> 
>>> 3. the correct certificate is in
>>>   cn=certificates,cn=ipa,cn=etc,{basedn}
>>> 
>>> Thanks,
>>> Fraser
>>> 
 Or you can try restarting certmonger on the non-working server to see
 if
 
 that triggers it to pull in the updated cert. Theoretically this
 should do it as well but given potential past replication problems it
 is possible the entry doesn't exist.
 
 getcert list -n ipaCert on each will show some basic information. The
 important thing is to see if there is some root cause that will make
 this blow up again at renewal time.
 
 rob
 
> 
> on 'ipa02' (the 'good' one):
> -
> ipa cert-show 1
>  Issuing CA: ipa
>  Certificate: <<>>
>  Subject: CN=Certificate Authority,O=.LOCAL
>  Issuer: CN=Certificate Authority,O=.LOCAL
>  Not Before: Thu Jan 01 06:23:38 2015 UTC
>  Not After: Mon Jan 01 06:23:38 2035 UTC
>  Fingerprint (MD5): a6:aa:88:d4:66:e2:70:c1:e3:8c:37:0b:f3:eb:19:7d
>  Fingerprint (SHA1):
> 11:c2:5a:58:bc:77:55:37:39:9b:13:b1:1a:a2:02:50:be:2e:a0:7f
>  Serial number: 1
>  Serial number (hex): 0x1
>  Revoked: False
> --
> 
> 
> on 'ipa01'
> -
> ipa cert-show 1
> ipa: ERROR: Certificate operation cannot be completed: EXCEPTION
> (Invalid Credential.)
> -
> 
> Thinking about this, I decided to just start checking for
> inconsistencies and I noticed the following:
> 
> ipa02:
> ---
> [root@ipa02 ~]# certutil -L -d /etc/httpd/alias/ -n ipaCert -a |
> openssl x509 -text  | head
> Certificate:
>Data:
>Version: 3 (0x2)
>Serial Number: 268304413 (0xffe001d)
>Signature Algorithm: sha256WithRSAEncryption
>Issuer: O=x.LOCAL, 

Re: [Freeipa-users] Broken dirsrv and SSL certificate in CA-less install of FreeIPA 4.4 on CentOS 7.3

[Martin Basti]

On 30.12.2016 11:54, Martin Basti wrote:


Hello,

The first half of the first issue is this bug: 
https://fedorahosted.org/freeipa/ticket/6226


you have to enable SSL on server manually after installation


The second half of the first issue shouldn't be related to ticket 
above, but I don't know more details I'll leave this for IPA CA gurus



The second issue is unrelated to certificates, I believe that 
something in dirsrv causes this unusual behavior. I saw this before 
with other users.


* both no such entry for HTTP principal, or for topology plugin are 
the same issue


* all users have this issue with CA-less installation, but not always 
reproducible, I'm not sure if there can be a step in CA-less install 
that can cause this


* entries are in database (were added previously by installer) but 
during installation the search failed with no such entry, ldapsearch 
after installation works


* in access log SRCH is before ADD operation, but this is against the 
steps in installer, entry is added first and even installer failed 
hard so there is no way how to add it after failure caused by not 
found error.


[29/Dec/2016:10:33:02.775715491 +] conn=16 op=1 SRCH 
base="krbprincipalname=HTTP/ipa01.pakos...@pakos.uk,cn=services,cn=accounts,dc=pakos,dc=uk"
  scope=0 filter="(objectClass=*)" attrs=ALL
[29/Dec/2016:10:33:02.775892719 +] conn=16 op=1 RESULT err=32 tag=101 
nentries=0 etime=0
This caused installation failure (IMO - there is no more SRCH operation for 
HTTP principal in log) ^^
..
[29/Dec/2016:10:33:05.487917960 +] conn=17 op=10 ADD 
dn="krbprincipalname=HTTP/ipa01.pakos...@pakos.uk,cn=services,cn=accounts,dc=pakos,dc=uk"
[29/Dec/2016:10:33:05.492213776 +] conn=17 op=10 RESULT err=0 tag=105 
nentries=0 etime=0 csn=5864e6530004
[29/Dec/2016:10:33:05.492372184 +] conn=17 op=11 MOD 
dn="krbprincipalname=HTTP/ipa01.pakos...@pakos.uk,cn=services,cn=accounts,dc=pakos,dc=uk"
[29/Dec/2016:10:33:05.494649080 +] conn=17 op=11 RESULT err=0 tag=103 
nentries=0 etime=0 csn=5864e65300010004
[29/Dec/2016:10:33:05.494816357 +] conn=17 op=12 MOD 
dn="krbprincipalname=HTTP/ipa01.pakos...@pakos.uk,cn=services,cn=accounts,dc=pakos,dc=uk"
These were added after failure ??? ^

I need a DS guru assistance to resolve this :)
Martin^2
Ticket for this issue has been opened 
https://fedorahosted.org/freeipa/ticket/6575 Martin^2

On 29.12.2016 19:13, Peter Pakos wrote:

Access log: https://files.pakos.uk/access.txt
Error log: https://files.pakos.uk/ipareplica-install.log.txt
I hope it helps.
On 29 December 2016 at 12:52, Peter Pakos > wrote:


Hi guys,
I'm facing yet another problem with CA-less install of FreeIPA
replica and 3rd party SSL certificate.
Few days ago I deployed a new CA-less server (ipa02) by running
the following command:

ipa-server-install \   -r PAKOS.UK  \   -n
pakos.uk  \   -p 'password' \   -a
'password' \   --mkhomedir \   --setup-dns \  
--no-forwarders \   --no-dnssec-validation \  
--dirsrv-cert-file=/root/ssl/star.pakos.uk.pfx \  
--dirsrv-pin='' \  
--http-cert-file=/root/ssl/star.pakos.uk.pfx \  
--http-pin='' \   --http-cert-name=AlphaWildcardIPA \  
--idstart=1000


This server appears to be working OK.
Then yesterday I deployed a client (ipa01):

ipa-client-install \   -p admin \   -w 'password' \   --mkhomedir

Next, I promoted it to IPA server:

ipa-replica-install \   -w 'password' \   --mkhomedir \  
--setup-dns \   --no-forwarders \   --no-dnssec-validation \
  --dirsrv-cert-file=/root/ssl/star.pakos.uk.pfx \  
--dirsrv-pin='' \   --dirsrv-cert-name=AlphaWildcardIPA \  
--http-cert-file=/root/ssl/star.pakos.uk.pfx \  
--http-pin='' \   --http-cert-name=AlphaWildcardIPA


After it finished, I've noticed that dirsrv wasn't running on
port 636 on ipa01.
Further investigation revealed that the SSL wildcard certificate
(AlphaWildcardIPA) wasn't installed in dirsrv DB and CA
certificates were named oddly (CA 1 and CA 2):

[root@ipa01 ~]# certutil -L -d /etc/httpd/alias/ Certificate
Nickname Trust Attributes SSL,S/MIME,JAR/XPI AlphaWildcardIPA
u,u,u CA 1 ,, CA 2 C,, [root@ipa01 ~]# certutil -L -d
/etc/dirsrv/slapd-PAKOS-UK/ Certificate Nickname Trust Attributes
SSL,S/MIME,JAR/XPI GlobalSign Root CA - GlobalSign nv-sa ,,
AlphaSSL CA - SHA256 - G2 - GlobalSign nv-sa C,,

This is what I found in the error log:

[29/Dec/2016:01:43:58.852745536 +] 389-Directory/1.3.5.10
 B2016.341. starting up
[29/Dec/2016:01:43:58.867642515 +] default_mr_indexer_create:
warning - plugin [caseIgnoreIA5Match] does not handle
caseExactIA5Match [29/Dec/2016:01:43:58.889866051 +]
schema-compat-plugin - scheduled 

Re: [Freeipa-users] Replica issue / Certificate Authority

[Florence Blanc-Renaud]

On 01/04/2017 12:41 PM, Christophe TREFOIS wrote:

Hi Fraser,

We encountered the same issue. We exported the certificate from a "good"
replica, using certutil.
We then used certutil -A -n ipaCert -d /etc/httpd/alias/ -i
/opt/sysadmin/cacert.crt -a -t CT,C on the bad server and then restarted
ipa, and certmonger.

Now, the certificate is correct both using the certutil command and the
getcert list -n ipaCert command.

However, we see an "ca-error: Invalid cookie: ''  "  in the output of
getcert list -n ipaCert.


Hi Christophe,

is this error displayed on the renewal master? If not, you can run
$ getcert resubmit -i 
and the error should go away. On non-renewal master, resubmit downloads 
the certificate from LDAP (it does not ask for renewal), meaning that 
this operation cannot be harmful.


To know which server is the renewal master:
$ ldapsearch -h localhost -p 389 -D 'cn=Directory Manager' -w password 
-b "cn=masters,cn=ipa,cn=etc,$BASEDN" 
'(&(cn=CA)(ipaConfigString=caRenewalMaster))' dn

dn: cn=CA,cn=server.example.com,cn=masters,cn=ipa,cn=etc,$BASEDN

=> the renewal master is server.example.com

HTH,
Flo


Did we import the certificate correctly and should we worry about this
ca-error?
It seems replication is going fine, and also ipa-server-upgrade completes
successfully when run manually (whereas it failed previously from the same
error as in this thread)

Thanks for any pointers on how to clean the issue up properly,
Kind regards,

Christophe


-Original Message-
From: freeipa-users-boun...@redhat.com [mailto:freeipa-users-
boun...@redhat.com] On Behalf Of Fraser Tweedale
Sent: lundi 19 décembre 2016 00:11
To: Christopher Young 
Cc: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] Replica issue / Certificate Authority

On Fri, Dec 16, 2016 at 05:29:18PM -0500, Rob Crittenden wrote:

Christopher Young wrote:

Ok.  I think I have a 'hint' here, but I could use some help getting

this fixed.


Comparing the two IPA servers, I found the following (modified SOME
of the output myself):


You're right about the ipaCert. I'd export the renewed cert from your
working server using the same certutil command, just direct it to a
file instead. Then import it into the non-working server and restart
the httpd service. That should do it.


I agree that this should fix it.

You could also try running `ipa-certupdate' as root, if the correct

certificate is

to be found in cn=certificates,cn=ipa,cn=etc,{basedn}

Once everything is working again, you should check:

1. renewal master configuration is correct

2. certmonger tracking requests for the IPA RA cert are correct on
   both servers

3. the correct certificate is in
   cn=certificates,cn=ipa,cn=etc,{basedn}

Thanks,
Fraser


Or you can try restarting certmonger on the non-working server to see
if

that triggers it to pull in the updated cert. Theoretically this
should do it as well but given potential past replication problems it
is possible the entry doesn't exist.

getcert list -n ipaCert on each will show some basic information. The
important thing is to see if there is some root cause that will make
this blow up again at renewal time.

rob



on 'ipa02' (the 'good' one):
-
ipa cert-show 1
  Issuing CA: ipa
  Certificate: <<>>
  Subject: CN=Certificate Authority,O=.LOCAL
  Issuer: CN=Certificate Authority,O=.LOCAL
  Not Before: Thu Jan 01 06:23:38 2015 UTC
  Not After: Mon Jan 01 06:23:38 2035 UTC
  Fingerprint (MD5): a6:aa:88:d4:66:e2:70:c1:e3:8c:37:0b:f3:eb:19:7d
  Fingerprint (SHA1):
11:c2:5a:58:bc:77:55:37:39:9b:13:b1:1a:a2:02:50:be:2e:a0:7f
  Serial number: 1
  Serial number (hex): 0x1
  Revoked: False
--


on 'ipa01'
-
ipa cert-show 1
ipa: ERROR: Certificate operation cannot be completed: EXCEPTION
(Invalid Credential.)
-

Thinking about this, I decided to just start checking for
inconsistencies and I noticed the following:

ipa02:
---
[root@ipa02 ~]# certutil -L -d /etc/httpd/alias/ -n ipaCert -a |
openssl x509 -text  | head
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 268304413 (0xffe001d)
Signature Algorithm: sha256WithRSAEncryption
Issuer: O=x.LOCAL, CN=Certificate Authority
Validity
Not Before: Nov 23 18:19:31 2016 GMT
Not After : Nov 13 18:19:31 2018 GMT
Subject: O=x.LOCAL, CN=IPA RA

--
ipa01:
--
[root@ipa01 tmp]# certutil -L -d /etc/httpd/alias/ -n ipaCert -a |
openssl x509 -text  | head
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 7 (0x7)
Signature Algorithm: sha256WithRSAEncryption
Issuer: O=.LOCAL, CN=Certificate Authority
Validity
Not Before: Jan  1 06:24:23 2015 GMT
Not After : Dec 21 06:24:23 2016 GMT
Subject: O=.LOCAL, CN=IPA RA

--

So, it looks like somewhere in the process, the certificate got
renewed but not updated on 'ipa01'?  I apologize as I'm trying to
understand 

Re: [Freeipa-users] Manually configuring Freeipa bind configs to host secondary zones

[Tomas Krizek]

On 01/04/2017 10:28 AM, James Harrison wrote:
> Hi All,
> I realise Free IPA doesn't yet support secondary zones in the web
> interface or command line tools (I might be wrong :) ) When I talk
> about secondary zones I mean a zone replicated from Windows DNS masters.
>
> Can the Free IPA bind configs be manually altered to host secondary
> zones. Is it supported or will they just be over-written by Freeipa?
>
> I've been hunting for an answer online, but found nothing about this.
>
> Many thanks,
> James Harrison
>
>
Hi,

you can configure the secondary zone in named.conf and it should not be
over-written. IPA creates named.conf during installation and then only
changes the relevant IPA parts, for example during an upgrade.

Manual changes to the bind-dyndb-ldap section (dynamic-db / dyndb) may
break our custom parsing. However, since you want to only add a
secondary zone in the main section, you should be fine.

-- 
Tomas Krizek

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

Re: [Freeipa-users] ipa replica installation help

[Ben .T.George]

HI

port 8009 is not listening in master server

and i added ::1 localhost localhost.localdomain localhost6
localhost6.localdomain6 in hosts file.

still getting same error

 [28/44]: restarting directory server
ipa : CRITICAL Failed to restart the directory server (Command
'/bin/systemctl restart dirsrv@KW-EXAMPLE-COM.service' returned non-zero
exit status 1). See the installation log for details.
  [29/44]: setting up initial replication
  [error] error: [Errno 111] Connection refused
Your system may be partly configured.
Run /usr/sbin/ipa-server-install --uninstall to clean up.

ipa.ipapython.install.cli.install_tool(Replica): ERROR[Errno 111]
Connection refused
ipa.ipapython.install.cli.install_tool(Replica): ERRORThe
ipa-replica-install command failed. See /var/log/ipareplica-install.log for
more information


Also  ipv6 is disabled on both nodes

Regards,
Ben

On Wed, Jan 4, 2017 at 2:05 PM, Petr Vobornik  wrote:

> On 01/04/2017 10:59 AM, Ben .T.George wrote:
> > HI
> >
> > i tried the method mentioned on that document and it end up with below
> error. My
> > DNS is managed by external box and i dont want to create any DNS record
> on these
> > servers.
> >
> > and the command which i tried is(non client server)
> >
> > ipa-replica-install --principal admin --admin-password P@ssw0rd --domain
> > kw.example.com  --server
> zkwipamstr01.kw.example.com
> > 
> >
> >
> >
> > ipa : CRITICAL Failed to restart the directory server (Command
> > '/bin/systemctl restart dirsrv@KW-EXAMPLE-COM.service' returned
> non-zero exit
> > status 1). See the installation log for details.
> >[29/44]: setting up initial replication
> >[error] error: [Errno 111] Connection refused
> > Your system may be partly configured.
> > Run /usr/sbin/ipa-server-install --uninstall to clean up.
> >
> > ipa.ipapython.install.cli.install_tool(Replica): ERROR[Errno 111]
> Connection
> > refused
> > ipa.ipapython.install.cli.install_tool(Replica): ERRORThe
> > ipa-replica-install command failed. See /var/log/ipareplica-install.log
> for more
> > information
>
> This looks like bug https://fedorahosted.org/freeipa/ticket/6575
>
> To verify that, could you check if master server internally listens on
> port 8009 or if ipareplica-install.log contains CA_UNREACHABLE string
> near  step 27.
>
> Usual fix is to add following line to /etc/hosts
>   ::1 localhost localhost.localdomain localhost6
> localhost6.localdomain6
>
>
> > [root@zkwiparepa01 ~]# /bin/systemctl restart
> dirsrv@KW-EXAMPLE-COM.service
> > Job for dirsrv@KW-EXAMPLE-COM.service failed because the control
> process exited
> > with error code. See "systemctl status dirsrv@KW-EXAMPLE-COM.service"
> and
> > "journalctl -xe" for details.
> >
> > [root@zkwiparepa01 ~]# systemctl status dirsrv@KW-EXAMPLE-COM.service
> > ● dirsrv@KW-EXAMPLE-COM.service - 389 Directory Server KW-EXAMPLE-COM.
> > Loaded: loaded (/usr/lib/systemd/system/dirsrv@.service; enabled;
> vendor
> > preset: disabled)
> > Active: failed (Result: exit-code) since Wed 2017-01-04 12:54:46
> AST; 13s ago
> >Process: 14893 ExecStart=/usr/sbin/ns-slapd -D /etc/dirsrv/slapd-%i -i
> > /var/run/dirsrv/slapd-%i.pid (code=exited, status=1/FAILURE)
> >Process: 14887 ExecStartPre=/usr/sbin/ds_systemd_ask_password_acl
> > /etc/dirsrv/slapd-%i/dse.ldif (code=exited, status=0/SUCCESS)
> >   Main PID: 14893 (code=exited, status=1/FAILURE)
> >
> > Jan 04 12:54:46 zkwiparepa01.kw.example.com  example.com>
> > ns-slapd[14893]: [04/Jan/2017:12:54:46.177617891 +0300] Error:
> > betxnpostoperation plu...arted
> > Jan 04 12:54:46 zkwiparepa01.kw.example.com  example.com>
> > ns-slapd[14893]: [04/Jan/2017:12:54:46.178379752 +0300] Error: object
> plugin
> > Roles Pl...arted
> > Jan 04 12:54:46 zkwiparepa01.kw.example.com  example.com>
> > ns-slapd[14893]: [04/Jan/2017:12:54:46.179162340 +0300] Error:
> preoperation
> > plugin su...arted
> > Jan 04 12:54:46 zkwiparepa01.kw.example.com  example.com>
> > ns-slapd[14893]: [04/Jan/2017:12:54:46.179993432 +0300] Error: object
> plugin USN
> > is n...arted
> > Jan 04 12:54:46 zkwiparepa01.kw.example.com  example.com>
> > ns-slapd[14893]: [04/Jan/2017:12:54:46.181305209 +0300] Error: object
> plugin
> > Views is...arted
> > Jan 04 12:54:46 zkwiparepa01.kw.example.com  example.com>
> > ns-slapd[14893]: [04/Jan/2017:12:54:46.182094981 +0300] Error:
> extendedop plugin
> > whoa...arted
> > Jan 04 12:54:46 zkwiparepa01.kw.example.com  example.com>
> > systemd[1]: dirsrv@KW-EXAMPLE-COM.service: main process exited,
> code=exited,
> > status=1/FAILURE
> > Jan 04 12:54:46 zkwiparepa01.kw.example.com  example.com>
> > systemd[1]: Failed to start 389 

Re: [Freeipa-users] Debian: libpam-sss pam-configs update?

[Sumit Bose]

On Wed, Jan 04, 2017 at 10:39:37AM +0100, Jochen Hein wrote:
> 
> Hi,
> 
> I'm still working on my Debian systems to get local login to work with
> OTP.
> 
> In /etc/pam.d/common-auth we have:
> auth[success=2 default=ignore]  pam_unix.so nullok_secure
> auth[success=1 default=ignore]  pam_sss.so use_first_pass
> 
> On CentOS we have something more complicated in /etc/pam.d/system-auth:
> 
> auth[default=1 success=ok] pam_localuser.so
> auth[success=done ignore=ignore default=die] pam_unix.so nullok 
> try_first_pass
> authrequisite pam_succeed_if.so uid >= 1000 quiet_success
> authsufficientpam_sss.so forward_pass
> 
> I think we need something more elaborated for debian to replicate the
> (good!) experience from CentOS when asking for "First/Second Factor".
> The four lines from above work well, but how can we get that into
> pam-auth-update? Any ideas how this could be packaged?

The 

auth[default=1 success=ok] pam_localuser.so

line was added in CentOS/RHEL to make sure that the PAM conversation is
run by pam_sss for users managed by SSSD and not by pam_unix because
pam_unix can only ask for a password. It would have been possible to
call pam_sss first but it was considered safer to have pam_unix first to
make sure root login will always handled by pam_unix.

It has to be noted that pam_sss currently is a bit special when a
modules called earlier, e.g. pam_unix, put a password on the PAM stack.
Only if use_first_pass is used pam_sss will use the password on the
stack but also will never prompt on its own. If use_first_pass is not
used pam_sss will always prompt on its own and never check if there is
already a password in the stack. This behaviour was there since the very
first versions of pam_sss because we didn't wanted to copy the
try_first_pass behaviour of other PAM modules because this try-and-error
scheme might easily wrong password counters and lock accounts. So we
assumed that pam_sss is either the first module or will get the password
from other modules. This is why there is the 'default=die' option in the
pam_unix line for CentOS. But it turns out that there are valid use
cases where pam_sss should handle the prompting for SSSD users but
should accept a password on the PAM stack as well.

We plan to fix this with https://fedorahosted.org/sssd/ticket/2984 so
that pam_sss will check for a password on the PAM stack even if
use_first_pass is not set. But if there is one pam_sss will only use
this and will not prompt for other credentials is password
authentication fails. So the pam_localuser line will still be needed to
make sure users handled by SSSD will be prompted by pam_sss exclusively.

HTH

bye,
Sumit

> 
> Jochen
> 
> -- 
> The only problem with troubleshooting is that the trouble shoots back.
> 
> -- 
> Manage your subscription for the Freeipa-users mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-users
> Go to http://freeipa.org for more info on the project

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

Re: [Freeipa-users] Replica issue / Certificate Authority

[Christophe TREFOIS]

Hi Fraser,

We encountered the same issue. We exported the certificate from a "good"
replica, using certutil.
We then used certutil -A -n ipaCert -d /etc/httpd/alias/ -i
/opt/sysadmin/cacert.crt -a -t CT,C on the bad server and then restarted
ipa, and certmonger.

Now, the certificate is correct both using the certutil command and the
getcert list -n ipaCert command.

However, we see an "ca-error: Invalid cookie: ''  "  in the output of
getcert list -n ipaCert.

Did we import the certificate correctly and should we worry about this
ca-error?
It seems replication is going fine, and also ipa-server-upgrade completes
successfully when run manually (whereas it failed previously from the same
error as in this thread)

Thanks for any pointers on how to clean the issue up properly,
Kind regards,

Christophe

> -Original Message-
> From: freeipa-users-boun...@redhat.com [mailto:freeipa-users-
> boun...@redhat.com] On Behalf Of Fraser Tweedale
> Sent: lundi 19 décembre 2016 00:11
> To: Christopher Young 
> Cc: freeipa-users@redhat.com
> Subject: Re: [Freeipa-users] Replica issue / Certificate Authority
> 
> On Fri, Dec 16, 2016 at 05:29:18PM -0500, Rob Crittenden wrote:
> > Christopher Young wrote:
> > > Ok.  I think I have a 'hint' here, but I could use some help getting
this fixed.
> > >
> > > Comparing the two IPA servers, I found the following (modified SOME
> > > of the output myself):
> >
> > You're right about the ipaCert. I'd export the renewed cert from your
> > working server using the same certutil command, just direct it to a
> > file instead. Then import it into the non-working server and restart
> > the httpd service. That should do it.
> >
> I agree that this should fix it.
> 
> You could also try running `ipa-certupdate' as root, if the correct
certificate is
> to be found in cn=certificates,cn=ipa,cn=etc,{basedn}
> 
> Once everything is working again, you should check:
> 
> 1. renewal master configuration is correct
> 
> 2. certmonger tracking requests for the IPA RA cert are correct on
>both servers
> 
> 3. the correct certificate is in
>cn=certificates,cn=ipa,cn=etc,{basedn}
> 
> Thanks,
> Fraser
> 
> > Or you can try restarting certmonger on the non-working server to see
> > if
> >
> > that triggers it to pull in the updated cert. Theoretically this
> > should do it as well but given potential past replication problems it
> > is possible the entry doesn't exist.
> >
> > getcert list -n ipaCert on each will show some basic information. The
> > important thing is to see if there is some root cause that will make
> > this blow up again at renewal time.
> >
> > rob
> >
> > >
> > > on 'ipa02' (the 'good' one):
> > > -
> > > ipa cert-show 1
> > >   Issuing CA: ipa
> > >   Certificate: <<>>
> > >   Subject: CN=Certificate Authority,O=.LOCAL
> > >   Issuer: CN=Certificate Authority,O=.LOCAL
> > >   Not Before: Thu Jan 01 06:23:38 2015 UTC
> > >   Not After: Mon Jan 01 06:23:38 2035 UTC
> > >   Fingerprint (MD5): a6:aa:88:d4:66:e2:70:c1:e3:8c:37:0b:f3:eb:19:7d
> > >   Fingerprint (SHA1):
> > > 11:c2:5a:58:bc:77:55:37:39:9b:13:b1:1a:a2:02:50:be:2e:a0:7f
> > >   Serial number: 1
> > >   Serial number (hex): 0x1
> > >   Revoked: False
> > > --
> > >
> > >
> > > on 'ipa01'
> > > -
> > > ipa cert-show 1
> > > ipa: ERROR: Certificate operation cannot be completed: EXCEPTION
> > > (Invalid Credential.)
> > > -
> > >
> > > Thinking about this, I decided to just start checking for
> > > inconsistencies and I noticed the following:
> > >
> > > ipa02:
> > > ---
> > > [root@ipa02 ~]# certutil -L -d /etc/httpd/alias/ -n ipaCert -a |
> > > openssl x509 -text  | head
> > > Certificate:
> > > Data:
> > > Version: 3 (0x2)
> > > Serial Number: 268304413 (0xffe001d)
> > > Signature Algorithm: sha256WithRSAEncryption
> > > Issuer: O=x.LOCAL, CN=Certificate Authority
> > > Validity
> > > Not Before: Nov 23 18:19:31 2016 GMT
> > > Not After : Nov 13 18:19:31 2018 GMT
> > > Subject: O=x.LOCAL, CN=IPA RA
> > >
> > > --
> > > ipa01:
> > > --
> > > [root@ipa01 tmp]# certutil -L -d /etc/httpd/alias/ -n ipaCert -a |
> > > openssl x509 -text  | head
> > > Certificate:
> > > Data:
> > > Version: 3 (0x2)
> > > Serial Number: 7 (0x7)
> > > Signature Algorithm: sha256WithRSAEncryption
> > > Issuer: O=.LOCAL, CN=Certificate Authority
> > > Validity
> > > Not Before: Jan  1 06:24:23 2015 GMT
> > > Not After : Dec 21 06:24:23 2016 GMT
> > > Subject: O=.LOCAL, CN=IPA RA
> > >
> > > --
> > >
> > > So, it looks like somewhere in the process, the certificate got
> > > renewed but not updated on 'ipa01'?  I apologize as I'm trying to
> > > understand this.  I believe that my end goal is probably still the
> > > same (verify replication and get things working properly on the
> > > 'ipa01' 

[Freeipa-users] replication failing

[tarak sinha]

Hi All,

I have repliation issue on my Freeipa server and getting below error.
Please give me any advised to fix this issue.

NSMMReplicationPlugin - process_postop: Failed to apply update
(53103a520001006b) error (-1).  Aborting replication session(conn=1315
op=6)
[04/Jan/2017:03:03:09 -0800] NSMMReplicationPlugin - process_postop: Failed
to apply update (52f86af900010054) error (-1).  Aborting replication
session(conn=1320 op=6)
^C

>From Second host:-

NSMMReplicationPlugin - agmt="cn=meToauth2.qai.expertcity.com" (auth2:389):
Failed to send update operation to consumer (uniqueid
1f601f35-1ac811e1-9fdabec4-908cc93a, CSN 5313ea1900020054): Can't
contact LDAP server. Will retry later.
[04/Jan/2017:03:04:49 -0800] NSMMReplicationPlugin - agmt="cn=
meToauth2.qai.expertcity.com" (auth2:389): Consumer failed to replay change
(uniqueid a4463b24-1abe11e1-9fdabec4-908cc93a, CSN 52faf89d00020054):
Can't contact LDAP server(-1). Will retry later.
[04/Jan/2017:03:04:49 -0800] NSMMReplicationPlugin - agmt="cn=
meToauth2.qai.expertcity.com" (auth2:389): Warning: unable to send
endReplication extended operation (Can't contact LDAP server)
[04/Jan/2017:03:04:50 -0800] NSMMReplicationPlugin - process_postop: Failed
to apply update (52f14cde006b) error (-1).  Aborting replication
session(conn=1772 op=6)


-- 

*Thanks,*

*Tarak Nath Sinha*

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

Re: [Freeipa-users] ipa replica installation help

[Petr Vobornik]

On 01/04/2017 10:59 AM, Ben .T.George wrote:
> HI
> 
> i tried the method mentioned on that document and it end up with below error. 
> My 
> DNS is managed by external box and i dont want to create any DNS record on 
> these 
> servers.
> 
> and the command which i tried is(non client server)
> 
> ipa-replica-install --principal admin --admin-password P@ssw0rd --domain 
> kw.example.com  --server zkwipamstr01.kw.example.com 
> 
> 
> 
> 
> ipa : CRITICAL Failed to restart the directory server (Command 
> '/bin/systemctl restart dirsrv@KW-EXAMPLE-COM.service' returned non-zero exit 
> status 1). See the installation log for details.
>[29/44]: setting up initial replication
>[error] error: [Errno 111] Connection refused
> Your system may be partly configured.
> Run /usr/sbin/ipa-server-install --uninstall to clean up.
> 
> ipa.ipapython.install.cli.install_tool(Replica): ERROR[Errno 111] 
> Connection 
> refused
> ipa.ipapython.install.cli.install_tool(Replica): ERRORThe 
> ipa-replica-install command failed. See /var/log/ipareplica-install.log for 
> more 
> information

This looks like bug https://fedorahosted.org/freeipa/ticket/6575

To verify that, could you check if master server internally listens on
port 8009 or if ipareplica-install.log contains CA_UNREACHABLE string
near  step 27.

Usual fix is to add following line to /etc/hosts
  ::1 localhost localhost.localdomain localhost6
localhost6.localdomain6


> [root@zkwiparepa01 ~]# /bin/systemctl restart dirsrv@KW-EXAMPLE-COM.service
> Job for dirsrv@KW-EXAMPLE-COM.service failed because the control process 
> exited 
> with error code. See "systemctl status dirsrv@KW-EXAMPLE-COM.service" and 
> "journalctl -xe" for details.
> 
> [root@zkwiparepa01 ~]# systemctl status dirsrv@KW-EXAMPLE-COM.service
> ● dirsrv@KW-EXAMPLE-COM.service - 389 Directory Server KW-EXAMPLE-COM.
> Loaded: loaded (/usr/lib/systemd/system/dirsrv@.service; enabled; vendor 
> preset: disabled)
> Active: failed (Result: exit-code) since Wed 2017-01-04 12:54:46 AST; 13s 
> ago
>Process: 14893 ExecStart=/usr/sbin/ns-slapd -D /etc/dirsrv/slapd-%i -i 
> /var/run/dirsrv/slapd-%i.pid (code=exited, status=1/FAILURE)
>Process: 14887 ExecStartPre=/usr/sbin/ds_systemd_ask_password_acl 
> /etc/dirsrv/slapd-%i/dse.ldif (code=exited, status=0/SUCCESS)
>   Main PID: 14893 (code=exited, status=1/FAILURE)
> 
> Jan 04 12:54:46 zkwiparepa01.kw.example.com 
>  
> ns-slapd[14893]: [04/Jan/2017:12:54:46.177617891 +0300] Error: 
> betxnpostoperation plu...arted
> Jan 04 12:54:46 zkwiparepa01.kw.example.com 
>  
> ns-slapd[14893]: [04/Jan/2017:12:54:46.178379752 +0300] Error: object plugin 
> Roles Pl...arted
> Jan 04 12:54:46 zkwiparepa01.kw.example.com 
>  
> ns-slapd[14893]: [04/Jan/2017:12:54:46.179162340 +0300] Error: preoperation 
> plugin su...arted
> Jan 04 12:54:46 zkwiparepa01.kw.example.com 
>  
> ns-slapd[14893]: [04/Jan/2017:12:54:46.179993432 +0300] Error: object plugin 
> USN 
> is n...arted
> Jan 04 12:54:46 zkwiparepa01.kw.example.com 
>  
> ns-slapd[14893]: [04/Jan/2017:12:54:46.181305209 +0300] Error: object plugin 
> Views is...arted
> Jan 04 12:54:46 zkwiparepa01.kw.example.com 
>  
> ns-slapd[14893]: [04/Jan/2017:12:54:46.182094981 +0300] Error: extendedop 
> plugin 
> whoa...arted
> Jan 04 12:54:46 zkwiparepa01.kw.example.com 
>  
> systemd[1]: dirsrv@KW-EXAMPLE-COM.service: main process exited, code=exited, 
> status=1/FAILURE
> Jan 04 12:54:46 zkwiparepa01.kw.example.com 
>  
> systemd[1]: Failed to start 389 Directory Server KW-EXAMPLE-COM..
> Jan 04 12:54:46 zkwiparepa01.kw.example.com 
>  
> systemd[1]: Unit dirsrv@KW-EXAMPLE-COM.service entered failed state.
> Jan 04 12:54:46 zkwiparepa01.kw.example.com 
>  
> systemd[1]: dirsrv@KW-EXAMPLE-COM.service failed.
> Hint: Some lines were ellipsized, use -l to show in full.
> 
> 
> 
> Regards,
> Ben
> 
> 
> On Wed, Jan 4, 2017 at 11:19 AM, Martin Babinsky  > wrote:
> 
> On 01/04/2017 07:21 AM, Ben .T.George wrote:
> 
> HI
> 
> while trying to create ipa replica, i am getting below error,
> 
> Replica creation using 'ipa-replica-prepare' to generate replica file
> is supported only in 0-level IPA domain.
> 
> The current IPA domain level is 1 and thus the replica must
> be created by promoting an existing IPA client.
> 
> To set up a replica use the following procedure:
>  1.) set up a client on the host using 'ipa-client-install'
>  2.) 

Re: [Freeipa-users] Unspecified GSS failure. Minor code may provide more information KDC has no support for encryption type

[Sumit Bose]

On Mon, Jan 02, 2017 at 11:03:36PM +0530, tarak sinha wrote:
> Hi Team,
> 
> I am getting below error while trying to ssh my host without password.
> 
> Unspecified GSS failure. Minor code may provide more information KDC has no
> support for encryption type

Where do you see this error, on the client where you call ssh or in the
logs on the host you try to log in to? Are you using IPA user or do you
use trust and AD users from a trusted domain?

Do you see any related messages in the KDC logs?

bye,
Sumit

> 
> Thanks in advance
> 
> *Thanks,*
> 
> *Tarak Nath Sinha*

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

[Freeipa-users] Debian: libpam-sss pam-configs update?

[Jochen Hein]

Hi,

I'm still working on my Debian systems to get local login to work with
OTP.

In /etc/pam.d/common-auth we have:
auth[success=2 default=ignore]  pam_unix.so nullok_secure
auth[success=1 default=ignore]  pam_sss.so use_first_pass

On CentOS we have something more complicated in /etc/pam.d/system-auth:

auth[default=1 success=ok] pam_localuser.so
auth[success=done ignore=ignore default=die] pam_unix.so nullok 
try_first_pass
authrequisite pam_succeed_if.so uid >= 1000 quiet_success
authsufficientpam_sss.so forward_pass

I think we need something more elaborated for debian to replicate the
(good!) experience from CentOS when asking for "First/Second Factor".
The four lines from above work well, but how can we get that into
pam-auth-update? Any ideas how this could be packaged?

Jochen

-- 
The only problem with troubleshooting is that the trouble shoots back.

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

Re: [Freeipa-users] Kerberos authentication failed: kinit: Included profile directory could not be read while initializing Kerberos 5 library

[Lukas Slebodnik]

On (03/01/17 20:35), Alan Latteri wrote:
>Well on new installs of Cent 7.2, when I do `yum install ipa-client`, that is 
>the version provided.
>Unfortunately, most of our systems have to be on Cent 7.2, not 7.3, and it is 
>out of our control.
>
You will install el7.3 on CentOS 7.2 by default.
If you want to stay on 7.2 you need to change repositories

sh# yum install --setopt=debuglevel=1 --assumeno sssd-client
Ignored option -q, -v, -d or -e (probably due to merging: -yq != -y -q)


 Package   ArchVersion   RepositorySize

Installing:
 sssd-client   x86_64  1.14.0-43.el7_3.4 updates  171 k
Installing for dependencies:
 libsss_idmap  x86_64  1.14.0-43.el7_3.4 updates  118 k
 libsss_nss_idmap  x86_64  1.14.0-43.el7_3.4 updates  116 k

Transaction Summary

Install  1 Package (+2 Dependent packages)

sh# yum-config-manager --disable base extras updates
sh# yum-config-manager --enable "C7.2.1511*"
sh# yum repolist
Loaded plugins: fastestmirror, ovl
Loading mirror speeds from cached hostfile
repo id repo name
status
C7.2.1511-base/x86_64   CentOS-7.2.1511 - Base9007
C7.2.1511-centosplus/x86_64 CentOS-7.2.1511 - CentOSPlus   134
C7.2.1511-extras/x86_64 CentOS-7.2.1511 - Extras   393
C7.2.1511-fasttrack/x86_64  CentOS-7.2.1511 - CentOSPlus 0
C7.2.1511-updates/x86_64CentOS-7.2.1511 - Updates 2560


sh# yum install --setopt=debuglevel=1 --assumeno sssd-client


 Package Arch  Version   RepositorySize

Installing:
 sssd-client x86_641.13.0-40.el7_2.12C7.2.1511-updates158 k
Installing for dependencies:
 libsss_idmapx86_641.13.0-40.el7_2.12C7.2.1511-updates104 k
 libsss_nss_idmapx86_641.13.0-40.el7_2.12C7.2.1511-updates103 k

Transaction Summary

Install  1 Package (+2 Dependent packages)


LS

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

Re: [Freeipa-users] how to make email as mandatory field before user creation

[Standa Laznicka]

On 01/03/2017 06:45 PM, Petr Vobornik wrote:

On 01/02/2017 08:46 PM, nirajkumar.si...@accenture.com wrote:

Hi Prtr,

Can you please suggest how to do it with plugins and which plugin I need to use 
and how to integrate that plugin with freeipa.

Thanks
Niraj

Disclaimer: the example below is not really save because it doesn't
handle e.g. stageusers
... which you could perhaps ensure by replacing "user" with "baseuser" 
in the whole proposed "zuserplugin.py" file. It should not break more 
stuff than the proposed change I should hope :)

and it might not work with later releases of
FreeIPA because IPA doesn't provide any supported plugin API yet.

Example: https://pvoborni.fedorapeople.org/plugins/backend/zuserplugin.py

Old(FreeIPA 3.3) extending guide:
   http://www.freeipa.org/images/5/5b/FreeIPA33-extending-freeipa.pdf


-Original Message-
From: Petr Vobornik [mailto:pvobo...@redhat.com]
Sent: 02 January 2017 22:21
To: Singh, NirajKumar ; freeipa-users@redhat.com
Subject: Re: [Freeipa-users] how to make email as mandatory field before user 
creation

On 01/02/2017 05:00 PM, nirajkumar.si...@accenture.com wrote:

Hi Team,

Is there any way to make email as mandatory field before creating any
user from WEBUI or Console?

Thanks & Regards,

Niraj Kumar Singh


Hello Niraj,

FreeIPA doesn't support such configuration out of the box.

It is theoretically possible to implement IPA server side plugin to mark the 
field as required. It may not be straightforward though.

--
Petr Vobornik



This message is for the designated recipient only and may contain privileged, 
proprietary, or otherwise confidential information. If you have received it in 
error, please notify the sender immediately and delete the original. Any other 
use of the e-mail by you is prohibited. Where allowed by local law, electronic 
communications with Accenture and its affiliates, including e-mail and instant 
messaging (including content), may be scanned by our systems for the purposes 
of information security and assessment of internal compliance with Accenture 
policy.
__

www.accenture.com





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

[Freeipa-users] Manually configuring Freeipa bind configs to host secondary zones

[James Harrison]

Hi All,I realise Free IPA doesn't yet support secondary zones in the web 
interface or command line tools (I might be wrong :) ) When I talk about 
secondary zones I mean a zone replicated from Windows DNS masters.
Can the Free IPA bind configs be manually altered to host secondary zones. Is 
it supported or will they just be over-written by Freeipa?
I've been hunting for an answer online, but found nothing about this.

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

Re: [Freeipa-users] updating certificates

[Florence Blanc-Renaud]

On 12/24/2016 01:58 AM, Josh wrote:

Hi Rob,

I'd like to really clarify renew certificate process. I can successfully
update certificates in /etc/dirsrv/slapd-domain and /etc/httpd/alias but
any new ipa client gets expired certificate still present someplace in
LDAP. I was trying to use ipa-server-certinstall, described in
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/third-party-certs-http-ldap.html
but document does not cover the case where intermediate certificate is
required.

Hi Josh,

if the HTTP and LDAP certificates were signed by an intermediate CA, 
then you need to install both the root CA and the intermediate CA with 
ipa-cacert-manage install:


1/ install the root CA (if not already done)
ipa-cacert-manage install rootcert.pem
ipa-certupdate (on all the servers and clients)

2/ install the intermediate CA (if not already done)
ipa-cacert-manage install intermediatecert.pem
ipa-certupdate (on all the servers and clients)

3/ install the HTTP and LDAP certificates
ipa-server-certinstall ...

HTH,
Flo



Josh.

On 07/11/2016 10:10 AM, Rob Crittenden wrote:

j...@use.startmail.com wrote:

On Tuesday, June 28, 2016 10:50 AM, Rob Crittenden
 wrote:

j...@use.startmail.com wrote:

Greetings,

About a year ago I installed my freeipa server with certificates from
startssl using command line options --dirsrv-cert-file
--http-cert-file
etc.
The certificate is about to expire, what is the proper way to
update it
in all places?


It depends on whether you kept the original CSR or not. If you kept the
original CSR and are just renewing the certificate(s) then when you get
the new one, use certutil to add the updated cert to the appropriate
NSS
database like:

# certutil -A -n Server-Cert -d /etc/httpd/alias -t u,u,u -a -i
/path/to/new.crt



Rob,

Thank you, that worked just fine, except that I had to update an
intermediate certificate as well.

Two questions, please:

1. I noticed a strange discrepancy in behavior between
/etc/httpd/alias and /etc/dirsrv/slapd-domain.
In both places original intermediate certificate is listed with empty
",," trust attributes so I initially added new intermediate
certificate with empty attributes as well.
certutils -V showed valid certificate in /etc/httpd/alias and not
trusted in /etc/dirsrv/slapd-domain so I had to modify intermediate
certificate with -t "C,,"


Hmm, not sure. Did the CA chain change in between the issuance of the
two certs?

Adding a new certificate shouldn't affect the trust of any other certs
so I'm not sure what happened. It could be that those subordinate CAs
were loaded the first time incorrectly but weren't used so it wasn't
noticed, I'm not really sure.


2. Just out of curiosity I wanted to list private keys and is
prompted for a password:
# certutil -K -d /etc/httpd/alias/
certutil: Checking token "NSS Certificate DB" in slot "NSS User
Private Key and Certificate Services"
Enter Password or Pin for "NSS Certificate DB":

Which one of the many provided by a user passwords is used by
ipa-server-install command during NSS database initialization?


In each NSS directory there is a pwdfile.txt which contains the PIN
for the internal token. You can add -f /etc/httpd/alias/pwdfile.txt to
your command to list the private keys.

rob




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

Re: [Freeipa-users] Asking for help with crashed freeIPA istance

[Florence Blanc-Renaud]

On 01/02/2017 07:24 PM, Daniel Schimpfoessl wrote:

Thanks for your reply.

This was the initial error I asked for help a while ago and did not get
resolved. Further digging showed the recent errors.
The service was running (using ipactl start --force) and only after a
restart I am getting a stack trace for two primary messages:

Could not connect to LDAP server host wwgwho01.webwim.com
 port 636 Error netscape.ldap.LDAPException:
Authentication failed (48)
...

Internal Database Error encountered: Could not connect to LDAP server
host wwgwho01.webwim.com  port 636 Error
netscape.ldap.LDAPException: Authentication failed (48)
...

and finally:
[02/Jan/2017:12:20:34][localhost-startStop-1]: CMSEngine.shutdown()


2017-01-02 3:45 GMT-06:00 Florence Blanc-Renaud >:

systemctl start pki-tomcatd@pki-tomcat.service




Hi Daniel,

the next step would be to understand the root cause of this 
"Authentication failed (48)" error. Note the exact time of this log and 
look for a corresponding log in the LDAP server logs 
(/var/log/dirsrv/slapd-DOMAIN-COM/access), probably a failing BIND with 
err=48. This may help diagnose the issue (if we can see which 
certificate is used for the bind or if there is a specific error message).


For the record, a successful bind over SSL would produce this type of 
log where we can see the certificate subject and the user mapped to this 
certificate:

[...] conn=47 fd=84 slot=84 SSL connection from 10.34.58.150 to 10.34.58.150
[...] conn=47 TLS1.2 128-bit AES; client CN=CA Subsystem,O=DOMAIN.COM; 
issuer CN=Certificate Authority,O=DOMAIN.COM

[...] conn=47 TLS1.2 client bound as uid=pkidbuser,ou=people,o=ipaca
[...] conn=47 op=0 BIND dn="" method=sasl version=3 mech=EXTERNAL
[...] conn=47 op=0 RESULT err=0 tag=97 nentries=0 etime=0 
dn="uid=pkidbuser,ou=people,o=ipaca"


Flo

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

Re: [Freeipa-users] ipa replica installation help

[Martin Babinsky]

On 01/04/2017 07:21 AM, Ben .T.George wrote:

HI

while trying to create ipa replica, i am getting below error,

Replica creation using 'ipa-replica-prepare' to generate replica file
is supported only in 0-level IPA domain.

The current IPA domain level is 1 and thus the replica must
be created by promoting an existing IPA client.

To set up a replica use the following procedure:
1.) set up a client on the host using 'ipa-client-install'
2.) promote the client to replica running 'ipa-replica-install'
*without* replica file specified

'ipa-replica-prepare' is allowed only in domain level 0
The ipa-replica-prepare command failed.


i have IPA master server without AD integration and DNS is managed by
3rd party appliances.



Regards,
Ben




Hi Ben,

If you installed IPA 4.4 server then domain level 1 is the default. This 
domain level uses different mechanism to stand up replicas. See the 
latest IdM documentation[1] for more details.


[1] 
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/creating-the-replica.html


--
Martin^3 Babinsky

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