Re: [Freeipa-users] Windows Server can't use FreeIPA's DNS server

[Fil Di Noto]

Sounds more like a client problem (firewall, hosts file, network
settings/routes)

Other clients are able to resolve against the IPA server? You are seeing
the response come back on a packet capture taken from the windows server?

If yes to both of those, maybe the windows server thinks the IPA server is
not who it says it is. Is the IPA server hostname/domain name the same as a
previous windows host? If so that is probably not good.

On Sat, Jan 14, 2017 at 12:01 PM, Raul Dias  wrote:

> Hello,
>
> I am migrating a network to FreeIPA. LDAP, NFS, no Active Directory.
>
> A Windows Server 2008 R2, cannot use FreeIPAs bind to resolve DNS query.
> This server works fine with my old bind server, google's dns server
> (8.8.8.8), but not FreeIPA's.
> Using wireshark, I can see the the response gets to this host, but is
> simply ignored.  Clocks are in sync.
>
> Not sure if the problem is in the FreeIPA's side, probably not.
>
> Any ideas?
> -rsd
>
> --
> Manage your subscription for the Freeipa-users mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-users
> Go to http://freeipa.org for more info on the project
>
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Why does a SAN field on a CSR require a host to be in IPA?

[Fil Di Noto]

On Mon, Oct 24, 2016 at 9:55 PM, Fraser Tweedale <ftwee...@redhat.com> wrote:
> On Mon, Oct 24, 2016 at 12:30:10AM -0700, Fil Di Noto wrote:
>> On Sun, Oct 23, 2016 at 9:53 PM, Fraser Tweedale <ftwee...@redhat.com> wrote:
>> > On Sun, Oct 23, 2016 at 08:37:15PM -0700, Fil Di Noto wrote:
>> >> Hello,
>> >>
>> >>
>> >>
>> >> I would like to better understand why IPA requires SAN (subject 
>> >> alternative
>> >> name) entries to have a backing host record. In order to sign a 
>> >> certificate
>> >> with a SAN that corresponded to a user friendly CNAME I had to add a host
>> >> record (ipa host) for that DNS name (use force option to create without an
>> >> A/ record) as well as a service principle.
>> >>
>> >>
>> >>
>> >> I'm sure I'm not alone when I say I don't like doing that because it means
>> >> that a "Host" in FreeIPA is not a computer, it's a host record that may or
>> >> may not be the only record that corresponds to a computer. It gets
>> >> confusing.
>> >>
>> >>
>> >>
>> >> I assume things are this way to ensure integrity at some level. But I 
>> >> can't
>> >> picture it. What is the potential danger of simply bypassing the
>> >> host/principal checks and just signing the certificate with whatever SAN
>> >> field we like?
>> >>
>> > In this specific case, it is because certmonger requests service
>> > certificates with host credentials.  Therefore it is not just human
>> > administrators issuing certs.  And we MUST validate SAN against
>> > information in the directory (the only "source of truth" available
>> > to the CA / IPA cert-request command).  Otherwise you could put e.g.
>> > `google.com' into SAN, and we would issue the cert, and that would
>> > be Very Bad.
>> >
>>
>> In my case it's always human administrators issuing certs. I can see
>> how validation is a great way to prevent a scenario like the one you
>> described. But couldn't that be accommodated by tinkering with the
>> roles/privileges so that you could impose the restriction on external,
>> less-trusted applications but allow a trusted human administrator to
>> bypass it?
>>
>> Admin group by default would be nice. It would be unfortunate if
>> someone added a service account to the admin group, but I don't see
>> that as justification for ruling it out. How many other poor security
>> decisions has someone made already before they decided to add a
>> service account to the domain admin group? To that I would say that
>> degree of administrative negligence is not something that the project
>> should design around. But, I don't work at RedHat and I don't have to
>> take the support calls so my opinion means nothing.
>>
>> But if I'm an admin, enforcing the SAN restriction doesn't prevent me
>> from doing anything I couldn't already do by creating a couple host
>> records. It's just making things difficult for admins who ultimately
>> are securely deploying a service.
>>
> The question is not really one of privilege, but sanity.  FreeIPA
> has to make sure that certs issued by it correspond to the CA's view
> of reality, i.e. what is in the FreeIPA directory, at the time the
> request is made.  IMO to disable these checks for human users with a
> particular permission is a mistake waiting to happen.
>
> Yes, enforcing the restriction forces a human to put to created the
> needed objects before the cert request will be considered valid.
> Not a bad thing, IMO.

Help me understand. Assuming that the SAN in the CSR are
valid/intended/non-malicious, can you give me an example scenario
where sanity becomes a problem? Is IPA going to examine the cert at
some point in the future and get confused when it doesn't recognize
the entries in the SAN field?

In my imagination, I see IPA for whatever reason comes accross a cert
it signed in the past and decides it needs to compare the SAN to the
directory. Then it sees the SAN doesn't have an associated principal
in the directory. Who does IPA trust? (the directory obviously). IPA
says, "is this SAN in the directory? No. Did I sign the cert? Yes.
Should I trust the cert? Yes because I signed it."

I've got a hundred related questions, but maybe an example would help
me answer them myself.

>
> All this said, I think there is a valid RFE in allowing Kerberos
> principal aliases to be consulted when validating a CSR.  This would
> mean you do not have to create new object

Re: [Freeipa-users] Why does a SAN field on a CSR require a host to be in IPA?

[Fil Di Noto]

On Sun, Oct 23, 2016 at 9:53 PM, Fraser Tweedale <ftwee...@redhat.com> wrote:
> On Sun, Oct 23, 2016 at 08:37:15PM -0700, Fil Di Noto wrote:
>> Hello,
>>
>>
>>
>> I would like to better understand why IPA requires SAN (subject alternative
>> name) entries to have a backing host record. In order to sign a certificate
>> with a SAN that corresponded to a user friendly CNAME I had to add a host
>> record (ipa host) for that DNS name (use force option to create without an
>> A/ record) as well as a service principle.
>>
>>
>>
>> I'm sure I'm not alone when I say I don't like doing that because it means
>> that a "Host" in FreeIPA is not a computer, it's a host record that may or
>> may not be the only record that corresponds to a computer. It gets
>> confusing.
>>
>>
>>
>> I assume things are this way to ensure integrity at some level. But I can't
>> picture it. What is the potential danger of simply bypassing the
>> host/principal checks and just signing the certificate with whatever SAN
>> field we like?
>>
> In this specific case, it is because certmonger requests service
> certificates with host credentials.  Therefore it is not just human
> administrators issuing certs.  And we MUST validate SAN against
> information in the directory (the only "source of truth" available
> to the CA / IPA cert-request command).  Otherwise you could put e.g.
> `google.com' into SAN, and we would issue the cert, and that would
> be Very Bad.
>

In my case it's always human administrators issuing certs. I can see
how validation is a great way to prevent a scenario like the one you
described. But couldn't that be accommodated by tinkering with the
roles/privileges so that you could impose the restriction on external,
less-trusted applications but allow a trusted human administrator to
bypass it?

Admin group by default would be nice. It would be unfortunate if
someone added a service account to the admin group, but I don't see
that as justification for ruling it out. How many other poor security
decisions has someone made already before they decided to add a
service account to the domain admin group? To that I would say that
degree of administrative negligence is not something that the project
should design around. But, I don't work at RedHat and I don't have to
take the support calls so my opinion means nothing.

But if I'm an admin, enforcing the SAN restriction doesn't prevent me
from doing anything I couldn't already do by creating a couple host
records. It's just making things difficult for admins who ultimately
are securely deploying a service.

> The problem is slightly exacerbated in that 99% of the time you
> really want to issue service certs, but FreeIPA does not permit the
> creation of a service entry without a corresponding host entry.  So
> you end up with spurious host entries that do not correspond to
> actual hosts.  I have previously asked about relaxing this
> restriction.  The idea was rejected (for reasons I don't remember).

To be fair, I don't think I ever read specifically that a Host in IPA
was supposed to represent a single computer. But I imagine that the
majority of people who are using it thought that was the case, at
least at first. I don't think it would take much abstraction to
maintain that logical representation for administrators.

>> If this actually is a necessity and is not likely to change, I think it
>> would be beneficial to administrators to be able to manage "Hosts" that
>> correspond to CNAMEs (call them "Alias Hosts"? ) separately from Hosts that
>> are actually enrolled computers. They could be managed in a similar fashion
>> to SUDO rules, like maybe:
>>
>>
>>
>> Alias Hosts = a single name
>>
>> Alias Host Groups = groups of names
>>
>> Alias Host Maps = associate Alias Host/Group with a Hosts or Host Groups
>>
>>
>>
>> I'm picturing Alias Hosts and Alias groups as a seperate tab under Identity
>> (and some corresponding "ipa aliashost-*" CLI) and Alias Host Maps tab
>> under policy.
>>
> Now that we have kerberos principal aliases, we might be able to
> leverage that, perhaps even directly for service principals.  Any
> devs want to chime in on this idea?
>
> Cheers,
> Fraser

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

Re: [Freeipa-users] ipa-cacert-manage install failing with subject public key info mismatch

[Fil Di Noto]

Hi,

Can you give an example of what's different between the two subjects?

On Sun, Oct 23, 2016 at 9:03 AM, David Dejaeghere <
david.dejaegh...@gmail.com> wrote:

> Does somebody have an idea how to replace our certificates when the new
> ROOT ca certificate has a different subject?
> The UI is down because of this.
>
> 2016-10-19 11:42 GMT+02:00 David Dejaeghere :
>
>> Hello,
>>
>> When installing FreeIPA we used the CA from our Windows servers.
>> This one recently expired and we created a new one.  It seems that the
>> new root CA has another subject name and this seems to be an issue when we
>> want to install new certs on our FreeIPA hosts.
>>
>> ipa-cacert-manage install certnew.pem -n mycert -t C,,
>>
>> Installing CA certificate, please wait
>> Failed to install the certificate: subject public key info mismatch
>>
>> After validating the subjects are indeed different.
>>
>> How can we replace the required certs for dirsrv and http when the ca is
>> not installable?
>>
>> Kind Regards,
>>
>> David
>>
>>
>>
>
> --
> Manage your subscription for the Freeipa-users mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-users
> Go to http://freeipa.org for more info on the project
>
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

[Freeipa-users] Why does a SAN field on a CSR require a host to be in IPA?

[Fil Di Noto]

Hello,



I would like to better understand why IPA requires SAN (subject alternative
name) entries to have a backing host record. In order to sign a certificate
with a SAN that corresponded to a user friendly CNAME I had to add a host
record (ipa host) for that DNS name (use force option to create without an
A/ record) as well as a service principle.



I'm sure I'm not alone when I say I don't like doing that because it means
that a "Host" in FreeIPA is not a computer, it's a host record that may or
may not be the only record that corresponds to a computer. It gets
confusing.



I assume things are this way to ensure integrity at some level. But I can't
picture it. What is the potential danger of simply bypassing the
host/principal checks and just signing the certificate with whatever SAN
field we like?



If this actually is a necessity and is not likely to change, I think it
would be beneficial to administrators to be able to manage "Hosts" that
correspond to CNAMEs (call them "Alias Hosts"? ) separately from Hosts that
are actually enrolled computers. They could be managed in a similar fashion
to SUDO rules, like maybe:



Alias Hosts = a single name

Alias Host Groups = groups of names

Alias Host Maps = associate Alias Host/Group with a Hosts or Host Groups



I'm picturing Alias Hosts and Alias groups as a seperate tab under Identity
(and some corresponding "ipa aliashost-*" CLI) and Alias Host Maps tab
under policy.
-- 
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 has no RUV

[Fil Di Noto]

What do you do if a replica has no RUV, it may have been deleted.

I've tried disconnecting/connecting it to the other replicas to see if
it would re-build it but it doesn't

Re-initializing it doesn't seem to fix it either.

-- 
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] Replication attrlist_replace nsslapd-referral failed

[Fil Di Noto]

Things have been working better (so far) after taking some steps I read here:

https://www.redhat.com/archives/freeipa-users/2016-January/msg00257.html



On Mon, Oct 10, 2016 at 6:48 PM, Fil Di Noto <fdin...@gmail.com> wrote:
> After an IPA server is re-initialized it immediately begins failing
> incremental updates. I checked the kerberos logs and things appear to
> be ok there, I can manually test LDAP from all servers against all
> other servers.
>
> There is an DS5ReplicaBindDN entry in "dn:
> cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config" for
> an IPA server that no longer exists. But all IPA living servers have
> an entry for all other living servers.
> There is the correct number of cn=master, and cn=ca, and the
> caRenewalMaster is set on the correct master.
>
>  "ipa-replica-manage del --force --clean " does not remove the entry.
>
> There were some RUV from the old servers also and I cleaned them. The
> man page says if a clean is run on the wrong ID then the server should
> be re-initialized, so I just did that on purpose and re-initialized
> the one of the servers and that has cleared the NSMMReplicationPlugin
> error (so far) but I am still getting the attrlist_replace error.
>
> I'm getting no indication of kerberos problems.Could it be the
> NSACLPlugin ? It preceeds the other error every time but that is
> probably just regular startup procedure, and having an ACL for
> something that doesn't exist doesn't feel like a fatal error to me. I
> didn't do the KRA install.
>
> [root@ipa05 slapd-example-com]# tail -f errors
> [10/Oct/2016:23:27:57 +] NSACLPlugin - The ACL target
> cn=vaults,cn=kra,dc=example,dc=com does not exist
> [10/Oct/2016:23:27:57 +] NSACLPlugin - The ACL target
> cn=casigningcert
> cert-pki-ca,cn=ca_renewal,cn=ipa,cn=etc,dc=example,dc=com does not
> exist
> [10/Oct/2016:23:27:57 +] agmt="cn=meToipa07.example.com"
> (ipa07:389) - Can't locate CSN 57fc2e7f000a000d in the changelog
> (DB rc=-30988). If replication stops, the consumer may need to be
> reinitialized.
> [10/Oct/2016:23:27:57 +] NSMMReplicationPlugin - changelog program
> - agmt="cn=meToipa07.example.com" (ipa07:389): CSN
> 57fc2e7f000a000d not found, we aren't as up to date, or we purged
> [10/Oct/2016:23:27:57 +] NSMMReplicationPlugin -
> agmt="cn=meToipa07.example.com" (ipa07:389): Data required to update
> replica has been purged. The replica must be reinitialized.
> [10/Oct/2016:23:27:57 +] NSMMReplicationPlugin -
> agmt="cn=meToipa07.example.com" (ipa07:389): Incremental update failed
> and requires administrator action
> [10/Oct/2016:23:29:09 +] attrlist_replace - attr_replace
> (nsslapd-referral, ldap://ipa07.example.com:389/o%3Dipaca) failed.

-- 
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] Replication attrlist_replace nsslapd-referral failed

[Fil Di Noto]

After an IPA server is re-initialized it immediately begins failing
incremental updates. I checked the kerberos logs and things appear to
be ok there, I can manually test LDAP from all servers against all
other servers.

There is an DS5ReplicaBindDN entry in "dn:
cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config" for
an IPA server that no longer exists. But all IPA living servers have
an entry for all other living servers.
There is the correct number of cn=master, and cn=ca, and the
caRenewalMaster is set on the correct master.

 "ipa-replica-manage del --force --clean " does not remove the entry.

There were some RUV from the old servers also and I cleaned them. The
man page says if a clean is run on the wrong ID then the server should
be re-initialized, so I just did that on purpose and re-initialized
the one of the servers and that has cleared the NSMMReplicationPlugin
error (so far) but I am still getting the attrlist_replace error.

I'm getting no indication of kerberos problems.Could it be the
NSACLPlugin ? It preceeds the other error every time but that is
probably just regular startup procedure, and having an ACL for
something that doesn't exist doesn't feel like a fatal error to me. I
didn't do the KRA install.

[root@ipa05 slapd-example-com]# tail -f errors
[10/Oct/2016:23:27:57 +] NSACLPlugin - The ACL target
cn=vaults,cn=kra,dc=example,dc=com does not exist
[10/Oct/2016:23:27:57 +] NSACLPlugin - The ACL target
cn=casigningcert
cert-pki-ca,cn=ca_renewal,cn=ipa,cn=etc,dc=example,dc=com does not
exist
[10/Oct/2016:23:27:57 +] agmt="cn=meToipa07.example.com"
(ipa07:389) - Can't locate CSN 57fc2e7f000a000d in the changelog
(DB rc=-30988). If replication stops, the consumer may need to be
reinitialized.
[10/Oct/2016:23:27:57 +] NSMMReplicationPlugin - changelog program
- agmt="cn=meToipa07.example.com" (ipa07:389): CSN
57fc2e7f000a000d not found, we aren't as up to date, or we purged
[10/Oct/2016:23:27:57 +] NSMMReplicationPlugin -
agmt="cn=meToipa07.example.com" (ipa07:389): Data required to update
replica has been purged. The replica must be reinitialized.
[10/Oct/2016:23:27:57 +] NSMMReplicationPlugin -
agmt="cn=meToipa07.example.com" (ipa07:389): Incremental update failed
and requires administrator action
[10/Oct/2016:23:29:09 +] attrlist_replace - attr_replace
(nsslapd-referral, ldap://ipa07.example.com:389/o%3Dipaca) failed.

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

Re: [Freeipa-users] LDAP/DNS replication, IPA server service principal key issue

[Fil Di Noto]

Found it. Nothing to do with keytabs or their permissions. It was
settings in named.conf (sasl_user) which had the wrong server name.

On Fri, Oct 7, 2016 at 2:05 PM, Fil Di Noto <fdin...@gmail.com> wrote:
> I forgot to add the -k in the klist command. Actually the keytab looks
> correct. I noticed the file permissions were 0400 named:named but all
> other service keytabs I see are 0600. I thought that might be an issue
> so I tried changing the permissions to 0600 on all the servers but it
> hasn't changed the result.
>
> Any clue on whether those permissions (0400) are correct? I know folks
> like to do named like that with chroots and such but that seems wrong
> to me.
>
> On Fri, Oct 7, 2016 at 1:24 PM, Fil Di Noto <fdin...@gmail.com> wrote:
>> klist /etc/named.keytab
>> klist: Bad format in credentials cache
>>
>> It's actually like this on all the servers, and I assume it is only
>> showing up in the logs for the 1 server because that is the server
>> where we make changes and it is trying to push changes out to the
>> rest.
>>
>> If it were any other server than an IPA server I would just manually
>> ipa-getkeytab, but since it's also a KDC I'm having doubts about how
>> to proceed. What do you think Matt?
>>
>> On Fri, Oct 7, 2016 at 1:03 PM, Matt Wells <matt.we...@mosaic451.com> wrote:
>>> That's correct. Apparently it's on able to use the Kerberos credential to
>>> utilize that service associated with the server.
>>> Have you examined the key tab itself? Read it in and see what's inside of
>>> it.
>>>
>>>
>>> On Fri, Oct 7, 2016, 12:20 Fil Di Noto <fdin...@gmail.com> wrote:
>>>>
>>>> I'm trying to interpret these log messages. It seems like server ipa03
>>>> has no principal for the DNS service and is not able to replicate LDAP
>>>> to the other 3 IPA servers. If that is correct:
>>>>
>>>> 1. Is "DNS" the service principal it should be using?
>>>> 2. How do I correct this?
>>>> (what concerns me is that ipa03 is the server I designated as
>>>> the server where administrative changes are made in case manual
>>>> replication is needed)
>>>>
>>>>
>>>> Oct  7 18:38:47 ipa02.example.com named-pkcs11[4959]: connection to
>>>> the LDAP server was lost
>>>> Oct  7 18:38:47 ipa02.example.com named-pkcs11[4959]: Failed to get
>>>> initial credentials (TGT) using principal 'DNS/ipa03.example.com' and
>>>> keytab 'FILE:/etc/named.keytab' (Keytab contains no suitable keys for
>>>> DNS/ipa03.example@example.com)
>>>> Oct  7 18:38:47 ipa02.example.com named-pkcs11[4959]: ldap_syncrepl
>>>> will reconnect in 60 seconds
>>>> Oct  7 18:39:00 ipa04.example.com named-pkcs11[4537]: connection to
>>>> the LDAP server was lost
>>>> Oct  7 18:39:00 ipa04.example.com named-pkcs11[4537]: Failed to get
>>>> initial credentials (TGT) using principal 'DNS/ipa03.example.com' and
>>>> keytab 'FILE:/etc/named.keytab' (Keytab contains no suitable keys for
>>>> DNS/ipa03.example@example.com)
>>>> Oct  7 18:39:00 ipa04.example.com named-pkcs11[4537]: ldap_syncrepl
>>>> will reconnect in 60 seconds
>>>> Oct  7 18:39:16 ipa01.example.com named-pkcs11[15697]: connection to
>>>> the LDAP server was lost
>>>> Oct  7 18:39:16 ipa01.example.com named-pkcs11[15697]: Failed to get
>>>> initial credentials (TGT) using principal 'DNS/ipa03.example.com' and
>>>> keytab 'FILE:/etc/named.keytab' (Keytab contains no suitable keys for
>>>> DNS/ipa03.example@example.com)
>>>> Oct  7 18:39:16 ipa01.example.com named-pkcs11[15697]: ldap_syncrepl
>>>> will reconnect in 60 seconds
>>>>
>>>> --
>>>> 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
>>>
>>> --
>>> Matt Wells
>>> Chief Systems Architect
>>> RHCA II, RHCVA - #110-000-353
>>> (702) 808-0424
>>> matt.we...@mosaic451.com
>>>  Las Vegas | Phoenix | Portland Mosaic451.com
>>> CONFIDENTIALITY NOTICE: This transmittal is a confidential communication or
>>> may otherwise be privileged. If you are not intended recipient, you are
>>> hereby notified that you have received this transmittal in error and that
>>> any review, dissemination, distribution or copying of this transmittal is
>>> strictly prohibited. If you have received this communication in error,
>>> please notify this office, and immediately delete this message and all its
>>> attachments, if any.
>>> 1*

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

Re: [Freeipa-users] LDAP/DNS replication, IPA server service principal key issue

[Fil Di Noto]

I forgot to add the -k in the klist command. Actually the keytab looks
correct. I noticed the file permissions were 0400 named:named but all
other service keytabs I see are 0600. I thought that might be an issue
so I tried changing the permissions to 0600 on all the servers but it
hasn't changed the result.

Any clue on whether those permissions (0400) are correct? I know folks
like to do named like that with chroots and such but that seems wrong
to me.

On Fri, Oct 7, 2016 at 1:24 PM, Fil Di Noto <fdin...@gmail.com> wrote:
> klist /etc/named.keytab
> klist: Bad format in credentials cache
>
> It's actually like this on all the servers, and I assume it is only
> showing up in the logs for the 1 server because that is the server
> where we make changes and it is trying to push changes out to the
> rest.
>
> If it were any other server than an IPA server I would just manually
> ipa-getkeytab, but since it's also a KDC I'm having doubts about how
> to proceed. What do you think Matt?
>
> On Fri, Oct 7, 2016 at 1:03 PM, Matt Wells <matt.we...@mosaic451.com> wrote:
>> That's correct. Apparently it's on able to use the Kerberos credential to
>> utilize that service associated with the server.
>> Have you examined the key tab itself? Read it in and see what's inside of
>> it.
>>
>>
>> On Fri, Oct 7, 2016, 12:20 Fil Di Noto <fdin...@gmail.com> wrote:
>>>
>>> I'm trying to interpret these log messages. It seems like server ipa03
>>> has no principal for the DNS service and is not able to replicate LDAP
>>> to the other 3 IPA servers. If that is correct:
>>>
>>> 1. Is "DNS" the service principal it should be using?
>>> 2. How do I correct this?
>>> (what concerns me is that ipa03 is the server I designated as
>>> the server where administrative changes are made in case manual
>>> replication is needed)
>>>
>>>
>>> Oct  7 18:38:47 ipa02.example.com named-pkcs11[4959]: connection to
>>> the LDAP server was lost
>>> Oct  7 18:38:47 ipa02.example.com named-pkcs11[4959]: Failed to get
>>> initial credentials (TGT) using principal 'DNS/ipa03.example.com' and
>>> keytab 'FILE:/etc/named.keytab' (Keytab contains no suitable keys for
>>> DNS/ipa03.example@example.com)
>>> Oct  7 18:38:47 ipa02.example.com named-pkcs11[4959]: ldap_syncrepl
>>> will reconnect in 60 seconds
>>> Oct  7 18:39:00 ipa04.example.com named-pkcs11[4537]: connection to
>>> the LDAP server was lost
>>> Oct  7 18:39:00 ipa04.example.com named-pkcs11[4537]: Failed to get
>>> initial credentials (TGT) using principal 'DNS/ipa03.example.com' and
>>> keytab 'FILE:/etc/named.keytab' (Keytab contains no suitable keys for
>>> DNS/ipa03.example@example.com)
>>> Oct  7 18:39:00 ipa04.example.com named-pkcs11[4537]: ldap_syncrepl
>>> will reconnect in 60 seconds
>>> Oct  7 18:39:16 ipa01.example.com named-pkcs11[15697]: connection to
>>> the LDAP server was lost
>>> Oct  7 18:39:16 ipa01.example.com named-pkcs11[15697]: Failed to get
>>> initial credentials (TGT) using principal 'DNS/ipa03.example.com' and
>>> keytab 'FILE:/etc/named.keytab' (Keytab contains no suitable keys for
>>> DNS/ipa03.example@example.com)
>>> Oct  7 18:39:16 ipa01.example.com named-pkcs11[15697]: ldap_syncrepl
>>> will reconnect in 60 seconds
>>>
>>> --
>>> 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
>>
>> --
>> Matt Wells
>> Chief Systems Architect
>> RHCA II, RHCVA - #110-000-353
>> (702) 808-0424
>> matt.we...@mosaic451.com
>>  Las Vegas | Phoenix | Portland Mosaic451.com
>> CONFIDENTIALITY NOTICE: This transmittal is a confidential communication or
>> may otherwise be privileged. If you are not intended recipient, you are
>> hereby notified that you have received this transmittal in error and that
>> any review, dissemination, distribution or copying of this transmittal is
>> strictly prohibited. If you have received this communication in error,
>> please notify this office, and immediately delete this message and all its
>> attachments, if any.
>> 1*

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

Re: [Freeipa-users] LDAP/DNS replication, IPA server service principal key issue

[Fil Di Noto]

klist /etc/named.keytab
klist: Bad format in credentials cache

It's actually like this on all the servers, and I assume it is only
showing up in the logs for the 1 server because that is the server
where we make changes and it is trying to push changes out to the
rest.

If it were any other server than an IPA server I would just manually
ipa-getkeytab, but since it's also a KDC I'm having doubts about how
to proceed. What do you think Matt?

On Fri, Oct 7, 2016 at 1:03 PM, Matt Wells <matt.we...@mosaic451.com> wrote:
> That's correct. Apparently it's on able to use the Kerberos credential to
> utilize that service associated with the server.
> Have you examined the key tab itself? Read it in and see what's inside of
> it.
>
>
> On Fri, Oct 7, 2016, 12:20 Fil Di Noto <fdin...@gmail.com> wrote:
>>
>> I'm trying to interpret these log messages. It seems like server ipa03
>> has no principal for the DNS service and is not able to replicate LDAP
>> to the other 3 IPA servers. If that is correct:
>>
>> 1. Is "DNS" the service principal it should be using?
>> 2. How do I correct this?
>> (what concerns me is that ipa03 is the server I designated as
>> the server where administrative changes are made in case manual
>> replication is needed)
>>
>>
>> Oct  7 18:38:47 ipa02.example.com named-pkcs11[4959]: connection to
>> the LDAP server was lost
>> Oct  7 18:38:47 ipa02.example.com named-pkcs11[4959]: Failed to get
>> initial credentials (TGT) using principal 'DNS/ipa03.example.com' and
>> keytab 'FILE:/etc/named.keytab' (Keytab contains no suitable keys for
>> DNS/ipa03.example@example.com)
>> Oct  7 18:38:47 ipa02.example.com named-pkcs11[4959]: ldap_syncrepl
>> will reconnect in 60 seconds
>> Oct  7 18:39:00 ipa04.example.com named-pkcs11[4537]: connection to
>> the LDAP server was lost
>> Oct  7 18:39:00 ipa04.example.com named-pkcs11[4537]: Failed to get
>> initial credentials (TGT) using principal 'DNS/ipa03.example.com' and
>> keytab 'FILE:/etc/named.keytab' (Keytab contains no suitable keys for
>> DNS/ipa03.example@example.com)
>> Oct  7 18:39:00 ipa04.example.com named-pkcs11[4537]: ldap_syncrepl
>> will reconnect in 60 seconds
>> Oct  7 18:39:16 ipa01.example.com named-pkcs11[15697]: connection to
>> the LDAP server was lost
>> Oct  7 18:39:16 ipa01.example.com named-pkcs11[15697]: Failed to get
>> initial credentials (TGT) using principal 'DNS/ipa03.example.com' and
>> keytab 'FILE:/etc/named.keytab' (Keytab contains no suitable keys for
>> DNS/ipa03.example@example.com)
>> Oct  7 18:39:16 ipa01.example.com named-pkcs11[15697]: ldap_syncrepl
>> will reconnect in 60 seconds
>>
>> --
>> 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
>
> --
> Matt Wells
> Chief Systems Architect
> RHCA II, RHCVA - #110-000-353
> (702) 808-0424
> matt.we...@mosaic451.com
>  Las Vegas | Phoenix | Portland Mosaic451.com
> CONFIDENTIALITY NOTICE: This transmittal is a confidential communication or
> may otherwise be privileged. If you are not intended recipient, you are
> hereby notified that you have received this transmittal in error and that
> any review, dissemination, distribution or copying of this transmittal is
> strictly prohibited. If you have received this communication in error,
> please notify this office, and immediately delete this message and all its
> attachments, if any.
> 1*

-- 
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] LDAP/DNS replication, IPA server service principal key issue

[Fil Di Noto]

I'm trying to interpret these log messages. It seems like server ipa03
has no principal for the DNS service and is not able to replicate LDAP
to the other 3 IPA servers. If that is correct:

1. Is "DNS" the service principal it should be using?
2. How do I correct this?
(what concerns me is that ipa03 is the server I designated as
the server where administrative changes are made in case manual
replication is needed)


Oct  7 18:38:47 ipa02.example.com named-pkcs11[4959]: connection to
the LDAP server was lost
Oct  7 18:38:47 ipa02.example.com named-pkcs11[4959]: Failed to get
initial credentials (TGT) using principal 'DNS/ipa03.example.com' and
keytab 'FILE:/etc/named.keytab' (Keytab contains no suitable keys for
DNS/ipa03.example@example.com)
Oct  7 18:38:47 ipa02.example.com named-pkcs11[4959]: ldap_syncrepl
will reconnect in 60 seconds
Oct  7 18:39:00 ipa04.example.com named-pkcs11[4537]: connection to
the LDAP server was lost
Oct  7 18:39:00 ipa04.example.com named-pkcs11[4537]: Failed to get
initial credentials (TGT) using principal 'DNS/ipa03.example.com' and
keytab 'FILE:/etc/named.keytab' (Keytab contains no suitable keys for
DNS/ipa03.example@example.com)
Oct  7 18:39:00 ipa04.example.com named-pkcs11[4537]: ldap_syncrepl
will reconnect in 60 seconds
Oct  7 18:39:16 ipa01.example.com named-pkcs11[15697]: connection to
the LDAP server was lost
Oct  7 18:39:16 ipa01.example.com named-pkcs11[15697]: Failed to get
initial credentials (TGT) using principal 'DNS/ipa03.example.com' and
keytab 'FILE:/etc/named.keytab' (Keytab contains no suitable keys for
DNS/ipa03.example@example.com)
Oct  7 18:39:16 ipa01.example.com named-pkcs11[15697]: ldap_syncrepl
will reconnect in 60 seconds

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