[Freeipa-users] Easiest path to provide access to shares to Windows and Mac systems

[Kevin Vasko via FreeIPA-users]

So I feel we have a decent process for users on Linux (Ubuntu/CentOS)
to access NFS shares, however there is rumbling of people wanting to
use their Mac and Windows boxes to access the data shares.

The tricky part of this is we won't be able to enroll the Windows or
Mac systems into FreeIPA.

So is there a "simple" way to allow users on Mac and Windows that
can't be enrolled into the FreeIPA domain to access kerberized NFS
shares? I think this is going to be difficult in general to windows
and might have to swap to SMB?

For example, is there a way to download a SMB+Kerberos clients, grab
the keys from IPA and allow users to manually authenticate with kinit
and be able to access the NFS or a SMB share?
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: FreeIPA certificates to create a keystore

[Rob Crittenden via FreeIPA-users]

Hernán Fernández via FreeIPA-users wrote:
> Hello,
> 
> I have a FreeIPA server and about 7 nodes, each node has a certificate
> and a key.
> 
> I got those host certificates with:
> ipa-getcert request -v -f /etc/security/certificates/host.crt -k
> /etc/security/certificates/host.key
> 
> 
> I can see the CA certificate it's located at /etc/ipa/ca.crt. Where is
> the CAKey file?. I need to create a Keystore for the host.

You should never need the CA private key.

Maybe it's a matter of terminology. What kind of keystore are you trying
to create? Are you working from some documentation?

rob
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: Issues with certificates: X509: KEY_VALUES_MISMATCH

[Rob Crittenden via FreeIPA-users]

Dmitri Moudraninets wrote:
> Hi Rob,
> 
> ldapsearch -LLL -o ldif-wrap=no -x -D 'cn=directory manager' -W
> -b uid=ipara,ou=People,o=ipaca usercertificate
> 
> shows me the following:
> 
>         Issuer: O=CORP.MYDOMAIN.DE ,
> CN=Certificate Authority
>         Validity
>             Not Before: Dec  5 15:32:12 2017 GMT
>             Not After : *Nov 25 15:32:12 2019* GMT
> 
> It's going to expire on Monday. Can it be a problem?

You didn't provide the cert subject so I can't be sure this is the right
cert. If it contains CN = IPA RA then it is.

And yes, it expires in two days. What you'd need to do is restore it per
my previous instruction into /var/lib/ipa/ra-agent.pem on the renewal
master (ipa config-show to see which one it is).

Then run:

# getcert resubmit -f /var/lib/ipa/ra-agent.pem

That should renew the cert.

On the other masters I'd run the same command and that may fix things
there as well.

rob

> I tried this command:
> openssl x509 -text -in /var/lib/ipa/ra-agent.pem
> 
> and it shows the following:
> Certificate:
>     Data:
>         Version: 3 (0x2)
>         Serial Number: 28 (0x1c)
>     Signature Algorithm: sha256WithRSAEncryption
>         Issuer: O=CORP.MYDOMAIN.DE ,
> CN=Certificate Authority
>         Validity
>             Not Before: Oct 29 10:39:47 2019 GMT
>             Not After : Oct 29 09:39:47 2021 GMT
>         Subject: O=CORP.MYDOMAIN.DE, CN=dmud
>         Subject Public Key Info:
>             Public Key Algorithm: rsaEncryption
>                 Public-Key: (2048 bit)
>                 Modulus:
>                     00:ba:09:81:99:9b:17:99:07:5a:10:28:c8:7a:03:
> ...
>                     18:db:02:ce:b4:66:ce:5a:e9:12:af:d3:da:bf:f7:
>                     66:5f
>                 Exponent: 65537 (0x10001)
>         X509v3 extensions:
>             X509v3 Authority Key Identifier:
>                 keyid:D2:...70:BF
> 
>             X509v3 Subject Key Identifier:
>                 DE:...:51:0A
>             X509v3 Subject Alternative Name:
>                 email:d...@corp.mydomain.de
> 
>             Authority Information Access:
>                 OCSP - URI:http://ipa-ca.corp.mydomain.de/ca/ocsp
> 
> 
> I did nothing to /var/lib/ipa/ra-agent.pem yet.
> 
> 
> чт, 21 нояб. 2019 г. в 16:54, Rob Crittenden  >:
> 
> Dmitri Moudraninets wrote:
> > Hi Rob,
> >
> > Yes both masters are failing the same way. Output of openssl x509
> -noout
> > -modulus -in /var/lib/ipa/ra-agent.pem is the same on both masters.
> > Output of openssl rsa -noout -modulus -in /var/lib/ipa/ra-agent.key is
> > also the same on both masters. But the output of the first command is
> > not the same as the output of the second command.
> >
> > I can't remember that I troubleshoot any other problems but we
> tried to
> > generate some personal certificates for some users. Also we tried to
> > generate certificates with key files for some of our internal
> services.
> > We did that for the first time and it worked at the end. Also I
> changed
> > the admin password not so long ago.
> >
> >
> > Below you can find the output of the requested commands:
> >
> >
> > [root@second_master ~]# getcert list -f /var/lib/ipa/ra-agent.pem
> > Number of certificates and requests being tracked: 9.
> > Request ID '20180912151730':
> > status: MONITORING
> > stuck: no
> > key pair storage: type=FILE,location='/var/lib/ipa/ra-agent.key'
> > certificate: type=FILE,location='/var/lib/ipa/ra-agent.pem'
> > CA: dogtag-ipa-ca-renew-agent
> > issuer: CN=Certificate Authority,O=CORP.MYDOMAIN.DE
> 
> > 
> > subject: CN=dmud,O=CORP.MYDOMAIN.DE 
> 
> > *< I see a username here. Does it have
> > to be like that?*
> > expires: 2021-10-29 09:39:47 UTC
> > email: d...@corp.mydomain.de 
> >
> > key usage:
> digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
> > eku: id-kp-serverAuth,id-kp-clientAuth
> > pre-save command: /usr/libexec/ipa/certmonger/renew_ra_cert_pre
> > post-save command: /usr/libexec/ipa/certmonger/renew_ra_cert
> > track: yes
> > auto-renew: yes
> 
> Right, someone overwrote the RA agent certificate.
> 
> Look to see if the user entry in the CA has the right cert:
> 
> $ ldapsearch -LLL -o ldif-wrap=no -x -D 'cn=directory manager' -W -b
> uid=ipara,ou=People,o=ipaca usercertificate
> 
> Put the base64 value of the usercertificate attribute into a file and
> add a prefix/suffix around it:
> 
> -BEGIN CERTIFICATE-
> MIIblah=
> -END 

[Freeipa-users] Re: Issues with certificates: X509: KEY_VALUES_MISMATCH

[Dmitri Moudraninets via FreeIPA-users]

Hi Rob,

ldapsearch -LLL -o ldif-wrap=no -x -D 'cn=directory manager' -W
-b uid=ipara,ou=People,o=ipaca usercertificate

shows me the following:

Issuer: O=CORP.MYDOMAIN.DE, CN=Certificate Authority
Validity
Not Before: Dec  5 15:32:12 2017 GMT
Not After : *Nov 25 15:32:12 2019* GMT

It's going to expire on Monday. Can it be a problem?
I tried this command:
openssl x509 -text -in /var/lib/ipa/ra-agent.pem

and it shows the following:
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 28 (0x1c)
Signature Algorithm: sha256WithRSAEncryption
Issuer: O=CORP.MYDOMAIN.DE, CN=Certificate Authority
Validity
Not Before: Oct 29 10:39:47 2019 GMT
Not After : Oct 29 09:39:47 2021 GMT
Subject: O=CORP.MYDOMAIN.DE, CN=dmud
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:ba:09:81:99:9b:17:99:07:5a:10:28:c8:7a:03:
...
18:db:02:ce:b4:66:ce:5a:e9:12:af:d3:da:bf:f7:
66:5f
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Authority Key Identifier:
keyid:D2:...70:BF

X509v3 Subject Key Identifier:
DE:...:51:0A
X509v3 Subject Alternative Name:
email:d...@corp.mydomain.de
Authority Information Access:
OCSP - URI:http://ipa-ca.corp.mydomain.de/ca/ocsp


I did nothing to /var/lib/ipa/ra-agent.pem yet.


чт, 21 нояб. 2019 г. в 16:54, Rob Crittenden :

> Dmitri Moudraninets wrote:
> > Hi Rob,
> >
> > Yes both masters are failing the same way. Output of openssl x509 -noout
> > -modulus -in /var/lib/ipa/ra-agent.pem is the same on both masters.
> > Output of openssl rsa -noout -modulus -in /var/lib/ipa/ra-agent.key is
> > also the same on both masters. But the output of the first command is
> > not the same as the output of the second command.
> >
> > I can't remember that I troubleshoot any other problems but we tried to
> > generate some personal certificates for some users. Also we tried to
> > generate certificates with key files for some of our internal services.
> > We did that for the first time and it worked at the end. Also I changed
> > the admin password not so long ago.
> >
> >
> > Below you can find the output of the requested commands:
> >
> >
> > [root@second_master ~]# getcert list -f /var/lib/ipa/ra-agent.pem
> > Number of certificates and requests being tracked: 9.
> > Request ID '20180912151730':
> > status: MONITORING
> > stuck: no
> > key pair storage: type=FILE,location='/var/lib/ipa/ra-agent.key'
> > certificate: type=FILE,location='/var/lib/ipa/ra-agent.pem'
> > CA: dogtag-ipa-ca-renew-agent
> > issuer: CN=Certificate Authority,O=CORP.MYDOMAIN.DE
> > 
> > subject: CN=dmud,O=CORP.MYDOMAIN.DE 
> > *< I see a username here. Does it have
> > to be like that?*
> > expires: 2021-10-29 09:39:47 UTC
> > email: d...@corp.mydomain.de 
> > key usage:
> digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
> > eku: id-kp-serverAuth,id-kp-clientAuth
> > pre-save command: /usr/libexec/ipa/certmonger/renew_ra_cert_pre
> > post-save command: /usr/libexec/ipa/certmonger/renew_ra_cert
> > track: yes
> > auto-renew: yes
>
> Right, someone overwrote the RA agent certificate.
>
> Look to see if the user entry in the CA has the right cert:
>
> $ ldapsearch -LLL -o ldif-wrap=no -x -D 'cn=directory manager' -W -b
> uid=ipara,ou=People,o=ipaca usercertificate
>
> Put the base64 value of the usercertificate attribute into a file and
> add a prefix/suffix around it:
>
> -BEGIN CERTIFICATE-
> MIIblah=
> -END CERTIFICATE-
>
> $ openssl x509 -text -in /path/to/file
>
> If the Subject is O = CORP.MYDOMAIN.DE, CN = IPA RA then that's a good
> start. Also look at the expires date to be sure it is still valid.
>
> Assuming that is ok then re-run the openssl modulus commands to ensure
> they are the same.
>
> Assuming that too is ok then you have the proper, valid RA agent cert.
> In that case I'd move the current file out of the way, who knows what it
> is, then run:
>
> # openssl x509 -in /path/to/file -out /var/lib/ipa/ra-agent.pem (just to
> properly format the agent cert)
> # chown root:ipaapi /var/lib/ipa/ra-agent.pem
> # chmod 0440 /var/lib/ipa/ra-agent.pem
> # restorecon /var/lib/ipa/ra-agent.pem
>
> Then try something like: ipa cert-show 1
>
> This will exercise the RA agent cert and as long as you don't get an
> error back things are working again.
>
> The cert is common among all masters so you can copy the file to your
> other master(s), ensuring proper ownership, permissions and SELinux
> context.
>
> rob
>
>

-- 
WBR
Dmitry
___
FreeIPA-users