Hi Flo,
That's a good point! I checked the dirsrv certificate and confirmed
valid(good until later next year).
Since I had no problem to enroll another new IPA client(RHEL7 box
instead of RHEL6) to such replica server, I thought it might not be a
server end issue. However, when I tried to restart the DIRSRV service on
the replica server, I found these messages in the log
file /var/log/dirsrv/slapd-IPA-EXAMPLE-COM/errors:
[15/Dec/2016:13:38:15.891301246 -0500] 389-Directory/1.3.5.10
<http://1.3.5.10> B2016.257.1817 starting up
[15/Dec/2016:13:38:15.911777373 -0500] default_mr_indexer_create:
warning - plugin [caseIgnoreIA5Match] does not handle caseExactIA5Match
[15/Dec/2016:13:38:15.926320306 -0500] WARNING: changelog: entry cache
size 2097152 B is less than db size 5488640 B; We recommend to increase
the entry cache size nsslapd-cachememsize.
[15/Dec/2016:13:38:16.132155534 -0500] schema-compat-plugin - scheduled
schema-compat-plugin tree scan in about 5 seconds after the server startup!
[15/Dec/2016:13:38:16.167896279 -0500] NSACLPlugin - The ACL target
cn=dns,dc=ipa,dc=example,dc=com does not exist
[15/Dec/2016:13:38:16.173317345 -0500] NSACLPlugin - The ACL target
cn=dns,dc=ipa,dc=example,dc=com does not exist
[15/Dec/2016:13:38:16.178354342 -0500] NSACLPlugin - The ACL target
cn=keys,cn=sec,cn=dns,dc=ipa,dc=example,dc=com does not exist
[15/Dec/2016:13:38:16.183579322 -0500] NSACLPlugin - The ACL target
cn=dns,dc=ipa,dc=example,dc=com does not exist
[15/Dec/2016:13:38:16.188786976 -0500] NSACLPlugin - The ACL target
cn=dns,dc=ipa,dc=example,dc=com does not exist
[15/Dec/2016:13:38:16.193275650 -0500] NSACLPlugin - The ACL target
cn=groups,cn=compat,dc=ipa,dc=example,dc=com does not exist
[15/Dec/2016:13:38:16.197580407 -0500] NSACLPlugin - The ACL target
cn=computers,cn=compat,dc=ipa,dc=example,dc=com does not exist
[15/Dec/2016:13:38:16.201863256 -0500] NSACLPlugin - The ACL target
cn=ng,cn=compat,dc=ipa,dc=example,dc=com does not exist
[15/Dec/2016:13:38:16.206318629 -0500] NSACLPlugin - The ACL target
ou=sudoers,dc=ipa,dc=example,dc=com does not exist
[15/Dec/2016:13:38:16.211559100 -0500] NSACLPlugin - The ACL target
cn=users,cn=compat,dc=ipa,dc=example,dc=com does not exist
[15/Dec/2016:13:38:16.216146819 -0500] NSACLPlugin - The ACL target
cn=vaults,cn=kra,dc=ipa,dc=example,dc=com does not exist
[15/Dec/2016:13:38:16.220786596 -0500] NSACLPlugin - The ACL target
cn=vaults,cn=kra,dc=ipa,dc=example,dc=com does not exist
[15/Dec/2016:13:38:16.225594942 -0500] NSACLPlugin - The ACL target
cn=vaults,cn=kra,dc=ipa,dc=example,dc=com does not exist
[15/Dec/2016:13:38:16.229986749 -0500] NSACLPlugin - The ACL target
cn=vaults,cn=kra,dc=ipa,dc=example,dc=com does not exist
[15/Dec/2016:13:38:16.234518367 -0500] NSACLPlugin - The ACL target
cn=vaults,cn=kra,dc=ipa,dc=example,dc=com does not exist
[15/Dec/2016:13:38:16.238763121 -0500] NSACLPlugin - The ACL target
cn=vaults,cn=kra,dc=ipa,dc=example,dc=com does not exist
[15/Dec/2016:13:38:16.243031116 -0500] NSACLPlugin - The ACL target
cn=vaults,cn=kra,dc=ipa,dc=example,dc=com does not exist
[15/Dec/2016:13:38:16.247507984 -0500] NSACLPlugin - The ACL target
cn=vaults,cn=kra,dc=ipa,dc=example,dc=com does not exist
[15/Dec/2016:13:38:16.252327210 -0500] NSACLPlugin - The ACL target
cn=vaults,cn=kra,dc=ipa,dc=example,dc=com does not exist
[15/Dec/2016:13:38:16.259046910 -0500] NSACLPlugin - The ACL target
cn=vaults,cn=kra,dc=ipa,dc=example,dc=com does not exist
[15/Dec/2016:13:38:16.263856581 -0500] NSACLPlugin - The ACL target
cn=vaults,cn=kra,dc=ipa,dc=example,dc=com does not exist
[15/Dec/2016:13:38:16.269301704 -0500] NSACLPlugin - The ACL target
cn=ad,cn=etc,dc=ipa,dc=example,dc=com does not exist
[15/Dec/2016:13:38:16.283511408 -0500] NSACLPlugin - The ACL target
cn=casigningcert
cert-pki-ca,cn=ca_renewal,cn=ipa,cn=etc,dc=ipa,dc=example,dc=com does
not exist
[15/Dec/2016:13:38:16.287853825 -0500] NSACLPlugin - The ACL target
cn=casigningcert
cert-pki-ca,cn=ca_renewal,cn=ipa,cn=etc,dc=ipa,dc=example,dc=com does
not exist
[15/Dec/2016:13:38:16.395872649 -0500] NSACLPlugin - The ACL target
cn=automember rebuild membership,cn=tasks,cn=config does not exist
[15/Dec/2016:13:38:16.405404114 -0500] Skipping CoS Definition
cn=Password Policy,cn=accounts,dc=ipa,dc=example,dc=com--no CoS
Templates found, which should be added before the CoS Definition.
[15/Dec/2016:13:38:16.463117873 -0500] set_krb5_creds - Could not get
initial credentials for principal
[ldap/ipaprd2.example....@ipa.example.com
<mailto:ipaprd2.example....@ipa.example.com>] in keytab
[FILE:/etc/dirsrv/ds.keytab]: -1765328324 (Generic error (see e-text))
[15/Dec/2016:13:38:16.471256279 -0500] schema-compat-plugin -
schema-compat-plugin tree scan will start in about 5 seconds!
[15/Dec/2016:13:38:16.479213976 -0500] slapd started. Listening on All
Interfaces port 389 for LDAP requests
[15/Dec/2016:13:38:16.483683353 -0500] Listening on
/var/run/slapd-IPA-EXAMPLE-COM.socket for LDAPI requests
[15/Dec/2016:13:38:21.634319974 -0500] schema-compat-plugin - warning:
no entries set up under ou=sudoers,dc=ipa,dc=example,dc=com
[15/Dec/2016:13:38:21.639855161 -0500] schema-compat-plugin - warning:
no entries set up under cn=ng, cn=compat,dc=ipa,dc=example,dc=com
[15/Dec/2016:13:38:21.653406463 -0500] schema-compat-plugin - no RDN for
cn=cdm_users,cn=groups,cn=accounts,dc=ipa,dc=example,dc=com, unsetting
domain/map/id
"cn=compat,dc=ipa,dc=example,dc=com"/"cn=groups"/("cn=cdm_users,cn=groups,cn=accounts,dc=ipa,dc=example,dc=com")
[15/Dec/2016:13:38:21.714897614 -0500] schema-compat-plugin - warning:
no entries set up under cn=computers, cn=compat,dc=ipa,dc=example,dc=com
[15/Dec/2016:13:38:21.719933118 -0500] schema-compat-plugin - Finished
plugin initialization.
[15/Dec/2016:13:38:36.591969481 -0500] ipa-topology-plugin -
ipa_topo_util_get_replica_conf: server configuration missing
[15/Dec/2016:13:38:36.598683009 -0500] ipa-topology-plugin -
ipa_topo_util_get_replica_conf: cannot create replica
Any idea?
BTW, everything ran well on IPA 4.2(server installation and client
installation), as you once assisted me couple months ago, until we set
up a new IPA environment with RHEL7.3 instead of RHEL7.2, then the IPA
version changed from 4.2 to 4.4. Last time you guided me about the
change since IPA 4.3, for the newly introduced domain level concept, and
the way how the replica should be installed was changed too... Thanks again!
On Thu, Dec 15, 2016 at 10:52 AM, Florence Blanc-Renaud <f...@redhat.com
<mailto:f...@redhat.com>> wrote:
On 12/14/2016 07:49 PM, beeth beeth wrote:
Hi Flo,
Thanks for the great hint! I reran the ipa-client-install on the
rhel6
box(ipadev6), and monitored the access log file you mentioned on the
replica:
# ipa-client-install --domain=ipa.example.com
<http://ipa.example.com> <http://ipa.example.com>
--server=ipaprd2.example.com <http://ipaprd2.example.com>
<http://ipaprd2.example.com>
--hostname=ipadev6.example.com <http://ipadev6.example.com>
<http://ipadev6.example.com> -d
( ipaprd2 = primary IPA server on RHEL7; ipadev6 = replica on
RHEL6 )
AFTER about 3 seconds, I saw these on the replica ipaprd2:
[14/Dec/2016:13:11:41.071421132 -0500] conn=1040 fd=73 slot=73
connection from <IP of ipadev6> to <IP of ipaprd2>
[14/Dec/2016:13:11:41.071880026 -0500] conn=1040 op=0 EXT
oid="1.3.6.1.4.1.1466.20037"
[14/Dec/2016:13:11:41.071964217 -0500] conn=1040 op=0 RESULT err=2
tag=120 nentries=0 etime=0
[14/Dec/2016:13:11:41.073275674 -0500] conn=1040 op=1 UNBIND
[14/Dec/2016:13:11:41.073307101 -0500] conn=1040 op=1 fd=73
closed - U1
[14/Dec/2016:13:11:41.074782496 -0500] conn=1041 fd=73 slot=73
connection from <IP of ipadev6> to <IP of ipaprd2>
[14/Dec/2016:13:11:41.074985233 -0500] conn=1041 op=0 EXT
oid="1.3.6.1.4.1.1466.20037"
[14/Dec/2016:13:11:41.075022849 -0500] conn=1041 op=0 RESULT err=2
tag=120 nentries=0 etime=0
[14/Dec/2016:13:11:41.075448887 -0500] conn=1041 op=1 UNBIND
[14/Dec/2016:13:11:41.075460964 -0500] conn=1041 op=1 fd=73
closed - U1
[14/Dec/2016:13:11:49.006146850 -0500] conn=1029 op=8 UNBIND
[14/Dec/2016:13:11:49.006181982 -0500] conn=1029 op=8 fd=66
closed - U1
So I did see the err=2, and oid="1.3.6.1.4.1.1466.20037", I
checked the
oid and got:
1.3.6.1.4.1.1466.20037: StartTLS Request (RFC 4511)
It looked to be related with TLS... pease advise. Thanks!
Hi,
when the replica got installed, the installer must have configured
the directory server for SSL and start TLS. I tend to suspect an
expired certificate issue rather than a misconfiguration. Could you
please check that dirsrv certificate is still valid?
$ certutil -L -d /etc/dirsrv/slapd-DOMAIN-COM/ -n Server-Cert |grep Not
Not Before: Wed Dec 14 16:56:02 2016
Not After : Sat Dec 15 16:56:02 2018
If the certificate is still valid, you may want to read 389-ds
How-To to make sure that SSL is properly setup:
http://directory.fedoraproject.org/docs/389ds/howto/howto-ssl.html#deploy-the-settings
<http://directory.fedoraproject.org/docs/389ds/howto/howto-ssl.html#deploy-the-settings>
Flo.
On Wed, Dec 14, 2016 at 7:57 AM, Florence Blanc-Renaud
<f...@redhat.com <mailto:f...@redhat.com>
<mailto:f...@redhat.com <mailto:f...@redhat.com>>> wrote:
On 12/14/2016 01:08 PM, beeth beeth wrote:
Thanks David. I installed both the master and replica IPA
servers with
third-party certificates(Verisign), but I doubt that
could be
the issue,
because I had no problem to run the same ipa-client-install
command on a
RHEL7 machine(of course, the --hostname used a different
hostname of the
server). And I had no problem to run the ipa-client-install
command with
--server=<master> on such RHEL6 machine. So what could
cause the
LDAP
communication failed during the client enrollment with the
replica? Is
there a way I can troubleshoot this by running some
commands? So
far I
did telnet to check the open ports, as well as run the
ldapsearch
towards the replica. Thanks again!
On Tue, Dec 13, 2016 at 8:46 AM, David Kupka
<dku...@redhat.com <mailto:dku...@redhat.com>
<mailto:dku...@redhat.com <mailto:dku...@redhat.com>>
<mailto:dku...@redhat.com <mailto:dku...@redhat.com>
<mailto:dku...@redhat.com <mailto:dku...@redhat.com>>>> wrote:
On 13/12/16 05:44, beeth beeth wrote:
I have two IPA servers ipaprd1.example.com
<http://ipaprd1.example.com>
<http://ipaprd1.example.com>
<http://ipaprd1.example.com> and
ipaprd2.example.com <http://ipaprd2.example.com>
<http://ipaprd2.example.com>
<http://ipaprd2.example.com>, running
ipa 4.4 on RHEL7. When I tried to
install/configure the
client
on a RHEL6
system(called ipadev6), I had issue when I tried to
enroll it
with the
replica(ipaprd2), while no issue with the
primary(ipaprd1):
# ipa-client-install --domain=ipa.example.com
<http://ipa.example.com>
<http://ipa.example.com>
<http://ipa.example.com>
--server=ipaprd1.example.com <http://ipaprd1.example.com>
<http://ipaprd1.example.com>
<http://ipaprd1.example.com>
--server=ipaprd2.example.com
<http://ipaprd2.example.com>
<http://ipaprd2.example.com> <http://ipaprd2.example.com>
--hostname=ipadev6.example.com
<http://ipadev6.example.com>
<http://ipadev6.example.com> <http://ipadev6.example.com>
LDAP Error: Protocol error: unsupported extended
operation
Autodiscovery of servers for failover cannot
work with this
configuration.
If you proceed with the installation, services
will be
configured to always
access the discovered server for all operations
and will not
fail over to
other servers in case of failure.
Proceed with fixed values and no DNS discovery? [no]
Then I tried to run ipa-client-install to enroll
with the
replica(ipaprd2),
with debug mode, I got this:
# ipa-client-install --domain=ipa.example.com
<http://ipa.example.com>
<http://ipa.example.com>
<http://ipa.example.com>
--server=ipaprd2.example.com <http://ipaprd2.example.com>
<http://ipaprd2.example.com>
<http://ipaprd2.example.com>
--hostname=ipadev6.example.com
<http://ipadev6.example.com>
<http://ipadev6.example.com> <http://ipadev6.example.com> -d
/usr/sbin/ipa-client-install was invoked with
options:
{'domain': '
ipa.example.com <http://ipa.example.com>
<http://ipa.example.com>
<http://ipa.example.com>', 'force': False,
'realm_name': None,
'krb5_offline_passwords': True, 'primary': False,
'mkhomedir':
False,
'create_sshfp': True, 'conf_sshd': True,
'conf_ntp': True,
'on_master':
False, 'ntp_server': None, 'nisdomain': None,
'no_nisdomain': False,
'principal': None, 'hostname':
'ipadev6.example.com <http://ipadev6.example.com>
<http://ipadev6.example.com>
<http://ipadev6.example.com>', 'no_ac': False,
'unattended': None, 'sssd': True, 'trust_sshfp':
False,
'kinit_attempts':
5, 'dns_updates': False, 'conf_sudo': True,
'conf_ssh':
True,
'force_join':
False, 'ca_cert_file': None, 'server':
['ipaprd2.example.com <http://ipaprd2.example.com>
<http://ipaprd2.example.com>
<http://ipaprd2.example.com>'],
'prompt_password': False, 'permit': False,
'debug': True,
'preserve_sssd':
False, 'uninstall': False}
missing options might be asked for interactively
later
Loading Index file from
'/var/lib/ipa-client/sysrestore/sysrestore.index'
Loading StateFile from
'/var/lib/ipa-client/sysrestore/sysrestore.state'
[IPA Discovery]
Starting IPA discovery with
domain=ipa.example.com <http://ipa.example.com>
<http://ipa.example.com>
<http://ipa.example.com>, servers=['
ipaprd2.example.com <http://ipaprd2.example.com>
<http://ipaprd2.example.com>
<http://ipaprd2.example.com>'],
hostname=ipadev6.example.com
<http://ipadev6.example.com>
<http://ipadev6.example.com> <http://ipadev6.example.com>
Server and domain forced
[Kerberos realm search]
Search DNS for TXT record of
_kerberos.ipa.example.com <http://kerberos.ipa.example.com>
<http://kerberos.ipa.example.com
<http://kerberos.ipa.example.com>>
<http://kerberos.ipa.example.com
<http://kerberos.ipa.example.com>
<http://kerberos.ipa.example.com
<http://kerberos.ipa.example.com>>>.
No DNS record found
Search DNS for SRV record of
_kerberos._udp.ipa.example.com
<http://udp.ipa.example.com> <http://udp.ipa.example.com>
<http://udp.ipa.example.com>.
No DNS record found
SRV record for KDC not found! Domain:
ipa.example.com <http://ipa.example.com>
<http://ipa.example.com>
<http://ipa.example.com>
[LDAP server check]
Verifying that ipaprd2.example.com
<http://ipaprd2.example.com>
<http://ipaprd2.example.com> <http://ipaprd2.example.com>
(realm None) is an IPA server
Init LDAP connection with:
ldap://ipaprd2.example.com:389
<http://ipaprd2.example.com:389> <http://ipaprd2.example.com:389
<http://ipaprd2.example.com:389>>
<http://ipaprd2.example.com:389
<http://ipaprd2.example.com:389>
<http://ipaprd2.example.com:389
<http://ipaprd2.example.com:389>>>
LDAP Error: Protocol error: unsupported extended
operation
Discovery result: UNKNOWN_ERROR; server=None,
domain=ipa.example.com <http://ipa.example.com>
<http://ipa.example.com>
<http://ipa.example.com>,
kdc=None, basedn=None
Validated servers:
will use discovered domain: ipa.example.com
<http://ipa.example.com>
<http://ipa.example.com> <http://ipa.example.com>
IPA Server not found
[IPA Discovery]
Starting IPA discovery with
domain=ipa.example.com <http://ipa.example.com>
<http://ipa.example.com>
<http://ipa.example.com>, servers=['
ipaprd2.example.com <http://ipaprd2.example.com>
<http://ipaprd2.example.com>
<http://ipaprd2.example.com>'],
hostname=ipadev6.example.com
<http://ipadev6.example.com>
<http://ipadev6.example.com> <http://ipadev6.example.com>
Server and domain forced
[Kerberos realm search]
Search DNS for TXT record of
_kerberos.ipa.example.com <http://kerberos.ipa.example.com>
<http://kerberos.ipa.example.com
<http://kerberos.ipa.example.com>>
<http://kerberos.ipa.example.com
<http://kerberos.ipa.example.com>
<http://kerberos.ipa.example.com
<http://kerberos.ipa.example.com>>>.
No DNS record found
Search DNS for SRV record of
_kerberos._udp.ipa.example.com
<http://udp.ipa.example.com> <http://udp.ipa.example.com>
<http://udp.ipa.example.com>.
No DNS record found
SRV record for KDC not found! Domain:
ipa.example.com <http://ipa.example.com>
<http://ipa.example.com>
<http://ipa.example.com>
[LDAP server check]
Verifying that ipaprd2.example.com
<http://ipaprd2.example.com>
<http://ipaprd2.example.com> <http://ipaprd2.example.com>
(realm None) is an IPA server
Init LDAP connection with:
ldap://ipaprd2.example.com:389
<http://ipaprd2.example.com:389> <http://ipaprd2.example.com:389
<http://ipaprd2.example.com:389>>
<http://ipaprd2.example.com:389
<http://ipaprd2.example.com:389>
<http://ipaprd2.example.com:389
<http://ipaprd2.example.com:389>>>
LDAP Error: Protocol error: unsupported extended
operation
Discovery result: UNKNOWN_ERROR; server=None,
domain=ipa.example.com <http://ipa.example.com>
<http://ipa.example.com>
<http://ipa.example.com>,
kdc=None, basedn=None
Validated servers:
Failed to verify that ipaprd2.example.com
<http://ipaprd2.example.com>
<http://ipaprd2.example.com>
<http://ipaprd2.example.com> is an IPA Server.
This may mean that the remote server is not up
or is not
reachable due to
network or firewall settings.
Please make sure the following ports are opened
in the
firewall
settings:
TCP: 80, 88, 389
UDP: 88 (at least one of TCP/UDP ports 88
has to be
open)
Also note that following ports are necessary for
ipa-client working
properly after enrollment:
TCP: 464
UDP: 464, 123 (if NTP enabled)
(ipaprd2.example.com
<http://ipaprd2.example.com> <http://ipaprd2.example.com>
<http://ipaprd2.example.com>: Provided as
option)
Installation failed. Rolling back changes.
IPA client is not configured on this system.
I double checked the services running on the
replica,
all looked
well:
ports are listening, and I could telnet the
ports from the
client(ipadev6).
I could run "ldapserach" command to talk to the
replica(ipaprd2)
from this
client(ipadev6), with pulling out all the LDAP
records.
Also, I have another test box running RHEL7, and no
issue at all
to run the
exact same ipa-client-install command on that
RHEL7 box. So
could there be
a bug on the ipa-client software on RHEL6, to
talk to
IPA sever
running on
RHEL7? Please advise. Thank you!
Hi Beeth,
you may want to check the access and errors log of the Directory
Server in /var/log/dirsrv/slapd-DOMAIN. The extended
operations are
logged in the access log with the tag "EXT oid=...", but a
failing
operation related to unsupported extended operation will
probably
log a "RESULT err=2".
So I would first check access log and look for such a
failure. With
the OID we will be able to understand which operation is
failing and
which part could be misconfigured.
HTH,
Flo.
Best regards,
Beeth
Hello Beeth,
I've tried to reproduce the problem you described
with 7.3
(ipa-server 4.4.0-12) on master and replica and 6.9
(ipa-client
3.0.0-51) on client and it worked for me as expected.
I've done these steps:
[master] # ipa-server-install -a Secret123 -p
Secret123 --domain
example.test --realm EXAMPLE.TEST --setup-dns
--auto-forwarders -U
[replica] # ipa-client-install -p admin -w Secret123
--domain
example.test --server master.example.test -U
[replica] # ipa-replica-install
[client] # ipa-client-install -p admin -w Secret123
--domain
example.test --server replica.example.test -U
[client] # id admin
Is there anything you've done differently?
--
David Kupka
