LDAP connection issue - ipa replica fails at replication task
by Bhavin Vaidya
Hello,
We are able to add ipa-client, but ipa-replica-install fails at the point when it starts replication process.
On at the log we noticed that, it fails due to LDAP connections.
ldapsearch from client works, on same host which we are trying to create replica. (ran ipa-client to test and then uninstall).
[root@ds04 certs]# ldapsearch -x -v -H ldaps://ds01.example.com -s base -b '' namingContexts -d 1
ldap_url_parse_ext(ldaps://ds01.example.com)
ldap_initialize( ldaps://ds01.example.com:636/??base )
ldap_create
ldap_url_parse_ext(ldaps://ds01.example.com:636/??base)
ldap_sasl_bind
ldap_send_initial_request
ldap_new_connection 1 1 0
ldap_int_open_connection
ldap_connect_to_host: TCP ds01.example.com:636
ldap_new_socket: 3
ldap_prepare_socket: 3
ldap_connect_to_host: Trying 192.168.10.146:636
ldap_pvt_connect: fd: 3 tm: -1 async: 0
attempting to connect:
connect success
TLS: certdb config: configDir='/etc/openldap/certs' tokenDescription='ldap(0)' certPrefix='' keyPrefix='' flags=readOnly
TLS: using moznss security dir /etc/openldap/certs prefix .
TLS: certificate [CN=Certificate Authority,O=EXAMPLE.COM] is not valid - error -8172:Peer's certificate issuer has been marked as not trusted by the user..
TLS: error: connect - force handshake failure: errno 21 - moznss error -8172
TLS: can't connect: TLS error -8172:Peer's certificate issuer has been marked as not trusted by the user..
ldap_err2string
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
[root@ds04 certs]#
Our ds01:/etc/openldap/ldap.conf is set to:
SASL_NOCANON on
URI ldaps://ds01.example.com
BASE dc=example,dc=com
#TLS_CACERT /etc/openldap/certs/cacert.crt
TLS_CACERT /etc/ipa/ca.crt
[root@ds01 openldap]# certutil -d /etc/openldap/cacerts -L
certutil: function failed: SEC_ERROR_LEGACY_DATABASE: The certificate/key database is in an old, unsupported format.
All other replicas and clients (including new) runs this command perfectly fine.
Can not figure out past couple of days.
thank you and with regards,
Bhavin
6 years, 5 months
Re: several IPA CA certificate entries
by John Dennis
On 10/12/2017 05:06 PM, Bhavin Vaidya wrote:
> Hello Jon,
>
>
> thank you for your help. responded to main thread, and just sending you
> the actual output for certutil.
>
>
> [root@ds01 log]# certutil -d /etc/pki/nssdb -L
>
> Certificate Nickname Trust
> Attributes
>
> SSL,S/MIME,JAR/XPI
>
> ARTERIS.COM IPA CA CT,C,C
> ARTERIS.COM IPA CA CT,C,C
> ARTERIS.COM IPA CA CT,C,C
> ARTERIS.COM IPA CA CT,C,C
These nicknames do not look unique to me, I'm assuming you're still
editing them for inclusion in this email.
But irregardless here is where I'm going with this. Your goal is to
identify the correct cert to use and which to discard. The only way you
can do that is to examine each individual cert. To examine an individual
cert you must have it's *unique* nickname to pass to "certutil -L -a -n
xxx" where xxx is the unique nickname.
Only you can identify the correct cert once you list them. At the
absolute minimum they should each have a unique (issuer,serial_number)
pair. The one you want to use will probably select based on the issuer
and validity dates.
>
> ------------------------------------------------------------------------
> *From:* John Dennis <jdennis(a)redhat.com>
> *Sent:* Thursday, October 12, 2017 6:10 AM
> *To:* FreeIPA users list
> *Cc:* Bhavin Vaidya; Rob Crittenden
> *Subject:* Re: [Freeipa-users] Re: several IPA CA certificate entries
> On 10/12/2017 03:29 AM, Rob Crittenden via FreeIPA-users wrote:
>> Bhavin Vaidya via FreeIPA-users wrote:
>>> Hello,
>>>
>>>
>>> I'm having various problem on our FreeIPA setup, like can not establish
>>> new replica server or add a client anymore. Initially we had certificate
>>> issue, then we upgraded the Master FreeIPA server (CentOS 7.0.146) to
>>> FreeIPA v4.4.0) few months back.
>>>
>>>
>>> On master server it shows up 4 entries for IPA CA certificate. Is this
>>> normal?
>>>
>>>
>>> [root@ds01 ~]# certutil -d /etc/pki/nssdb -L
>>>
>>> Certificate Nickname Trust
>>> Attributes
>>>
>>> SSL,S/MIME,JAR/XPI
>>>
>>> EXAMPLE.COM IPA CA CT,C,C
>>> EXAMPLE.COM IPA CA CT,C,C
>>> EXAMPLE.COM IPA CA CT,C,C
>>> EXAMPLE.COM IPA CA CT,C,C
>>
>> The question is: are these all different certificates (and why)? I
>> assume someone ran ipa-cacert-manage renew a bunch of times.
>>
>> Multiple entries in itself shouldn't be a problem.
>>
>> I assume this is related to your client install issues. You may be able
>> to get away with having just the latest CA cert stored in LDAP to avoid
>> this.
>
> I saw this last night and my first thought was this shouldn't happen
> because certutil enforces nickname uniqueness.
>
> We would like to verify what each cert is, specifically it's issuer and
> serial number. But we can't ask certutil to show us the details of a
> cert because you must pass the -n nickname flag to certutil so it can
> find the cert to display. But since the nicknames are not unique you
> can't do that. This is why certutil (and any low level NSS API that adds
> a cert to the db) demands name uniqueness.
>
> Are the names listed with -L truly unique? It looks like you edited them.
>
>
> --
> John
--
John
6 years, 5 months
yum update caused FreeIPA to temporarily return NXDOMAIN for valid records
by Nicholas Hinds
During an upgrade from 4.5.0-21.el7.centos.1.2 to 4.5.0-21.el7.centos.2.2
on a CentOS 7.4 machine, FreeIPA's DNS server briefly returned NXDOMAIN for
records which existed in FreeIPA. These invalid responses were returned for
a very short amount of time, but caused long-running issues with Java
clients which tend to cache DNS responses. Upgraded packages included:
389-ds-base, 389-ds-base-libs, 389-ds-base-snmp, ipa-client,
ipa-client-common, ipa-python-compat, ipa-server, ipa-server-common,
ipa-server-dns, ipa-server-trust-ad, python2-ipa-server, and a dozen
sss-related packages.
I reproduced this in a FreeIPA test environment by running `while true; do
dig some.dns.entry.managed.by.freeipa @ip.address.of.freeipa | tee -a
a-log-file; done` from one server, and running `yum update` on the FreeIPA
machine. The invalid NXDOMAIN responses were returned some time after the
`yum update` logged 'Cleanup' for the RPMs, and seemed to be during the
'Verifying' phase.
These NXDOMAIN responses claimed that an upstream nameserver (
a.root-servers.net) was the authority for my zone:
a-log-file-; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.37.rc1.el6_7.7 <<>>
some.dns.entry.managed.by.freeipa @172.16.0.77
a-log-file-;; global options: +cmd
a-log-file-;; Got answer:
a-log-file:;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 2889
a-log-file-;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1,
ADDITIONAL: 0
a-log-file-
a-log-file-;; QUESTION SECTION:
a-log-file-;some.dns.entry.managed.by.freeipa. IN A
a-log-file-
a-log-file-;; AUTHORITY SECTION:
a-log-file-. 60 IN SOA a.root-servers.net. nstld.verisign-grs.com.
2017102400 1800 900 604800 86400
a-log-file-
a-log-file-;; Query time: 227 msec
a-log-file-;; SERVER: 172.16.0.77#53(172.16.0.77)
a-log-file-;; WHEN: Tue Oct 24 18:30:28 2017
a-log-file-;; MSG SIZE rcvd: 130
Usually when querying an invalid DNS entry, the dig output still claims
that my FreeIPA server is authoritative for the zone:
$ dig doesntexist.zone.managed.by.freeipa @172.16.0.77
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.37.rc1.el6_7.7 <<>>
doesntexist.zone.managed.by.freeipa @172.16.0.77
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 59953
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;doesntexist.zone.managed.by.freeipa. IN A
;; AUTHORITY SECTION:
zone.managed.by.freeipa. 30 IN SOA idm01.freeipa.
hostmaster.zone.managed.by.freeipa. 1508869828 30 900 1209600 30
;; Query time: 0 msec
;; SERVER: 172.16.0.77#53(172.16.0.77)
;; WHEN: Tue Oct 24 19:27:12 2017
;; MSG SIZE rcvd: 113
Is it possible that during a yum update, the FreeIPA DNS server temporarily
forgets what zones it's authoritative for (or forgets all DNS records) and
just delegates to the upstream DNS server for half a second or so? Or is
something else going on here?
I'm open to suggestions.
Thanks,
Nicholas.
6 years, 5 months
Replica stopped working: pki-ca port failed?
by Lachlan Musicman
When I first installed our replica, it worked just fine - I could add a
user and see it on the master server. And vice versa.
I recently went back to take a look and make sure everything was working -
and it's not.
ipactl status shows everything is ok. Munge is up. I can ssh hostname
between machines.
When I look at the ID Views in the interface, I get an "IPA Error 903:
InternalError".
When I do an id <username> I get nosuch user.
I did some googling. In /var log/dirsrv/domain/errors I found this:
[26/Oct/2017:12:31:23.454702287 +1100] - ERR - set_krb5_creds - Could not
get initial credentials for principal [ldap/
vmdr-linuxidm.unix.domain.com(a)UNIX.DOMAIN.COM] in keytab
[FILE:/etc/dirsrv/ds.keytab]: -1765328228 (Cannot contact any KDC for
requested realm)
I can get `kinit admin` working fine. But there's something wrong. I don't
know where to look exactly.
/var/log/httpd/error has this
RuntimeError: Unable to load file /usr/share/ipa/smb.conf.empty
Which is interesting. There's no file /usr/share/ipa/smb.conf.empty but
there is a /usr/share/ipa/smb.conf.template?
Ok, I think I've found the problem:
ipa-replica-conncheck -c -m <master>
Failed to connect to port 7389 tcp on 10.126.18.73
PKI-CA: Directory Service port (7389): FAILED
ERROR: Port check failed! Inaccessible port(s): 7389 (TCP)
On the master, pki-tomcatd is showing as OK, although nmap -sT -O localhost
doesn't show 7389 open.
Where can I look next?
ipa -version
VERSION: 4.5.0, API_VERSION: 2.228
cheers
L.
------
"The antidote to apocalypticism is *apocalyptic civics*. Apocalyptic civics
is the insistence that we cannot ignore the truth, nor should we panic
about it. It is a shared consciousness that our institutions have failed
and our ecosystem is collapsing, yet we are still here — and we are
creative agents who can shape our destinies. Apocalyptic civics is the
conviction that the only way out is through, and the only way through is
together. "
*Greg Bloom* @greggish
https://twitter.com/greggish/status/873177525903609857
6 years, 5 months
Re: Port 389
by Sean Hogan
Ok.. no worries. Thanks Simo
From: Simo Sorce via FreeIPA-users
<freeipa-users(a)lists.fedorahosted.org>
To: FreeIPA users list <freeipa-users(a)lists.fedorahosted.org>
Cc: Sean Hogan <schogan(a)us.ibm.com>, Simo Sorce <simo(a)redhat.com>
Date: 10/26/2017 02:17 PM
Subject: [Freeipa-users] Re: Port 389
On Thu, 2017-10-26 at 14:11 -0700, Sean Hogan via FreeIPA-users wrote:
> Hello IPA,
>
> Hopefully a quick question.
>
> RHEL 7.3 IPA 4.4
>
> I have been digging around RHEL docs
>
https://urldefense.proofpoint.com/v2/url?u=https-3A__access.redhat.com_so...
for firewall ports and it
> says
> 389 is required for replication of IPA servers and clients to IPA
> servers.
>
> FreeIPA docs say this:
> SSL/startTLS When possible, configure your LDAP client to
> communicate over
> SSL/TLS. You can either use port 389 and enable startTLS in the
> client or
> configure to use the ldaps port, 636. The IPA CA certificate can be
> found
> in /etc/ipa/ca.crt on all enrolled hosts.
>
>
>
>
>
> Question is this... can IPA be configured without Port 389 at all
> for clients to comm with IPA servers?
Nope, sorry.
Most clients use SASL/GSSAPI to secure the connection, and that is done
over port 389.
>
> I realize the starttls using 389 encrypts the comms but for our
> vlan firewall rules 389 is not something we really want to open. It
> is easier to open IPA server IP to IPA server IP port 389 bi-
> direction if needed for replication but for clients it would be the
> whole subnet to IPA server 389.
> I also noticed somewhere that direct 636 instead of 389 with starttls
> for clients is deprecated but I think that was in Directory Server
> docs.
--
Simo Sorce
Sr. Principal Software Engineer
Red Hat, Inc
_______________________________________________
FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org
6 years, 5 months
Port 389
by Sean Hogan
Hello IPA,
Hopefully a quick question.
RHEL 7.3 IPA 4.4
I have been digging around RHEL docs
https://access.redhat.com/solutions/357673 for firewall ports and it says
389 is required for replication of IPA servers and clients to IPA servers.
FreeIPA docs say this:
SSL/startTLS When possible, configure your LDAP client to communicate over
SSL/TLS. You can either use port 389 and enable startTLS in the client or
configure to use the ldaps port, 636. The IPA CA certificate can be found
in /etc/ipa/ca.crt on all enrolled hosts.
Question is this... can IPA be configured without Port 389 at all for
clients to comm with IPA servers?
I realize the starttls using 389 encrypts the comms but for our vlan
firewall rules 389 is not something we really want to open. It is easier
to open IPA server IP to IPA server IP port 389 bi-direction if needed for
replication but for clients it would be the whole subnet to IPA server 389.
I also noticed somewhere that direct 636 instead of 389 with starttls for
clients is deprecated but I think that was in Directory Server docs.
Sean Hogan
6 years, 5 months
Re: Sync against AD group
by Rob Crittenden
Miguel Angel Coa M. wrote:
> Rob,
> My idea about A/D group is centralize the users for the winsync because
> some are in one OU and others in others (but i see this isn't possible)
>
> eg.
>
> Example2.com <-- Domain root
> Builtin <-- Default
> .....
> .....
> Users <-- Default users -> base search (CN=users,DC=example2, DC=com)
> .....
> Area01 <-- Custom OU and i've some user for sync --> base search
> (OU=area01,DC=example2, DC=com)
> Area02 <-- Custom OU and i've others user for sync --> base search
> (OU=area02,DC=example2, DC=com)
> Area03 <-- Custom OU and i've others user for sync --> base
> search (OU=area03,DC=example2, DC=com)
> ......
> AreaXX <-- Custom OU and i've others user for sync --> base
> search (OU=areaXX,DC=example2, DC=com)
>
>
> ¿In my case what could I do?
Right, moving all the users to a custom OU or otherwise separate subtree
would be the only way to do it AFAIK.
rob
>
>
> Thanks.
>
>
> Saludos.
> ---
> Miguel Coa M.
>
> 2017-10-25 18:42 GMT-03:00 Rob Crittenden <rcritten(a)redhat.com
> <mailto:rcritten@redhat.com>>:
>
> Miguel Angel Coa M. wrote:
> > Hi Rob,
> > CN=LAB is a group entry and inside i've a few members
> >
> > [.................]
> > # LAB, Users, example2.com <http://example2.com> <http://example2.com>
> > dn: CN=LAB,CN=Users,DC=example2,DC=com
> > objectClass: top
> > objectClass: group
> > cn: LAB
> > description: Usuario de grupo LAB
> > member: CN=winuser64,CN=Users,DC=example2,DC=com
> > member: CN=winuserlab2 userlab2,OU=Test,DC=example2,DC=com
> > member: CN=winuser40 winuser40,OU=Test,DC=example2,DC=com
> > member: CN=winuserlab1 userlab1,OU=Test,DC=example2,DC=com
> > distinguishedName: CN=LAB,CN=Users,DC=example2,DC=com
> > instanceType: 4
> > whenCreated: 20171023203927.0Z
> > whenChanged: 20171024203108.0Z
> > uSNCreated: 49193
> > uSNChanged: 61493
> > name: LAB
> > objectGUID:: gQBcEwVqHU+L3DmmZPVFFw==
> > objectSid:: AQUAAAAAAAUVAAAAguTkYzspTdFQ0vfEWwQAAA==
> > sAMAccountName: LAB
> > sAMAccountType: 268435456
> > groupType: -2147483640
> > objectCategory: CN=Group,CN=Schema,CN=Configuration,DC=example2,DC=com
> > dSCorePropagationData: 16010101000000.0Z
>
> That's why. winsync syncs against a subtree, not members of a group.
>
> rob
>
> > [.................]
> >
> >
> > Regards.
> >
> >
> >
> >
> > Saludos.
> > ---
> > Miguel Coa M.
> >
> > 2017-10-25 17:28 GMT-03:00 Rob Crittenden <rcritten(a)redhat.com <mailto:rcritten@redhat.com>
> > <mailto:rcritten@redhat.com <mailto:rcritten@redhat.com>>>:
> >
> > Miguel Angel Coa M. via FreeIPA-users wrote:
> > > Hello Everyone,
> > > I've setting IPA server connect with AD (Windows Server
> 2012R2) and work
> > > fine, but i need change the sub-tree for user sync and this
> step fail
> > > (not sync anything) .
> > > For example, when i sync against the default base is ok
> > >
> > > [.................]
> > > CN=Users,DC=example2,dc=com
> > > [.................]
> > >
> > > [.................]
> > > nsds7WindowsReplicaSubtree: CN=Users,DC=example2,DC=com
> > > [.................]
> > >
> > >
> > > But i try change the base and does not sync anything
> > >
> > > [.................]
> > > CN=LAB,CN=Users,DC=example2,dc=com
> > > [.................]
> > >
> > > When the LAB is AD group. ¿is possible sync against AD group?
> >
> > IIRC winsync looks for entries that match objectclass=ntuser.
> I CN=LAB
> > literally a group entry or a subtree?
> >
> > rob
> >
> >
>
>
6 years, 5 months
Re: Sync against AD group
by Rob Crittenden
Miguel Angel Coa M. wrote:
> Hi Rob,
> CN=LAB is a group entry and inside i've a few members
>
> [.................]
> # LAB, Users, example2.com <http://example2.com>
> dn: CN=LAB,CN=Users,DC=example2,DC=com
> objectClass: top
> objectClass: group
> cn: LAB
> description: Usuario de grupo LAB
> member: CN=winuser64,CN=Users,DC=example2,DC=com
> member: CN=winuserlab2 userlab2,OU=Test,DC=example2,DC=com
> member: CN=winuser40 winuser40,OU=Test,DC=example2,DC=com
> member: CN=winuserlab1 userlab1,OU=Test,DC=example2,DC=com
> distinguishedName: CN=LAB,CN=Users,DC=example2,DC=com
> instanceType: 4
> whenCreated: 20171023203927.0Z
> whenChanged: 20171024203108.0Z
> uSNCreated: 49193
> uSNChanged: 61493
> name: LAB
> objectGUID:: gQBcEwVqHU+L3DmmZPVFFw==
> objectSid:: AQUAAAAAAAUVAAAAguTkYzspTdFQ0vfEWwQAAA==
> sAMAccountName: LAB
> sAMAccountType: 268435456
> groupType: -2147483640
> objectCategory: CN=Group,CN=Schema,CN=Configuration,DC=example2,DC=com
> dSCorePropagationData: 16010101000000.0Z
That's why. winsync syncs against a subtree, not members of a group.
rob
> [.................]
>
>
> Regards.
>
>
>
>
> Saludos.
> ---
> Miguel Coa M.
>
> 2017-10-25 17:28 GMT-03:00 Rob Crittenden <rcritten(a)redhat.com
> <mailto:rcritten@redhat.com>>:
>
> Miguel Angel Coa M. via FreeIPA-users wrote:
> > Hello Everyone,
> > I've setting IPA server connect with AD (Windows Server 2012R2) and work
> > fine, but i need change the sub-tree for user sync and this step fail
> > (not sync anything) .
> > For example, when i sync against the default base is ok
> >
> > [.................]
> > CN=Users,DC=example2,dc=com
> > [.................]
> >
> > [.................]
> > nsds7WindowsReplicaSubtree: CN=Users,DC=example2,DC=com
> > [.................]
> >
> >
> > But i try change the base and does not sync anything
> >
> > [.................]
> > CN=LAB,CN=Users,DC=example2,dc=com
> > [.................]
> >
> > When the LAB is AD group. ¿is possible sync against AD group?
>
> IIRC winsync looks for entries that match objectclass=ntuser. I CN=LAB
> literally a group entry or a subtree?
>
> rob
>
>
6 years, 5 months
Sync against AD group
by Miguel Angel Coa M.
Hello Everyone,
I've setting IPA server connect with AD (Windows Server 2012R2) and work
fine, but i need change the sub-tree for user sync and this step fail (not
sync anything) .
For example, when i sync against the default base is ok
[.................]
CN=Users,DC=example2,dc=com
[.................]
[.................]
nsds7WindowsReplicaSubtree: CN=Users,DC=example2,DC=com
[.................]
But i try change the base and does not sync anything
[.................]
CN=LAB,CN=Users,DC=example2,dc=com
[.................]
When the LAB is AD group. ¿is possible sync against AD group?
Saludos.
---
Miguel Coa M.
6 years, 5 months
FreeIPA+Ubuntu-16.04+Samba, is there a solution
by Kees Bakker
Hey,
As described by Alexander in [1], Samba on Ubuntu 16.04 is built against Heimdal,
and that conflicts with FreeIPA (which requires MIT Kerberos).
We have a network with Ubuntu 16.04 servers, and Ubuntu 16.04 workstations,
and some Windows PCs. So far I was unable to configure the samba server to
use the IPA server for authentication (again, see [1]).
So, what are my options Ubuntu 16.04 / Samba / FreeIPA / Windows PCs?
I was thinking to setup a Fedora or Centos server (with samba), but I have no clue
if that path will lead to a working solution.
Another alternative, maybe, is to use LDAP, but I'm afraid to screw my nicely working
IPA server. There is this guide [2], but I've already done ipa-adtrust-install and I think
there is now already some LDAP scheme added for samba. (Not sure though)
Any thoughts?
[1] https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1552249
[2] https://help.ubuntu.com/lts/serverguide/samba-ldap.html
--
Kees Bakker
6 years, 5 months
