ipa-getcert and java certstore/keytool
by Jochen Hein
Hi,
I'm playing around with keycloak and wanted to use an SSL certificate
from IPA. I've looked around but didn't see any howto about using java
keytool with ipa-getcert. Has someone experience with it?
I was not successful adding key/cert created by certmonger into keytool,
and also not successful signing a csr from keytool with IPA. If noone
has hints, I'll try again and provide commands/logs...
Jochen
--
This space is intentionally left blank.
6 years, 8 months
Re: Trying To Connect FreeIPA with OKTA/OneLogin/Bitium
by Guillermo Fuentes
Hi Chris and all!
Chris, thanks for putting together the guide on integrating FreeIPA with Okta.
The integration works fine except for accounts with expired passwords.
Okta will allow login for an account with an expired password.
Although the guide says "This is all well documented and supported
within OKTA.", Okta's support team said they haven't tested the
integration with FreeIPA and for OKTA to recognize the password has
expired, the user has to have the pwdReset attribute set to TRUE (for
expired) or FALSE
(https://support.okta.com/help/Documentation/Knowledge_Article/Configuring...).
I can't find the pwdReset attribute anywhere in the FreeIPA schema
which will suggest me I'll have to extend it, unless Okta is willing
to recognize and honor the krbPasswordExpiration attribute used in the
guide.
Did you or someone in the list have gotten this to work properly?
Thanks so much in advance,
Guillermo
------------
From: Chris Whittle <cwhittl gmail com>
To: dpal redhat com
Cc: freeipa-users <freeipa-users redhat com>
Subject: Re: [Freeipa-users] Trying To Connect FreeIPA with OKTA/OneLogin/Bitium
Date: Tue, 12 Aug 2014 08:46:26 -0500
http://www.freeipa.org/page/HowTo/Integrate_With_Okta
On Sat, Aug 9, 2014 at 11:31 PM, Dmitri Pal <dpal redhat com> wrote:
>
> On 08/08/2014 04:26 PM, Chris Whittle wrote:
...
6 years, 8 months
SUDO Rules not getting processed
by Alka Murali
Hello,
I have implemented a freeipa server and enrolled many clients like Ubuntu,
Debian, CentOS. In all those clients, my sudo rules worked.
However if I try the sudo rules to the users in Ubuntu 16, its not
recognising the sudo user
------
Aug 4 19:22:40 **** sudo: pam_unix(sudo:auth): authentication failure;
logname=device uid=1441000030 euid=0 tty=/dev/pts/1 ruser=device rhost=
user=device
Aug 4 19:22:40 ***** sudo: pam_sss(sudo:auth): authentication success;
logname=device uid=1441000030 euid=0 tty=/dev/pts/1 ruser=device rhost=
user=device
Aug 4 19:22:40 ***** sudo: device : user NOT authorized on host ;
TTY=pts/1 ; PWD=/home/device ; USER=root ; COMMAND=/usr/bin/less
/var/log/syslog
-------
I have updated the sssd and ldap configuration file as well as nssswitch
conf. However the rule was not being accepted.
I have properly configured SSSD, LDAP and NSS. Let me know if any
additional settings needs to be updated.
Awaiting your reply.
Thanks and Regards,
Alka Murali
6 years, 8 months
Extended Schema attributes missing
by Randy Morgan
When we setup our IPA server, we extended the schema to include 3 fields
that were important to the work we do. When we performed the last
update, those fields still show as required, but they are missing and we
cannot add users to IPA unless we remove the required aspect of those
fields. The problem is we need those fields. Was there something in
the last update that relocated libraries or changed the locations for
extensions to the schema in IPA? We are running RHEL 7.3 and IPA 4.4.0.
Thanks in advance,
Randy
--
Randy Morgan
CSR
Department of Chemistry and Biochemistry
Brigham Young University
801-422-4100
6 years, 8 months
Re: Chrome 58 Doesn't Trust SSL Certificates Signed by FreeIPA
by Fraser Tweedale
On Mon, Jul 17, 2017 at 08:41:26AM -0400, Prasun Gera wrote:
> Bumping this for help. I need to renew my replica's SSL certificate which
> will expire in a month, but I can't find any instructions. It looks like
> the replica's web-ui cert isn't tracked by the master or the replica. I'm
> using a pretty stock installation with no external CAs or certs. So
> ideally, all of this should have been handled automatically by ipa, but it
> isn't. There have also been quite a few cert related posts of late which
> makes me think if there are (were) some other issues with replica setup a
> couple of years ago, which is when the certs were originally generated.
>
Hi Prasun,
You can add a tracking request to Certmonger for the cert:
% ipa-getcert start-tracking -d /etc/httpd/alias -n Server-Cert \
-p /etc/httpd/alias/pwdfile.txt \
-K ldap/<hostname>@<realm> -D <hostname>
The `-D <hostname>` option will ensure that the CSR contains the
subject alt name for <hostname>, which will in turn be propagated to
the issued certificiate.
Once the tracking request is set up you can renew the cert via
`ipa-getcert resubmit -i <request-id>`.
Cheers,
Fraser
> On Sun, Apr 23, 2017 at 10:08 PM, Prasun Gera <prasun.gera(a)gmail.com> wrote:
>
> > I tried that, but the replica's "getcert list" doesn't seem to show any
> > results. "Number of certificates and requests being tracked: 0." Is that
> > expected ?
> >
> > On Sun, Apr 23, 2017 at 8:50 PM, Fraser Tweedale <ftweedal(a)redhat.com>
> > wrote:
> >
> >> On Sun, Apr 23, 2017 at 03:32:19AM -0400, Prasun Gera wrote:
> >> > Thank you. That worked for the master. How do I fix the replica's cert ?
> >> > This is on ipa-server-4.4.0-14.el7_3.7.x86_64 on RHEL7. I am not using
> >> > ipa's DNS at all. Did this happen because of that ?
> >> >
> >> This is not related to DNS.
> >>
> >> To fix the replica, log onto the host and perform the same steps
> >> with Certmonger there. The tracking Request ID will be different
> >> but otherwise the process is the same.
> >>
> >> Cheers,
> >> Fraser
> >>
> >> > On Thu, Apr 20, 2017 at 9:06 PM, Fraser Tweedale <ftweedal(a)redhat.com>
> >> > wrote:
> >> >
> >> > > On Thu, Apr 20, 2017 at 07:31:16PM -0400, Prasun Gera wrote:
> >> > > > I can confirm that I see this behaviour too. My ipa server install
> >> is a
> >> > > > pretty stock install with no 3rd party certificates.
> >> > > >
> >> > > > On Thu, Apr 20, 2017 at 5:46 PM, Simon Williams <
> >> > > > simon.williams(a)thehelpfulcat.com> wrote:
> >> > > >
> >> > > > > Yesterday, Chrome on both my Ubuntu and Windows machines updated
> >> to
> >> > > > > version 58.0.3029.81. It appears that this version of Chrome
> >> will not
> >> > > > > trust certificates based on Common Name. Looking at the Chrome
> >> > > > > documentation and borne out by one of the messages, from Chrome
> >> 58,
> >> > > > > the subjectAltName is required to identify the DNS name of the
> >> host
> >> > > that
> >> > > > > the certificate is issued for. I would be grateful if someone
> >> could
> >> > > point
> >> > > > > me in the direction of how to recreate my SSL certificates so that
> >> > > > > the subjectAltName is populated.
> >> > > > >
> >> > > > > Thanks in advance
> >> > > > >
> >> > > > > --
> >> > > > > 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
> >> > > > >
> >> > > Which version of IPA are you using?
> >> > >
> >> > > The first thing you should do, which I think should be sufficient in
> >> > > most cases, is to tell certmonger to submit a new cert request for
> >> > > each affected certificate, instructing to include the relevant
> >> > > DNSName in the subjectAltName extension in the CSR.
> >> > >
> >> > > To list certmonger tracking requests and look for the HTTPS
> >> > > certificate. For example:
> >> > >
> >> > > $ getcert list
> >> > > Number of certificate and requests being tracked: 11
> >> > > ...
> >> > > Request ID '20170418012901':
> >> > > status: MONITORING
> >> > > stuck: no
> >> > > key pair storage: type=NSSDB,location='/etc/
> >> > > httpd/alias',nickname='Server-Cert',token='NSS Certificate
> >> > > DB',pinfile='/etc/httpd/alias/pwdfile.txt'
> >> > > certificate: type=NSSDB,location='/etc/
> >> > > httpd/alias',nickname='Server-Cert',token='NSS Certificate DB'
> >> > > CA: IPA
> >> > > issuer: CN=Certificate Authority,O=IPA.LOCAL 201703211317
> >> > > subject: CN=f25-2.ipa.local,O=IPA.LOCAL 201703211317
> >> > > expires: 2019-03-22 03:20:19 UTC
> >> > > dns: f25-2.ipa.local
> >> > > key usage: digitalSignature,nonRepudiatio
> >> n,keyEncipherment,
> >> > > dataEncipherment
> >> > > eku: id-kp-serverAuth,id-kp-clientAuth
> >> > > pre-save command:
> >> > > post-save command: /usr/libexec/ipa/certmonger/re
> >> start_httpd
> >> > > track: yes
> >> > > auto-renew: yes
> >> > > ...
> >> > >
> >> > > Using the Request ID of the HTTPS certificate, resubmit the request
> >> > > but use the ``-D <hostname>`` option to specify a DNSName to include
> >> > > in the SAN extension:
> >> > >
> >> > > $ getcert resubmit -i <Request ID> -D <hostname>
> >> > >
> >> > > ``-D <hostname>`` can be specified multiple times, if necessary.
> >> > >
> >> > > This should request a new certificate that will have the server DNS
> >> > > name in the SAN extension.
> >> > >
> >> > > HTH,
> >> > > Fraser
> >> > >
> >>
> >
> >
6 years, 8 months
Deleting revoked certs from CA master
by Mark Haney
So now that we have a nicely replicating domain and ca, I'd like to rid
myself of these revoked certificates which I tried as a way to fix the
replication and setting up of a CA. Is there a way to delete these
certs out of the store?
--
Mark Haney
Network Engineer at NeoNova
919-460-3330 option 1
mark.haney(a)neonova.net
www.neonova.net
6 years, 8 months
custom attributes as a part of default ipa permissions
by Petr Fišer
Hello,
We are currently deploying FreeIPA and we make use of custom attributes.
We defined them in custom.py script (located in
/usr/lib/python2.7/site-packages/ipaserver/plugins/custom.py). custom.py
looks like this:
from ipaserver.plugins.user import user
from ipalib.parameters import Int
from ipalib.parameters import Str
from ipalib import _
user.user.takes_params = user.user.takes_params + (
Str('mailroutingaddress?',
cli_name='mailroutingaddress'
label=_('Mail routing address'),)
)
This works fine, server makes the attribute visible through API and also
the "ipa" command can work with it. Basically, we made those attributes
part of our default.
However, users (ordinary user in FreeIPA and also sysaccounts) cannot
access those attributes when binding directly to the LDAP. This is due
to ACI that FreeIPA writes into the LDAP.
I know that in FreeIPA:
* For user himself, ldap://self filter can be defined with "ipa
selfservice-add 'some name' --attrs=mailroutingaddress
--permissions=read" .
* For user to read attributes of other users, I can define permission,
privilege and role and add this role to a user or group.
* For sysaccounts, it is advised to define custom ACI in the LDAP itself.
What I am thinking of: Is there any way that I can make FreeIPA
re-generate its LDAP ACI based on our extended user class? Say let the
IPA server load our custom.py which extends "user" with
"mailroutingaddress" attribute and then call "ipa whatever" which
effectively modifies FreeIPA's notion of user class and redefines the ACI?
Kind regards,
--
Petr Fišer
BCV solutions s.r.o.
Mobile: +420 607 618 243
E-mail: petr.fiser(a)bcvsolutions.eu
Jabber: petr.fiser(a)bcvsolutions.eu
6 years, 8 months
OSX (El Capitan) - FreeIPA
by Luiz Garrido ALKEMY X
Hi,
We have an environment with mixed OSX and CentOS computers and IPA is
working great for almost everything.
The only problem that we have (besides the known ones) is that the IPA
user logged to an OSX computer is not getting group information. Logged
to a CentOS, the `id` command shows all the groups assigned to the user
but running the same command on an OSX under the same user, the groups
are different, mainly Apple groups and not our IPA groups. Does anyone
had this problem?
So, because of this, ACL permissions on our NFS server is not working
for OSX machines, but are working great for CentOS ones.
Thanks!
Luiz Garrido
6 years, 8 months
Unable to re-join CentOS client to FreeIPA
by Alexandre Pitre
I'm unable to rejoin a CentOS client to my FreeIPA realm. I ran the
uninstall command on my client: ipa-client-install --uninstall
As far as I know the uninstall was successful. It asked me to reboot. After
rebooting if I try to rerun the install command:
ipa-client-install -U -p admin -w P@ssw0rd! --enable-dns-updates
--mkhomedir --domain=customdomain.ad.com --realm=IPA.AD.COM --server=
ipa01.ipa.ad.com --server=ipa02.ipa.ad.com --no-ntp --debug
FYI, we're using a different DNS domain than our freeIPA realm, hence why
I have to provide all those flags.
Running the install command failed. Here's the output from
/var/log/ipa-client-uninstall.log
2017-08-03T19:17:58Z DEBUG stderr=
2017-08-03T19:17:58Z DEBUG trying to retrieve CA cert via LDAP from
ipa-01.ipa.ad.com
2017-08-03T19:17:58Z DEBUG get_ca_certs_from_ldap() error:
Insufficientaccess: SASL(-1): generic failure: GSSAPI Error: Unspecified
GSS failure. Minor code may provide more information (Server krbtgt/
AD.COM(a)IPA.AD.COM not found in Kerberos database)
2017-08-03T19:17:58Z DEBUG Insufficient access: SASL(-1): generic failure:
GSSAPI Error: Unspecified GSS failure. Minor code may provide more
information (Server krbtgt/AD.COM(a)IPA.AD.COM not found in Kerberos database)
2017-08-03T19:17:58Z ERROR In unattended mode without a One Time Password
(OTP) or without --ca-cert-file You must specify --force to retrieve the CA
cert using HTTP
2017-08-03T19:17:58Z ERROR Cannot obtain CA certificate HTTP certificate
download requires --force
2017-08-03T19:17:58Z ERROR Installation failed. Rolling back changes.
2017-08-03T19:17:58Z ERROR IPA client is not configured on this system.
Do I need to run/clean something else ? This error is consistent with all
of the client I tried to re-join.
Thanks for your help,
Alex
6 years, 8 months
