api authorization stopped working after upgrade to 4.9.12-11 on RHEL8
by Rasto Rickardt
Hello,
i have setup of 5 IPA servers on RHEL8. This morning i upgraded with dnf
upgrade IPA components to 4.9.12-11 for example:
ipa-server-4.9.12-11.module+el8.9.0+20824+f2605038.x86_64
ipa-server-common-4.9.12-11.module+el8.9.0+20824+f2605038.noarch
After upgrade finished without errors, i was not able to login to UI
with correct password with message "Your session has expired. Please log
in again."
dirsrv replication looks OK.
I checked logs, everytime i try to login, /var/log/httpd/error_log contain:
[Thu Jan 11 17:30:03.490345 2024] [wsgi:error] [pid 3299146:tid
139867429353216] [remote 185.103.146.26:46292] ipa: INFO: 401
Unauthorized: Insufficient access: SASL(-1): generic failure: GSSAPI
Error: Unspecified GSS failure. Minor code may provide more information
(Credential cache is empty)
I can do kinit, without any error. But when i try to use ipa user-show,
not working.
ipaupgrade.log attached, rest inline.
If you have any idea how to fix this please, i will be gratefull.
Thank you,
Rasto
ipa -d user-show
ipa: DEBUG: Loading Index file from
'/var/lib/ipa-client/sysrestore/sysrestore.index'
ipa: DEBUG: Loading StateFile from
'/var/lib/ipa-client/sysrestore/sysrestore.state'
ipa: DEBUG: Loading StateFile from
'/var/lib/ipa-client/sysrestore/sysrestore.state'
ipa: DEBUG: found session_cookie in persistent storage for principal
'rrickardt@redacted', cookie:
'ipa_session=MagBearerToken=VsNzXWPFKUTUmXpNpoXBnYn%2f7kaXq3b77Vb1HDzWdZ8u1c3ZAAReJFNMYwMeRLYSv4pggL%2bb3O1YH9lpJuXswOV%2fK%2fs%2bF96bBeIykbO2%2bnklplxnRxGyjo4edYLEo4QvfYIr9P2xGoxPEsCjrDj6m%2bro3UZtiFKGIgrI9KJKfZAhLrk46ooeAZ0HF7IAR5DgI07EdHeXdoP%2bA1T70CoXYA%3d%3d'
ipa: DEBUG: setting session_cookie into context
'ipa_session=MagBearerToken=VsNzXWPFKUTUmXpNpoXBnYn%2f7kaXq3b77Vb1HDzWdZ8u1c3ZAAReJFNMYwMeRLYSv4pggL%2bb3O1YH9lpJuXswOV%2fK%2fs%2bF96bBeIykbO2%2bnklplxnRxGyjo4edYLEo4QvfYIr9P2xGoxPEsCjrDj6m%2bro3UZtiFKGIgrI9KJKfZAhLrk46ooeAZ0HF7IAR5DgI07EdHeXdoP%2bA1T70CoXYA%3d%3d;'
ipa: DEBUG: trying https://ipa2.id.example.com/ipa/session/json
ipa: DEBUG: New HTTP connection (ipa2.id.example.com)
ipa: DEBUG: HTTP connection destroyed (ipa2.id.example.com)
Traceback (most recent call last):
File
"/usr/lib/python3.6/site-packages/ipaclient/remote_plugins/__init__.py",
line 120, in get_package
plugins = api._remote_plugins
AttributeError: 'API' object has no attribute '_remote_plugins'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/lib/python3.6/site-packages/ipalib/rpc.py", line 730, in
single_request
response.msg)
xmlrpc.client.ProtocolError: <ProtocolError for
ipa2.id.example.com/ipa/session/json: 401 Unauthorized>
ipa: DEBUG: trying https://ipa2.id.example.com/ipa/session/json
ipa: DEBUG: New HTTP connection (ipa2.id.example.com)
ipa: DEBUG: HTTP connection destroyed (ipa2.id.example.com)
Traceback (most recent call last):
File
"/usr/lib/python3.6/site-packages/ipaclient/remote_plugins/__init__.py",
line 120, in get_package
plugins = api._remote_plugins
AttributeError: 'API' object has no attribute '_remote_plugins'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/lib/python3.6/site-packages/ipalib/rpc.py", line 730, in
single_request
response.msg)
xmlrpc.client.ProtocolError: <ProtocolError for
ipa2.id.example.com/ipa/session/json: 401 Unauthorized>
ipa: INFO: Connection to https://ipa2.id.example.com/ipa/session/json
failed with <ProtocolError for ipa2.id.example.com/ipa/session/json: 401
Unauthorized>
krb5kdc.log
Jan 11 17:41:35 ipa7.id.example.com krb5kdc[1230](info): AS_REQ (6
etypes {aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19),
aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17),
camellia256-cts-cmac(26), camellia128-cts-cmac(25)}) 10.112.65.75:
NEEDED_PREAUTH: rrickardt(a)id.example.com for
krbtgt/id.example.com(a)id.example.com, Additional pre-authentication required
Jan 11 17:41:35 ipa7.id.example.com krb5kdc[1230](info): closing down fd 12
Jan 11 17:41:35 ipa7.id.example.com krb5kdc[1230](info): AS_REQ (6
etypes {aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19),
aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17),
camellia256-cts-cmac(26), camellia128-cts-cmac(25)}) 10.112.65.75:
ISSUE: authtime 1704991295, etypes {rep=aes256-cts-hmac-sha1-96(18),
tkt=aes256-cts-hmac-sha1-96(18), ses=aes256-cts-hmac-sha1-96(18)},
rrickardt(a)id.example.com for krbtgt/id.example.com(a)id.example.com
Jan 11 17:41:35 ipa7.id.example.com krb5kdc[1230](info): closing down fd 12
Jan 11 17:41:35 ipa7.id.example.com krb5kdc[1231](info): TGS_REQ (6
etypes {aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19),
aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17),
camellia256-cts-cmac(26), camellia128-cts-cmac(25)}) 10.112.65.75:
ISSUE: authtime 1704991295, etypes {rep=aes256-cts-hmac-sha1-96(18),
tkt=aes256-cts-hmac-sha1-96(18), ses=aes256-cts-hmac-sha1-96(18)},
rrickardt(a)id.example.com for HTTP/ipa7.id.example.com(a)id.example.com
Jan 11 17:41:35 ipa7.id.example.com krb5kdc[1231](info): closing down fd 12
Jan 11 17:41:35 ipa7.id.example.com krb5kdc[1230](info): TGS_REQ (6
etypes {aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19),
aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17),
camellia256-cts-cmac(26), camellia128-cts-cmac(25)}) 10.112.65.75:
S4U2PROXY_EVIDENCE_TKT_WITHOUT_PAC: authtime 1704991295, etypes
{rep=UNSUPPORTED:(0)} HTTP/ipa7.id.example.com(a)id.example.com for
ldap/ipa7.id.example.com(a)id.example.com, KDC policy rejects request
Jan 11 17:41:35 ipa7.id.example.com krb5kdc[1230](info): ...
CONSTRAINED-DELEGATION s4u-client=<unknown>
Jan 11 17:41:35 ipa7.id.example.com krb5kdc[1230](info): closing down fd 12
Jan 11 17:41:35 ipa7.id.example.com krb5kdc[1230](info): TGS_REQ (6
etypes {aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19),
aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17),
camellia256-cts-cmac(26), camellia128-cts-cmac(25)}) 10.112.65.75:
S4U2PROXY_EVIDENCE_TKT_WITHOUT_PAC: authtime 1704991295, etypes
{rep=UNSUPPORTED:(0)} HTTP/ipa7.id.example.com(a)id.example.com for
ldap/ipa7.id.example.com(a)id.example.com, KDC policy rejects request
Jan 11 17:41:35 ipa7.id.example.com krb5kdc[1230](info): ...
CONSTRAINED-DELEGATION s4u-client=<unknown>
Jan 11 17:41:35 ipa7.id.example.com krb5kdc[1230](info): closing down fd 12
3 months, 1 week
Cannot create users on platform migration: sambaSID failure
by Melissa Ferreira da Silva Boiko
Hi,
I'm trying to upgrade an ancient master replica (the CA master) running FreeIPA 4.5 on CentOS 7.4. Upgrading the freeipa packages in-place (in a cloned VM) caused numerous problems so I'm trying to create a new master replica on a fresh Fedora 39, using the "Migrating to different platform or OS" procedure described on
https://www.freeipa.org/page/Howto/Migration
At first sight the new replica appears to work, but user creation fails, both on the web and command-line, with:
ipa user-add --first=Testy --last=McTestface teste123
ipa: ERROR: missing attribute "sambaSID" required by object class "sambaSamAccount"
Web searches seem to suggest this is due to a missing DNA plugin that should autogenerate the sambaSIDs, but I failed to find a guide on how to enable that plugin with current IPA (4.11). Should it be enabled automatically?
Unless it's used for something internal to IPA I don't think we actually are even using AD integration or SMB shares, so removing Samba support altogether would also be an option, but I don't know what's the safe way of doing that to the schema either.
Thanks for your help!
3 months, 2 weeks
Re: Create IPA user via LDAP
by Ronald Wimmer
On 08.01.24 17:58, Alexander Bokovoy wrote:
> On Пан, 08 сту 2024, Ronald Wimmer wrote:
>> On 02.01.24 17:57, Ronald Wimmer via FreeIPA-users wrote:
>>> On 02.01.24 16:27, Rob Crittenden wrote:
>>>> Ronald Wimmer via FreeIPA-users wrote:
>>>>>
>>>>>
>>>>> On 14.12.23 14:42, Alexander Bokovoy wrote:
>>>>>> On Чцв, 14 сне 2023, Ronald Wimmer via FreeIPA-users wrote:
>>>>>>> In our company we do have an IAM tool for user management. We
>>>>>>> need to
>>>>>>> create IPA users via this particular tool. I am aware of all IPA
>>>>>>> commands or API calls to create/modify or delete a user.
>>>>>>>
>>>>>>> As the tool does not support FreeIPA yet they asked if there is a
>>>>>>> way
>>>>>>> to manage users by using LDAP only. Could that work? What about
>>>>>>> attributes like ipaNTSecurityIdentifier, ipaUniqueID or uidNumber?
>>>>>>
>>>>>> Learn about lifecycle management. This is your way of integrating
>>>>>> with
>>>>>> such tools bvy creating staged users:
>>>>>> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/...
>>>>>>
>>>>>
>>>>> I followed the instructions from the documentation.
>>>>>
>>>>> How could I possibly overcome
>>>>>
>>>>> Dec 19 09:18:39 tipa01.ipatest.mydomain.at ipa-activate-all[836863]:
>>>>> ipa: ERROR: Constraint violation: pre-hashed passwords are not valid
>>>>>
>>>>> I need to set passwords from the external system.
>>>>
>>>> You need to enable migration mode (ipa config-mod --enable-migration
>>>> true).
>>>>
>>>> By default a pre-hashed password can only be set once: during the user
>>>> add operation.
>>>
>>> Ok. So this would not work for a password change. So if we need to
>>> set an initial password and change that particular password in some
>>> point in time the only feasible way is the IPA API, right?
>>>
>>> Can the immediate password expiration be overridden?
>>
>> As we have an upcoming please allow me to ask if I got the point here.
>>
>> I appreciate your support in this matter!
>>
>
> I was looking over the code. The only way to accept pre-hashed passwords
> is when they also have Kerberos keys set. This means you cannot use
> external LDAP modify/add for that as you cannot create the Kerberos key
> without knowing a Kerberos master key.
>
> So the only other option is to submit a clear-text password:
>
> userPassword: {CLEAR}text-password
>
> That will be accepted and if bind DN that performed this change is
> either a cn=Directory Manager or a one from the passsync managers, it
> would also not be marked for expiration immediately.
If I try to set the userPassword attribute to some value with an LDAP
browser and chose "plaintext" the value gets hashed immediately. I do
see {PBKDF2_SHA256}. As a consequence the user cannot be activated.
What am I doing wrong?
I tried to enable migration mode and wanted to try it again but now I
cannot connect to IPA's LDAP directory at all anymore...
[root@tipa01 ~]# ipa config-mod --enable-migration=true
Maximum username length: 32
Maximum hostname length: 64
Home directory base: /home
Default shell: /bin/sh
Default users group: ipausers
Default e-mail domain: ipatest.mydomain.at
Search time limit: 2
Search size limit: 100
User search fields: uid,givenname,sn,telephonenumber,ou,title
Group search fields: cn,description
Enable migration mode: True
Certificate Subject base: O=IPATEST.MYDOMAIN.AT
Password Expiration Notification (days): 4
Password plugin features: AllowNThash, KDC:Disable Last Success
SELinux user map order:
guest_u:s0$xguest_u:s0$user_u:s0$staff_u:s0-s0:c0.c1023$sysadm_u:s0-s0:c0.c1023$unconfined_u:s0-s0:c0.c1023
Default SELinux user: unconfined_u:s0-s0:c0.c1023
Default PAC types: MS-PAC, nfs:NONE
IPA masters: tipa01.ipatest.mydomain.at, tipa02.ipatest.mydomain.at
IPA master capable of PKINIT: tipa01.ipatest.mydomain.at,
tipa02.ipatest.mydomain.at
IPA CA servers: tipa01.ipatest.mydomain.at
IPA CA renewal master: tipa01.ipatest.mydomain.at
Domain resolution order: org.mydomain.at:ipatest.mydomain.at
[root@tipa01 ~]# ipa config-mod --enable-migration=false
ipa: ERROR: Major (851968): Unspecified GSS failure. Minor code may
provide more information, Minor (2529638972): KDC returned error string:
PROCESS_TGS
3 months, 3 weeks
idrange problem
by Steve Berg
For a few weeks now I've been seeing a problem getting authenticated to
my ipa domain. I can get command line and web UI stuff done by using
the admin user but if I get a ticket using my account which is in the
admins group I get the following on the web UI:
Your session has expired. Please log in again.
On the command line any ipa commands I've tried so far give me:
ipa: ERROR: Insufficient access: SASL(-1): generic failure: GSSAPI
Error: Unspecified GSS failure. Minor code may provide more information
(Credential cache is empty)
Getting a ticket as admin on command line lets me run ipa commands with
no problem. I think I've got all pertinent certificates loaded up
properly. Gonna try a reboot on one of the servers shortly. I have 4
servers on r different vlans, replication between seems to be working
properly.
I think the problem is most of the user ID's we use on this domain are
not in the ID range configured. We let the install choose a default
range when we first set this up. Most of our users have a UID based on
their EDIPI # which is a 32-bit ID assigned when a user first gets a DoD
CAC. They're usually 10 digits long.
For instance the lowest EDIPI based UID we have currently is something
like 1004201873 and the largest is 1658224121. (I made those but
they're close to the actual UIDs.)
ipa idrange-find show me this, (did some masking of the info):
Range name: domain_id_range
First Posix ID of the range: 824xxx000
Number of IDs in the range: 200000
First RID of the corresponding RID range: 1000
First RID of the secondary RID range: 100000000
Range name: domain_subid_range
First Posix ID of the range: 214xxx3648
Number of IDs in the range: 214xxx2576
First RID of the corresponding RID range: 214xxx3648
Domain SID of the trusted domain: S-1-5-21-xxxxxx-83xx66-82xxx729
Range type: Active Directory domain range
Should I adjust the range that's already there or add a third that
encompasses the likely range of numbers I'm gonna see in the future? I
started to add a range with appropriate values but when it wanted the
primary and secondary RID base values I was not sure how to figure that
out or estimate.
--
//- Fixer of that which is broke -//
//- Home =sberg(a)mississippi.com -//
//- Sinners can repent, but stupid is forever. -//
3 months, 3 weeks
certmonger error on ubuntu
by Robson Francisco de Souza
Hello!
I've been running FreeIPA 4.3.1 on Ubuntu 16.04 for almost two years and
most certificates should expire within three weeks. As this deadline
approaches, I noticed certmonger has been unable to renew certificates due
to the error below.
After googling for two days, I found this issue has been observed by many
people before, mostly after expiration of the certificates, as in
https://tinyurl.com/vajmocw
Still, I couldn't find a solution to this problem.
If it is impossible to fix this issue while using FreeIPA 4.3.1, I would
like to:
1) Find a way to renew all certificates even if certmonger can't be fixed.
This would allow me to postpone the solution to after the next OS and/or
FreeIPA upgrade
2) Find out what version of FreeIPA I should upgrade to while the operating
system remains Ubuntu 16.04
Any help would be appreciated!
Thanks!
Robson
======> Command: systemctl status certmonger
Nov 17 20:53:08 ipa.cefapnet.icb.usp.br certmonger[3873125]: 2019-11-17
20:53:08 [3873125] Error 77 connecting to
https://ipa.cefapnet.icb.usp.br:8443/ca/agent/ca/profileReview: Problem
with the SSL CA cert (path? access rights?).
Nov 17 21:10:13 ipa.cefapnet.icb.usp.br
dogtag-ipa-ca-renew-agent-submit[3875188]: Forwarding request to
dogtag-ipa-renew-agent
Nov 17 21:10:13 ipa.cefapnet.icb.usp.br
dogtag-ipa-ca-renew-agent-submit[3875188]: dogtag-ipa-renew-agent returned 3
Nov 17 21:10:13 ipa.cefapnet.icb.usp.br certmonger[3873125]: 2019-11-17
21:10:13 [3873125] Error 77 connecting to
https://ipa.cefapnet.icb.usp.br:8443/ca/agent/ca/profileReview: Problem
with the SSL CA cert (path? access rights?).
Nov 17 21:25:20 ipa.cefapnet.icb.usp.br
dogtag-ipa-ca-renew-agent-submit[3875738]: Forwarding request to
dogtag-ipa-renew-agent
Nov 17 21:25:20 ipa.cefapnet.icb.usp.br
dogtag-ipa-ca-renew-agent-submit[3875738]: dogtag-ipa-renew-agent returned 3
Nov 17 21:25:21 ipa.cefapnet.icb.usp.br certmonger[3873125]: 2019-11-17
21:25:21 [3873125] Error 77 connecting to
https://ipa.cefapnet.icb.usp.br:8443/ca/agent/ca/profileReview: Problem
with the SSL CA cert (path? access rights?).
Nov 17 21:25:31 ipa.cefapnet.icb.usp.br
dogtag-ipa-ca-renew-agent-submit[3875766]: Forwarding request to
dogtag-ipa-renew-agent
Nov 17 21:25:31 ipa.cefapnet.icb.usp.br
dogtag-ipa-ca-renew-agent-submit[3875766]: dogtag-ipa-renew-agent returned 3
Nov 17 21:25:31 ipa.cefapnet.icb.usp.br certmonger[3873125]: 2019-11-17
21:25:31 [3873125] Error 77 connecting to
https://ipa.cefapnet.icb.usp.br:8443/ca/agent/ca/profileReview: Problem
with the SSL CA cert (path? access rights?).
--
Robson Francisco de Souza, PhD
Laboratório de Estrutura e Evolução de Proteínas (LEEP/PSEL)
Departamento de Microbiologia
Instituto de Ciências Biomédicas
Universidade de São Paulo
Av. Prof. Lineu Prestes, 1374 - Ed. Biomédicas II - Sala 250 - 2o. andar
Tel: 3091-0891
Cidade Universitária - CEP 05508-900 - São Paulo - SP - Brasil
----
Robson Francisco de Souza, PhD
Protein Structure and Evolution Laboratory (LEEP/PSEL)
Microbiology Departament
Biomedical Sciences Institute
University of Sao Paulo
Av. Prof. Lineu Prestes, 1374 - Biomédicas II - Sala 250
Phone: 55-11-3091-0891
Cidade Universitária - ZIP 05508-900 - São Paulo - SP - Brazil
3 months, 4 weeks
FreeIPA Upgrade - overwrites custom authselect config
by Finn Fysj
I've recently tried to run an upgrade of my IPA server (4.10.2) because of some CVE fix for 4.10.3.
At the end of upgrade the IPA server tries to run: CalledProcessError(Command ['/usr/bin/authselect', 'select', 'sssd', 'with-sudo', '--force'], why does it do this?
The upgrade in my case fails because I've set made following files immutable: /etc/authselect/{password-auth,system-auth}.
4 months
CentOS 7 FreeIPA upgrade, 4.5 to 4.6.8: certmonger hanger
by Melissa Ferreira da Silva Boiko
Hello all.
I'm trying to replace an ancient FreeIPA 4.5.0 master (and primary CA
master) on CentOS 7.4. I am having problems trying to make replicas with
FreeIPA 4.11, and past threads suggest the errors are due to
incompatibility of password hash algorithms, which are supposed to be fixed
on the older releases rather than the newer.
Therefore I'm trying to upgrade the old server to the current version in
the CentOS 7 repos, 4.6.8, to try to create fresh replicas from there. But
I'm having issues with the certmonger systemd service hanging, and breaking
ipa-server-upgrade--whether I update the whole CentOS to 7.9.2009, or just
ipa-server and its dependencies, the result is the same.
This is where ipa-server-upgrade breaks:
[Verifying that root certificate is published]
[Migrate CRL publish directory]
CRL tree already moved
[Verifying that CA proxy configuration is correct]
IPA server upgrade failed: Inspect /var/log/ipaupgrade.log and run
command ipa-server-upgrade manually.
Unexpected error - see /var/log/ipaupgrade.log for details:
CalledProcessError: Command '/bin/systemctl start
certmonger.service' returned non-zero exit status 1
The ipa-server-upgrade command failed. See /var/log/ipaupgrade.log
for more information
This is because certmonger.service hangs until timeout. That happens when
starting the service manually, too. Logs for certmonger.service are not
informative:
-- Subject: Unit certmonger.service has begun start-up
-- Unit certmonger.service has begun starting up.
Jan 31 14:38:59 vm-ipa-1.intra.viaboxxsystems.de systemd[1]:
certmonger.service start operation timed out. Terminating.
Jan 31 14:40:29 vm-ipa-1.intra.viaboxxsystems.de systemd[1]:
certmonger.service stop-sigterm timed out. Killing.
Jan 31 14:40:29 vm-ipa-1.intra.viaboxxsystems.de systemd[1]:
certmonger.service: main process exited, code=killed, status=9/KILL
-- Subject: Unit certmonger.service has failed
-- Unit certmonger.service has failed.
Jan 31 14:40:29 vm-ipa-1.intra.viaboxxsystems.de systemd[1]: Unit
certmonger.service entered failed state.
Jan 31 14:40:29 vm-ipa-1.intra.viaboxxsystems.de systemd[1]:
certmonger.service failed.
root@vm-ipa-1.intra.viaboxxsystems.de[lxc](e:0,1s)(j:0) ~
Running `certmonger -S -n -d 9` seems to run ok. The only difference in
the systemd service file is, I think, whatever it is that the BusName
setting does. dbus is running seemingly without issue, nothing on logs.
Restarting dbus.service doesn't help.
The machine is an LXC container with 4GiB RAM, which doesn't come close to
being exhausted when trying to restart certmonger. No OOM in logs.
I saw this thread about certmonger problems with ulimit in containers:
https://bugzilla.redhat.com/show_bug.cgi?id=1656519
But the suggested workaround (make sure ulimit -n is the same in container
and host) doesn't apply because it's already the same for us.
How should I proceed from here?
4 months
Issues with sudo permissions
by slek kus
Hi, created an account which is meant to automate things with Ansible AWX.
Tried to grant this account sudo access to the linux clients but things seem not to work out.
Not sure why. hbactests returns OK.
----
[root@idm01 ~]# ipa hbactest --user=ansible --host=debclient1.linux.<redacted>.services --service=sshd
--------------------
Access granted: True
--------------------
Matched rules: allow_ansible_ssh2idm
Not matched rules: allow_systemd-user
Not matched rules: test_aduser
[root@idm01 ~]# ipa hbactest --user=ansible --host=debclient1.linux.<redacted>.services --service=sudo-i
--------------------
Access granted: True
--------------------
Matched rules: allow_ansible_ssh2idm
Not matched rules: allow_systemd-user
Not matched rules: test_aduser
[root@idm01 ~]# ipa hostgroup-show all_clients_hg
Host-group: all_clients_hg
Description: This group contains all clients registered to this IdM.
Member hosts: debclient2.linux.<redacted>.services, debclient1.linux.<redacted>.services
Member of HBAC rule: allow_ansible_ssh2idm, test_aduser
[root@idm01 ~]# ipa hbacrule-show allow_ansible_ssh2idm
Rule name: allow_ansible_ssh2idm
Enabled: True
Users: ansible
Host Groups: ipaservers, all_clients_hg
HBAC Services: sshd, sudo, sudo-i
HBAC Service Groups: Sudo
----
I can login with user ansible onto debclient2, using a ssh pub key set in IDM just fine.
But when trying to sudo, this is not allowed. Even though I have locally enabled it in sudoers (which should't be nessecary).
----
root@debclient2:~# su - ansible@linux.<redacted>.services
su: Permission denied
root@debclient2:~# getent passwd ansible@linux.<redacted>.services
ansible:*:996000008:996000008:Automation User:/home/ansible:/bin/bash
ansible@debclient2:~$ sudo -i
[sudo] password for ansible:
ansible is not allowed to run sudo on debclient2.
ansible@debclient2:~$ id
uid=996000008(ansible) gid=996000008(ansible) groups=996000008(ansible)
-----
4 months
FreeIPA cluster, backup and restore
by Finn Fysj
Have a cluster setup with is setup using Ansible FreeIPA roles ipaserver & ipareplica.
Running ipabackup using script as the ipabackup role doesn't work as wanted or intended, meaning not able to take backup of data.
Multiple master, only one with CA installed.
When I run ipabackup to backup data I get the following:
Error: Local roles do not match globally used roles CA. A backup done on this host would not be complete enough to restore a fully functional, identical cluster.
The ipa-backup command failed. See /var/log/ipabackup.log for more information.
The error message is somewhat understandable. We don't use FreeIPA CA capabilities, so that's the reason we don't have it installed on replicas, unless you guys would recommend otherwise?
I've tried to test a little using these ansible roles. What happens if my Master with the only backup goes down? Yes, I'll have a replica making sure everything works as normal, so I can scrap the master, rebuild it and restore the data backup I took.
However, once the node is restored, there's still not any connection between the two nodes now, since a re-run of the ipareplica won't do anything since it's already installed. Does that mean we need to rebuild this node as well?
A normal data restore of a node will stop the replication connection between the two nodes, meaning it needs to be "re-connected", this is also not something that can be done using these roles?
One final question: If we have a working cluster setup, and some sausage fingers manages to delete the replica from the "CA node". How can I re-initalize this with the ansible replica role, or is rebuild the only option?
4 months
Re: issues ssh'ing as AD user to freeipa client
by Sumit Bose
Am Wed, Dec 13, 2023 at 11:49:00PM +0000 schrieb Ostrom, Erik via FreeIPA-users:
> Hi,
>
> I'm having some issues ssh'ing as an AD user to a freeipa client, but I can successfully ssh as the same user to the IPA master.
> Our IPA domain, ipa.subdomain.contoso.com, is set up with a one-way trust with ad.contoso.com (IPA trusts ADs users). I have the standard "allow all" HBAC rule in place on FreeIPA for testing purposes. ad.contoso.com is a relatively huge AD, with over 400,000 user accounts.
>
> ssh erik-ipa(a)freeipa1.ipa.subdomain.contoso.com --- (IPA user to FreeIPA master), works
> ssh erik-ad@ad.contso.com(a)freeipa1.ipa.subdomain.contoso.com --- (AD user to FreeIPA master), works
> ssh erik-ipa(a)rl9-ipa-client1.in.subdomain.contoso.com --- (IPA user to FreeIPA client), works
> ssh erik-ad@ad.contoso.com(a)rl9-ipa-client1.in.subdomain.contoso.com --- (AD user to FreeIPA client), doesn't work
>
> I'm not sure what to look at in the SSSD logs to see what's going wrong here. I have uploaded sanitized SSSD logs from rl9-ipa-client1.in.subdomain.contoso.com for a failed login attempt (listed above as not working) at the following link:https://privatebin.net/?55e82c73463ae145#A59jSajU1ZwEwr3nEKhPqsT8Um4...
Hi,
according to the logs, the IPA server needs too much time to prepare the
data of the AD user which the client requested.
(2023-12-12 16:31:13): [be[ipa.subdomain.contoso.com]] [ipa_s2n_get_acct_info_send] (0x0400): [RID#229] Sending request_type: [REQ_FULL_WITH_MEMBERS] for trust user [erik-ad] to IPA server
(2023-12-12 16:31:13): [be[ipa.subdomain.contoso.com]] [ipa_s2n_exop_send] (0x0400): [RID#229] Executing extended operation
(2023-12-12 16:31:13): [be[ipa.subdomain.contoso.com]] [ipa_s2n_exop_send] (0x2000): [RID#229] ldap_extended_operation sent, msgid = 41
(2023-12-12 16:31:13): [be[ipa.subdomain.contoso.com]] [sdap_op_add] (0x2000): [RID#229] New operation 41 timeout 6
(2023-12-12 16:31:13): [be[ipa.subdomain.contoso.com]] [sdap_process_result] (0x2000): Trace: sh[0x55e456f262f0], connected[1], ops[0x55e456efac80], ldap[0x55e455ed5310]
(2023-12-12 16:31:13): [be[ipa.subdomain.contoso.com]] [sdap_process_result] (0x2000): Trace: end of ldap_result list
(2023-12-12 16:31:19): [be[ipa.subdomain.contoso.com]] [sdap_op_timeout] (0x1000): [RID#229] Issuing timeout [ldap_opt_timeout] for message id 41
Typically this means that the server has to refresh some or all cached
data of the user, which in this case will include all group-memberships
and for some technical reasons this means refreshing all related
expired groups and their members.
At least for the group members this can be speed up by setting
ignore_group_members = True
subdomain_inherit = ignore_group_members
in the [domain/...] section on IPA servers and clients.
Another option is to set
refresh_expired_interval = 4000
in the [domain/...] sections on the IPA servers to make sure that SSSD
will try every 4000s to refresh cached entries which are about to
expire. As a result the IPA servers should be able to always reply to
request form IPA client with cached data without the need to refresh it.
HTH
bye,
Sumit
>
> If anyone can tell what my issue is here, or if other logs would be helpful let me know. I appreciate the help!
>
> Thanks,
> Erik
> --
> _______________________________________________
> 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...
> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
4 months