On su, 22 loka 2017, Harald Dunkel wrote:
On Fri, 20 Oct 2017 20:42:25 +0300
Alexander Bokovoy via FreeIPA-users <freeipa-users@lists.fedorahosted.org>
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.
--
/ Alexander Bokovoy
_______________________________________________
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
