Re: [Freeipa-users] backing up and starting over...

[Robert Story]

On Thu, 22 Dec 2016 16:48:10 -0500 Robert wrote:
RS> I tried to create a replica. It went well for the directory server, but
RS> then:
RS> 
RS> Configuring certificate server (pki-tomcatd). Estimated time: 3 minutes 30
RS> seconds [1/27]: creating certificate server user
RS>   [2/27]: configuring certificate server instance
RS> ipa.ipaserver.install.cainstance.CAInstance: CRITICAL Failed to configure
RS> CA instance: Command '/usr/sbin/pkispawn -s CA -f /tmp/tmpqYyqJJ' returned
RS> non-zero exit status 1 ipa.ipaserver.install.cainstance.CAInstance:
RS> CRITICAL See the installation logs and the following files/directories for
RS> more information: ipa.ipaserver.install.cainstance.CAInstance:
RS> CRITICAL   /var/log/pki/pki-tomcat [error] RuntimeError: CA configuration
RS> failed.
RS> [...]
RS> So this looks like the culprit:
RS> 
RS> [22/Dec/2016:16:07:48][http-bio-8443-exec-3]: updateNumberRange: Failed to 
contact master using admin portjavax.ws.rs.InternalServerErrorException: HTTP 
500 Internal Server Error

So eventually I found proxy errors like this in a logfile:

  proxy_ajp:error (70007)The timeout specified has expired:

I added large timeouts to /etc/httpd/conf.d/ipa-pki-proxy.conf

 Timeout 900
 ProxyTimeout 900

This allowed my replica install to complete. However, when I logged in to
the new replica, I was getting the same long timeout trying to load users.
The error log had this:

[Fri Dec 23 00:50:39.206858 2016] [proxy_ajp:error] [pid 31182]
[client 10.71.10.118:49784] AH00896: failed to make connection to backend: 
localhost

This started ringing a little bell in my head about localhost and ipv4 vs
ipv6. I disabled ipv6 in /etc/sysctl.conf, and voila, users load in less
than 5 seconds instead of 5 minutes or timing out.

Hopefully this will also resolve the other weirdness I've been seeing. I'm
keeping my fingers crossed.


Robert

-- 
Senior Software Engineer @ Parsons


pgpqGB0jo68SB.pgp
Description: OpenPGP digital 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] Asking for help with crashed freeIPA istance

[Daniel Schimpfoessl]

I do not believe I changed the DM password. I know I had to update the
admin passwords regularly.

Only during the startup using ipactl start --force I am able to connect to
the service using the password for DM and it returns:

# extended LDIF
#
# LDAPv3
# base <> with scope baseObject
# filter: (objectclass=*)
# requesting: ALL
#

#
dn:
objectClass: top
namingContexts: cn=changelog
namingContexts: dc=myorg,dc=com
namingContexts: o=ipaca
defaultnamingcontext: dc=myorg,dc=com
supportedExtension: 2.16.840.1.113730.3.5.7
supportedExtension: 2.16.840.1.113730.3.5.8
supportedExtension: 2.16.840.1.113730.3.5.10
supportedExtension: 2.16.840.1.113730.3.8.10.3
supportedExtension: 2.16.840.1.113730.3.8.10.4
supportedExtension: 2.16.840.1.113730.3.8.10.4.1
supportedExtension: 1.3.6.1.4.1.4203.1.11.1
supportedExtension: 2.16.840.1.113730.3.8.10.1
supportedExtension: 2.16.840.1.113730.3.8.10.5
supportedExtension: 2.16.840.1.113730.3.5.3
supportedExtension: 2.16.840.1.113730.3.5.12
supportedExtension: 2.16.840.1.113730.3.5.5
supportedExtension: 2.16.840.1.113730.3.5.6
supportedExtension: 2.16.840.1.113730.3.5.9
supportedExtension: 2.16.840.1.113730.3.5.4
supportedExtension: 2.16.840.1.113730.3.6.5
supportedExtension: 2.16.840.1.113730.3.6.6
supportedExtension: 2.16.840.1.113730.3.6.7
supportedExtension: 2.16.840.1.113730.3.6.8
supportedExtension: 1.3.6.1.4.1.1466.20037
supportedControl: 2.16.840.1.113730.3.4.2
supportedControl: 2.16.840.1.113730.3.4.3
supportedControl: 2.16.840.1.113730.3.4.4
supportedControl: 2.16.840.1.113730.3.4.5
supportedControl: 1.2.840.113556.1.4.473
supportedControl: 2.16.840.1.113730.3.4.9
supportedControl: 2.16.840.1.113730.3.4.16
supportedControl: 2.16.840.1.113730.3.4.15
supportedControl: 2.16.840.1.113730.3.4.17
supportedControl: 2.16.840.1.113730.3.4.19
supportedControl: 1.3.6.1.1.13.1
supportedControl: 1.3.6.1.1.13.2
supportedControl: 1.3.6.1.4.1.42.2.27.8.5.1
supportedControl: 1.3.6.1.4.1.42.2.27.9.5.2
supportedControl: 1.2.840.113556.1.4.319
supportedControl: 1.3.6.1.4.1.42.2.27.9.5.8
supportedControl: 1.3.6.1.4.1.4203.666.5.16
supportedControl: 2.16.840.1.113730.3.8.10.6
supportedControl: 2.16.840.1.113730.3.4.14
supportedControl: 2.16.840.1.113730.3.4.20
supportedControl: 1.3.6.1.4.1.1466.29539.12
supportedControl: 2.16.840.1.113730.3.4.12
supportedControl: 2.16.840.1.113730.3.4.18
supportedControl: 2.16.840.1.113730.3.4.13
supportedControl: 1.3.6.1.4.1.4203.1.9.1.1
supportedSASLMechanisms: EXTERNAL
supportedSASLMechanisms: GSS-SPNEGO
supportedSASLMechanisms: GSSAPI
supportedSASLMechanisms: DIGEST-MD5
supportedSASLMechanisms: CRAM-MD5
supportedSASLMechanisms: ANONYMOUS
supportedLDAPVersion: 2
supportedLDAPVersion: 3
vendorName: 389 Project
vendorVersion: 389-Directory/1.3.4.0 B2016.215.1556
dataversion: 020161359470201613594702016135947
netscapemdsuffix: cn=ldap://dc=wwgwho01,dc=myorg,dc=com:389
lastusn: 8690425
changeLog: cn=changelog
firstchangenumber: 2752153
lastchangenumber: 2752346

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1


2016-12-21 9:27 GMT-06:00 Rob Crittenden :

> Daniel Schimpfoessl wrote:
> > Thanks for getting back to me.
> >
> > getcert list | grep expires shows dates years in the future for all
> > certificates
> > Inline-Bild 1
> >
> > ipactl start --force
> >
> > Eventually the system started with:
> >  Forced start, ignoring pki-tomcatd Service, continuing normal
> > operations.
> >
> > systemctl status ipa shows: failed
>
> I don't think this is a certificate problem at all. I think the timing
> with your renewal is just coincidence.
>
> Did you change your Directory Manager password at some point?
>
> >
> > ldapsearch -H ldaps://localhost:636 -D "cn=directory manager" -w
> > password -b "" -s base
> > ldapsearch -H ldaps://localhost:636 -D "cn=directory manager" -w
> > *** -b "" -s base
> > Inline-Bild 2
>
> You need the -x flag to indicate simple bind.
>
> rob
>
> > The logs have thousands of lines like it, what am I looking for
> > specifically?
> >
> > Daniel
> >
> >
> > 2016-12-20 4:18 GMT-06:00 Florence Blanc-Renaud  > >:
> >
> > On 12/19/2016 07:15 PM, Daniel Schimpfoessl wrote:
> >
> > Good day and happy holidays,
> >
> > I have been running a freeIPA instance for a few years and been
> very
> > happy. Recently the certificate expired and I updated it using
> the
> > documented methods. At first all seemed fine. Added a Nagios
> > monitor for
> > the certificate expiration and restarted the server (single
> > server). I
> > have weekly snapshots, daily backups (using Amanda on the entire
> > disk).
> >
> > One day the services relying on IPA failed to authenticate.
> > Looking at
> > the server the ipa service had stopped. Restarting the service
> > fails.
> > Restoring a few weeks old snapshot does not start either.

Re: [Freeipa-users] backing up and starting over...

[Robert Story]

On Thu, 22 Dec 2016 09:25:52 +0100 Florence wrote:
FBR> you can find more information about backup and restore procedure in this 
FBR> guide [1]. But, as stated in the documentation, the safest method would 
FBR> rather be to install a replica [2].
FBR> [...]
FBR> [2] 
FBR> 
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/install-replica.html

I tried to create a replica. It went well for the directory server, but
then:

Configuring certificate server (pki-tomcatd). Estimated time: 3 minutes 30
seconds [1/27]: creating certificate server user
  [2/27]: configuring certificate server instance
ipa.ipaserver.install.cainstance.CAInstance: CRITICAL Failed to configure
CA instance: Command '/usr/sbin/pkispawn -s CA -f /tmp/tmpqYyqJJ' returned
non-zero exit status 1 ipa.ipaserver.install.cainstance.CAInstance:
CRITICAL See the installation logs and the following files/directories for
more information: ipa.ipaserver.install.cainstance.CAInstance:
CRITICAL   /var/log/pki/pki-tomcat [error] RuntimeError: CA configuration
failed.

from ipa-replica-install.log:

2016-12-22T21:00:53Z DEBUG Starting external process
2016-12-22T21:00:53Z DEBUG args=/usr/sbin/pkispawn -s CA -f /tmp/tmpqYyqJJ
2016-12-22T21:10:08Z DEBUG Process finished, return code=1
2016-12-22T21:10:08Z DEBUG stdout=Log file: 
/var/log/pki/pki-ca-spawn.20161222160055.log
Loading deployment configuration from /tmp/tmpqYyqJJ.
Installing CA into /var/lib/pki/pki-tomcat.
Storing deployment configuration into 
/etc/sysconfig/pki/tomcat/pki-tomcat/ca/deployment.cfg.
Importing certificates from /tmp/ca.p12:
...
Import complete
---
Imported certificates in /etc/pki/pki-tomcat/alias:

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

ocspSigningCert cert-pki-ca  u,u,u
subsystemCert cert-pki-cau,u,u
caSigningCert cert-pki-caCTu,Cu,Cu
Server-Cert cert-pki-ca  u,u,u
auditSigningCert cert-pki-ca u,u,Pu

Installation failed:


Please check the CA logs in /var/log/pki/pki-tomcat/ca.

2016-12-22T21:10:08Z DEBUG stderr=
2016-12-22T21:10:08Z CRITICAL Failed to configure CA instance: Command 
'/usr/sbin/pkispawn -s CA -f /tmp/tmpqYyqJJ' returned non-zero exit status 1
2016-12-22T21:10:08Z CRITICAL See the installation logs and the following 
files/directories for more information:
2016-12-22T21:10:08Z CRITICAL   /var/log/pki/pki-tomcat
2016-12-22T21:10:08Z DEBUG Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 
448, in start_creation
run_step(full_msg, method)
  File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 
438, in run_step
method()
  File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line 
590, in __spawn_instance
DogtagInstance.spawn_instance(self, cfg_file)
  File "/usr/lib/python2.7/site-packages/ipaserver/install/dogtaginstance.py", 
line 181, in spawn_instance
self.handle_setup_error(e)
  File "/usr/lib/python2.7/site-packages/ipaserver/install/dogtaginstance.py", 
line 420, in handle_setup_error
raise RuntimeError("%s configuration failed." % self.subsystem)
RuntimeError: CA configuration failed.

2016-12-22T21:10:08Z DEBUG   [error] RuntimeError: CA configuration failed.
2016-12-22T21:10:08Z DEBUG   File 
"/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 171, in execute
return_value = self.run()
  File "/usr/lib/python2.7/site-packages/ipapython/install/cli.py", line 318, 
in run
cfgr.run()
  File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 310, 
in run
self.execute()
  File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 332, 
in execute
for nothing in self._executor():
  File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 372, 
in __runner
self._handle_exception(exc_info)
  File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 394, 
in _handle_exception
six.reraise(*exc_info)
  File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 362, 
in __runner
step()
  File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 359, 
in 
step = lambda: next(self.__gen)
  File "/usr/lib/python2.7/site-packages/ipapython/install/util.py", line 81, 
in run_generator_with_yield_from
six.reraise(*exc_info)
  File "/usr/lib/python2.7/site-packages/ipapython/install/util.py", line 59, 
in run_generator_with_yield_from
value = gen.send(prev_value)
  File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 586, 
in _configure
next(executor)
  File 

Re: [Freeipa-users] replica running trust-agents can't resolve AD users - which of these sssd errors should I be focusing on?

[Alexander Bokovoy]

On to, 22 joulu 2016, Chris Dagdigian wrote:

Hi folks,

Summary:  Replica w/ Trust agents can't resolve AD users. Not sure 
which debug_level=log error I should focus on. Would appreciate extra 
eyeballs on this ..


Have a brand new replica (v4.4) running and after installing the AD 
trust agents I still can't recognize users who exist in the trusted AD 
domains.


Running at debug_level=10 for logging as usual however deleting the 
logs and doing a fresh reboot followed by trying to resolve a users 
still make 4000+ log entries so rather than include it here I've 
posted a sanitized sssd_domain.log file here:


http://chrisdag.me/sssd_companyidm.org.log.txt

There are two sets of messages in that massive log file that concern 
me but I don't know enough yet to figure out which one to focus on.


The first set of messages show what appears to be a fatal error in 
connecting to the local ldap:// server on the replica.


However -
- dirsirv logs look fine
- the various ldapsearch commands in the Free-IPA troublehooting page 
work to query both the replica and the remote master

- 'ipactl status' shows directory services running
- no firewall blocking and AWS VPC flowLogs show no REJECT traffic 
whatsoever for the NIC on the replica

Can you show us ldap_child.log and krb5_child.log from /var/log/sssd on
the replica?

There seem to be something weird with networking stack, because at
15:43:13 the next attempt to connect gets 'connection refused'. May be
389-ds is just warming up and there is not enough CPU or I/O to handle
the load?

(Thu Dec 22 15:43:13 2016) [sssd[be[companyidm.org]]]
[be_resolve_server_process] (0x0200): Found address for server 
usaeilidmp002.companyidm.org: [10.127.66.11] TTL 7200
(Thu Dec 22 15:43:13 2016) [sssd[be[companyidm.org]]]
[sssd_async_socket_init_send] (0x4000): Using file descriptor [27] for the 
connection.
(Thu Dec 22 15:43:13 2016) [sssd[be[companyidm.org]]]
[sssd_async_socket_init_send] (0x0400): Setting 6 seconds timeout for connecting
(Thu Dec 22 15:43:13 2016) [sssd[be[companyidm.org]]]
[sssd_async_connect_done] (0x0020): connect failed [111][Connection refused].
(Thu Dec 22 15:43:13 2016) [sssd[be[companyidm.org]]]
[sssd_async_socket_init_done] (0x0020): sdap_async_sys_connect request failed: 
[111]: Connection refused.

this is definitely is different from the result of two seconds before:

(Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]]
[sssd_async_socket_init_send] (0x4000): Using file descriptor [21] for the 
connection.
(Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]]
[sssd_async_connect_send] (0x0020): connect failed [101][Network is 
unreachable].
(Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]]
[sssd_async_socket_init_send] (0x0400): Setting 6 seconds timeout for connecting
(Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]]
[sssd_async_socket_init_done] (0x0020): sdap_async_sys_connect request failed: 
[101]: Network is unreachable.
(Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]]
[sssd_async_socket_state_destructor] (0x0400): closing socket [21] 
(Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]]

[sss_ldap_init_sys_connect_done] (0x0020): sssd_async_socket_init request 
failed: [101]: Network is unreachable.
(Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]]
[sdap_sys_connect_done] (0x0020): sdap_async_connect_call request failed: 
[101]: Network is unreachable.

Later, in a minute it seems to respond just well:


(Thu Dec 22 15:44:28 2016) [sssd[be[companyidm.org]]]
[sssd_async_socket_init_send] (0x4000): Using file descriptor [27] for the 
connection.
(Thu Dec 22 15:44:28 2016) [sssd[be[companyidm.org]]]
[sssd_async_socket_init_send] (0x0400): Setting 6 seconds timeout for connecting
(Thu Dec 22 15:44:28 2016) [sssd[be[companyidm.org]]]
[sdap_ldap_connect_callback_add] (0x1000): New LDAP connection to 
[ldap://usaeilidmp002.companyidm.org:389/??base] with fd [27].
(Thu Dec 22 15:44:28 2016) [sssd[be[companyidm.org]]]
[sdap_get_rootdse_send] (0x4000): Getting rootdse
(Thu Dec 22 15:44:28 2016) [sssd[be[companyidm.org]]]
[sdap_print_server] (0x2000): Searching 10.127.66.11:389
...

(Thu Dec 22 15:44:28 2016) [sssd[be[companyidm.org]]] [sdap_parse_range]
(0x2000): No sub-attributes for [supportedSASLMechanisms]
(Thu Dec 22 15:44:28 2016) [sssd[be[companyidm.org]]] [sdap_parse_range]
(0x2000): No sub-attributes for [defaultNamingContext]
(Thu Dec 22 15:44:28 2016) [sssd[be[companyidm.org]]] [sdap_parse_range]
(0x2000): No sub-attributes for [lastUSN]
(Thu Dec 22 15:44:28 2016) [sssd[be[companyidm.org]]]
[sdap_process_result] (0x2000): Trace: sh[0x7f4f63ace530], connected[1], 
ops[0x7f4f63b283d0], ldap[0x7f4f63b28720]
(Thu Dec 22 15:44:28 2016) [sssd[be[companyidm.org]]]
[sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_RESULT]
(Thu Dec 22 15:44:28 2016) [sssd[be[companyidm.org]]]
[sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no errmsg 
set
(Thu Dec 22 15:44:28 2016) 

Re: [Freeipa-users] Still unclear about relation between IPA DNS domain and company DNS domain.

[Martin Basti]

On 22.12.2016 17:53, Brian Candler wrote:

On 20/12/2016 08:07, Petr Spacek wrote:
I've tried to clarify things in man pages and on web as well. Please 
have a
look to changes and let us know if it is better or not, and 
preferably what

can be improved and in which way

The modified deployment page is here:
http://www.freeipa.org/page/Deployment_Recommendations

Man page changes and changes in description of installer options are 
here:

https://github.com/freeipa/freeipa/pull/352


Thank you for working on this.

This is getting clearer, but I would like to expand a little more.

(1) This introduces a concept of an "IPA Primary Domain".  Is that 
just the DNS domain which holds the SRV records which point to the 
realm's kerberos/ldap servers, or does it have any other function? In 
other words, what other effects would there be from choosing a 
different IP Primary Domain?


it holds SRV records, A/ records for CA

LDAP tree is constructed from the domain (cn=accounts,dc=example,dc=com)



Let me give a specific example.

- IPA server hostname is ipa.foo.example.com
- I want to create kerberos realm BAR.EXAMPLE.COM

Which IPA primary domain should I choose?

The expected place for SRV records for realm BAR.EXAMPLE.COM would be 
in the DNS under domain bar.example.com.  So I'm thinking that 
"--domain bar.example.com" is the right thing - and can't think why 
you'd ever want to do anything else.





Then use bar.example.com, IPA servers can have names outside the IPA 
domain name space.


Different people wants different things, that's why the option is there.



(2) I'm trying to work out how --domain, --realm, --server and 
systemhostname influence each other, if one or more is not provided.


For ipa-server-install, testing suggests:

* --domain defaults to the domain part of the system hostname
* --realm defaults to the uppercased --domain
* (--server is obviously itself :-)

For ipa-client-install it seems a bit more complex. Based on the 
manpage, I believe the sequence is something like this:


* If --domain is not specified, then it's the domain from the system 
hostname
* If --server is not specified, then it hunts for servers based on the 
--domain (looking in that domain and its parents until suitable SRV 
records are found)
* If --realm is not specified, then it sends a query to the 
--server(s) to ask what realm they are in


But the manpage says you can specify both --server and --domain:

  "Client  machine  can  also be configured without a DNS 
autodiscovery at all. When both
   --server and --domain options are used, client installer will 
use the specified server

   and  domain  directly."


Server and client can be in different DNS domains, that's probably why 
it has separate options.


I know that it is not clear how client determine domain and server, but 
there were more important things to fix, this may be improved in future.





In that case, I can't see what the --domain is used for here, if it's 
only purpose is to locate servers (and you've already told it which 
--server to use)


Thanks,

Brian.



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] Ipa cert automatic renew Failing.

[Lucas Diedrich]

Yey!! It fixed the problem over the new CA Master now, i finally can see
and search for the certs. But, in the replicas i can't browse for them, it
prompts me this (IPA Error 4301: CertificateOperationError), should i ran
the post-save command in all replicas?

Thanks.

Em qui, 22 de dez de 2016 às 11:13, Florence Blanc-Renaud 
escreveu:

> On 12/22/2016 01:15 PM, Lucas Diedrich wrote:
> > Florence, for some creepy reason the cert from pkidbuser is different
> > from subsystem certs, and this pkidbuser is outdated now, but i can't
> > manage one way to re-issue it. I had to change the CA server because of
> > that, and the Selinux in the old CA Server was disabled, on the new one
> > is in Permissive mode but doesn't a warning in /var/log/audit/audit.log.
> >
> > This is the pkidbuser cert:
> https://paste.fedoraproject.org/511023/24084431/
> > This is the subsystem cert:
> https://paste.fedoraproject.org/511025/14824085/
> > The ca.subsystem.cert matches the pkidbuser cert.
> >
> > lucasdiedrich.
> >
> Hi,
>
> you can try to manually call the post-save command that certmonger
> should have issued after putting the certificate in
> /etc/pki/pki-tomcat/alias:
> on the renewal master:
> $ sudo /usr/libexec/ipa/certmonger/stop_pkicad
> $ sudo /usr/libexec/ipa/certmonger/renew_ca_cert "subsystemCert
> cert-pki-ca"
>
> Then check the journal log that should display the following if
> everything goes well:
> $ sudo journalctl --since today | grep renew_ca_cert
> [...] renew_ca_cert[6478]: Updating entry
> uid=CA-ipaserver.domain.com-8443,ou=people,o=ipaca
> [...] renew_ca_cert[6478]: Updating entry uid=pkidbuser,ou=people,o=ipaca
> [...] renew_ca_cert[6478]: Starting pki_tomcatd
> [...] renew_ca_cert[6478]: Started pki_tomcatd
>
> If the operation does not succeed, you will have to check the LDAP
> server logs in /etc/dirsrv/slapd-DOMAIN/access.
>
> HTH,
> Flo.
>
> > Em qui, 22 de dez de 2016 às 06:54, Florence Blanc-Renaud
> > > escreveu:
> >
> > On 12/21/2016 07:52 PM, Lucas Diedrich wrote:
> > > Hello guys,
> > >
> > > I'm having some trouble with, whats is happening with my server is
> > that
> > > i'm hiting an old BUG
> > > (https://bugzilla.redhat.com/show_bug.cgi?id=1033273). Talking to
> > mbasti
> > > over irc he oriented me to send this to the email list.
> > >
> > > The problem is, i got on CA Master, so because of this problem the
> CA
> > > Master certificates couldn't be renewd, so now i promoted another
> > master
> > > to be the CA. And the problem still persist.
> > >
> > > This is the certs from my new CA
> > > (https://paste.fedoraproject.org/510617/14823448/),
> > > this is the certs from my old CA
> > > (https://paste.fedoraproject.org/510618/44871148/)
> > > This is the log then i restart pki-tomcat( "CA port 636 Error
> > > netscape.ldap.LDAPException: Authentication failed (49)")
> > > This is the log from dirsrv when i restart pki-tomcat
> > > (https://paste.fedoraproject.org/510614/23446801/)
> > >
> > > Basically my CA is not working anymore...
> > >
> > > Anyway, i tried lots of thing but couldn't fix this, anyone has
> > some idea?
> > >
> > >
> > >
> > Hi,
> >
> > Pki-tomcat is using the LDAP server as a data store, meaning that it
> > needs to authenticate to LDAP. In order to do that, pki-tomcat is
> using
> > the certificate 'subsystemCert cert-pki-ca' stored in
> > /etc/pki/pki-tomcat/alias. For the authentication to succeed, the
> > certificate must be stored in a user entry
> > (uid=pkidbuser,ou=people,o=ipaca).
> >
> > Can you check the content of this entry, especially the
> usercertificate
> > attribute? It should match the certificate used by pki-tomcat:
> >
> > $ certutil -L -d /etc/pki/pki-tomcat/alias -n 'subsystemCert
> > cert-pki-ca' -a
> > -BEGIN CERTIFICATE-
> > [...]
> > -END CERTIFICATE-
> >
> > $ kinit admin
> > $ ldapsearch -Y GSSAPI -h `hostname` -p 389 -b
> > uid=pkidbuser,ou=people,o=ipaca "(objectclass=*)" usercertificate
> > dn: uid=pkidbuser,ou=people,o=ipaca
> > usercertificate:: 
> >
> > The file /etc/pki/pki-tomcat/ca/CS.cfg should also contain this
> > certificate in the directive ca.subsystem.cert.
> >
> >
> > A possible cause for the entries not being updated is the bug 1366915
> > [1] linked to SE linux on RHEL7, or bug 1365188 [2] linked to SE
> linux
> > on Fedora 24.
> >
> > Flo
> >
> > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1366915
> > [2] https://bugzilla.redhat.com/show_bug.cgi?id=1365188
> >
> >
> >
>
>
-- 
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] Still unclear about relation between IPA DNS domain and company DNS domain.

[Brian Candler]

On 20/12/2016 08:07, Petr Spacek wrote:

I've tried to clarify things in man pages and on web as well. Please have a
look to changes and let us know if it is better or not, and preferably what
can be improved and in which way

The modified deployment page is here:
http://www.freeipa.org/page/Deployment_Recommendations

Man page changes and changes in description of installer options are here:
https://github.com/freeipa/freeipa/pull/352


Thank you for working on this.

This is getting clearer, but I would like to expand a little more.

(1) This introduces a concept of an "IPA Primary Domain".  Is that just 
the DNS domain which holds the SRV records which point to the realm's 
kerberos/ldap servers, or does it have any other function? In other 
words, what other effects would there be from choosing a different IP 
Primary Domain?


Let me give a specific example.

- IPA server hostname is ipa.foo.example.com
- I want to create kerberos realm BAR.EXAMPLE.COM

Which IPA primary domain should I choose?

The expected place for SRV records for realm BAR.EXAMPLE.COM would be in 
the DNS under domain bar.example.com.  So I'm thinking that "--domain 
bar.example.com" is the right thing - and can't think why you'd ever 
want to do anything else.




(2) I'm trying to work out how --domain, --realm, --server and 
systemhostname influence each other, if one or more is not provided.


For ipa-server-install, testing suggests:

* --domain defaults to the domain part of the system hostname
* --realm defaults to the uppercased --domain
* (--server is obviously itself :-)

For ipa-client-install it seems a bit more complex. Based on the 
manpage, I believe the sequence is something like this:


* If --domain is not specified, then it's the domain from the system 
hostname
* If --server is not specified, then it hunts for servers based on the 
--domain (looking in that domain and its parents until suitable SRV 
records are found)
* If --realm is not specified, then it sends a query to the --server(s) 
to ask what realm they are in


But the manpage says you can specify both --server and --domain:

  "Client  machine  can  also be configured without a DNS 
autodiscovery at all. When both
   --server and --domain options are used, client installer will 
use the specified server

   and  domain  directly."

In that case, I can't see what the --domain is used for here, if it's 
only purpose is to locate servers (and you've already told it which 
--server to use)


Thanks,

Brian.

--
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] replica running trust-agents can't resolve AD users - which of these sssd errors should I be focusing on?

[Chris Dagdigian]

Hi folks,

Summary:  Replica w/ Trust agents can't resolve AD users. Not sure which 
debug_level=log error I should focus on. Would appreciate extra eyeballs 
on this ..


Have a brand new replica (v4.4) running and after installing the AD 
trust agents I still can't recognize users who exist in the trusted AD 
domains.


Running at debug_level=10 for logging as usual however deleting the logs 
and doing a fresh reboot followed by trying to resolve a users still 
make 4000+ log entries so rather than include it here I've posted a 
sanitized sssd_domain.log file here:


http://chrisdag.me/sssd_companyidm.org.log.txt

There are two sets of messages in that massive log file that concern me 
but I don't know enough yet to figure out which one to focus on.


The first set of messages show what appears to be a fatal error in 
connecting to the local ldap:// server on the replica.


However -
 - dirsirv logs look fine
 - the various ldapsearch commands in the Free-IPA troublehooting page 
work to query both the replica and the remote master

 - 'ipactl status' shows directory services running
 - no firewall blocking and AWS VPC flowLogs show no REJECT traffic 
whatsoever for the NIC on the replica


But I still see this scary section in the logs right after startup:

This is about line #577 in the log where I see some scary LDAP related 
errors:
(Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] [new_subdomain] 
(0x0400): Creating [shanetest.org] as subdomain of [companyidm.org]!
(Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] [new_subdomain] 
(0x0400): Creating [companyaws.org] as subdomain of [companyidm.org]!
(Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] [new_subdomain] 
(0x0400): Creating [COMPANY.ORG] as subdomain of [companyidm.org]!
(Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] [new_subdomain] 
(0x0400): Creating [child2.shanetest.org] as subdomain of 
[companyidm.org]!
(Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] [new_subdomain] 
(0x0400): Creating [EAME.COMPANY.ORG] as subdomain of [companyidm.org]!
(Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] [new_subdomain] 
(0x0400): Creating [APAC.COMPANY.ORG] as subdomain of [companyidm.org]!
(Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] [new_subdomain] 
(0x0400): Creating [LATAM.COMPANY.ORG] as subdomain of [companyidm.org]!
(Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] [new_subdomain] 
(0x0400): Creating [NAFTA.COMPANY.ORG] as subdomain of [companyidm.org]!
(Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] 
[link_forest_roots] (0x2000): [companyidm.org] is a forest root
(Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] 
[link_forest_roots] (0x2000): [shanetest.org] is a forest root
(Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] 
[link_forest_roots] (0x2000): [shanetest.org] is a forest root of 
[child2.shanetest.org]
(Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] 
[link_forest_roots] (0x2000): [companyaws.org] is a forest root
(Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] 
[link_forest_roots] (0x2000): [COMPANY.ORG] is a forest root
(Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] 
[link_forest_roots] (0x2000): [COMPANY.ORG] is a forest root of 
[EAME.COMPANY.ORG]
(Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] 
[link_forest_roots] (0x2000): [COMPANY.ORG] is a forest root of 
[APAC.COMPANY.ORG]
(Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] 
[link_forest_roots] (0x2000): [COMPANY.ORG] is a forest root of 
[LATAM.COMPANY.ORG]
(Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] 
[link_forest_roots] (0x2000): [COMPANY.ORG] is a forest root of 
[NAFTA.COMPANY.ORG]
(Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] 
[sss_write_domain_mappings] (0x0200): Mapping file for domain 
[companyidm.org] is 
[/var/lib/sss/pubconf/krb5.include.d/domain_realm_companyidm_org]
(Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] [become_user] 
(0x0200): Trying to become user [0][0].
(Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] [become_user] 
(0x0200): Already user [0].
(Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] [main] (0x0400): 
Backend provider (companyidm.org) started!
(Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] 
[ipa_server_trusted_dom_setup_send] (0x1000): Trust direction of 
subdom shanetest.org from forest shanetest.org is: one-way inbound: 
local domain trusts the remote domain
(Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] 
[ipa_server_trusted_dom_setup_1way] (0x0400): Will re-fetch keytab for 
shanetest.org
(Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] 
[ipa_getkeytab_send] (0x0400): Retrieving keytab for 
companyidm$@SHANETEST.ORG from usaeilidmp002.companyidm.org into 
/var/lib/sss/keytabs/shanetest.org.keytabRw7Iai using ccache 
/var/lib/sss/db/ccache_companyidm.ORG
(Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] 
[child_handler_setup] (0x2000): Setting up signal handler up for pid [649]
(Thu Dec 22 15:43:11 

Re: [Freeipa-users] NTLM SASL?

[Brian Candler]

On 22/12/2016 14:08, Alexander Bokovoy wrote:

dn: cn=config
changetype: modify
replace: nsslapd-allowed-sasl-mechanisms
-
# accepted, but doesn't change the value of the attribute

So for now, I've set "nsslapd-allowed-sasl-mechanisms: GSSAPI 
EXTERNAL". But that means this server is in a different config state 
to its replica peers, which I wonder might bite me one day.

You can shut the server down (ipactl stop), change the value in the
config (/etc/dirsrv/slapd-INSTANCE/dse.ldif) and start the server again
(ipactl start). 


Thank you.  I looked in this file and the setting wasn't there! But a 
bit more investigation showed that the following update *does* update 
the config in dse.ldif:



dn: cn=config
changetype: modify
replace: nsslapd-allowed-sasl-mechanisms
-


However the doesn't become visible until you restart the server. Until 
then, doing an ldapsearch on cn=config returns the previous value of 
this attribute.


Anyway, all is good now.

Thanks again,

Brian.
-- 
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] really dumb question - is an IPA replica automatically a client as well?

[Alexander Bokovoy]

On to, 22 joulu 2016, Chris Dagdigian wrote:


Working on a messy multi-AD / multi-child-domain environment ...

Just deployed my 1st replica server after the v4.4 upgrade

The IPA replica seems fine and "ipactl status" reports no issues. The 
webUI clearly shows all of the values/config that came over from the 
master


However the replica server does not resolve or enumerate any users in 
any of the trusted AD domains despite sssd.conf and krb5.com being 
similar to the IPA master. No obvious errors or blocked traffic 
although I have not yet enabled debug=10 logging yet.


Before I begin the standard krb5 and sssd troubleshooting I wanted to 
ask the dumb question  first -- does an IPA replica automatically get 
enrolled as a managed client? Should I expect it to recognize the 
remote AD user IDs by default?

It is a managed client for itself. I.e. it only talks to itself.
And the replica is not automatically resolving users and groups from the
trusted AD domains. To do so, it needs to be at least a trust agent.

See
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/Windows_Integration_Guide/index.html#trust-controller-agent
for details.
--
/ Alexander Bokovoy

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

[Freeipa-users] really dumb question - is an IPA replica automatically a client as well?

[Chris Dagdigian]

Working on a messy multi-AD / multi-child-domain environment ...

Just deployed my 1st replica server after the v4.4 upgrade

The IPA replica seems fine and "ipactl status" reports no issues. The 
webUI clearly shows all of the values/config that came over from the master


However the replica server does not resolve or enumerate any users in 
any of the trusted AD domains despite sssd.conf and krb5.com being 
similar to the IPA master. No obvious errors or blocked traffic although 
I have not yet enabled debug=10 logging yet.


Before I begin the standard krb5 and sssd troubleshooting I wanted to 
ask the dumb question  first -- does an IPA replica automatically get 
enrolled as a managed client? Should I expect it to recognize the remote 
AD user IDs by default?


Chris

--
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] NTLM SASL?

[Brian Candler]

On 22/12/2016 12:48, Simo Sorce wrote:

Sorry Brian but we do not support SASL NTLM or SASL SPNEGO/NTLM at this
time, to do that you not only need the mechanism but also a way for that
mechanism to either contact a NT-like Domain Controller or have direct
access to the NT password hashes for any user you want to authenticate,
and none of that is set up by default.
I installed ipa-server-trust-ad, and FreeIPA is storing the ipaNTHash 
attribute. The RADIUS server uses a privileged principal which has 
permissions to read out this attribute, and then it uses that to 
authenticate users.


All works nicely - even password changing for expired passwords over 
MSCHAPv2. However the password-change script currently needs a 
privileged FreeIPA principal (permitted to change anyone's password), 
which also needs to be in passSyncManagersDNs so that the changed 
passwords aren't immediately expired. And unfortunately that means it 
also bypasses FreeIPA's password complexity tests, so I have to 
implement those externally.


Some FreeRADIUS config snippets below, in case anyone's interested.


We are planning to enable the integrated Samba server (which is used for
trusts only at the moment) to provide NTLM services for radius servers,
but it is not ready yet, although you may try to experiment with it.


I could give it a try, although if it's not in 4.4.0 I'd have to set up 
a separate testbed for it.  If the new code includes NTLM password 
changing that would certainly simplify things a lot.


Cheers,

Brian.


# mods-available/ldap

update {
control:NT-Password:= 'ipaNTHash'
control:Tmp-String-9:= 'krbPasswordExpiration'
}

user {
base_dn = "${..base_dn}"
filter = "(uid=%{%{Stripped-User-Name}:-%{User-Name}})"
scope = "one"
# 
https://www.redhat.com/archives/freeipa-users/2011-June/msg00078.html

access_attribute = "nsaccountlock"
access_positive = no
}

group {
membership_attribute = 'memberOf'
name_attributes = 'cn'
cacheable_dn = 'yes'
cacheable_name = 'no'
}

# mods-available/eap

eap {
  mschapv2 {
send_error = yes
  }
}

# mods-available/mschap

local_cpw = "%{exec:/usr/local/sbin/freeipa-passwd 
'%{mschap:User-Name}' '%{MS-CHAP-New-Cleartext-Password}' 
'%{control:NT-Password}'}"


# policy.d

password_expiry {
  # 
https://github.com/FreeRADIUS/freeradius-server/blob/v3.0.x/doc/modules/mschap.rst

  # http://wiki.freeradius.org/config/run_time_variables
  if (:Tmp-String-9 < "%D%H%G00Z") {
update control {
   := '[Ue]'
}
  } else {
update control {
   := '[U]'
}
  }
}


--
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] NTLM SASL?

[Brian Candler]

On 22/12/2016 11:42, Brian Candler wrote:

Now, under cn=config, I see:

nsslapd-allowed-sasl-mechanisms:

(i.e. empty).

I tried changing this to "NTLM" and it accepted the change. 


Aside: I'm also stuck changing it back to what it was :-(

None of these works:

dn: cn=config
changetype: modify
replace: nsslapd-allowed-sasl-mechanisms
nsslapd-allowed-sasl-mechanisms:
-
# Server is unwilling to perform (53)

dn: cn=config
changetype: modify
delete: nsslapd-allowed-sasl-mechanisms
-
# Server is unwilling to perform (53)
#additional info: Deleting attributes is not allowed

dn: cn=config
changetype: modify
replace: nsslapd-allowed-sasl-mechanisms
-
# accepted, but doesn't change the value of the attribute

So for now, I've set "nsslapd-allowed-sasl-mechanisms: GSSAPI EXTERNAL". 
But that means this server is in a different config state to its replica 
peers, which I wonder might bite me one day.


Thanks,

Brian.

--
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] [Freeipa-devel] Certificate expiration consequences

[Florence Blanc-Renaud]

On 12/22/2016 12:22 PM, Pablo Hinojosa wrote:

Hi all,

I have realized my Freeipa webui ssl certificate is near to expire. It
is supposed to auto-renew but it seems I am affected by this bug/defect
 (maybe due to a
missconfigured installation). Here
 you can check current
status with getcert list.

My main priority is to know if LDAP login will work when certificated is
expired. Will I have problems with it? Will login blocked? or it will
work as expected.

Thanks for your support

Cheers,

--

Pablo Hinojosa
System administrator
Kanteron Systems (kanteron.com )




Hi Pablo,

(moving this discussion to freeipa-users).

you probably have other certificates already expired in your deployment 
(auditSigningCert cert-pki-ca, ocspSigningCert cert-pki-ca, 
subsystemCert cert-pki-ca, Server-Cert cert-pki-ca in 
/etc/pki/pki-tomcat/alias and ipaCert in /etc/httpd/alias).


The best thing to do would be to fix this problem first, and the HTTPd 
and LDAP server certificates should be able to renew automatically.


The following document [1] may help you. The general idea is to find 
which certificate expired first, go back in time (by changing the date 
of your server) and manually renew the certificates.


If your LDAP and HTTP certificates are already expired, the 
documentation [2] explains how to start IPA stack and also lists the 
limitations when running with expired certificates.


HTH,
Flo.


[1] https://access.redhat.com/solutions/643753
[2] 
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/expired-certs.html


--
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] backing up and starting over...

[Robert Story]

On Thu, 22 Dec 2016 13:02:18 +0100 Martin wrote:
MB> On 22.12.2016 09:25, Florence Blanc-Renaud wrote:
MB> > On 12/21/2016 10:26 PM, Robert Story wrote:  
MB> >> I'm running a small instance of freeipa on CentOS 7 in our lab, for 
MB> >> about 20
MB> >> machines. Since CentOS 7.3 came out and upgraded from 4.2 to 4.4, things
MB> >> have gotten flaky. e.g. clicking on a user get the spinning 'Working'
MB> >> dialog and can take 3-5 minutes to load the page. But often it will die
MB> >> with 'internal error'.  
MB> 
MB> Could you check in /var/log/httpd/error_log what is it?
MB> Does cli work well? ipa user-find

Yes, cli works, and ldap mostly works, but not always. GUI works
occasionally.

Here's one:


mod_wsgi (pid=6358): Exception occurred processing WSGI script 
'/usr/share/ipa/wsgi.py'.
Traceback (most recent call last):
  File "/usr/share/ipa/wsgi.py", line 49, in application
return api.Backend.wsgi_dispatch(environ, start_response)
  File "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 262, in 
__call__
return self.route(environ, start_response)
  File "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 274, in 
route
return app(environ, start_response)
  File "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 833, in 
__call__
self.create_context(ccache=ipa_ccache_name)
  File "/usr/lib/python2.7/site-packages/ipalib/backend.py", line 123, in 
create_context
self.Backend.ldap2.connect(ccache=ccache)
  File "/usr/lib/python2.7/site-packages/ipalib/backend.py", line 66, in connect
conn = self.create_connection(*args, **kw)
  File "/usr/lib/python2.7/site-packages/ipaserver/plugins/ldap2.py", line 205, 
in create_connection
client_controls=clientctrls)
  File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1108, in 
gssapi_bind
'', auth_tokens, server_controls, client_controls)
  File "/usr/lib64/python2.7/contextlib.py", line 35, in __exit__
self.gen.throw(type, value, traceback)
  File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1007, in 
error_handler
raise errors.DatabaseError(desc=desc, info=info)
DatabaseError: Server is unwilling to perform: Too many failed logins.

and this:

ipa: INFO: 401 Unauthorized: kinit: Clients credentials have been revoked while 
getting initial credentials

and

ipa: ERROR: non-public: IOError: request data read error
Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 358, in 
wsgi_execute
data = read_input(environ)
  File "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 195, in 
read_input
return environ['wsgi.input'].read(length)
IOError: request data read error
rstory@EXAMPLE: None: IOError

and

AH00163: Apache/2.4.6 (CentOS) mod_auth_gssapi/1.4.0 mod_nss/1.0.14 NSS/3.21 
Basic ECC mod_wsgi/3.4 Python/2.7.5 configured -- resuming normal operations
AH00094: Command line: '/usr/sbin/httpd -D FOREGROUND'
ipa: INFO: *** PROCESS START ***
ipa: INFO: *** PROCESS START ***
ipa: INFO: 401 Unauthorized: kinit: Cannot contact any KDC for realm 'EXAMPLE' 
while getting initial credentials
[pid 3714]
ipa: INFO: 401 Unauthorized: kinit: Cannot contact any KDC for realm 'EXAMPLE' 
while getting initial credentials
[pid 3715]
ipa: ERROR: release_ipa_ccache: ccache_name 
(FILE:/var/run/ipa_memcached/krbcc_3714) != KRB5CCNAME environment variable 
(/var/run/httpd/ipa/krbcache/krb5ccache)
ipa: INFO: 401 Unauthorized: Insufficient access: SASL(-1): generic failure: 
GSSAPI Error: Unspecified GSS failure.  Minor code may provide more information 
(Cannot contact any KDC for realm 'EXAMPLE')
mod_wsgi (pid=3714): Exception occurred processing WSGI script 
'/usr/share/ipa/wsgi.py'.
Traceback (most recent call last):
  File "/usr/share/ipa/wsgi.py", line 49, in application
return api.Backend.wsgi_dispatch(environ, start_response)
  File "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 262, in 
__call__
return self.route(environ, start_response)
  File "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 274, in 
route
return app(environ, start_response)
  File "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 978, in 
__call__
self.kinit(user, self.api.env.realm, password, ipa_ccache_name)
  File "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 1010, in 
kinit
raise CCacheError(message=unicode(e))
CCacheError: Major (851968): Unspecified GSS failure.  Minor code may provide 
more information, Minor (2529639068): Cannot contact any KDC for realm 'EXAMPLE'
AH00170: caught SIGWINCH, shutting down gracefully

and

Script timed out before returning headers: wsgi.py, referer: 
https://auth-1.example/ipa/ui/
Script timed out before returning headers: wsgi.py, referer: 
https://auth-1.example/ipa/ui/
Script timed out before returning headers: wsgi.py, referer: 
https://auth-1.example/ipa/ui/

and

SSL Library Error: -12195 Peer does 

Re: [Freeipa-users] Ipa cert automatic renew Failing.

[Florence Blanc-Renaud]

On 12/22/2016 01:15 PM, Lucas Diedrich wrote:

Florence, for some creepy reason the cert from pkidbuser is different
from subsystem certs, and this pkidbuser is outdated now, but i can't
manage one way to re-issue it. I had to change the CA server because of
that, and the Selinux in the old CA Server was disabled, on the new one
is in Permissive mode but doesn't a warning in /var/log/audit/audit.log.

This is the pkidbuser cert: https://paste.fedoraproject.org/511023/24084431/
This is the subsystem cert: https://paste.fedoraproject.org/511025/14824085/
The ca.subsystem.cert matches the pkidbuser cert.

lucasdiedrich.


Hi,

you can try to manually call the post-save command that certmonger 
should have issued after putting the certificate in 
/etc/pki/pki-tomcat/alias:

on the renewal master:
$ sudo /usr/libexec/ipa/certmonger/stop_pkicad
$ sudo /usr/libexec/ipa/certmonger/renew_ca_cert "subsystemCert cert-pki-ca"

Then check the journal log that should display the following if 
everything goes well:

$ sudo journalctl --since today | grep renew_ca_cert
[...] renew_ca_cert[6478]: Updating entry 
uid=CA-ipaserver.domain.com-8443,ou=people,o=ipaca

[...] renew_ca_cert[6478]: Updating entry uid=pkidbuser,ou=people,o=ipaca
[...] renew_ca_cert[6478]: Starting pki_tomcatd
[...] renew_ca_cert[6478]: Started pki_tomcatd

If the operation does not succeed, you will have to check the LDAP 
server logs in /etc/dirsrv/slapd-DOMAIN/access.


HTH,
Flo.


Em qui, 22 de dez de 2016 às 06:54, Florence Blanc-Renaud
> escreveu:

On 12/21/2016 07:52 PM, Lucas Diedrich wrote:
> Hello guys,
>
> I'm having some trouble with, whats is happening with my server is
that
> i'm hiting an old BUG
> (https://bugzilla.redhat.com/show_bug.cgi?id=1033273). Talking to
mbasti
> over irc he oriented me to send this to the email list.
>
> The problem is, i got on CA Master, so because of this problem the CA
> Master certificates couldn't be renewd, so now i promoted another
master
> to be the CA. And the problem still persist.
>
> This is the certs from my new CA
> (https://paste.fedoraproject.org/510617/14823448/),
> this is the certs from my old CA
> (https://paste.fedoraproject.org/510618/44871148/)
> This is the log then i restart pki-tomcat( "CA port 636 Error
> netscape.ldap.LDAPException: Authentication failed (49)")
> This is the log from dirsrv when i restart pki-tomcat
> (https://paste.fedoraproject.org/510614/23446801/)
>
> Basically my CA is not working anymore...
>
> Anyway, i tried lots of thing but couldn't fix this, anyone has
some idea?
>
>
>
Hi,

Pki-tomcat is using the LDAP server as a data store, meaning that it
needs to authenticate to LDAP. In order to do that, pki-tomcat is using
the certificate 'subsystemCert cert-pki-ca' stored in
/etc/pki/pki-tomcat/alias. For the authentication to succeed, the
certificate must be stored in a user entry
(uid=pkidbuser,ou=people,o=ipaca).

Can you check the content of this entry, especially the usercertificate
attribute? It should match the certificate used by pki-tomcat:

$ certutil -L -d /etc/pki/pki-tomcat/alias -n 'subsystemCert
cert-pki-ca' -a
-BEGIN CERTIFICATE-
[...]
-END CERTIFICATE-

$ kinit admin
$ ldapsearch -Y GSSAPI -h `hostname` -p 389 -b
uid=pkidbuser,ou=people,o=ipaca "(objectclass=*)" usercertificate
dn: uid=pkidbuser,ou=people,o=ipaca
usercertificate:: 

The file /etc/pki/pki-tomcat/ca/CS.cfg should also contain this
certificate in the directive ca.subsystem.cert.


A possible cause for the entries not being updated is the bug 1366915
[1] linked to SE linux on RHEL7, or bug 1365188 [2] linked to SE linux
on Fedora 24.

Flo

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1366915
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1365188





--
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] NTLM SASL?

[Simo Sorce]

On Thu, 2016-12-22 at 11:42 +, Brian Candler wrote:
> Question: does FreeIPA (or specifically the 389 directory server) 
> implement the NTLM SASL mechanism?
> 
> It appears not at first attempt:
> 
> # yum install cyrus-sasl-ntlm
> # ldapsearch -Y NTLM
> SASL/NTLM authentication started
> ldap_sasl_interactive_bind_s: Authentication method not supported (7)
>  additional info: sasl mechanism not supported
> 
> Now, under cn=config, I see:
> 
>  nsslapd-allowed-sasl-mechanisms:
> 
> (i.e. empty).
> 
> I tried changing this to "NTLM" and it accepted the change. If I try 
> changing it to "ntlm" I get "Server is unwilling to perform" - which is 
> a good sign, since clearly "NTLM" is valid.
> 
> However even after restarting the server, I still get "sasl mechanism 
> not supported" when I try the bind.
> 
> -=-=-=-
> 
> The reason I'm asking: I'm using FreeRADIUS for MSCHAP authentication, 
> and one of the things MSCHAP supports is a password change feature for 
> expired passwords. FreeRADIUS lets me shell out to an external process 
> to perform the password change:
> 
>  local_cpw = "%{exec:/usr/local/sbin/freeipa-passwd 
> '%{mschap:User-Name}' '%{MS-CHAP-New-Cleartext-Password}' 
> '%{control:NT-Password}'"
> 
> Now, the last argument is the user's *old* NTLM password hash. So 
> ideally I would use this to authenticate to the FreeIPA server to 
> perform the password change - this would avoid the freeipa-passwd script 
> having to have any privileged credentials of its own.
> 
> But the only way I can think of doing that would be via a SASL NTLM bind.

Sorry Brian but we do not support SASL NTLM or SASL SPNEGO/NTLM at this
time, to do that you not only need the mechanism but also a way for that
mechanism to either contact a NT-like Domain Controller or have direct
access to the NT password hashes for any user you want to authenticate,
and none of that is set up by default.

We are planning to enable the integrated Samba server (which is used for
trusts only at the moment) to provide NTLM services for radius servers,
but it is not ready yet, although you may try to experiment with it.

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

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

Re: [Freeipa-users] DNS reverse zone is not managed by this server

[Martin Basti]

On 22.12.2016 10:57, Maciej Drobniuch wrote:

Hi Martin

Appreciate your help!

On Thu, Dec 22, 2016 at 10:48 AM, Martin Basti > wrote:




On 22.12.2016 09:37, Maciej Drobniuch wrote:

Hi Martin

Thank you for reply.

1. The dig is returning proper PTR record. I've added it manually
to the zone and it's working.


I was asking for SOA and zone name, IMO there is nothing secret
about reverse zone name from private address space

what returns this command on server?
python -c 'import netaddr; from dns import resolver; ip =
netaddr.IPAddress("10.0.0.165"); revn = ip.reverse_dns; print
revn; print resolver.zone_for_name(revn)'


# python -c 'import netaddr; from dns import resolver; ip = 
netaddr.IPAddress("10.0.0.165"); revn = ip.reverse_dns; print revn; 
print resolver.zone_for_name(revn)'

165.0.0.10.in-addr.arpa.
in-addr.arpa.


It looks that python-dns failed to find proper zone, what is supposed to 
be authoritative zone for that record in your system?

How do your reverse zones look?





2. The problem exists while adding host entries or A records with
"create reverse" option.

That's why I asked to run dig, the code uses DNS system to
determine zone.


3. If I'll bind a host with ipa-client-install the PTR record
gets created in the reverse zone and it works

Ok

Manually creating the PTR record works fine as well.




4. The resolv.conf file has only the IPA server IP
addres/localhost added.


Have you changed it recently?

Yes, it pointed to outside 8.8.8.8, so the OS did not see the local 
reverse zone.
Now it's pointing to localhost. And I get dig the PTRs. (I've manually 
created the ptr)


# dig -x 10.0.0.165

; <<>> DiG 9.9.4-RedHat-9.9.4-38.el7_3 <<>> -x 10.0.0.165
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35592
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2

;; OPT PSEUDOSECTION:
; E: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;165.0.0.10.in-addr.arpa.INPTR

;; ANSWER SECTION:
165.0.0.10.in-addr.arpa. 1200INPTRprdfrmprb01.cs.int 
.


;; AUTHORITY SECTION:
1.0.10.in-addr.arpa.86400INNSfreeipa1.cs.int .



This authority section looks suspicious, I would expect something like 
0.0.10.in-addr.arpa.


Back to question about your reverse zones.


;; ADDITIONAL SECTION:
freeipa1.cs.int .1200INA10.0.0.200

;; Query time: 3 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: czw gru 22 04:51:23 EST 2016
;; MSG SIZE  rcvd: 124



Martin




Cheers!
M.

On Wed, Dec 21, 2016 at 5:43 PM, Martin Basti > wrote:

Hello all :)


On 20.12.2016 01:33, Maciej Drobniuch wrote:

Hi All!

I get the following message while adding a new hostname.

"The host was added but the DNS update failed with: DNS
reverse zone in-addr.arpa. for IP address 10.0.0.165 is not
managed by this server"


IPA failed to get correct reverse zone, can you try dig -x
10.0.0.165 what will be in SOA answer?

What is the name of reverse zone you have on IPA DNS server?


Martin



The reverse zone is configured and working.
When I am manually adding the PTR record to the reverse zone
- all OK

While adding a new host,  the A record is being created but
the PTR fails with the message above.

Reinstalling centos+IPA worked once but I had to reinstall
again because of problems with kerberos(probably dependencies).

Not sure what is the root cause of the issue.

VERSION: 4.4.0, API_VERSION: 2.213

CENTOS7 Linux freeipa1 3.10.0-229.el7.x86_64 #1 SMP Fri Mar
6 11:36:42 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

Any help appreciated!
-- 
Best regards


Maciej Drobniuch
Network Security Engineer
Collective-sense LLC







-- 
Best regards


Maciej Drobniuch
Network Security Engineer
Collective-sense LLC





--
Best regards

Maciej Drobniuch
Network Security Engineer
2410 Camino Ramon, Suite 129
San Ramon, CA 94583


-- 
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] NTLM SASL?

[Alexander Bokovoy]

On to, 22 joulu 2016, Brian Candler wrote:
Question: does FreeIPA (or specifically the 389 directory server) 
implement the NTLM SASL mechanism?

No, it doesn't. Even if you install cyrus-sasl-ntlm module, 389-ds will
not be able to authenticate:
[22/Dec/2016:14:16:08.920773153 +0200] conn=20 fd=109 slot=109 SSL connection 
from 192.168.5.196 to 192.168.5.196
[22/Dec/2016:14:16:08.926439405 +0200] conn=20 TLS1.2 128-bit AES
[22/Dec/2016:14:16:08.929793115 +0200] conn=20 op=0 BIND 
dn="uid=foobar,cn=users,cn=accounts,dc=split,dc=test" method=sasl version=3 
mech=NTLM
[22/Dec/2016:14:16:08.930458789 +0200] conn=20 op=0 RESULT err=14 tag=97 
nentries=0 etime=0, SASL bind in progress
[22/Dec/2016:14:16:11.841985315 +0200] conn=20 op=1 BIND 
dn="uid=foobar,cn=users,cn=accounts,dc=split,dc=test" method=sasl version=3 
mech=NTLM
[22/Dec/2016:14:16:11.843719821 +0200] conn=20 op=1 RESULT err=49 tag=97 nentries=0 etime=0 - SASL(-14): authorization failure: 
[22/Dec/2016:14:16:11.843761905 +0200] conn=20 op=2 UNBIND

[22/Dec/2016:14:16:11.843771888 +0200] conn=20 op=2 fd=109 closed - U1

The reason for that is due to how SASL support is implemented in 389-ds:
it only supports those SASL mechanisms which don't require direct
access to the userPassword attribute (GSSAPI). Alternatively, if
userPassword contains a clear-text password, those SASL mechanisms that
require access to the clear text password will also work.

FreeIPA does not store clear text password, so no chance for SASL
DIGEST-MD5 or SASL NTLM.


-=-=-=-

The reason I'm asking: I'm using FreeRADIUS for MSCHAP authentication, 
and one of the things MSCHAP supports is a password change feature for 
expired passwords. FreeRADIUS lets me shell out to an external process 
to perform the password change:


   local_cpw = "%{exec:/usr/local/sbin/freeipa-passwd 
'%{mschap:User-Name}' '%{MS-CHAP-New-Cleartext-Password}' 
'%{control:NT-Password}'"


Now, the last argument is the user's *old* NTLM password hash. So 
ideally I would use this to authenticate to the FreeIPA server to 
perform the password change - this would avoid the freeipa-passwd 
script having to have any privileged credentials of its own.


But the only way I can think of doing that would be via a SASL NTLM bind.

Sorry, this is not going to work.

--
/ Alexander Bokovoy

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

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

[Simo Sorce]

On Thu, 2016-12-22 at 08:24 +0100, Petr Spacek wrote:
> On 21.12.2016 21:36, Brian J. Murrell wrote:
> > Some additional information.  I can't seem to use the CLI either. 
> > Perhaps that is expected:
> > 
> > # kinit admin
> > Password for ad...@example.com:
> > 
> > # klist
> > Ticket cache: KEYRING:persistent:0:krb_ccache_3jm4X9m
> > Default principal: ad...@example.com
> > 
> > Valid starting ExpiresService principal
> > 21/12/16 15:29:20  22/12/16 15:29:17  krbtgt/example@example.com
> > 
> > # ipa host-find
> > ipa: ERROR: Insufficient access:  Invalid credentials
> > 
> > When I do that (the ipa host-find) /var/log/krb5kdc.log says:
> > 
> > Dec 21 15:29:28 server.example.com krb5kdc[13548](info): TGS_REQ (6 etypes 
> > {18 17 16 23 25 26}) fd31:aeb1:48df:0:214:d1ff:fe13:45ac: ISSUE: authtime 
> > 1482352160, etypes {rep=18 tkt=18 ses=18}, ad...@example.com for 
> > HTTP/server.example@example.com
> > Dec 21 15:29:28 server.example.com krb5kdc[13548](info): closing down fd 12
> > Dec 21 15:29:28 server.example.com krb5kdc[13548](info): TGS_REQ (6 etypes 
> > {18 17 16 23 25 26}) fd31:aeb1:48df:0:214:d1ff:fe13:45ac: ISSUE: authtime 
> > 1482352160, etypes {rep=18 tkt=18 ses=18}, 
> > HTTP/server.example@example.com for ldap/server.example@example.com
> > Dec 21 15:29:28 server.example.com krb5kdc[13548](info): ... 
> > CONSTRAINED-DELEGATION s4u-client=ad...@example.com
> > Dec 21 15:29:28 server.example.com krb5kdc[13548](info): closing down fd 12
> > 
> > Not sure if that's helpful or not but it's something new (to me) so I
> > thought I would add it to the case.
> > 
> > Most unfortunately I need to access IPA to do some configuration
> > changes so this is getting more unfortunate than just some errors in a
> > log now.  :-(
> 
> Yes, this will be manifestation of the same problem. Interestingly the LDAP
> server should use the ds.keytab file instead of krb5.keytab.
> 
> We need someone from DS team of with deep Kerberos/gssproxy knowledge to look
> into it.
> 
> Simo, Ludwig, how can this happen?

As Martin said, incorrect configuration of DS makes it fall back to use
the default keytab. Either /etc/sysconfig/dirsrv or the DS systemd unit
file must specify the correct keytab in the KRB5_KTNAME environment
variable.

Simo.

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

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

Re: [Freeipa-users] Ipa cert automatic renew Failing.

[Lucas Diedrich]

Florence, for some creepy reason the cert from pkidbuser is different from
subsystem certs, and this pkidbuser is outdated now, but i can't manage one
way to re-issue it. I had to change the CA server because of that, and the
Selinux in the old CA Server was disabled, on the new one is in Permissive
mode but doesn't a warning in /var/log/audit/audit.log.

This is the pkidbuser cert: https://paste.fedoraproject.org/511023/24084431/
This is the subsystem cert: https://paste.fedoraproject.org/511025/14824085/
The ca.subsystem.cert matches the pkidbuser cert.

lucasdiedrich.

Em qui, 22 de dez de 2016 às 06:54, Florence Blanc-Renaud 
escreveu:

> On 12/21/2016 07:52 PM, Lucas Diedrich wrote:
> > Hello guys,
> >
> > I'm having some trouble with, whats is happening with my server is that
> > i'm hiting an old BUG
> > (https://bugzilla.redhat.com/show_bug.cgi?id=1033273). Talking to mbasti
> > over irc he oriented me to send this to the email list.
> >
> > The problem is, i got on CA Master, so because of this problem the CA
> > Master certificates couldn't be renewd, so now i promoted another master
> > to be the CA. And the problem still persist.
> >
> > This is the certs from my new CA
> > (https://paste.fedoraproject.org/510617/14823448/),
> > this is the certs from my old CA
> > (https://paste.fedoraproject.org/510618/44871148/)
> > This is the log then i restart pki-tomcat( "CA port 636 Error
> > netscape.ldap.LDAPException: Authentication failed (49)")
> > This is the log from dirsrv when i restart pki-tomcat
> > (https://paste.fedoraproject.org/510614/23446801/)
> >
> > Basically my CA is not working anymore...
> >
> > Anyway, i tried lots of thing but couldn't fix this, anyone has some
> idea?
> >
> >
> >
> Hi,
>
> Pki-tomcat is using the LDAP server as a data store, meaning that it
> needs to authenticate to LDAP. In order to do that, pki-tomcat is using
> the certificate 'subsystemCert cert-pki-ca' stored in
> /etc/pki/pki-tomcat/alias. For the authentication to succeed, the
> certificate must be stored in a user entry
> (uid=pkidbuser,ou=people,o=ipaca).
>
> Can you check the content of this entry, especially the usercertificate
> attribute? It should match the certificate used by pki-tomcat:
>
> $ certutil -L -d /etc/pki/pki-tomcat/alias -n 'subsystemCert cert-pki-ca'
> -a
> -BEGIN CERTIFICATE-
> [...]
> -END CERTIFICATE-
>
> $ kinit admin
> $ ldapsearch -Y GSSAPI -h `hostname` -p 389 -b
> uid=pkidbuser,ou=people,o=ipaca "(objectclass=*)" usercertificate
> dn: uid=pkidbuser,ou=people,o=ipaca
> usercertificate:: 
>
> The file /etc/pki/pki-tomcat/ca/CS.cfg should also contain this
> certificate in the directive ca.subsystem.cert.
>
>
> A possible cause for the entries not being updated is the bug 1366915
> [1] linked to SE linux on RHEL7, or bug 1365188 [2] linked to SE linux
> on Fedora 24.
>
> Flo
>
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1366915
> [2] https://bugzilla.redhat.com/show_bug.cgi?id=1365188
>
-- 
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] NTLM SASL?

[Brian Candler]

Question: does FreeIPA (or specifically the 389 directory server) 
implement the NTLM SASL mechanism?


It appears not at first attempt:

# yum install cyrus-sasl-ntlm
# ldapsearch -Y NTLM
SASL/NTLM authentication started
ldap_sasl_interactive_bind_s: Authentication method not supported (7)
additional info: sasl mechanism not supported

Now, under cn=config, I see:

nsslapd-allowed-sasl-mechanisms:

(i.e. empty).

I tried changing this to "NTLM" and it accepted the change. If I try 
changing it to "ntlm" I get "Server is unwilling to perform" - which is 
a good sign, since clearly "NTLM" is valid.


However even after restarting the server, I still get "sasl mechanism 
not supported" when I try the bind.


-=-=-=-

The reason I'm asking: I'm using FreeRADIUS for MSCHAP authentication, 
and one of the things MSCHAP supports is a password change feature for 
expired passwords. FreeRADIUS lets me shell out to an external process 
to perform the password change:


local_cpw = "%{exec:/usr/local/sbin/freeipa-passwd 
'%{mschap:User-Name}' '%{MS-CHAP-New-Cleartext-Password}' 
'%{control:NT-Password}'"


Now, the last argument is the user's *old* NTLM password hash. So 
ideally I would use this to authenticate to the FreeIPA server to 
perform the password change - this would avoid the freeipa-passwd script 
having to have any privileged credentials of its own.


But the only way I can think of doing that would be via a SASL NTLM bind.

Regards,

Brian.

--
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] DNS reverse zone is not managed by this server

[Maciej Drobniuch]

Hi Martin

Appreciate your help!

On Thu, Dec 22, 2016 at 10:48 AM, Martin Basti  wrote:

>
>
> On 22.12.2016 09:37, Maciej Drobniuch wrote:
>
> Hi Martin
>
> Thank you for reply.
>
> 1. The dig is returning proper PTR record. I've added it manually to the
> zone and it's working.
>
>
> I was asking for SOA and zone name, IMO there is nothing secret about
> reverse zone name from private address space
>
> what returns this command on server?
> python -c 'import netaddr; from dns import resolver; ip =
> netaddr.IPAddress("10.0.0.165"); revn = ip.reverse_dns; print revn; print
> resolver.zone_for_name(revn)'
>
>
> # python -c 'import netaddr; from dns import resolver; ip =
netaddr.IPAddress("10.0.0.165"); revn = ip.reverse_dns; print revn; print
resolver.zone_for_name(revn)'
165.0.0.10.in-addr.arpa.
in-addr.arpa.


2. The problem exists while adding host entries or A records with "create
> reverse" option.
>
> That's why I asked to run dig, the code uses DNS system to determine zone.
>
> 3. If I'll bind a host with ipa-client-install the PTR record gets created
> in the reverse zone and it works
>
> Ok
>
Manually creating the PTR record works fine as well.

>
>
> 4. The resolv.conf file has only the IPA server IP addres/localhost added.
>
>
> Have you changed it recently?
>
Yes, it pointed to outside 8.8.8.8, so the OS did not see the local reverse
zone.
Now it's pointing to localhost. And I get dig the PTRs. (I've manually
created the ptr)

# dig -x 10.0.0.165

; <<>> DiG 9.9.4-RedHat-9.9.4-38.el7_3 <<>> -x 10.0.0.165
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35592
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;165.0.0.10.in-addr.arpa. IN PTR

;; ANSWER SECTION:
165.0.0.10.in-addr.arpa. 1200 IN PTR prdfrmprb01.cs.int.

;; AUTHORITY SECTION:
1.0.10.in-addr.arpa. 86400 IN NS freeipa1.cs.int.

;; ADDITIONAL SECTION:
freeipa1.cs.int. 1200 IN A 10.0.0.200

;; Query time: 3 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: czw gru 22 04:51:23 EST 2016
;; MSG SIZE  rcvd: 124

>
>
> Martin
>
>
>
> Cheers!
> M.
>
> On Wed, Dec 21, 2016 at 5:43 PM, Martin Basti  wrote:
>
>> Hello all :)
>>
>> On 20.12.2016 01:33, Maciej Drobniuch wrote:
>>
>> Hi All!
>>
>> I get the following message while adding a new hostname.
>>
>> "The host was added but the DNS update failed with: DNS reverse zone
>> in-addr.arpa. for IP address 10.0.0.165 is not managed by this server"
>>
>>
>> IPA failed to get correct reverse zone, can you try dig -x 10.0.0.165
>> what will be in SOA answer?
>>
>> What is the name of reverse zone you have on IPA DNS server?
>>
>>
>> Martin
>>
>>
>> The reverse zone is configured and working.
>> When I am manually adding the PTR record to the reverse zone - all OK
>>
>> While adding a new host,  the A record is being created but the PTR fails
>> with the message above.
>>
>> Reinstalling centos+IPA worked once but I had to reinstall again because
>> of problems with kerberos(probably dependencies).
>>
>> Not sure what is the root cause of the issue.
>>
>> VERSION: 4.4.0, API_VERSION: 2.213
>>
>> CENTOS7 Linux freeipa1 3.10.0-229.el7.x86_64 #1 SMP Fri Mar 6 11:36:42
>> UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
>>
>> Any help appreciated!
>> --
>> Best regards
>>
>> Maciej Drobniuch
>> Network Security Engineer
>> Collective-sense LLC
>>
>>
>>
>>
>
>
> --
> Best regards
>
> Maciej Drobniuch
> Network Security Engineer
> Collective-sense LLC
>
>
>


-- 
Best regards

Maciej Drobniuch
Network Security Engineer
2410 Camino Ramon, Suite 129
San Ramon, CA 94583
-- 
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] DNS reverse zone is not managed by this server

[Martin Basti]

On 22.12.2016 09:37, Maciej Drobniuch wrote:

Hi Martin

Thank you for reply.

1. The dig is returning proper PTR record. I've added it manually to 
the zone and it's working.


I was asking for SOA and zone name, IMO there is nothing secret about 
reverse zone name from private address space


what returns this command on server?
python -c 'import netaddr; from dns import resolver; ip = 
netaddr.IPAddress("10.0.0.165"); revn = ip.reverse_dns; print revn; 
print resolver.zone_for_name(revn)'



2. The problem exists while adding host entries or A records with 
"create reverse" option.

That's why I asked to run dig, the code uses DNS system to determine zone.

3. If I'll bind a host with ipa-client-install the PTR record gets 
created in the reverse zone and it works

Ok


4. The resolv.conf file has only the IPA server IP addres/localhost added.


Have you changed it recently?

Martin



Cheers!
M.

On Wed, Dec 21, 2016 at 5:43 PM, Martin Basti > wrote:


Hello all :)


On 20.12.2016 01:33, Maciej Drobniuch wrote:

Hi All!

I get the following message while adding a new hostname.

"The host was added but the DNS update failed with: DNS reverse
zone in-addr.arpa. for IP address 10.0.0.165 is not managed by
this server"


IPA failed to get correct reverse zone, can you try dig -x
10.0.0.165 what will be in SOA answer?

What is the name of reverse zone you have on IPA DNS server?


Martin



The reverse zone is configured and working.
When I am manually adding the PTR record to the reverse zone - all OK

While adding a new host,  the A record is being created but the
PTR fails with the message above.

Reinstalling centos+IPA worked once but I had to reinstall again
because of problems with kerberos(probably dependencies).

Not sure what is the root cause of the issue.

VERSION: 4.4.0, API_VERSION: 2.213

CENTOS7 Linux freeipa1 3.10.0-229.el7.x86_64 #1 SMP Fri Mar 6
11:36:42 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

Any help appreciated!
-- 
Best regards


Maciej Drobniuch
Network Security Engineer
Collective-sense LLC







--
Best regards

Maciej Drobniuch
Network Security Engineer
Collective-sense LLC


-- 
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] FreeIPA 4.4 - Can't find topology segment, nsunique attribute

[Georgijs Radovs]

Hello, Martin!

Thank you for your help, conflicts resolved.

All is well.

FreeIPA is awesome! )


On 2016.12.22. 11:01, Martin Babinsky wrote:

On 12/22/2016 09:31 AM, Georgijs Radovs wrote:

Hello everyone!

Today, I've updated 2 FreeIPA servers from version 4.2 to version 4.4.

Both of these servers are Masters and CAs, both are replicating between
each other.

But, when I run

*ipa topologysegment-find* to view replication agreements for *domain*
and *ca* suffixes

it returns zero results.

Web UI also does not show any agreements, but when I try to create a
replication agreement between both servers, I get error that agreement
already exists.

Also, when viewing directory using ldap browser, I found these 
containers:


DN:
cn=ca+nsuniqueid=7252d047-c76611e6-a1fcaefe-5d4473a3,cn=topology,cn=ipa,cn=etc,dc=example,dc=com 




DN:
cn=domain+nsuniqueid=7252d000-c76611e6-a1fcaefe-5d4473a3,cn=topology,cn=ipa,cn=etc,dc=example,dc=com 




Both of them contain topology segments, which I'm trying to create, but
they do not show up anywhere.

How do I remove nsuniqueid attribute or delete those containers?



Hi Georgijs,

these entries come from replication conflicts, please see the 
following guide on how to solve them:


https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html 



Also as a side note, such conflicts may come from upgrading IPA 
masters at once which is not recommended. Make sure that when you 
upgrade the topology you only upgrade one master at time.





--


--
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] DNS reverse zone is not managed by this server

[Maciej Drobniuch]

Hi Martin

Thank you for reply.

1. The dig is returning proper PTR record. I've added it manually to the
zone and it's working.
2. The problem exists while adding host entries or A records with "create
reverse" option.
3. If I'll bind a host with ipa-client-install the PTR record gets created
in the reverse zone and it works
4. The resolv.conf file has only the IPA server IP addres/localhost added.

Cheers!
M.

On Wed, Dec 21, 2016 at 5:43 PM, Martin Basti  wrote:

> Hello all :)
>
> On 20.12.2016 01:33, Maciej Drobniuch wrote:
>
> Hi All!
>
> I get the following message while adding a new hostname.
>
> "The host was added but the DNS update failed with: DNS reverse zone
> in-addr.arpa. for IP address 10.0.0.165 is not managed by this server"
>
>
> IPA failed to get correct reverse zone, can you try dig -x 10.0.0.165 what
> will be in SOA answer?
>
> What is the name of reverse zone you have on IPA DNS server?
>
>
> Martin
>
>
> The reverse zone is configured and working.
> When I am manually adding the PTR record to the reverse zone - all OK
>
> While adding a new host,  the A record is being created but the PTR fails
> with the message above.
>
> Reinstalling centos+IPA worked once but I had to reinstall again because
> of problems with kerberos(probably dependencies).
>
> Not sure what is the root cause of the issue.
>
> VERSION: 4.4.0, API_VERSION: 2.213
>
> CENTOS7 Linux freeipa1 3.10.0-229.el7.x86_64 #1 SMP Fri Mar 6 11:36:42 UTC
> 2015 x86_64 x86_64 x86_64 GNU/Linux
>
> Any help appreciated!
> --
> Best regards
>
> Maciej Drobniuch
> Network Security Engineer
> Collective-sense LLC
>
>
>
>


-- 
Best regards

Maciej Drobniuch
Network Security Engineer
Collective-sense LLC
-- 
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] FreeIPA 4.4 - Can't find topology segment, nsunique attribute

[Ludwig Krispenz]

Hi
On 12/22/2016 09:31 AM, Georgijs Radovs wrote:

Hello everyone!

Today, I've updated 2 FreeIPA servers from version 4.2 to version 4.4.

Both of these servers are Masters and CAs, both are replicating 
between each other.


But, when I run

*ipa topologysegment-find* to view replication agreements for *domain* 
and *ca* suffixes


it returns zero results.

Web UI also does not show any agreements, but when I try to create a 
replication agreement between both servers, I get error that agreement 
already exists.


Also, when viewing directory using ldap browser, I found these 
containers:


DN: 
cn=ca+nsuniqueid=7252d047-c76611e6-a1fcaefe-5d4473a3,cn=topology,cn=ipa,cn=etc,dc=example,dc=com


DN: 
cn=domain+nsuniqueid=7252d000-c76611e6-a1fcaefe-5d4473a3,cn=topology,cn=ipa,cn=etc,dc=example,dc=com


Both of them contain topology segments, which I'm trying to create, 
but they do not show up anywhere.
this is unfortunatly the result of raising the domainlevel and creating 
segments while replication conflict entries exist.
In the next update we will prevent this by checking for conflicts before 
raising domainlevel.


How do I remove nsuniqueid attribute or delete those containers?
not so simple, I'll try to sketch the options for cn=domain, the 
procedure for cn=ca is then the same.


So lets say you have:
cn=domain,cn=topology,cn=ipa,cn=etc,dc=example,dc=com
cn=domain+nsuniqueid=7252d000-c76611e6-a1fcaefe-5d4473a3,cn=topology,cn=ipa,cn=etc,dc=example,dc=com
cn=segment1,cn=domain+nsuniqueid=7252d000-c76611e6-a1fcaefe-5d4473a3,cn=topology,cn=ipa,cn=etc,dc=example,dc=com

and what you want is:
cn=domain,cn=topology,cn=ipa,cn=etc,dc=example,dc=com
cn=segment1,cn=domain,cn=topology,cn=ipa,cn=etc,dc=example,dc=com

unfortunately the segment is below the conflict entry. so you have two 
options:
- remove the "normal" entry and then rename the conflict entry, this 
will leave child parent relationship and the dn of the segment should be 
adjusted automatically


- move the segment to the "normal" entry (it could be rejected by the 
topology plugin, so you would have to disable it temporariliy on the 
server where you run this)

and then remove the "conflict" entry

--
Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric 
Shander

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

[Martin Babinsky]

On 12/21/2016 07:22 PM, Brian J. Murrell wrote:

On Wed, 2016-12-21 at 17:50 +0100, Petr Spacek wrote:

Okay, I believe that this is the problem:

On 21.12.2016 15:53, Brian J. Murrell wrote:

[21/Dec/2016:09:39:12.003351818 -0500] conn=77028 fd=107 slot=107
connection from local to /var/run/slapd-EXAMPLE.COM.socket


...

[21/Dec/2016:09:39:12.064476101 -0500] conn=77028 op=0 BIND dn=""
method=sasl version=3 mech=GSSAPI
[21/Dec/2016:09:39:12.067486416 -0500] conn=77028 op=0 RESULT
err=49 tag=97 nentries=0 etime=0 - SASL(-1): generic failure:
GSSAPI Error: Unspecified GSS failure.  Minor code may provide more
information (Permission denied)
[21/Dec/2016:09:39:12.192506861 -0500] conn=77028 op=1 UNBIND
[21/Dec/2016:09:39:12.192549740 -0500] conn=77028 op=1 fd=107
closed - U1


I have no idea why it is returning Permission denied.

Is it reproducible when you run this?
$ kinit -kt /etc/ipa/dnssec/ipa-dnskeysyncd.keytab
ipa-dnskeysyncd/server.example.com
$ ldapsearch -Y GSSAPI -H /var/run/slapd-EXAMPLE.COM.socket
?


# klist
Ticket cache: KEYRING:persistent:0:0
Default principal: ipa-dnskeysyncd/server.example@example.com

Valid starting ExpiresService principal
21/12/16 13:05:16  22/12/16 13:02:12  ldap/server.example@example.com
21/12/16 13:02:12  22/12/16 13:02:12  krbtgt/example@example.com

# ldapsearch -Y GSSAPI -H ldapi://%2Fvar%2Frun%2Fslapd-EXAMPLE.COM.socket
SASL/GSSAPI authentication started
ldap_sasl_interactive_bind_s: Invalid credentials (49)



We need to find out why it is blowing up on GSSAPI negotiation.

Wild guess is that /etc/dirsrv/ds.keytab could have wrong
permissions. It
should have
-rw---. 1 dirsrv dirsrv unconfined_u:object_r:dirsrv_config_t:s0


# ls -lZ /etc/dirsrv/ds.keytab
-rw---. dirsrv dirsrv system_u:object_r:dirsrv_config_t:s0 
/etc/dirsrv/ds.keytab


If you manage to reproduce it, you can attach strace to the running
dirsrv


By that I assume you mean the ns-slapd.

The strace (minus poll/select/futex noise) is attached.




process and see what call is failing (if it is a system call)...

Perhaps this one:

[pid 13449] open("/etc/krb5.keytab", O_RDONLY) = -1 EACCES (Permission denied)

# ls -lZ /etc/krb5.keytab
-rw---. root root system_u:object_r:krb5_keytab_t:s0 /etc/krb5.keytab

But looking into the backup of this system, even a week and a month
ago, that file had the same permissions/ownership.  And changing it to
644 temporarily doesn't fix the "ldap_sasl_interactive_bind_s: Invalid
credentials (49)" from ldapsearch.

Cheers,
b.





Hi Brian,

DS should use /etc/sysconfig/dirsrv to set its KRB5_KTNAME env variable 
to /etc/dirsrv/ds.keytab. I guess that it cannot get this info from the 
file, thus it falls back to Kerberos library default which is 
/etc/krb5.keytab. That obviosuly fails because it is accesible only to 
root and contains keys only to host/, nfs/, and cifs/ (if you have 
Samba) principals.


Can you please verify that /etc/sysconfig/dirsrv file exists and that it 
contains the following lines?:


KRB5_CCNAME=/tmp/krb5cc_389
KRB5_KTNAME=/etc/dirsrv/ds.keytab


If not, please add this line to the file, restart dirsrv and try IPA 
commands again.


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

Re: [Freeipa-users] FreeIPA 4.4 - Can't find topology segment, nsunique attribute

[Martin Babinsky]

On 12/22/2016 09:31 AM, Georgijs Radovs wrote:

Hello everyone!

Today, I've updated 2 FreeIPA servers from version 4.2 to version 4.4.

Both of these servers are Masters and CAs, both are replicating between
each other.

But, when I run

*ipa topologysegment-find* to view replication agreements for *domain*
and *ca* suffixes

it returns zero results.

Web UI also does not show any agreements, but when I try to create a
replication agreement between both servers, I get error that agreement
already exists.

Also, when viewing directory using ldap browser, I found these containers:

DN:
cn=ca+nsuniqueid=7252d047-c76611e6-a1fcaefe-5d4473a3,cn=topology,cn=ipa,cn=etc,dc=example,dc=com


DN:
cn=domain+nsuniqueid=7252d000-c76611e6-a1fcaefe-5d4473a3,cn=topology,cn=ipa,cn=etc,dc=example,dc=com


Both of them contain topology segments, which I'm trying to create, but
they do not show up anywhere.

How do I remove nsuniqueid attribute or delete those containers?



Hi Georgijs,

these entries come from replication conflicts, please see the following 
guide on how to solve them:


https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html

Also as a side note, such conflicts may come from upgrading IPA masters 
at once which is not recommended. Make sure that when you upgrade the 
topology you only upgrade one master at time.


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

Re: [Freeipa-users] Ipa cert automatic renew Failing.

[Florence Blanc-Renaud]

On 12/21/2016 07:52 PM, Lucas Diedrich wrote:

Hello guys,

I'm having some trouble with, whats is happening with my server is that
i'm hiting an old BUG
(https://bugzilla.redhat.com/show_bug.cgi?id=1033273). Talking to mbasti
over irc he oriented me to send this to the email list.

The problem is, i got on CA Master, so because of this problem the CA
Master certificates couldn't be renewd, so now i promoted another master
to be the CA. And the problem still persist.

This is the certs from my new CA
(https://paste.fedoraproject.org/510617/14823448/),
this is the certs from my old CA
(https://paste.fedoraproject.org/510618/44871148/)
This is the log then i restart pki-tomcat( "CA port 636 Error
netscape.ldap.LDAPException: Authentication failed (49)")
This is the log from dirsrv when i restart pki-tomcat
(https://paste.fedoraproject.org/510614/23446801/)

Basically my CA is not working anymore...

Anyway, i tried lots of thing but couldn't fix this, anyone has some idea?




Hi,

Pki-tomcat is using the LDAP server as a data store, meaning that it 
needs to authenticate to LDAP. In order to do that, pki-tomcat is using 
the certificate 'subsystemCert cert-pki-ca' stored in 
/etc/pki/pki-tomcat/alias. For the authentication to succeed, the 
certificate must be stored in a user entry 
(uid=pkidbuser,ou=people,o=ipaca).


Can you check the content of this entry, especially the usercertificate 
attribute? It should match the certificate used by pki-tomcat:


$ certutil -L -d /etc/pki/pki-tomcat/alias -n 'subsystemCert cert-pki-ca' -a
-BEGIN CERTIFICATE-
[...]
-END CERTIFICATE-

$ kinit admin
$ ldapsearch -Y GSSAPI -h `hostname` -p 389 -b 
uid=pkidbuser,ou=people,o=ipaca "(objectclass=*)" usercertificate

dn: uid=pkidbuser,ou=people,o=ipaca
usercertificate:: 

The file /etc/pki/pki-tomcat/ca/CS.cfg should also contain this 
certificate in the directive ca.subsystem.cert.



A possible cause for the entries not being updated is the bug 1366915 
[1] linked to SE linux on RHEL7, or bug 1365188 [2] linked to SE linux 
on Fedora 24.


Flo

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1366915
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1365188

--
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] FreeIPA 4.4 - Can't find topology segment, nsunique attribute

[Georgijs Radovs]

Hello everyone!

Today, I've updated 2 FreeIPA servers from version 4.2 to version 4.4.

Both of these servers are Masters and CAs, both are replicating between 
each other.


But, when I run

*ipa topologysegment-find* to view replication agreements for *domain* 
and *ca* suffixes


it returns zero results.

Web UI also does not show any agreements, but when I try to create a 
replication agreement between both servers, I get error that agreement 
already exists.


Also, when viewing directory using ldap browser, I found these containers:

DN: 
cn=ca+nsuniqueid=7252d047-c76611e6-a1fcaefe-5d4473a3,cn=topology,cn=ipa,cn=etc,dc=example,dc=com


DN: 
cn=domain+nsuniqueid=7252d000-c76611e6-a1fcaefe-5d4473a3,cn=topology,cn=ipa,cn=etc,dc=example,dc=com


Both of them contain topology segments, which I'm trying to create, but 
they do not show up anywhere.


How do I remove nsuniqueid attribute or delete those containers?

--


--
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] backing up and starting over...

[Florence Blanc-Renaud]

On 12/21/2016 10:26 PM, Robert Story wrote:

I'm running a small instance of freeipa on CentOS 7 in our lab, for about 20
machines. Since CentOS 7.3 came out and upgraded from 4.2 to 4.4, things
have gotten flaky. e.g. clicking on a user get the spinning 'Working'
dialog and can take 3-5 minutes to load the page. But often it will die
with 'internal error'.

Is there a way to back up data so that I can re-install 4.4 and restore the
data? Specifically users+uids/groups+gids, HBAC and sudo rules?


Robert




Hi,

you can find more information about backup and restore procedure in this 
guide [1]. But, as stated in the documentation, the safest method would 
rather be to install a replica [2].


HTH,
Flo

[1] 
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/backup-restore.html
[2] 
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/install-replica.html


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