Not able to login into IPA UI after full server backup, error says: "Your session has expired. Please re-login."
by Saurabh Garg
All IPA services work else than IPA UI login. For Admin account it throws the error "Your session has expired. Please re-login."
# cat /var/log/httpd/error_log | grep error
[Mon Nov 04 03:30:57.855012 2019] [:error] [pid 26165] ipa: INFO: Starting new HTTP connection (1): ipaserver.home.mydomain.com
[Mon Nov 04 03:30:57.858643 2019] [:error] [pid 26165] ipa: INFO: Starting new HTTPS connection (1): ipaserver.home.mydomain.com
[Mon Nov 04 04:14:57.945806 2019] [:error] [pid 31576] ipa: INFO: *** PROCESS START ***
[Mon Nov 04 04:14:57.973073 2019] [:error] [pid 31579] ipa: INFO: *** PROCESS START ***
[Mon Nov 04 04:14:57.977523 2019] [:error] [pid 31578] ipa: INFO: *** PROCESS START ***
[Mon Nov 04 04:14:57.993765 2019] [:error] [pid 31577] ipa: INFO: *** PROCESS START ***
[Mon Nov 04 04:15:26.343676 2019] [:error] [pid 31578] ipa: INFO: Starting new HTTP connection (1): ipaserver.home.mydomain.com
[Mon Nov 04 04:15:26.347563 2019] [:error] [pid 31578] ipa: INFO: Starting new HTTPS connection (1): ipaserver.home.mydomain.com
# kinit admin
Password for admin(a)MYDOMAIN.COM:
# klist
Ticket cache: KEYRING:persistent:0:0
Default principal: admin(a)MYDOMAIN.COM
Valid starting Expires Service principal
11/04/2019 04:39:36 11/05/2019 04:39:23 krbtgt/MYDOMAIN.COM(a)MYDOMAIN.COM
# ipa -v ping
ipa: INFO: trying https://ipaserver.home.mydomain.com/ipa/json
ipa: INFO: [try 1]: Forwarding 'schema' to json server 'https://ipaserver.home.mydomain.com/ipa/json'
ipa: INFO: trying https://ipaserver.home.mydomain.com/ipa/session/json
ipa: INFO: [try 1]: Forwarding 'ping/1' to json server 'https://ipaserver.home.mydomain.com/ipa/session/json'
-------------------------------------------
IPA server version 4.6.5. API version 2.231
-------------------------------------------
# kinit -kt /var/lib/ipa/gssproxy/http.keytab http(a)MYDOMAIN.COM
kinit: Keytab contains no suitable keys for http(a)MYDOMAIN.COM while getting initial credentials
# kinit -kt /var/lib/ipa/gssproxy/http.keytab HTTP/ipaserver.home.mydomain.com
# klist
Ticket cache: KEYRING:persistent:0:krb_ccache_jTRWw54
Default principal: HTTP/ipaserver.home.mydomain.com(a)MYDOMAIN.COM
Valid starting Expires Service principal
11/04/2019 04:42:26 11/05/2019 04:42:26 krbtgt/MYDOMAIN.COM(a)MYDOMAIN.COM
Can someone please help me with what might me the issue?
Any suggestions?
PS: I have already restarted restart krb5kdc,sssd & httpd services.
Thanks in advance,
Saurabh Garg
4 years, 4 months
ipa-client password
by TomK
Hey All,
Given a line like this:
ipa-client-install --force-join -p admin -w "*********" --fixed-primary
--server=idmipa01.nix.mds.xyz --server=idmipa02.nix.mds.xyz
--domain=nix.mds.xyz --realm=NIX.MDS.XYZ -U
1) Is there a way to pull the password from a safe store before passing
it in or pull from a safe store directly?
or
2) Can I specify an unprevilidged user to register with?
or
3) Register without the use of a password?
Looking to register clients in ways that don't reveal any account
passwords with which the registration has occurred with.
--
Thx,
TK.
4 years, 4 months
remove self service privileges/permissions for specific users
by Joshua Hoblitt
Hello,
I would like to be able to create a small number of user accounts which are not able to perform any self service (change passwd, set ssh pub keys), while leaving the default self service abilities enabled for most users. It appears that it is not possible to remove or negate permissions via privileges or roles. It also appears that it is not possible to remove the global self service privileges and replace them with a role as it isn't possible to constrain generic privileges to "self". Is that correct? Is there any existing way to achieve non-self-service users?
Thanks,
-Josh
4 years, 4 months
Resilience to network/interface interruption
by lejeczek
hi guys,
I think my IPA goes down when there is problem with the interface.
Around the time this happens:
..
netxen_nic: p3p1 NIC Link is down
netxen_nic: p3p1 NIC Link is up
netxen_nic: p3p1 NIC Link is down
netxen_nic: p3p1 NIC Link is up
netxen_nic: p3p1 NIC Link is down
netxen_nic: p3p1 NIC Link is up
netxen_nic: p3p1 NIC Link is down
..
IPA is lost. There is probably more to it as IPAs run in containers but
this is first thing I'd like to check.
Are there any tuning which could be done to IPA/OS/kernel in order to
help IPA and make system more resilient that way?
many thanks, L.
4 years, 4 months
Nested groups & ID-view
by Kimmo Rantala
Hello all.
We encountered a situation where ID views broke authentication... or at least we think so.
The situation was as follows:
Customer insisted that they have to have a "hardened" SSH config like this: AllowGroups staff. This staff (GID 500) group was/is a local group in 100+ machines. They did this "to control who can login" despite me and a couple of my colleagues trying to tell them (sometimes with strong words attached) that FreeIPA's HBAC rules will handle this very thing but to no avail. Of course this resulted into situation where the IPA users could not login because sshd prevented it.
We came up with a solution where we would create this ID-view:
Anchor to override: res_staff
Group name: staff
GID: 500
and apply that to those 100+ clients. We didn't like the idea to abuse ID-views like this especially after the client insisted that the res_staff group should be a nested group like this:
dev-team -> res_staff + <insert a bunch of other groups>
ops-team -> res_staff + <insert a bunch of other groups>
.
.
.
(I have to admit that after seeing and hearing about this, I considered telling my bosses to outright fire this customer)
For a while everything worked but then logins started to fail. Upon examining, it turned out that id command would no longer return the full list of groups of a user and the "hardened" sshd config killed the login. After we cleared the SSSD caches and restarted SSSD, the logins would work for a while and id command would return all the groups where user belonged to.
It is also worth mentioning that this client has a fetish for nested groups so it is not uncommon to see groups 4-5 "deep" and it is a general mess.
Also: No AD trust here. Just ye olde IPA domain. The good thing is that the environment is extremely homogeneous. All the IPA servers CentOS 7.6 and the clients CentOS 7.x.
We have the logs with debug level 6 but before I'll send them for examination, I would like to ask that is there a limitation/bug in the ID-views functionality where it fails when the anchor group is nested?
Thank you.
PS. Alexander, you are awesome.
4 years, 4 months
Nested groups & ID-view
by Kimmo Rantala
Hello all.
We encountered a situation where ID views broke authentication... or at least we think so.
The situation was as follows:
Customer insisted that they have to have a "hardened" SSH config like this: AllowGroups staff. This staff (GID 500) group was/is a local group in 100+ machines. They did this "to control who can login" despite me and a couple of my colleagues trying to tell them (sometimes with strong words attached) that FreeIPA's HBAC rules will handle this very thing but to no avail. Of course this resulted into situation where the IPA users could not login because sshd prevented it.
We came up with a solution where we would create this ID-view:
Anchor to override: res_staff
Group name: staff
GID: 500
and apply that to those 100+ clients. We didn't like the idea to abuse ID-views like this especially after the client insisted that the res_staff group should be a nested group like this:
dev-team -> res_staff + <insert a bunch of other groups>
ops-team -> res_staff + <insert a bunch of other groups>
.
.
.
(I have to admit that after seeing and hearing about this, I considered telling my bosses to outright fire this customer)
For a while everything worked but then logins started to fail. Upon examining, it turned out that id command would no longer return the full list of groups of a user and the "hardened" sshd config killed the login. After we cleared the SSSD caches and restarted SSSD, the logins would work for a while and id command would return all the groups where user belonged to.
It is also worth mentioning that this client has a fetish for nested groups so it is not uncommon to see groups 4-5 "deep" and it is a general mess.
Also: No AD trust here. Just ye olde IPA domain. The good thing is that the environment is extremely homogeneous. All the IPA servers CentOS 7.6 and the clients CentOS 7.x.
We have the logs with debug level 6 but before I'll send them for examination, I would like to ask that is there a limitation/bug in the ID-views functionality where it fails when the anchor group is nested?
Thank you.
PS. Alexander, you are awesome.
4 years, 4 months