ipa-cacert-manage vs NIS support

[Harald Dunkel]

Hi folks,

I had to replace the CA chain about 3 months ago, using
ipa-cacert-manage. Question:

Does this affect freeipa's NIS support? Is there a hidden
certificate somewhere I missed to renew?

The freeipa servers are running Centos 7.3 and 7.4.

Every helpful comment is highly appreciated
Harri

[Alexander Bokovoy]

On pe, 20 loka 2017, Harald Dunkel via FreeIPA-users wrote:
> Hi folks,
>
> I had to replace the CA chain about 3 months ago, using
> ipa-cacert-manage. Question:
>
> Does this affect freeipa's NIS support? Is there a hidden
> certificate somewhere I missed to renew?

NIS does not utilize SSL as far as I know.

[Harald Dunkel]

On Fri, 20 Oct 2017 20:42:25 +0300
Alexander Bokovoy via FreeIPA-users  wrote:
> On pe, 20 loka 2017, Harald Dunkel via FreeIPA-users wrote:
> > Hi folks,
> >
> > I had to replace the CA chain about 3 months ago, using
> > ipa-cacert-manage. Question:
> >
> > Does this affect freeipa's NIS support? Is there a hidden
> > certificate somewhere I missed to renew?
>
> NIS does not utilize SSL as far as I know.

Are you sure? NIS has access to password information.

My problem is, that authentication appears to be broken on 
all NIS clients (2 AIX 6.1 hosts). The problem came up on 
Friday, 2017-10-20 at about 10:00 or 11:00.

Running getcert list on my ipa server I see certificates like

:
Request ID '20171020111318':
        status: MONITORING
        stuck: no
        key pair storage: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='subsystemCert cert-pki-ca',token='NSS Certificate DB',pin set
        certificate: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='subsystemCert cert-pki-ca',token='NSS Certificate DB'
        CA: dogtag-ipa-ca-renew-agent
        issuer: CN=Certificate Authority,O=example AG,C=DE
        subject: CN=CA Subsystem,O=example AG,C=DE
        expires: 2019-08-01 08:06:59 UTC
        key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
        eku: id-kp-serverAuth,id-kp-clientAuth
        pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad
        post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert "subsystemCert cert-pki-ca"
        track: yes
        auto-renew: yes
:

Take a look at the Request ID:

# getcert list | grep 2017
Request ID '20171020111316':
Request ID '20171020111317':
Request ID '20171020111318':
Request ID '20171020111319':
Request ID '20171020111320':
Request ID '20171020111321':
Request ID '20171020111322':
Request ID '20171020111323':
Request ID '20171020111343':

Is this just a coincidence?

Every helpful comment is highly appreciated

Harri

[Alexander Bokovoy]

On su, 22 loka 2017, Harald Dunkel wrote:
> On Fri, 20 Oct 2017 20:42:25 +0300
> Alexander Bokovoy via FreeIPA-users  wrote:
> > On pe, 20 loka 2017, Harald Dunkel via FreeIPA-users wrote:
> > > Hi folks,
> > >
> > > I had to replace the CA chain about 3 months ago, using
> > > ipa-cacert-manage. Question:
> > >
> > > Does this affect freeipa's NIS support? Is there a hidden
> > > certificate somewhere I missed to renew?
> >
> > NIS does not utilize SSL as far as I know.
>
> Are you sure? NIS has access to password information.

NIS protocol does not utilize SSL. This is why we do not recommend using
it other than a short time for migration. Communication between NIS
server and NIS client isn't secured on the network.

In addition, NIS implementation in FreeIPA uses hard-coded map
definitions that didn't change for last few years. Last change I did was
in January 2016 adding nsAccountLock support. A change before that was
in 2014. These changes are in RHEL/CentOS 7 for about a year.

The map definitions in nis plugin, however, only work with {CRYPT} type
values in userPassword attribute. All new installations use much better
schemes, like SSHA512 and before that just SSHA. These hashes aren't
directly compatible with crypt() POSIX function and thus clients would
not recognize them. NIS plugin would actually not provide hashes at all
if userPassword attribute does not start with {CRYPT}.

I don't think this is your problem, though, because then most likely
you'd see some users still being able to authenticate if their hashes
are still represented by {CRYPT} plugin. If they were able to
authenticate before and they didn't change passwords, they would be able
to authenticate now too.

{CRYPT} scheme is not in use for very long time, though. Default
password scheme in 389-ds was SHA1 since 2005 and SSHA1 since 2012.
SSHA512 was switched to in 2016. The only way you could get {CRYPT} into
FreeIPA is via migration mode by explicitly setting passwords to
encrypted values upon user creation.
> My problem is, that authentication appears to be broken on
> all NIS clients (2 AIX 6.1 hosts). The problem came up on
> Friday, 2017-10-20 at about 10:00 or 11:00.

I'd suggest reviewing configuration on those boxes. As I said, there is
nothing in NIS protocol that could help you protecting the traffic with
certificates so certificate changes wouldn't be affecting you.
> Running getcert list on my ipa server I see certificates like
>
> :
> Request ID '20171020111318':
>        status: MONITORING
>        stuck: no
>        key pair storage: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='subsystemCert cert-pki-ca',token='NSS Certificate DB',pin set
>        certificate: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='subsystemCert cert-pki-ca',token='NSS Certificate DB'
>        CA: dogtag-ipa-ca-renew-agent
>        issuer: CN=Certificate Authority,O=example AG,C=DE
>        subject: CN=CA Subsystem,O=example AG,C=DE
>        expires: 2019-08-01 08:06:59 UTC
>        key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
>        eku: id-kp-serverAuth,id-kp-clientAuth
>        pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad
>        post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert "subsystemCert cert-pki-ca"
>        track: yes
>        auto-renew: yes
> :
>
> Take a look at the Request ID:
>
> # getcert list | grep 2017
> Request ID '20171020111316':
> Request ID '20171020111317':
> Request ID '20171020111318':
> Request ID '20171020111319':
> Request ID '20171020111320':
> Request ID '20171020111321':
> Request ID '20171020111322':
> Request ID '20171020111323':
> Request ID '20171020111343':
>
> Is this just a coincidence?

Most likely it is a coincidence.

[Harald Dunkel]

On Mon, 23 Oct 2017 08:29:30 +0300
Alexander Bokovoy via FreeIPA-users  wrote:
> On su, 22 loka 2017, Harald Dunkel wrote:
> > My problem is, that authentication appears to be broken on
> > all NIS clients (2 AIX 6.1 hosts). The problem came up on
> > Friday, 2017-10-20 at about 10:00 or 11:00.
>
> I'd suggest reviewing configuration on those boxes. As I said, there is
> nothing in NIS protocol that could help you protecting the traffic with
> certificates so certificate changes wouldn't be affecting you.

I did a review on the weekend. I wasn't thinking about certificates to
authenticate the traffic between NIS client and server, but between 
the "regular" freeipa and freeipa's NIS support. Seems like NIS is 
much deeper integrated in freeipa than I expected.

ypbind seems to work on AIX. ypcat -k passwd lists passwd entries 
without password hash. (AIX 6.1 does not support an /etc/shadow file, 
AFAICT, but the users are supposed to log in via ssh public key and 
.ssh/authorized_keys. This wasn't a problem in the past.)

The problem I have now is that apparently authentication gets stuck 
completely. Even root cannot login on the console. To login I had
to boot AIX in maintenance mode and disable NIS first. If I enable
NIS again, then no login is possible.

The AIX 7.1 hosts work fine (using LDAP and Kerberos). I never made 
LDAP/Kerberos work on AIX 6.1. Maybe I have to try harder to get rid 
of NIS completely.

Thanx for your support
Harri

[Alexander Bokovoy]

On ma, 23 loka 2017, Harald Dunkel wrote:
> On Mon, 23 Oct 2017 08:29:30 +0300
> Alexander Bokovoy via FreeIPA-users  wrote:
> > On su, 22 loka 2017, Harald Dunkel wrote:
> > > My problem is, that authentication appears to be broken on
> > > all NIS clients (2 AIX 6.1 hosts). The problem came up on
> > > Friday, 2017-10-20 at about 10:00 or 11:00.
> >
> > I'd suggest reviewing configuration on those boxes. As I said, there is
> > nothing in NIS protocol that could help you protecting the traffic with
> > certificates so certificate changes wouldn't be affecting you.
>
> I did a review on the weekend. I wasn't thinking about certificates to
> authenticate the traffic between NIS client and server, but between
> the "regular" freeipa and freeipa's NIS support. Seems like NIS is
> much deeper integrated in freeipa than I expected.

NIS server is a plugin to FreeIPA LDAP server, running in the same
instance and performing internal queries. It is not affected by any
external LDAP client changes because it is part of the LDAP server
itself.
> ypbind seems to work on AIX. ypcat -k passwd lists passwd entries
> without password hash. (AIX 6.1 does not support an /etc/shadow file,
> AFAICT, but the users are supposed to log in via ssh public key and
> .ssh/authorized_keys. This wasn't a problem in the past.)
>
> The problem I have now is that apparently authentication gets stuck
> completely. Even root cannot login on the console. To login I had
> to boot AIX in maintenance mode and disable NIS first. If I enable
> NIS again, then no login is possible.

So, NIS client can still get data from NIS server? Just AIX login fails?

If ypcat -k passwd doesn't block on accessing the server, then the issue
likely is not on an LDAP server side. Otherwise NIS server plugin in
LDAP server would be blocking itself and you'd see it as ypcat not
retrieving the data at all.