Force users to create OTP token on first login
by Russ Long
Is there a way to put a policy or something in place, so when users login for the first time, they are forced to create an OTP Token? We need to force OTP into the system as well as the servers that authenticate with it.
Thanks!
3 months, 2 weeks
Re: CA Master Confusion
by Florence Blanc-Renaud
On 8/6/19 9:21 PM, Auerbach, Steven via FreeIPA-users wrote:
> As I work through understanding the current state of my CA mastering in this realm I am getting results I do not understand from these ipa commands (on the v4.6.4 server) and from the ldapsearch commands (on the v3.0.0 server):
> On the v4.6.4 replica (ipa<3>):
> $ sudo ipa config-show |grep 'CA renewal master'
> [sudo] password for <user>:
> $
> $
>
> On the v3.0.0 (ipa<1>):
> $ sudo ldapsearch -H ldap://$HOSTNAME -D 'cn=Directory Manager' -W -b 'cn=masters,cn=ipa,cn=etc,dc=fbog,dc=local' '(&(cn=CA)(ipaConfigString=caRenewalMaster))' dn
> [sudo] password for <user>:
> Enter LDAP Password:
> # extended LDIF
> #
> # LDAPv3
> # base <cn=masters,cn=ipa,cn=etc,dc=<mydomain>,dc=local> with scope subtree
> # filter: (&(cn=CA)(ipaConfigString=caRenewalMaster))
> # requesting: dn
> #
>
> # search result
> search: 2
> result: 0 Success
>
> # numResponses: 1
>
Hi,
the ipaConfigString=caRenewalMaster attribute was introduced in freeIPA
4.0 (please see [1] Howto/Promote_CA_to_Renewal_and_CRL_Master), hence I
am not surprised that the search does not return anything.
When the 3.0 server was installed, the attribute did not exist yet. When
the 4.x replica was installed, the attribute was not added since the new
replica wasn't CA master.
As the attribute is not set at all, the ipa config-show command
(internally using the same ldapsearch you did) is unable to find a CA
master.
If you want to move the CA master role to ipa3, just follow the steps in
[1], making sure to apply the steps for the corresponding IPA version.
Also please note that we do not recommend using versions 3.x and 4.x
together over a long period of time. This is completely OK when you want
to migrate but once you have ensured all the services are properly
working, the 3.x master should be decommissioned. Please see [2].
HTH,
flo
[1] https://www.freeipa.org/page/Howto/Promote_CA_to_Renewal_and_CRL_Master
[2]
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/...
>
>
> Neither tells me anything. Is it possible that the original installation never had a CA master at all? This seems odd considering when I look for CA Master(s), on the v4.6.4 (ipa<3>) tells me:
>
> $ sudo ipa server-role-find --role 'CA server'
> [sudo] password for <user>:
> ----------------------
> 3 server roles matched
> ----------------------
> Server name: ipa<2>.mydomain.local
> Role name: CA server
> Role status: absent
>
> Server name: ipa<1>.mydomain.local
> Role name: CA server
> Role status: enabled
>
> Server name: ipa<3>.mydomain.local
> Role name: CA server
> Role status: absent
> ----------------------------
> Number of entries returned 3
> ----------------------------
>
> And on the v3.0.0 (ipa<1>) I get:
>
> $ sudo ldapsearch -H ldap://$HOSTNAME -D 'cn=Directory Manager' -W -b 'cn=masters,cn=ipa,cn=etc,dc=<mydomain>,dc=local' '(&(cn=CA)(ipaConfigString=caServer))' dn
> Enter LDAP Password:
> # extended LDIF
> #
> # LDAPv3
> # base <cn=masters,cn=ipa,cn=etc,dc=fbog,dc=local> with scope subtree
> # filter: (&(cn=CA)(ipaConfigString=caServer))
> # requesting: dn
> #
>
> # search result
> search: 2
> result: 0 Success
>
> # numResponses: 1
>
> I know I am missing something basic and fundamental here. Is there a CA Master or not? If not, would I want to just enable the CA Master on the newest server (ipa<3>)?
>
> The way forward is not clear.
> -Steven Auerbach
> _______________________________________________
> FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-leave(a)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.fedoraho...
>
3 months, 3 weeks
ipa vault: internal error, "Invalid Credential"
by Dmitry Perets
Hi,
Pretty much any vault-related calls in one of my environments result in the internal error, although the call seems to (partially) succeed.
For example:
# ipa vault-add test --type standard
ipa: ERROR: an internal error has occurred
But the vault is created:
# ipa vault-find
---------------
1 vault matched
---------------
Vault name: test
Type: standard
Vault user: admin
----------------------------
Number of entries returned 1
----------------------------
I'll get the same erorr if I try "ipa vault-del", "vault-archive" or "vault-retrieve".
At the same time, the following is written in /var/log/messages:
Sep 19 23:54:39 t-idm-ber800-1 server: Invalid Credential.
Sep 19 23:54:39 t-idm-ber800-1 server: at com.netscape.cmscore.authentication.CertUserDBAuthentication.authenticate(CertUserDBAuthentication.java:174)
Sep 19 23:54:39 t-idm-ber800-1 server: at com.netscape.cms.realm.PKIRealm.authenticate(PKIRealm.java:112)
Sep 19 23:54:39 t-idm-ber800-1 server: at com.netscape.cms.tomcat.ProxyRealm.authenticate(ProxyRealm.java:85)
Sep 19 23:54:39 t-idm-ber800-1 server: at org.apache.catalina.authenticator.SSLAuthenticator.authenticate(SSLAuthenticator.java:114)
Sep 19 23:54:39 t-idm-ber800-1 server: at com.netscape.cms.tomcat.SSLAuthenticatorWithFallback.doSubAuthenticate(SSLAuthenticatorWithFallback.java:47)
Sep 19 23:54:39 t-idm-ber800-1 server: at com.netscape.cms.tomcat.AbstractPKIAuthenticator.doAuthenticate(AbstractPKIAuthenticator.java:89)
Sep 19 23:54:39 t-idm-ber800-1 server: at com.netscape.cms.tomcat.SSLAuthenticatorWithFallback.authenticate(SSLAuthenticatorWithFallback.java:59)
Sep 19 23:54:39 t-idm-ber800-1 server: at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:578)
Sep 19 23:54:39 t-idm-ber800-1 server: at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:169)
Sep 19 23:54:39 t-idm-ber800-1 server: at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:103)
Sep 19 23:54:39 t-idm-ber800-1 server: at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:962)
Sep 19 23:54:39 t-idm-ber800-1 server: at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:116)
Sep 19 23:54:39 t-idm-ber800-1 server: at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:445)
Sep 19 23:54:39 t-idm-ber800-1 server: at org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:190)
Sep 19 23:54:39 t-idm-ber800-1 server: at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:637)
Sep 19 23:54:39 t-idm-ber800-1 server: at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:316)
Sep 19 23:54:39 t-idm-ber800-1 server: at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
Sep 19 23:54:39 t-idm-ber800-1 server: at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
Sep 19 23:54:39 t-idm-ber800-1 server: at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
Sep 19 23:54:39 t-idm-ber800-1 server: at java.lang.Thread.run(Thread.java:748)
Any idea what could go wrong here....?
Thanks.
Info: ipa-server 4.6.4 on RHEL 7.6, and I am running these commands from the IPA server itself, on which CA and KRA are installed (in fact, it's the only active CA/KRA master in that environment).
---
Regards,
Dmitry Perets
3 months, 3 weeks
Re: Enabling more FreeIPA CA servers
by Fraser Tweedale
Hi Stuart,
Adding the freeipa-users@ mailing list for visibility.
I'd have to work through your scenario to work out why it fails.
But it may be some time before I get around to that.
I think your idea to first try creating a CA replica on F28 before
moving forward to F30 is a sensible thing to try.
One question though: are you on Domain Level 0 or 1?
(`ipa domainlevel-get`).
Cheers,
Fraser
On Thu, Sep 26, 2019 at 07:35:58PM +0100, Stuart McRobert wrote:
> Dear Fraser,
>
> I've read through lots of posts but I am uncertain about the best way
> forward and wonder if I could seek your guidance? I just don't want to break
> things.
>
> Currently we have three freeipa servers (1-3) on Fedora 26 (clearly need
> updating) with ipa VERSION: 4.4.4, API_VERSION: 2.215 and one new Fedora 30
> server (#4) which I just started to add with VERSION: 4.8.1, API_VERSION:
> 2.233.
>
> The reason for adding a new server before updating the others is the web
> interface warning:
>
> Warning: Only One CA Server Detected
> It is strongly recommended to keep the CA services installed on more than
> one server
>
> which I fully understand is not good, but it doesn't offer to just fix it!
>
> I suspect server #4 may be too new, failing with both
>
> ipa-replica-install --setup-ca
>
> and
>
> ipa-ca-install
>
> in a very similar way, e.g.
>
> 2019-09-26T16:18:15Z ERROR Unable to log in as uid=admin-freeipa04.services.nsa.stats.ox.ac.uk,ou=people,o=ipaca on ldap://freeipa01.services.nsa.stats.ox.ac.uk:389
> 2019-09-26T16:18:15Z DEBUG Traceback (most recent call last):
> File "/usr/lib/python3.7/site-packages/ipaserver/install/service.py", line 603, in start_creation
> run_step(full_msg, method)
> File "/usr/lib/python3.7/site-packages/ipaserver/install/service.py", line 589, in run_step
> method()
> File "/usr/lib/python3.7/site-packages/ipaserver/install/dogtaginstance.py", line 503, in setup_admin
> self.admin_dn, master_conn
> ipalib.errors.NotFound: uid=admin-freeipa04.services.nsa.stats.ox.ac.uk,ou=people,o=ipaca did not replicate to ldap://freeipa01.services.nsa.stats.ox.ac.uk:389
>
> 2019-09-26T16:18:15Z DEBUG [error] NotFound: uid=admin-freeipa04.services.nsa.stats.ox.ac.uk,ou=people,o=ipaca did not replicate to ldap://freeipa01.services.nsa.stats.ox.ac.uk:389
>
>
> which I think others have also run into.
>
> Next thought was to confirm what we had:
>
> [root@freeipa01 ~]# ipa server-find
> ---------------------
> 4 IPA servers matched
> ---------------------
> Server name: freeipa01.services.nsa.stats.ox.ac.uk F26
>
> Server name: freeipa02.services.nsa.stats.ox.ac.uk F26
>
> Server name: freeipa03.services.nsa.stats.ox.ac.uk F26
>
> Server name: freeipa04.services.nsa.stats.ox.ac.uk F30
> ----------------------------
> Number of entries returned 4
> ----------------------------
> [root@freeipa01 ~]# ipa server-role-find --role "CA server"
> ----------------------
> 4 server roles matched
> ----------------------
> Server name: freeipa01.services.nsa.stats.ox.ac.uk
> Role name: CA server
> Role status: enabled
>
> Server name: freeipa02.services.nsa.stats.ox.ac.uk
> Role name: CA server
> Role status: absent
>
> Server name: freeipa03.services.nsa.stats.ox.ac.uk
> Role name: CA server
> Role status: absent
>
> Server name: freeipa04.services.nsa.stats.ox.ac.uk
> Role name: CA server
> Role status: absent
> ----------------------------
> Number of entries returned 4
> ----------------------------
>
>
> and then find out how to change the "Role status:" to enabled, starting on
> freeipa02 but I am not sure how to achieve this, e.g.
>
>
> [root@freeipa02 ~]# ipa-ca-install
> CA is already installed on this host.
>
> true but doesn't really help. Sorry if this is very easy to do with a
> command I have totally missed.
>
> Currently I know if freeipa01 fails, client logins also fail, and I assume
> this is because it is the only CA server enabled.
>
> Work plan:
>
> 1. Enable more CA servers
>
> 2. Update Fedora 26 to 30, perhaps via 28 first if advised not to jump too
> far at once, probably updating servers #2, then #3 and finally #1.
>
> 3. Add more servers for resiliency
>
>
> Any idea how to get more CA servers enabled or any other suggestions?
>
> Many thanks
>
> Best wishes
>
> Stuart
3 months, 3 weeks
Re: Enabling more FreeIPA CA servers
by Fraser Tweedale
On Mon, Sep 30, 2019 at 08:19:15AM +0100, Stuart McRobert wrote:
> Dear Fraser,
>
> Thanks, I've retained the CC but will probably need to join.
>
> > I think your idea to first try creating a CA replica on F28 before
> > moving forward to F30 is a sensible thing to try.
>
> I will explore adding a F28 replica
>
> > One question though: are you on Domain Level 0 or 1?
> > (`ipa domainlevel-get`).
>
> All four servers currently report:
>
> % ipa domainlevel-get
> -----------------------
> Current domain level: 1
> -----------------------
>
> This isn't something I've custom set, and earlier I thought the original
> three servers were at level 0 with only the new F30 one at 1.
>
Thanks for confirming Stuart. This setting is not surprising and it
is the value we want. I will try to find time to carry out some
tests on f26 -> f30 replica creation later this week.
Cheers,
Fraser
> Best wishes
>
> Stuart
>
3 months, 3 weeks
Configuring Windows 10 to use FreeIPA
by Joyce Babu
I followed the instructions for setting up Windows10 to use FreeIPA for
authentication
https://www.freeipa.org/page/Windows_authentication_against_FreeIPA
After following the instruction, the default domain displayed on windows 10
login screen is EXAMPLE and EXAMPLE.COM. I am able to login by entering
EXAMPLE.COM\user as the username. But when I enter the username without the
leading domain name, login fails with 'Client not found in Kerberos
database' error.
Sep 27 17:17:58 ipa.example.org krb5kdc[419](info): AS_REQ (6 etypes
{aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17),
DEPRECATED:arcfour-hmac(23), DEPRECATED:arcfour-hmac-exp(24), (-135),
DEPRECATED:des-cbc-md5(3)}) 192.168.0.185: CLIENT_NOT_FOUND: user@EXAMPLE
for krbtgt/EXAMPLE@EXAMPLE, Client not found in Kerberos database
Is it possible to change the default domain in windows login screen to
EXAMPLE.COM from EXAMPLE?
Thanks,
Joyce Babu
3 months, 4 weeks
getcert list status: NEED_CA issue
by Satish Patel
Few days ago my Master CA was messed up and getcert list was showing
empty list (no cert to track)
So i run following command to add certs manually:
getcert start-tracking -d /etc/pki/pki-tomcat/alias -n
'ocspSigningCert cert-pki-ca' -P XXXXXXX
getcert start-tracking -d /etc/pki/pki-tomcat/alias -n
'auditSigningCert cert-pki-ca' -P XXXXXXX
getcert start-tracking -d /etc/pki/pki-tomcat/alias -n 'subsystemCert
cert-pki-ca' -P XXXXXXX
getcert start-tracking -d /etc/pki/pki-tomcat/alias -n 'Godaddy' -P XXXXXXX
getcert start-tracking -d /etc/pki/pki-tomcat/alias -n 'Godaddy
Intermediate' -P XXXXXXX
And after that i am seeing this status (status: NEED_CA ) it should
be MONITORING right?
# getcert list
Number of certificates and requests being tracked: 12.
Request ID '20190915042927':
status: NEED_CA
stuck: yes
key pair storage:
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='caSigningCert
cert-pki-ca',token='NSS Certificate DB',pin set
certificate: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='caSigningCert
cert-pki-ca',token='NSS Certificate DB'
issuer: CN=Certificate Authority,O=example.com
subject: CN=Certificate Authority,O=example.com
expires: 2037-01-05 14:47:24 UTC
key usage: digitalSignature,nonRepudiation,keyCertSign,cRLSign
pre-save command:
post-save command:
track: yes
auto-renew: yes
Request ID '20190915043150':
status: NEED_CA
stuck: yes
key pair storage:
type=NSSDB,location='/etc/pki/pki-tomcat/alaas',nickname='Server-Cert
cert-pki-ca',token='NSS Certificate DB',pin set
certificate: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='Server-Cert
cert-pki-ca',token='NSS Certificate DB'
issuer: CN=Certificate Authority,O=example.com
subject: CN=ldap-example-5-1.foo.example.com,O=example.com
expires: 2020-11-17 18:30:29 UTC
key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
eku: id-kp-serverAuth,id-kp-clientAuth
pre-save command:
post-save command:
track: yes
auto-renew: yes
Request ID '20190915043212':
status: NEED_CA
stuck: yes
key pair storage:
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='ocspSigningCert
cert-pki-ca',token='NSS Certificate DB',pin set
certificate: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='ocspSigningCert
cert-pki-ca',token='NSS Certificate DB'
issuer: CN=Certificate Authority,O=example.com
subject: CN=OCSP Subsystem,O=example.com
expires: 2020-11-17 18:31:26 UTC
eku: id-kp-OCSPSigning
pre-save command:
post-save command:
track: yes
auto-renew: yes
4 months
inconsistency when reading server roles ?
by Eugène Adell
Hello,
I am using freeipa 4.5.0.21 (full details below) and I noticed a weird
behaviour. When getting informations about a server with a regular
user, it won't show the server roles while these roles will be given
when checking the server roles themselves. In this case the roles are
of 'configured' status instead of 'enabled' (which is probably what
would be expected).
As it's not documented in the official Guide and I didn't find
anything in the mail archive, I believe some clarification is needed.
Should server roles be found through some commands but not others ? Is
there any security issue of showing them always ?
(user)
# ipa server-show srv3.idm.local --all
dn: cn=srv3.idm.local,cn=masters,cn=ipa,cn=etc,dc=idm,dc=local
Server name: srv3.idm.local
Enabled server roles:
objectclass: top, nsContainer, ipaReplTopoManagedServer,
ipaConfigObject, ipaSupportedDomainLevelConfig
(user)
# ipa server-role-show srv3.idm.local 'NTP server'
Server name: srv3.idm.local
Role name: NTP server
Role status: configured
(admin)
# ipa server-show srv3.idm.local --all
dn: cn=srv3.idm.local,cn=masters,cn=ipa,cn=etc,dc=idm,dc=local
Server name: srv3.idm.local
Managed suffixes: domain, ca
Min domain level: 0
Max domain level: 1
Enabled server roles: CA server, DNS server, NTP server
objectclass: top, nsContainer, ipaReplTopoManagedServer,
ipaConfigObject, ipaSupportedDomainLevelConfig
# yum info ipa-server -v
Loading "fastestmirror" plugin
Config time: 0.008
Yum version: 3.4.3
rpmdb time: 0.000
Setting up Package Sacks
Loading mirror speeds from cached hostfile
pkgsack time: 0.004
Installed Packages
Name : ipa-server
Arch : x86_64
Version : 4.5.0
Release : 21.el7.centos.2.2
Size : 1.0 M
Repo : installed
From repo : ipa
Committer : Johnny Hughes <johnny(a)centos.org>
Committime : Thu Oct 19 14:00:00 2017
Buildtime : Thu Oct 19 22:52:09 2017
Install time: Mon Sep 23 21:46:46 2019
Installed by: root <root>
Changed by : System <unset>
Summary : The IPA authentication server
URL : http://www.freeipa.org/
Licence : GPLv3+
Description : IPA is an integrated solution to provide centrally
managed Identity (users,
: hosts, services), Authentication (SSO, 2FA), and Authorization
: (host access control, SELinux user roles, services). The
solution provides
: features for further integration with Linux based
clients (SUDO, automount)
: and integration with Active Directory based
infrastructures (Trusts).
: If you are installing an IPA server, you need to install
this package.
# cat /etc/*release*
CentOS Linux release 7.4.1708 (Core)
Derived from Red Hat Enterprise Linux 7.4 (Source)
NAME="CentOS Linux"
VERSION="7 (Core)"
ID="centos"
ID_LIKE="rhel fedora"
VERSION_ID="7"
PRETTY_NAME="CentOS Linux 7 (Core)"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:centos:centos:7"
HOME_URL="https://www.centos.org/"
BUG_REPORT_URL="https://bugs.centos.org/"
CENTOS_MANTISBT_PROJECT="CentOS-7"
CENTOS_MANTISBT_PROJECT_VERSION="7"
REDHAT_SUPPORT_PRODUCT="centos"
REDHAT_SUPPORT_PRODUCT_VERSION="7"
CentOS Linux release 7.4.1708 (Core)
CentOS Linux release 7.4.1708 (Core)
cpe:/o:centos:centos:7
Best regards
Eugene
4 months
Issues with Free IPA (Red Hat IDM). Sporadic lookup results. Different results in EL 6 and 7.
by Bob Jones
All,
First the deets of the setup:
3 IDM servers on RHEL 7.7
ipa version VERSION: 4.6.5, API_VERSION: 2.231
sssd version 1.16.4
389 directory server version 1.3.9.1-10
Clients:
EL7: ipa version 5.6.5, sssd version
EL6: ipa version 3.0.0.51, sssd 1.13.3.60
Servers are setup in an AD trust ipa-ad-trust-posix. I have done the performance tweaks for sssd as described at https://jhrozek.wordpress.com/2015/08/19/performance-tuning-sssd-for-larg... and we use the accounts/groups in AD for login, authorization, and file ownership.
There are 3 main issues we are having.
1. On ipa clients on EL 7 servers we are running into sporadic issues. If you totally clear the sssd cache and do an ls -la on let's say /home where there are 12 unique owners of directories usually between 8 to 10 of the UID numbers come back with the the user found, but you have to wait 1 to 5 minutes before the rest of the uids owning the other directories come back as found.
2. Also on ipa clients on EL 7 servers we are running into an issue where occasionally, at what seems like totally random times, AD users that normally can access a client suddenly can't. Someone will have to go in and clear the SSSD cache after which the user will once again be able to access the system.
3. There are some users that are just not visible on the EL 6 clients. On the IDM servers and on EL 7 clients the AD users are able to be found by id and the users can login. On EL 6 those AD users just do not resolve and cannot be seen.
Anyway, we have had Red Hat support looking at problem 3 for almost 2 months now with no luck. We have been poking around at problems 1 and 2 but no eureka moments as of yet. I'm hoping someone else on this list has encountered these same issues and found a solution. I would greatly appreciate any insight and help that anyone could provide.
Sincerely,
—
Bob Jones
Lead Linux Services Engineer
ITS ECP - Linux Services
University of Virginia
rwj5d(a)virginia.edu
4 months
