[Freeipa-users] Re: pki-tomcatd service stopped

[Alexander Bokovoy via FreeIPA-users]

On Срд, 29 мая 2024, Natxo Asenjo wrote:

hi,

indeed, sorry.

# cat
/etc/pki/pki.version
│
Configuration-Version: 11.5.0

# ipactl restart
Restarting Directory Service
Restarting krb5kdc Service
Restarting kadmin Service
Restarting named Service
Restarting httpd Service
Restarting ipa-custodia Service
Restarting pki-tomcatd Service
Restarting smb Service
Restarting winbind Service
Restarting ipa-otpd Service
Restarting ipa-dnskeysyncd Service
ipa: INFO: The ipactl command was successful

]# ipactl status
Directory Service: RUNNING
krb5kdc Service: RUNNING
kadmin Service: RUNNING
named Service: RUNNING
httpd Service: RUNNING
ipa-custodia Service: RUNNING
pki-tomcatd Service: STOPPED
smb Service: RUNNING
winbind Service: RUNNING
ipa-otpd Service: RUNNING
ipa-dnskeysyncd Service: RUNNING
1 service(s) are not running

May 29 12:12:34 kdc.sub.domain.tld systemd[1]: Starting PKI Tomcat Server
pki-tomcat...
May 29 12:12:35 kdc.sub.domain.tld pki-server[36733]: ERROR: Unable to
parse version number: "11.5.0"
May 29 12:12:35 kdc.sub.domain.tld pki-server[36733]: Traceback (most
recent call last):
May 29 12:12:35 kdc.sub.domain.tld pki-server[36733]:   File
"/usr/lib/python3.9/site-packages/pki/server/pkiserver.py", line 41, in

May 29 12:12:35 kdc.sub.domain.tld pki-server[36733]:
cli.execute(sys.argv)
May 29 12:12:35 kdc.sub.domain.tld pki-server[36733]:   File
"/usr/lib/python3.9/site-packages/pki/server/cli/__init__.py", line 145, in
execute
May 29 12:12:35 kdc.sub.domain.tld pki-server[36733]:
super().execute(args)
May 29 12:12:35 kdc.sub.domain.tld pki-server[36733]:   File
"/usr/lib/python3.9/site-packages/pki/cli/__init__.py", line 217, in execute
May 29 12:12:35 kdc.sub.domain.tld pki-server[36733]:
module.execute(module_args)
May 29 12:12:35 kdc.sub.domain.tld pki-server[36733]:   File
"/usr/lib/python3.9/site-packages/pki/server/cli/upgrade.py", line 144, in
execute
May 29 12:12:35 kdc.sub.domain.tld pki-server[36733]: self.upgrade(
May 29 12:12:35 kdc.sub.domain.tld pki-server[36733]:   File
"/usr/lib/python3.9/site-packages/pki/server/cli/upgrade.py", line 178, in
upgrade
May 29 12:12:35 kdc.sub.domain.tld pki-server[36733]: upgrader.upgrade()
May 29 12:12:35 kdc.sub.domain.tld pki-server[36733]:   File
"/usr/lib/python3.9/site-packages/pki/upgrade.py", line 481, in upgrade
May 29 12:12:35 kdc.sub.domain.tld pki-server[36733]: versions =
self.versions()
May 29 12:12:35 kdc.sub.domain.tld pki-server[36733]:   File
"/usr/lib/python3.9/site-packages/pki/upgrade.py", line 238, in versions
May 29 12:12:35 kdc.sub.domain.tld pki-server[36733]: current_version =
self.get_current_version()
May 29 12:12:35 kdc.sub.domain.tld pki-server[36733]:   File
"/usr/lib/python3.9/site-packages/pki/upgrade.py", line 341, in
get_current_version
May 29 12:12:35 kdc.sub.domain.tld pki-server[36733]: current_version =
self.get_tracker().get_version()
May 29 12:12:35 kdc.sub.domain.tld pki-server[36733]:   File
"/usr/lib/python3.9/site-packages/pki/upgrade.py", line 141, in get_version
May 29 12:12:35 kdc.sub.domain.tld pki-server[36733]: return
pki.util.Version(version)
May 29 12:12:35 kdc.sub.domain.tld pki-server[36733]:   File
"/usr/lib/python3.9/site-packages/pki/util.py", line 613, in __init__
May 29 12:12:35 kdc.sub.domain.tld pki-server[36733]: raise
Exception('Unable to parse version number: %s' % obj)
May 29 12:12:35 kdc.sub.domain.tld pki-server[36733]: Exception: Unable to
parse version number: "11.5.0"


The only way to get this string in double quotes is if it was in double
quotes in the original file:

-

obj = "11.5.0"
m = re.match(r'^(\d+)\.(\d+)\.(\d+)', obj)
m.group(2)

'5'

raise Exception('Unable to parse version number: %s' % obj)

Traceback (most recent call last):
  File "", line 1, in 
Exception: Unable to parse version number: 11.5.0

obj = '"11.5.0"'
m = re.match(r'^(\d+)\.(\d+)\.(\d+)', obj)
m.group(2)

Traceback (most recent call last):
  File "", line 1, in 
AttributeError: 'NoneType' object has no attribute 'group'

raise Exception('Unable to parse version number: %s' % obj)

Traceback (most recent call last):
  File "", line 1, in 
Exception: Unable to parse version number: "11.5.0"
-

So I still think there is something wrong with the file it reads...



If I revert it to 11.4.2, so it looks as though it is not reading this file
for getting this information.

# cat /etc/pki/pki.version
Configuration-Version: 11.4.2

# ipactl restart
Restarting Directory Service
Restarting krb5kdc Service
Restarting kadmin Service
Restarting named Service
Restarting httpd Service
Restarting ipa-custodia Service
Restarting pki-tomcatd Service
Restarting smb Service
Restarting winbind Service
Restarting ipa-otpd Service
Restarting ipa-dnskeysyncd Service
ipa: INFO: The ipactl command was successful

# ipactl status
Directory Service: RUNNING
krb5kdc Service: 

[Freeipa-users] Re: when 2FA enabled, with 2 factor prompt asking doesn't work

[Alexander Bokovoy via FreeIPA-users]

On Пан, 27 мая 2024, seojeong kim via FreeIPA-users wrote:

For offline authentication mode,  I have to give up single prompting. then,,
I should get pwd  and otp seperately.
2fa user / 2 factor input separately,

Can I use sshpass ? As I research , I can't find any way to convey pwd and otp 
seperately by using sshpass.


I don't think you'd be able to use sshpass without modifications.
sshpass does not take into account multiple prompts.

You probably best to switch to GSSAPI authentication instead: obtain a
Kerberos ticket to this user locally and then use that ticket to
authenticate to your SSH server.

Another alternative is to use SSH keys.

--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Re: when 2FA enabled, with 2 factor prompt asking doesn't work

[Alexander Bokovoy via FreeIPA-users]

On Пан, 27 мая 2024, seojeong kim via FreeIPA-users wrote:

IPA offline authentication mode doesn't work  when sssd.conf has  sing_prompt = 
True for  ipauserauthtype=otp   user?
When I have a test,   ipauserauthtype = otp.

singple_prompt = False,
first_factor = pwd :
second_factor = otp :

offline authentication works with above configuration but,  when I set 
Single_prompt  = True,
offline authentication doesn't work.


That is expected. Offline authentication works by storing a hashed
version of a password locally and then comparing hashed version of an
entered password against this hash. As a result, when you use a single
prompt, there is no separate password to hash, the whole pin+token
sequence is hashed. Since token value changes each time, it will never
match the stored hashed version.

If you want offline authentication to work in such case, you have to
give up single prompting.


--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Re: AllowUsers/Groups on ipa clients

[Alexander Bokovoy via FreeIPA-users]

On Суб, 25 мая 2024, Sam Morris wrote:

On Sat, 2024-05-25 at 12:46 +0100, Sam Morris via FreeIPA-users wrote:

On Sat, 2024-05-25 at 11:01 +0300, Alexander Bokovoy via FreeIPA-
users
wrote:
> On Пят, 24 мая 2024, Sam Morris via FreeIPA-users wrote:
> > On 24/05/2024 15:52, Alexander Bokovoy via FreeIPA-users wrote:
> > > On Fri, 24 May 2024, Sam Morris via FreeIPA-users wrote:
> > > > On 24/05/2024 13:07, Sam Morris via FreeIPA-users wrote:
> > > > > On non-IPA clients I'm using AllowUsers/AllowGroups to
> > > > > restrict
> > > > > which local users are able to SSH into a system.
> > > > >
> > > > > On IPA clients I am using HBAC to control the same for IPA
> > > > > users. But what's the best way to control which local users
> > > > > can
> > > > > SSH in to an IPA client?
> > > >
> > > > Sorry, I forgot to add "... without disrupting access to the
> > > > IPA
> > > > client for IPA users".
> > >
> > > [...]
> > >
> > > I don't understand why you cannot handle the access control
> > > through HBAC
> > > rules. These days glibc supports group merging feature (since
> > > glibc
> > > 2.24, around 2016), so you can have a group in IPA and a group
> > > in
> > > /etc/group, then include local user into that local group. With
> > > appropriate configuration, SSSD will add local user into that
> > > IPA
> > > group
> > > membership locally and thus you can use that IPA group in HBAC
> > > rules.
> > >
> > > See
> > > https://sourceware.org/glibc/wiki/Proposals/GroupMerging and
> > > man
> > > page for nsswitch.conf(5), 'merge' ACTION for 'group'
> > > database.>
> >
> > Thanks for that, I haven't used group merging yet. But, hmm, I'm
> > not
> > sure it will help here...
> >
> > My goals are:
> >
> > * Local user access to be controlled by group membership
> > * IPA user access to be controlled via IPA HBAC
> > * IPA user access to not be controlled by group membership
>
> I don't know how you would get that working. What I suggest instead
> is
> to have both local and IPA users access done via IPA HBAC. This is
> possible to achieve without modifying any PAM or SSH daemon setup.
>
> [...]
>
> Your IPA allow-ssh POSIX group will have no members in IPA.
> Your local allow-ssh POSIX group will have local users that need to
> be
> logged in on a specific host.
>
> Your HBAC rule for allow-ssh would include IPA allow-ssh group.
> That
> is
> enough -- the rest is done by SSSD on the specific system.

Oh, I didn't know that HBAC rules could apply to local users!

I've now got an HBAC rule that has sshd added to it as well as my
empty
IPA POSIX group. And it applies to all hosts. I've not yet added my
local user (id 1000) to it, but the local user can still log in.

I'm on Fedora 40 and I've got the standard authselect sssd profile
selected and the "enable-with-files-access-provider" feature enabled.
This gives me the following PAM configuration:

--- /etc/pam.d/sshd
account    required pam_sepermit.so
account    required pam_nologin.so
account    include  password-auth

--- /etc/pam.d/password-auth
account required pam_unix.so
account sufficient   pam_usertype.so issystem
account [default=bad success=ok user_unknown=ignore] pam_sss.so
#account required pam_deny.so
account required  pam_permit.so

By uncommenting and moving the pam_deny line around I can see that
it's
pam_sss that's letting my local user in, even though they are not a
member of any groups added to any HBAC rules.

At debug_level 4 these messages are printed to sssd_pam.log:

(2024-05-25 12:39:49): [pam] [pam_cmd_acct_mgmt] (0x0100): [CID#11]
entering pam_cmd_acct_mgmt
(2024-05-25 12:39:49): [pam] [pam_print_data] (0x0100): [CID#11]
command: SSS_PAM_ACCT_MGMT
(2024-05-25 12:39:49): [pam] [pam_print_data] (0x0100): [CID#11]
domain: not set
(2024-05-25 12:39:49): [pam] [pam_print_data] (0x0100): [CID#11]
user: local
(2024-05-25 12:39:49): [pam] [pam_print_data] (0x0100): [CID#11]
service: sshd
(2024-05-25 12:39:49): [pam] [pam_print_data] (0x0100): [CID#11] tty:
ssh
(2024-05-25 12:39:49): [pam] [pam_print_data] (0x0100): [CID#11]
ruser: not set
(2024-05-25 12:39:49): [pam] [pam_print_data] (0x0100): [CID#11]
rhost: ::1
(2024-05-25 12:39:49): [pam] [pam_print_data] (0x0100): [CID#11]
authtok type: 0 (No authentication token available)
(2024-05-25 12:39:49): [pam] [pam_print_data] (0x0100): [CID#11]
newauthtok type: 0 (No authentication token available)
(20

[Freeipa-users] Re: AllowUsers/Groups on ipa clients

[Alexander Bokovoy via FreeIPA-users]

On Пят, 24 мая 2024, Sam Morris via FreeIPA-users wrote:

On 24/05/2024 15:52, Alexander Bokovoy via FreeIPA-users wrote:

On Fri, 24 May 2024, Sam Morris via FreeIPA-users wrote:

On 24/05/2024 13:07, Sam Morris via FreeIPA-users wrote:
On non-IPA clients I'm using AllowUsers/AllowGroups to restrict 
which local users are able to SSH into a system.


On IPA clients I am using HBAC to control the same for IPA 
users. But what's the best way to control which local users can 
SSH in to an IPA client?


Sorry, I forgot to add "... without disrupting access to the IPA 
client for IPA users".


[...]

I don't understand why you cannot handle the access control through HBAC
rules. These days glibc supports group merging feature (since glibc
2.24, around 2016), so you can have a group in IPA and a group in
/etc/group, then include local user into that local group. With
appropriate configuration, SSSD will add local user into that IPA group
membership locally and thus you can use that IPA group in HBAC rules.

See https://sourceware.org/glibc/wiki/Proposals/GroupMerging and man
page for nsswitch.conf(5), 'merge' ACTION for 'group' database.>


Thanks for that, I haven't used group merging yet. But, hmm, I'm not 
sure it will help here...


My goals are:

* Local user access to be controlled by group membership
* IPA user access to be controlled via IPA HBAC
* IPA user access to not be controlled by group membership


I don't know how you would get that working. What I suggest instead is
to have both local and IPA users access done via IPA HBAC. This is
possible to achieve without modifying any PAM or SSH daemon setup.



If I create a local group 'allow-ssh' and configure sshd with 
'AllowGroups allow-ssh' then my IPA users can't SSH in any more, 
because they aren't a member of the local group.


So I was thinking that the local group combined with "AllowGroups 
ipausers allow-ssh" would work, but then we have the undesirably large 
POSIX group that will cause performance in large domains.


If I understand group merging correctly, it lets me create a local 
allow-ssh group with the same GID as an IPA POSIX allow-ssh group, and 
then looking up the group's membership will return both local and IPA 
users. But doesn't that mean all my users need to be in the IPA 
allow-ssh POSIX group, which is no different to making ipausers into a 
POSIX group?


Your IPA allow-ssh POSIX group will have no members in IPA.
Your local allow-ssh POSIX group will have local users that need to be
logged in on a specific host.

Your HBAC rule for allow-ssh would include IPA allow-ssh group. That is
enough -- the rest is done by SSSD on the specific system.

Try it. ;)

--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Re: pki-tomcatd service stopped

[Alexander Bokovoy via FreeIPA-users]

On Fri, 24 May 2024, Natxo Asenjo via FreeIPA-users wrote:

hi,

after a botched update (https://access.redhat.com/solutions/7065748) and
rolling back the changes, this service will not start:

# ipactl status
Directory Service: RUNNING
krb5kdc Service: RUNNING
kadmin Service: RUNNING
named Service: RUNNING
httpd Service: RUNNING
ipa-custodia Service: RUNNING
pki-tomcatd Service: STOPPED
smb Service: RUNNING
winbind Service: RUNNING
ipa-otpd Service: RUNNING
ipa-dnskeysyncd Service: RUNNING
1 service(s) are not running

in journalctl I found this stdout/stderr messages:


May 24 11:40:35 kdc1.sub.domain.tld named[27437]: zone sub.domain.tld/IN:
sending notifies (serial 1716543629)
May 24 11:40:35 kdc1.sub.domain.tld pki-server[27758]: ERROR: Unable to
parse version number: "11.5.0"
May 24 11:40:35 kdc1.sub.domain.tld pki-server[27758]: Traceback (most
recent call last):
May 24 11:40:35 kdc1.sub.domain.tld pki-server[27758]:   File
"/usr/lib/python3.9/site-packages/pki/server/pkiserver.py", line 41, in

May 24 11:40:35 kdc1.sub.domain.tld pki-server[27758]:
cli.execute(sys.argv)
May 24 11:40:35 kdc1.sub.domain.tld pki-server[27758]:   File
"/usr/lib/python3.9/site-packages/pki/server/cli/__init__.py", line 145, in
execute
May 24 11:40:35 kdc1.sub.domain.tld pki-server[27758]:
super().execute(args)
May 24 11:40:35 kdc1.sub.domain.tld pki-server[27758]:   File
"/usr/lib/python3.9/site-packages/pki/cli/__init__.py", line 217, in execute
May 24 11:40:35 kdc1.sub.domain.tld pki-server[27758]:
module.execute(module_args)
May 24 11:40:35 kdc1.sub.domain.tld pki-server[27758]:   File
"/usr/lib/python3.9/site-packages/pki/server/cli/upgrade.py", line 144, in
execute
May 24 11:40:35 kdc1.sub.domain.tld pki-server[27758]: self.upgrade(
May 24 11:40:35 kdc1.sub.domain.tld pki-server[27758]:   File
"/usr/lib/python3.9/site-packages/pki/server/cli/upgrade.py", line 178, in
upgrade
May 24 11:40:35 kdc1.sub.domain.tld pki-server[27758]:
upgrader.upgrade()
May 24 11:40:35 kdc1.sub.domain.tld pki-server[27758]:   File
"/usr/lib/python3.9/site-packages/pki/upgrade.py", line 481, in upgrade
May 24 11:40:35 kdc1.sub.domain.tld pki-server[27758]: versions =
self.versions()
May 24 11:40:35 kdc1.sub.domain.tld pki-server[27758]:   File
"/usr/lib/python3.9/site-packages/pki/upgrade.py", line 238, in versions
May 24 11:40:35 kdc1.sub.domain.tld pki-server[27758]: current_version
= self.get_current_version()
May 24 11:40:35 kdc1.sub.domain.tld pki-server[27758]:   File
"/usr/lib/python3.9/site-packages/pki/upgrade.py", line 341, in
get_current_version
May 24 11:40:35 kdc1.sub.domain.tld pki-server[27758]: current_version
= self.get_tracker().get_version()
May 24 11:40:35 kdc1.sub.domain.tld pki-server[27758]:   File
"/usr/lib/python3.9/site-packages/pki/upgrade.py", line 141, in get_version
May 24 11:40:35 kdc1.sub.domain.tld pki-server[27758]: return
pki.util.Version(version)
May 24 11:40:35 kdc1.sub.domain.tld pki-server[27758]:   File
"/usr/lib/python3.9/site-packages/pki/util.py", line 613, in __init__
May 24 11:40:35 kdc1.sub.domain.tld pki-server[27758]: raise
Exception('Unable to parse version number: %s' % obj)
May 24 11:40:35 kdc1.sub.domain.tld pki-server[27758]: Exception: Unable to
parse version number: "11.5.0"


What do you have in /etc/pki/pki.version file? Is it literally

# cat /etc/pki/pki.version
Configuration-Version: "11.5.0"

? If so, then remove quotes around 11.5.0, they are not expected.


May 24 11:40:35 kdc1.sub.domain.tld systemd[1]:
pki-tomcatd@pki-tomcat.service: Control process exited, code=exited,
status=1/FAILURE
May 24 11:40:35 kdc1.sub.domain.tld systemd[1]:
pki-tomcatd@pki-tomcat.service: Failed with result 'exit-code'.
May 24 11:40:35 kdc1.sub.domain.tld systemd[1]: Failed to start PKI Tomcat
Server pki-tomcat.

So it seems something is broken on this upgrade script. This is in in
almalinux 9.3
ipa-server-4.10.2-5.el9_3.alma.1.x86_64

I cannot upgrade because I get bitten by the named ldap thing, even though
the versions are newer.

I will create a replicat to a rhel host but first I need to get the CA up
and running obviously :-).

Any ideas?

Thanks!

--
regards,

natxo

--
--
Groeten,
natxo





--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Re: AllowUsers/Groups on ipa clients

[Alexander Bokovoy via FreeIPA-users]

On Fri, 24 May 2024, Sam Morris via FreeIPA-users wrote:

On 24/05/2024 13:07, Sam Morris via FreeIPA-users wrote:
On non-IPA clients I'm using AllowUsers/AllowGroups to restrict 
which local users are able to SSH into a system.


On IPA clients I am using HBAC to control the same for IPA users. 
But what's the best way to control which local users can SSH in to 
an IPA client?


Sorry, I forgot to add "... without disrupting access to the IPA 
client for IPA users".


It looks like I could modify the ipausers group to be a POSIX group, 
and then put 'AllowGroups ipausers' into sshd_config. That way all 
local users would be denied, and all IPA suers would be allowed, 
with pam_sss.so later controlling access based on HBAC.


I found this in the FreeIPA 2.2.0 release notes:

"On new installations the default users group, ipausers, is now 
non-POSIX to speed up user enumeration in SSSD. To make ipausers a 
POSIX group run ipa group-mod –posix ipausers."


So it seems like this is a safe and normal thing to do. I wonder if 
there are any references to the user enumeration performance issue in 
SSSD? My own domain doesn't have many users, but I'm also considering 
doing this at work, and I'd like to understand the sorts of issues it 
might cause.


We made 'ipausers' group non-POSIX due to memberof computational
complexity. If you have several thousands users, every time you'd add a
new user, it gets added to ipausers group and then that group's
membership has to be re-calculated, leading to evaluation of data and
potential update of thousands entries. This slows down 'ipa user-add',
for example, substantially. For POSIX 'ipausers' group this also means
constant churn of querying LDAP and retrieving all user entries for each
SSSD client because they'd need to resolve this group on the client as
it is a POSIX one.

So we ended up with fixing the latter, making ipausers non-POSIX group
and solving 'all clients must chase all user data every time a new user
is added' worst case scenario.

I don't understand why you cannot handle the access control through HBAC
rules. These days glibc supports group merging feature (since glibc
2.24, around 2016), so you can have a group in IPA and a group in
/etc/group, then include local user into that local group. With
appropriate configuration, SSSD will add local user into that IPA group
membership locally and thus you can use that IPA group in HBAC rules.

See https://sourceware.org/glibc/wiki/Proposals/GroupMerging and man
page for nsswitch.conf(5), 'merge' ACTION for 'group' database.

--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Re: update clients dns records

[Alexander Bokovoy via FreeIPA-users]

On Срд, 22 мая 2024, Rob Crittenden via FreeIPA-users wrote:

Dmitry Krasov via FreeIPA-users wrote:

Hi Florence.
As far as I understand, it's all because the keytab file become bad in some 
time.

1. Why it's so?
2. I know how to fix file manually, but how can I check it in script "if file become 
bad"?


What makes you think the keytab is bad?

A simple way to validate a keytab is to compare the version number to
the one the KDC has.

$ kinit admin
$ kvno host/

# klist -kt /etc/krb5.keytab

Compare the version numbers. It's ok for the keytab to have multiple
versions but one has to match what the KDC version number is.


It would also help to see SSSD logs that show how nsupdate runs and what
fails there. Or why is it not running. SSSD will tell some details in
the logs if you enable debug level 9.



--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Re: FreeIPA v4.11 - wsgi:ipa high cpu load

[Alexander Bokovoy via FreeIPA-users]

On Аўт, 14 мая 2024, Djerk Geurts via FreeIPA-users wrote:


Hi all,

Last week, we saw CPU jump from 7% to 62% on our primary FreeIPA server 
(4.11.1-2.fc39) on Fedora 39. Inspecting the server shows that the wigs:ipa 
process runs at >95% CPU.

Has anyone else observed this, and would anyone have a solution, or be able to 
point me in the right direction for what might be causing this?

FreeIPA works fine and we can’t tell any adverse effects on the server apart 
from burning more CPU.


Haven't seen that. Any chance you can collect a backtrace from that
process?

I think you'd need to install debuginfo first to have a meaningful
output...


--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Re: External IdP/OAuth - additional feature ideas

[Alexander Bokovoy via FreeIPA-users]

On Аўт, 14 мая 2024, Manuel Linsmayer via FreeIPA-users wrote:

Hello,

I've connected FreeIPA to Dex and Keycloak, which works fine. However,
there are two features I'm missing, which would make life a lot easier:

- Automatic creation of user account upon first "login" -- at the
moment, the FreeIPA user has to be created upfront, and the "IdP
reference" has to be set. If the "preferred username" from the IdP can
be the same as the username in FreeIPA, then the FreeIPA account could
be provisioned automatically.

- Evaluation of group memberships from Userinfo endpoint -- upon every
login, group memberships should be adapted. This way, group memberships
could be managed in the IdP system.


These questions need to be asked from those IdPs. Depending on how they
implement their retrieval of user data from IPA, they probably will need
to improve. I suspect you are using something that talks directly to
LDAP and thus has a need to create accounts via LDAP with enough
privileges to do so. Same for group membership -- somebody has to
re-evaluate those group details after a change and that change at LDAP
side might be not noticed by the IdP.


Or are there any other features available to "ease" and "streamline"
the integration between IdP and FreeIPA?


We are working on a companion project that attempts to create a new
backend to Keycloak. It uses SSSD as a backend itself but is able to set
things up in such way that autocreation of users happens automatically
through IPA API.

See https://github.com/freeipa/ipa-tuura/ and FOSDEM 2024's talk for
more details. 


FOSDEM talk: 
https://fosdem.org/2024/schedule/event/fosdem-2024-2618-ipa-tuura-freeipa-connector-for-keycloak/



--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Re: unable to convert attribute 'cacertificate:binary'

[Alexander Bokovoy via FreeIPA-users]

On Аўт, 30 кра 2024, Antoine Gatineau via FreeIPA-users wrote:


On 4/30/24 15:34, Rob Crittenden wrote:

Antoine Gatineau via FreeIPA-users wrote:

Hello,

When enrolling a opensuse tumbleweed client, ipa-client-install fails to
get the cacertificate from ldap with error:

2024-04-30T11:23:16Z DEBUG Initializing principal adminprincipal using
password
2024-04-30T11:23:16Z DEBUG Starting external process
2024-04-30T11:23:16Z DEBUG args=['/usr/bin/kinit', 'adminuser', '-c',
'/tmp/krbcc2swf0edk/ccache']
2024-04-30T11:23:16Z DEBUG Process finished, return code=0
2024-04-30T11:23:16Z DEBUG stdout=Password for adminuser:

2024-04-30T11:23:16Z DEBUG stderr=
2024-04-30T11:23:16Z DEBUG trying to retrieve CA cert via LDAP from
ipa-server-01.empire.lan
2024-04-30T11:23:16Z DEBUG retrieving schema for SchemaCache
url=ldap://ipa-server-01.empire.lan:389
conn=
2024-04-30T11:23:17Z ERROR unable to convert the attribute
'cacertificate;binary' value
b'0\x82\x04\x.ETC' to
type 
2024-04-30T11:23:17Z DEBUG get_ca_certs_from_ldap() error: %i format: a
real number is required, not dict
2024-04-30T11:23:17Z DEBUG %i format: a real number is required, not dict
2024-04-30T11:23:17Z ERROR Cannot obtain CA certificate
'ldap://ipa-server-01.empire.lan' doesn't have a certificate.
2024-04-30T11:23:17Z ERROR Installation failed. Rolling back changes.

ipa server is 4.11.0 (centos stream 9 latest)

ipa client is 4.11.1 (opensuse tumbleweed) from this source:
https://build.opensuse.org/package/show/security%3Aidm/freeipa


With debian 12 and ipa-client 4.9.11 the enrollment succeeds.

With centos stream 9 and ipa-client 4.11.0 the enrollment succeeds.

Is there a limitation with clients newer than the server?

Not usually.


What can I check to fix this issue?

I'd start with comparing what version of python-cryptography is on the
working vs non-working systems.


debian: 38.0.4-3 (python 3.11)

centos stream: 36.0.1-4.el9 (python 3.9)

tumbleweed: python311-cryptography 42.0.5-1.1

Indeed, it is quite newer on tumbleweed.

https://cryptography.io/en/latest/changelog/
There are some deprecations in 39.0 that might be in play but I don't 
know exactly what is used by ipa.


*

  *BACKWARDS INCOMPATIBLE:* Removed the |encode_point| and
  |from_encoded_point| methods on |EllipticCurvePublicNumbers|
  
,
  which had been deprecated for several years. |public_bytes()|
  

  and |from_encoded_point()|
  

  should be used instead.

*

  *BACKWARDS INCOMPATIBLE:* Support for using MD5 or SHA1 in
  |CertificateBuilder|
  
,
  other X.509 builders, and PKCS7 has been removed.


We don't use any of those features at all.

Fedora 39+ is using python-cryptography 42.0.5 and it works fine with
FreeIPA with a set of fixes to https://pagure.io/freeipa/issue/9518.
Perhaps Tumbleweed misses these patches?

My concern and why I asked to provide the certificate was due to the
particular message displayed in your logs. That message comes from
PyUnicode_Format() which is internal Python function that is called by
internal Python code when a string is transformed from bytes to Python
string. Neither FreeIPA nor Cryptography code provides any string that
uses '%i' format in the certificate parsing path. This means it might be
a string from the certificate itself here. However, the certificate you
sent me does not have any problem and is loadable without issues.



--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Re: unable to convert attribute 'cacertificate:binary'

[Alexander Bokovoy via FreeIPA-users]

On Аўт, 30 кра 2024, Antoine Gatineau via FreeIPA-users wrote:

Hello,

When enrolling a opensuse tumbleweed client, ipa-client-install fails 
to get the cacertificate from ldap with error:


2024-04-30T11:23:16Z DEBUG Initializing principal adminprincipal using 
password

2024-04-30T11:23:16Z DEBUG Starting external process
2024-04-30T11:23:16Z DEBUG args=['/usr/bin/kinit', 'adminuser', '-c', 
'/tmp/krbcc2swf0edk/ccache']

2024-04-30T11:23:16Z DEBUG Process finished, return code=0
2024-04-30T11:23:16Z DEBUG stdout=Password for adminuser:

2024-04-30T11:23:16Z DEBUG stderr=
2024-04-30T11:23:16Z DEBUG trying to retrieve CA cert via LDAP from 
ipa-server-01.empire.lan
2024-04-30T11:23:16Z DEBUG retrieving schema for SchemaCache 
url=ldap://ipa-server-01.empire.lan:389 
conn=
2024-04-30T11:23:17Z ERROR unable to convert the attribute 
'cacertificate;binary' value 
b'0\x82\x04\x.ETC' to 
type 
2024-04-30T11:23:17Z DEBUG get_ca_certs_from_ldap() error: %i format: 
a real number is required, not dict

2024-04-30T11:23:17Z DEBUG %i format: a real number is required, not dict
2024-04-30T11:23:17Z ERROR Cannot obtain CA certificate
'ldap://ipa-server-01.empire.lan' doesn't have a certificate.
2024-04-30T11:23:17Z ERROR Installation failed. Rolling back changes.

ipa server is 4.11.0 (centos stream 9 latest)

ipa client is 4.11.1 (opensuse tumbleweed) from this source: 
https://build.opensuse.org/package/show/security%3Aidm/freeipa



With debian 12 and ipa-client 4.9.11 the enrollment succeeds.

With centos stream 9 and ipa-client 4.11.0 the enrollment succeeds.

Is there a limitation with clients newer than the server?

What can I check to fix this issue?


Start by checking the certificate itself. Can you provide it (offline,
if needed)?



--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Re: IPA replica cannot lookup AD trust users (worked before)

[Alexander Bokovoy via FreeIPA-users]

On Пят, 26 кра 2024, slek kus via FreeIPA-users wrote:

Hi Alexander, according to /etc/resolv.conf it is integrated and points to 
localhost, but nmcli says DNS is set to idm01.
A bit strange, since resolv.conf is generated by networkmanager.

[root@idm02 ~]# nmcli dev show | grep DNS
IP4.DNS[1]: 172.16.27.10   < this is idm01
[root@idm02 ~]# cat /etc/resolv.conf
# Generated by NetworkManager
search linux.redacted.domain
nameserver 127.0.0.1


Both servers are in the same nertwork.

On idm02, I can resolve the ipa domain it is the AD domains that fail:

[root@idm02 ~]# host -t SRV _ldap._tcp.linux.redacted.domain
_ldap._tcp.linux.redacted.domain has SRV record 0 200 389 
idm02.linux.redacted.domain.
_ldap._tcp.linux.redacted.domain has SRV record 0 100 389 
idm01.linux.redacted.domain.


Do you have DNSSEC validation enforced on BIND side?

# grep dnssec /etc/named/ipa-options-ext.conf
/* dnssec-enable is obsolete and 'yes' by default */
dnssec-validation no;

If dnssec-validation is set to yes, that would explain because your AD
DNS server most likely is not using DNSSEC at all.

--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Re: IPA replica cannot lookup AD trust users (worked before)

[Alexander Bokovoy via FreeIPA-users]

On Пят, 26 кра 2024, slek kus via FreeIPA-users wrote:

Hi Sumit, that does not return anything good on the replica. See below.

On the main IPA node node:

[alma@idm01 ~]$ host -t SRV _ldap._tcp.redacted.domain
_ldap._tcp.redacted.domain has SRV record 0 100 389 dc01.redacted.domain.
_ldap._tcp.redacted.domain has SRV record 0 100 389 dc01.redacted.domain.

[alma@idm01 ~]$ host -t SRV _ldap._tcp.domaina.redacted.domain
_ldap._tcp.domaina.redacted.domain has SRV record 0 100 389 
windc-dc01.domaina.redacted.domain.
_ldap._tcp.domaina.redacted.domain has SRV record 0 100 389 
windc-dc02.domaina.redacted.domain.

[alma@idm01 ~]$ host -t SRV _ldap._tcp.domainb.redacted.domain
_ldap._tcp.domainb.redacted.domain has SRV record 0 100 389 
windc-dc02.domainb.redacted.domain.
_ldap._tcp.domainb.redacted.domain has SRV record 0 100 389 
windc-dc01.domainb.redacted.domain.

On the secondary (replica):

[alma@idm02 ~]$  host -t SRV _ldap._tcp.redacted.domain
Host _ldap._tcp.redacted.domain not found: 2(SERVFAIL)

[alma@idm02 ~]$  host -t SRV _ldap._tcp.domainb.redacted.domain
Host _ldap._tcp.domainb.redacted.domain not found: 2(SERVFAIL)

[alma@idm02 ~]$  host -t SRV _ldap._tcp.domaina.redacted.domain
Host _ldap._tcp.domaina.redacted.domain not found: 2(SERVFAIL)

The DNS zone seems replicated and OK on the replica. The record is present 
there too.


What is used as a DNS server for the idm02? Are you running idm02 with
an integrated DNS server or it is some other machine that resolves the
queries?

SERVFAIL means DNS server did return an error when processing your
request. Judging that this error happens for IPA domain's DNS zone and
for others too, I wonder if you have a generic DNS resolution issue from
idm02? For example, if idm01 is used as a DNS server there and idm02 is
in a different IP network, then BIND on idm01 will not allow DNS client
from idm02 to perform DNS queries. You'd need to add an ACL to allow
that.

Or it could be a DNSSEC error where a client is configured to have
DNSSEC validation but the DNS server responds without DNSSEC.



On the main IPA node node:

[alma@idm01 ~]$ ipa dnsrecord-find linux.redacted.domain.
Record name: _ldap._tcp
 SRV record: 0 100 389 idm01.linux.redacted.domain., 0 200 389 
idm02.linux.redacted.domain.

On the secondary (replica):
-
[alma@idm02 ~]$ ipa dnsrecord-find linux.redacted.domain.
Record name: _ldap._tcp
 SRV record: 0 100 389 idm01.linux.redacted.domain., 0 200 389 
idm02.linux.redacted.domain.
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue




--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Re: Question regarding “Samba on an IdM domain member”

[Alexander Bokovoy via FreeIPA-users]

On Пан, 22 кра 2024, Thomas Handler via FreeIPA-users wrote:


Hello,

beginning of March I have received support running Samba on an IdM
domain member from Alexander. Back then my problem was what Alexander
pinpoints in his
text https://vda.li/en/posts/2019/03/24/Kerberos-host-to-realm-translation/ 
under
"Mixed realm deployments” where the Linux machine running Samba was in
the wrong DNS zone.

After having fixed this things are running fine.

Now it came as it already was obvious back then and what is well noted
already in the RedHat
Docs 
https://access.redhat.com/documentation/en-en/red_hat_enterprise_linux/9/html/using_external_red_hat_utilities_with_identity_management/setting-up-samba-on-an-idm-domain-member_using-external-red-hat-utilities-with-idm
 where
is stated “AD users logged into a Windows machine can not access Samba
shares hosted on an IdM domain member”.

So the customer has now stumbled exactly over this and I just wanted to
confirm that my understanding of this section in the docs is correct
and that there’s no way to ensure that an AD user on a Windows machine
can access the shares on the Samba machine joined to IdM. 


Short answer: yes, the documentation is up to date.


--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Re: windows client auth not working

[Alexander Bokovoy via FreeIPA-users]

On Аўт, 16 кра 2024, Anton Menshutin via FreeIPA-users wrote:

Hello, list.
I have installed freeipa server 4.10.2-8 under RockyLinux and would
like to setup windows clients to join freeipa domain.  I followed the
guide
https://www.freeipa.org/page/Windows_authentication_against_FreeIPA.


This is a hack and is not supported at all. It is explicitly stated on
that page:

Note also that the described configuration is not supported by FreeIPA
development team and also is not supported by Red Hat Enterprise Linux
Identity Management product. A work on making possible to login to
Windows machines already enrolled into a trusted Active Directory forest
is ongoing and is not available yet in any released FreeIPA version.



When I enter user credentials for the first time windows asks to change
password, after password is changed it does not login.

After that every attempt results in the "wrong user or password"
message.  Looking at kerberos log it seems that password is correct but
windows does not let the user in for some reason. In audit log it says
that login was refused with some error that does not explain anything.
Time is in sync as well as timezone.

There are a lot of posts saying that this should work but I don't have
any clues where to look. Any ideas what might be wrong?


Joining Windows clients to IPA domain is not supported. These
configurations may or may not work for some people. There are no plans
to enable this use case at all.

--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Re: upgrade idm servers rhel 7 to 8 problems

[Alexander Bokovoy via FreeIPA-users]

On Аўт, 02 кра 2024, Natxo Asenjo wrote:

hi,



On Tue, Mar 26, 2024 at 2:47 PM Natxo Asenjo  wrote:


hi,

posting back to the list.

Apparently the idm server cannot find a SID of a domain when trying to
resolve the user account. It does find the user account, but  there are
sids coupled to the account correspondig to a domain wich cannot be
resolved.

It took me a while but the sid of that child domain is not the one not
resolved.

It turns out, the sid of the domain not resolving is the one of the idm
realm itself., we have  some idm groups mapped to the AD groups we allow in
idm for rbac, and if I look at the ipaNTSecurityIdentifier attributes of
the id groups, those are the not resolved groups.

This is unexpected (to me at least).

so we have this trust (verified on two different idm servers, same value):

 ipa trust-find
---
1 trust matched
---
  Realm name: domain.local
  Domain NetBIOS name: DOMAIN
  Domain Security Identifier: S-1-5-21-1416133915-1866970209-3316290679
  Trust type: Active Directory domain

Number of entries returned 1

but inside this idm domain, we have some idm posix groups with the
ipantsecurityidentifier of the not resolvable domain, for instance:
S-1-5-21-1214650608-3976977395-3073169311-101072

So basically, it is not matching because of this ipantsecurityidentifier,
I think.

I do not know how to fix this at this moment, or why it has happened. Any
ideas?




I wonder if somebody with more sssd knowlegde than me could push me in the
right direction. Is it maybe better to ask in the sssd mailing list?


No idea why is that. Is the SID of IPA domain
S-1-5-21-1214650608-3976977395-3073169311? If not, please replace SIDs
of the IPA groups that have S-1-5-21-1214650608-3976977395-3073169311 in
their ipaNTSecurityIdentifier by the proper IPA domain SID. You probably
need to construct an LDIF file that does this modification.





Regards,

Natxo Asenjo

--
--
Groeten,
natxo





--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Re: How to prevent non-admin users of FreeIPA from reading the list of users in the web interface?

[Alexander Bokovoy via FreeIPA-users]

On Чцв, 04 кра 2024, Riccardo Rotondo via FreeIPA-users wrote:

Hi Alexander,

Thank you Alexander, this solution probably fits our needs.
My only problem now is the I configured freeipa with docker, and in
that image developer didn't include the Fedora Account System plugin
for IPA so in the log I found:

ERROR in middleware: Uncaught IPA exception: Unknown option: fasgroup

I'll check with them if I can add this plug in post installation.


I'd say you need to build your own image on top of
freeipa/freeipa-container. I'd rather do that by cloning git repo and
extending 


RUN yum -y install --setopt=install_weak_deps=False ipa-server ipa-server-dns 
ipa-server-trust-ad patch ipa-healthcheck ipa-client-epn && yum clean all

in one of the Dockerfile.* for your target. Or you can derive from
freeipa-container image and explicitly add that in your own Dockerfile.


--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Re: Client install fails with: "Joining realm failed: JSON-RPC call failed: Timeout was reached"

[Alexander Bokovoy via FreeIPA-users]

On Sun, 31 Mar 2024, Antoine Gatineau via FreeIPA-users wrote:
iirc port 80 and 443 are needed. 123 is for ntp so if you don't sync 
time from the ipa servers you woudl not need that port.


https://access.redhat.com/solutions/357673


Everything is covered in the documentation:

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/installing_identity_management/preparing-the-system-for-ipa-server-installation_installing-identity-management#port-requirements-for-idm_preparing-the-system-for-ipa-server-installation

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/installing_identity_management/preparing-the-system-for-ipa-client-installation_installing-identity-management#port-requirements-for-ipa-clients_preparing-the-system-for-ipa-client-installation

It is best to follow the documentation -- take
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9
and check the box 'Identity management' on the left side to limit amount
of books to the topics relevant to identity management. Unfortunately,
currently this documentation site does not allow pre-select the topics.

Another place to look is this old draft I never managed to turn into a
blog or documentation article myself:
https://vda.li/drafts/firewall-considerations.txt

It is still valid.



On 3/29/24 13:13, slek kus via FreeIPA-users wrote:

Hi, not sure what might be an issue. Clients in the same network join just fine.
The failing client is on another network. The following ports have been 
allowed: 53, 389, 636, 88, 464
Saw a list somewhere, mentioning 123, 80 and 443. Are these porst nessecary for 
the client/idm communication?
--
___
FreeIPA-users mailing list --freeipa-users@lists.fedorahosted.org
To unsubscribe send an email tofreeipa-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
Do not reply to spam, report 
it:https://pagure.io/fedora-infrastructure/new_issue





--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Re: upgrade idm servers rhel 7 to 8 problems

[Alexander Bokovoy via FreeIPA-users]

On Пан, 25 сак 2024, Natxo Asenjo wrote:

On Mon, Mar 25, 2024 at 2:50 PM Alexander Bokovoy 
wrote:


On Пан, 25 сак 2024, Natxo Asenjo wrote:
>On Mon, Mar 25, 2024 at 1:49 PM Alexander Bokovoy 
>wrote:

>> Can you give more details about this ID?
>>
>
>is this a local user account ?
>
>On both client and server involved in this problem:
>
># id -nu 2000
>id: ‘2000’: no such user
>
>Or I am misunderstanding your question, if so, apologies?

There are quite a few IDs that get the same treatment:

(2024-03-25 11:17:07): [be[idm.domain.local]] [ad_account_can_shortcut]
(0x0080): [RID#146] Mapping ID [65535] to SID failed: [IDMAP domain not
found]
(2024-03-25 11:17:07): [be[idm.domain.local]] [ad_account_can_shortcut]
(0x0080): [RID#148] Mapping ID [1001] to SID failed: [IDMAP domain not
found]
(2024-03-25 11:17:07): [be[idm.domain.local]] [ad_account_can_shortcut]
(0x0080): [RID#150] Mapping ID [2000] to SID failed: [IDMAP domain not
found]
(2024-03-25 11:17:07): [be[idm.domain.local]] [ad_account_can_shortcut]
(0x0080): [RID#152] Mapping ID [1200] to SID failed: [IDMAP domain not
found]
(2024-03-25 11:17:11): [be[idm.domain.local]] [ad_account_can_shortcut]
(0x0080): [RID#154] Mapping ID [2000] to SID failed: [IDMAP domain not
found]
(2024-03-25 11:17:13): [be[idm.domain.local]] [ad_account_can_shortcut]
(0x0080): [RID#156] Mapping ID [101] to SID failed: [IDMAP domain not found]
(2024-03-25 11:17:13): [be[idm.domain.local]] [ad_account_can_shortcut]
(0x0080): [RID#158] Mapping ID [103] to SID failed: [IDMAP domain not found]
(2024-03-25 11:17:19): [be[idm.domain.local]] [ad_account_can_shortcut]
(0x0080): [RID#160] Mapping ID [65532] to SID failed: [IDMAP domain not
found]
(2024-03-25 11:17:29): [be[idm.domain.local]] [ad_account_can_shortcut]
(0x0080): [RID#162] Mapping ID [101] to SID failed: [IDMAP domain not found]
(2024-03-25 11:17:29): [be[idm.domain.local]] [ad_account_can_shortcut]
(0x0080): [RID#164] Mapping ID [103] to SID failed: [IDMAP domain not found]
(2024-03-25 11:17:37): [be[idm.domain.local]] [ad_account_can_shortcut]
(0x0080): [RID#166] Mapping ID [65532] to SID failed: [IDMAP domain not
found]
(2024-03-25 11:17:45): [be[idm.domain.local]] [ad_account_can_shortcut]
(0x0080): [RID#168] Mapping ID [101] to SID failed: [IDMAP domain not found]
(2024-03-25 11:17:45): [be[idm.domain.local]] [ad_account_can_shortcut]
(0x0080): [RID#170] Mapping ID [103] to SID failed: [IDMAP domain not found]
(2024-03-25 11:17:46): [be[idm.domain.local]] [ad_account_can_shortcut]
(0x0080): [RID#172] Mapping ID [65535] to SID failed: [IDMAP domain not
found]
(2024-03-25 11:17:46): [be[idm.domain.local]] [ad_account_can_shortcut]
(0x0080): [RID#174] Mapping ID [1001] to SID failed: [IDMAP domain not
found]
(2024-03-25 11:17:46): [be[idm.domain.local]] [ad_account_can_shortcut]
(0x0080): [RID#176] Mapping ID [2000] to SID failed: [IDMAP domain not
found]

By the code mark, it is in AD provider:

$ git grep ad_account_can_shortcut
src/providers/ad/ad_id.c:static bool ad_account_can_shortcut(struct
sdap_idmap_ctx *idmap_ctx,
src/providers/ad/ad_id.c:shortcut =
ad_account_can_shortcut(ctx->opts->idmap_ctx,

so it attempts to perform ID to name translation but fails to see if
this ID matches the AD domain's ID range.

If you have full SSSD logs from both client and IPA server at the same
time, those would be helpful.



Of course. If you don't mind I will not sanitize them and send them
directly to you. That will prevent search/replace errors on my part.

I will make 2 tarballs, one for client, one for server, and send them
directly, if it's ok.


That is fine. Thank you!



--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Re: upgrade idm servers rhel 7 to 8 problems

[Alexander Bokovoy via FreeIPA-users]

On Пан, 25 сак 2024, Natxo Asenjo wrote:

On Mon, Mar 25, 2024 at 1:49 PM Alexander Bokovoy 
wrote:



Here we can see ID 2000 cannot be mapped to any domain and thus the ID
cannot be resolved:

(2024-03-25 11:17:07): [be[idm.domain.local]] [sss_domain_get_state]
(0x1000): [RID#150] Domain idm.domain.local is Active
(2024-03-25 11:17:07): [be[idm.domain.local]] [sss_domain_get_state]
(0x1000): [RID#150] Domain domain.local is Active
(2024-03-25 11:17:07): [be[idm.domain.local]]
[ipa_srv_ad_acct_lookup_step] (0x0400): [RID#150] Looking up AD account
(2024-03-25 11:17:07): [be[idm.domain.local]] [sss_domain_get_state]
(0x1000): [RID#150] Domain idm.domain.local is Active
(2024-03-25 11:17:07): [be[idm.domain.local]] [sss_domain_get_state]
(0x1000): [RID#150] Domain domain.local is Active
(2024-03-25 11:17:07): [be[idm.domain.local]] [ad_account_can_shortcut]
(0x0080): [RID#150] Mapping ID [2000] to SID failed: [IDMAP domain not
found]
(2024-03-25 11:17:07): [be[idm.domain.local]] [ad_handle_acct_info_send]
(0x0400): [RID#150] This ID is from different domain
(2024-03-25 11:17:07): [be[idm.domain.local]] [sysdb_search_user_by_uid]
(0x0400): [RID#150] No such entry
(2024-03-25 11:17:07): [be[idm.domain.local]] [get_object_from_cache]
(0x0200): [RID#150] Object wasn't found in cache
(2024-03-25 11:17:07): [be[idm.domain.local]]
[ipa_get_ad_acct_ad_part_done] (0x0080): [RID#150] Object not found, ending
request
(2024-03-25 11:17:07): [be[idm.domain.local]] [sdap_id_op_destroy]
(0x4000): [RID#150] releasing operation connection
(2024-03-25 11:17:07): [be[idm.domain.local]] [sdap_id_conn_data_idle]
(0x4000): [RID#150] Marking connection as idle

Can you give more details about this ID?



is this a local user account ?

On both client and server involved in this problem:

# id -nu 2000
id: ‘2000’: no such user

Or I am misunderstanding your question, if so, apologies?


There are quite a few IDs that get the same treatment:

(2024-03-25 11:17:07): [be[idm.domain.local]] [ad_account_can_shortcut] 
(0x0080): [RID#146] Mapping ID [65535] to SID failed: [IDMAP domain not found]
(2024-03-25 11:17:07): [be[idm.domain.local]] [ad_account_can_shortcut] 
(0x0080): [RID#148] Mapping ID [1001] to SID failed: [IDMAP domain not found]
(2024-03-25 11:17:07): [be[idm.domain.local]] [ad_account_can_shortcut] 
(0x0080): [RID#150] Mapping ID [2000] to SID failed: [IDMAP domain not found]
(2024-03-25 11:17:07): [be[idm.domain.local]] [ad_account_can_shortcut] 
(0x0080): [RID#152] Mapping ID [1200] to SID failed: [IDMAP domain not found]
(2024-03-25 11:17:11): [be[idm.domain.local]] [ad_account_can_shortcut] 
(0x0080): [RID#154] Mapping ID [2000] to SID failed: [IDMAP domain not found]
(2024-03-25 11:17:13): [be[idm.domain.local]] [ad_account_can_shortcut] 
(0x0080): [RID#156] Mapping ID [101] to SID failed: [IDMAP domain not found]
(2024-03-25 11:17:13): [be[idm.domain.local]] [ad_account_can_shortcut] 
(0x0080): [RID#158] Mapping ID [103] to SID failed: [IDMAP domain not found]
(2024-03-25 11:17:19): [be[idm.domain.local]] [ad_account_can_shortcut] 
(0x0080): [RID#160] Mapping ID [65532] to SID failed: [IDMAP domain not found]
(2024-03-25 11:17:29): [be[idm.domain.local]] [ad_account_can_shortcut] 
(0x0080): [RID#162] Mapping ID [101] to SID failed: [IDMAP domain not found]
(2024-03-25 11:17:29): [be[idm.domain.local]] [ad_account_can_shortcut] 
(0x0080): [RID#164] Mapping ID [103] to SID failed: [IDMAP domain not found]
(2024-03-25 11:17:37): [be[idm.domain.local]] [ad_account_can_shortcut] 
(0x0080): [RID#166] Mapping ID [65532] to SID failed: [IDMAP domain not found]
(2024-03-25 11:17:45): [be[idm.domain.local]] [ad_account_can_shortcut] 
(0x0080): [RID#168] Mapping ID [101] to SID failed: [IDMAP domain not found]
(2024-03-25 11:17:45): [be[idm.domain.local]] [ad_account_can_shortcut] 
(0x0080): [RID#170] Mapping ID [103] to SID failed: [IDMAP domain not found]
(2024-03-25 11:17:46): [be[idm.domain.local]] [ad_account_can_shortcut] 
(0x0080): [RID#172] Mapping ID [65535] to SID failed: [IDMAP domain not found]
(2024-03-25 11:17:46): [be[idm.domain.local]] [ad_account_can_shortcut] 
(0x0080): [RID#174] Mapping ID [1001] to SID failed: [IDMAP domain not found]
(2024-03-25 11:17:46): [be[idm.domain.local]] [ad_account_can_shortcut] 
(0x0080): [RID#176] Mapping ID [2000] to SID failed: [IDMAP domain not found]

By the code mark, it is in AD provider:

$ git grep ad_account_can_shortcut
src/providers/ad/ad_id.c:static bool ad_account_can_shortcut(struct 
sdap_idmap_ctx *idmap_ctx,
src/providers/ad/ad_id.c:shortcut = 
ad_account_can_shortcut(ctx->opts->idmap_ctx,

so it attempts to perform ID to name translation but fails to see if
this ID matches the AD domain's ID range.

If you have full SSSD logs from both client and IPA server at the same
time, those would be helpful.


--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
--

[Freeipa-users] Re: upgrade idm servers rhel 7 to 8 problems

[Alexander Bokovoy via FreeIPA-users]

On Пан, 25 сак 2024, Natxo Asenjo wrote:

hi,

apparently a log I attached is a bit too large and awaits moderation. Could
I send it directly to you, mr Bokovoy?


If it is different from the one attached to the previous email, sure.



Thanks in advance.

Regards,

Natxo

On Mon, Mar 25, 2024 at 12:19 PM Natxo Asenjo 
wrote:


hi,

i have added debug = 9 to the domain/idm.domain.local in the sssd.conf of
the idm server and restarted sssd.

I have no hits on the server on the time when the client does a lookup
using id user@domain and finding nothing (no such user)

this is the sss_domain log server file during the same time (as
attachtment with name idm_rhel8server.txt)

During the same minute locally on the rhel8 server I could run the id
user@domain command with a positive result:

(2024-03-25 11:17:55): [nss] [sss_domain_get_state] (0x1000): [CID#1]
Domain domain.local is Active
(2024-03-25 11:17:55): [nss] [sss_parse_name_for_domains] (0x0200):
[CID#1] name 'user@domain' matched expression for domain 'domain.local',
user is user
(2024-03-25 11:17:55): [nss] [sss_nss_get_object_send] (0x0400): [CID#1]
Client [0x55686dfef680][22]: sent cache request #166
(2024-03-25 11:17:55): [nss] [cache_req_set_name] (0x0400): [CID#1] CR
#166: Setting name [user]
(2024-03-25 11:17:55): [nss] [cache_req_select_domains] (0x0400): [CID#1]
CR #166: Performing a single domain search
(2024-03-25 11:17:55): [nss] [sss_domain_get_state] (0x1000): [CID#1]
Domain idm.domain.local is Active
(2024-03-25 11:17:55): [nss] [sss_domain_get_state] (0x1000): [CID#1]
Domain domain.local is Active
(2024-03-25 11:17:55): [nss] [cache_req_search_domains] (0x0400): [CID#1]
CR #166: Search will check the cache and check the data provider
(2024-03-25 11:17:55): [nss] [cache_req_validate_domain_type] (0x2000):
[CID#1] Request type POSIX-only for domain domain.local type POSIX is valid
(2024-03-25 11:17:55): [nss] [cache_req_set_domain] (0x0400): [CID#1] CR
#166: Using domain [domain.local]
(2024-03-25 11:17:55): [nss] [cache_req_prepare_domain_data] (0x0400):
[CID#1] CR #166: Preparing input data for domain [domain.local] rules
(2024-03-25 11:17:55): [nss] [cache_req_search_send] (0x0400): [CID#1] CR
#166: Looking up user@domain.local
(2024-03-25 11:17:55): [nss] [cache_req_search_ncache] (0x0400): [CID#1]
CR #166: Checking negative cache for [user@domain.local]
(2024-03-25 11:17:55): [nss] [sss_ncache_check_str] (0x2000): [CID#1]
Checking negative cache for [NCE/USER/domain.local/user@domain.local]
(2024-03-25 11:17:55): [nss] [cache_req_search_ncache] (0x0400): [CID#1]
CR #166: [user@domain.local] is not present in negative cache
(2024-03-25 11:17:55): [nss] [cache_req_search_cache] (0x0400): [CID#1] CR
#166: Looking up [user@domain.local] in cache
(2024-03-25 11:17:55): [nss] [cache_req_search_send] (0x0400): [CID#1] CR
#166: Returning [user@domain.local] from cache
(2024-03-25 11:17:55): [nss] [cache_req_search_ncache_filter] (0x0400):
[CID#1] CR #166: This request type does not support filtering result by
negative cache
(2024-03-25 11:17:55): [nss] [cache_req_create_and_add_result] (0x0400):
[CID#1] CR #166: Found 1 entries in domain domain.local
(2024-03-25 11:17:55): [nss] [cache_req_done] (0x0400): [CID#1] CR #166:
Finished: Success
(2024-03-25 11:17:55): [nss] [sss_nss_protocol_done] (0x4000): [CID#1]
Sending reply: success


So unclear why I can resolve the user locally on the idm server but not on
the client.

What else can I try?

Thanks for your support.

--
regards,
Natxo

On Fri, Mar 22, 2024 at 5:15 PM Alexander Bokovoy 
wrote:


On Пят, 22 сак 2024, Natxo Asenjo via FreeIPA-users wrote:
>hi,
>
>thanks for replying. Yes, we had seen this already, that is also why I
was
>pointing to the rhel 8 idm server in krb5.conf en sssd.conf
>
>I missed the dns_lookup_kdc = false directive though, in krb5.conf
>[libdefaults] section, I modified it, tried but still not working.
>
>The rest points to the one host.
>
>#File modified by ipa-client-install
>
>includedir /etc/krb5.conf.d/
>[libdefaults]
>  default_realm = IDM.DOMAIN.LOCAL
>  dns_lookup_realm = true
>  rdns = false
>  dns_canonicalize_hostname = false
>
>  dns_lookup_kdc = false
>  ticket_lifetime = 24h
>  forwardable = true
>  udp_preference_limit = 0
>  default_ccache_name = KEYRING:persistent:%{uid}
>
>[realms]
>
>  IDM.DOMAIN.LOCAL = {
>kdc =ds.idm.domain.local:88
>master_kdc = ds.idm.domain.local:88
>admin_server = ds.idm.domain.local:749
>kpasswd_server = ds.idm.domain.local:464
>default_domain = idm.domain.local
>pkinit_anchors =
>FILE:/var/lib/ipa-client/pki/kdc-ca-bundle.pem
>pkinit_pool = FILE:/var/lib/ipa-client/pki/ca-bundle.pem
>  }
>
>
>and this:
>
># grep ipa_server /etc/sssd/sssd.conf
>ipa_server = ds.idm.domain.local
>
>When I try ssh from a remote host, I see that sssd tries getting info
for a
>trusted user:
>
>(2024-03-22 16:42:35): [be[idm.domain.local]] [dp_get_account_info_send]
>(0x0200): Got request for 

[Freeipa-users] Re: upgrade idm servers rhel 7 to 8 problems

[Alexander Bokovoy via FreeIPA-users]

On Пан, 25 сак 2024, Natxo Asenjo wrote:

hi,

i have added debug = 9 to the domain/idm.domain.local in the sssd.conf of
the idm server and restarted sssd.

I have no hits on the server on the time when the client does a lookup
using id user@domain and finding nothing (no such user)

this is the sss_domain log server file during the same time (as attachtment
with name idm_rhel8server.txt)


Here we can see ID 2000 cannot be mapped to any domain and thus the ID
cannot be resolved:

(2024-03-25 11:17:07): [be[idm.domain.local]] [sss_domain_get_state] (0x1000): 
[RID#150] Domain idm.domain.local is Active
(2024-03-25 11:17:07): [be[idm.domain.local]] [sss_domain_get_state] (0x1000): 
[RID#150] Domain domain.local is Active
(2024-03-25 11:17:07): [be[idm.domain.local]] [ipa_srv_ad_acct_lookup_step] 
(0x0400): [RID#150] Looking up AD account
(2024-03-25 11:17:07): [be[idm.domain.local]] [sss_domain_get_state] (0x1000): 
[RID#150] Domain idm.domain.local is Active
(2024-03-25 11:17:07): [be[idm.domain.local]] [sss_domain_get_state] (0x1000): 
[RID#150] Domain domain.local is Active
(2024-03-25 11:17:07): [be[idm.domain.local]] [ad_account_can_shortcut] 
(0x0080): [RID#150] Mapping ID [2000] to SID failed: [IDMAP domain not found]
(2024-03-25 11:17:07): [be[idm.domain.local]] [ad_handle_acct_info_send] 
(0x0400): [RID#150] This ID is from different domain
(2024-03-25 11:17:07): [be[idm.domain.local]] [sysdb_search_user_by_uid] 
(0x0400): [RID#150] No such entry
(2024-03-25 11:17:07): [be[idm.domain.local]] [get_object_from_cache] (0x0200): 
[RID#150] Object wasn't found in cache
(2024-03-25 11:17:07): [be[idm.domain.local]] [ipa_get_ad_acct_ad_part_done] 
(0x0080): [RID#150] Object not found, ending request
(2024-03-25 11:17:07): [be[idm.domain.local]] [sdap_id_op_destroy] (0x4000): 
[RID#150] releasing operation connection
(2024-03-25 11:17:07): [be[idm.domain.local]] [sdap_id_conn_data_idle] 
(0x4000): [RID#150] Marking connection as idle

Can you give more details about this ID?



During the same minute locally on the rhel8 server I could run the id
user@domain command with a positive result:

(2024-03-25 11:17:55): [nss] [sss_domain_get_state] (0x1000): [CID#1]
Domain domain.local is Active
(2024-03-25 11:17:55): [nss] [sss_parse_name_for_domains] (0x0200): [CID#1]
name 'user@domain' matched expression for domain 'domain.local', user is
user
(2024-03-25 11:17:55): [nss] [sss_nss_get_object_send] (0x0400): [CID#1]
Client [0x55686dfef680][22]: sent cache request #166
(2024-03-25 11:17:55): [nss] [cache_req_set_name] (0x0400): [CID#1] CR
#166: Setting name [user]
(2024-03-25 11:17:55): [nss] [cache_req_select_domains] (0x0400): [CID#1]
CR #166: Performing a single domain search
(2024-03-25 11:17:55): [nss] [sss_domain_get_state] (0x1000): [CID#1]
Domain idm.domain.local is Active
(2024-03-25 11:17:55): [nss] [sss_domain_get_state] (0x1000): [CID#1]
Domain domain.local is Active
(2024-03-25 11:17:55): [nss] [cache_req_search_domains] (0x0400): [CID#1]
CR #166: Search will check the cache and check the data provider
(2024-03-25 11:17:55): [nss] [cache_req_validate_domain_type] (0x2000):
[CID#1] Request type POSIX-only for domain domain.local type POSIX is valid
(2024-03-25 11:17:55): [nss] [cache_req_set_domain] (0x0400): [CID#1] CR
#166: Using domain [domain.local]
(2024-03-25 11:17:55): [nss] [cache_req_prepare_domain_data] (0x0400):
[CID#1] CR #166: Preparing input data for domain [domain.local] rules
(2024-03-25 11:17:55): [nss] [cache_req_search_send] (0x0400): [CID#1] CR
#166: Looking up user@domain.local
(2024-03-25 11:17:55): [nss] [cache_req_search_ncache] (0x0400): [CID#1] CR
#166: Checking negative cache for [user@domain.local]
(2024-03-25 11:17:55): [nss] [sss_ncache_check_str] (0x2000): [CID#1]
Checking negative cache for [NCE/USER/domain.local/user@domain.local]
(2024-03-25 11:17:55): [nss] [cache_req_search_ncache] (0x0400): [CID#1] CR
#166: [user@domain.local] is not present in negative cache
(2024-03-25 11:17:55): [nss] [cache_req_search_cache] (0x0400): [CID#1] CR
#166: Looking up [user@domain.local] in cache
(2024-03-25 11:17:55): [nss] [cache_req_search_send] (0x0400): [CID#1] CR
#166: Returning [user@domain.local] from cache
(2024-03-25 11:17:55): [nss] [cache_req_search_ncache_filter] (0x0400):
[CID#1] CR #166: This request type does not support filtering result by
negative cache
(2024-03-25 11:17:55): [nss] [cache_req_create_and_add_result] (0x0400):
[CID#1] CR #166: Found 1 entries in domain domain.local
(2024-03-25 11:17:55): [nss] [cache_req_done] (0x0400): [CID#1] CR #166:
Finished: Success
(2024-03-25 11:17:55): [nss] [sss_nss_protocol_done] (0x4000): [CID#1]
Sending reply: success


So unclear why I can resolve the user locally on the idm server but not on
the client.

What else can I try?

Thanks for your support.

--
regards,
Natxo

On Fri, Mar 22, 2024 at 5:15 PM Alexander Bokovoy 
wrote:


On Пят, 22 сак 2024, Natxo Asenjo via FreeIPA-users wrote:
>hi,
>
>thanks for replying. 

[Freeipa-users] Re: How to prevent non-admin users of FreeIPA from reading the list of users in the web interface?

[Alexander Bokovoy via FreeIPA-users]

On Пан, 25 сак 2024, Riccardo Rotondo via FreeIPA-users wrote:

Hi,
I'm writing here because, 6 years after, I have the same question cknight 
previously asked.

Any update on that?

My users only login to web UI and can't perform ldap search so the only
way they can obtain users info it's from the "Users" page
("#/e/user/details/userame") I understand this question could sound
odd, but in Europe we have many laws protecting users privacy and these
info can not be published.


I'd repeat my response recently from a different thread:


What changed since that time, is that Fedora project has created Noggin,
https://github.com/fedora-infra/noggin, a self-service portal for user
management on top of FreeIPA deployment. You might want to look at that
and use it instead.


You may consider not exposing the FreeIPA web UI to regular users at
all.


--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Re: upgrade idm servers rhel 7 to 8 problems

[Alexander Bokovoy via FreeIPA-users]

On Пят, 22 сак 2024, Natxo Asenjo via FreeIPA-users wrote:

hi,

thanks for replying. Yes, we had seen this already, that is also why I was
pointing to the rhel 8 idm server in krb5.conf en sssd.conf

I missed the dns_lookup_kdc = false directive though, in krb5.conf
[libdefaults] section, I modified it, tried but still not working.

The rest points to the one host.

#File modified by ipa-client-install

includedir /etc/krb5.conf.d/
[libdefaults]
 default_realm = IDM.DOMAIN.LOCAL
 dns_lookup_realm = true
 rdns = false
 dns_canonicalize_hostname = false

 dns_lookup_kdc = false
 ticket_lifetime = 24h
 forwardable = true
 udp_preference_limit = 0
 default_ccache_name = KEYRING:persistent:%{uid}

[realms]

 IDM.DOMAIN.LOCAL = {
   kdc =ds.idm.domain.local:88
   master_kdc = ds.idm.domain.local:88
   admin_server = ds.idm.domain.local:749
   kpasswd_server = ds.idm.domain.local:464
   default_domain = idm.domain.local
   pkinit_anchors =
FILE:/var/lib/ipa-client/pki/kdc-ca-bundle.pem
   pkinit_pool = FILE:/var/lib/ipa-client/pki/ca-bundle.pem
 }


and this:

# grep ipa_server /etc/sssd/sssd.conf
ipa_server = ds.idm.domain.local

When I try ssh from a remote host, I see that sssd tries getting info for a
trusted user:

(2024-03-22 16:42:35): [be[idm.domain.local]] [dp_get_account_info_send]
(0x0200): Got request for [0x1][BE_REQ_USER][name=user@ad]
(2024-03-22 16:42:35): [be[idm.domain.local]] [dp_attach_req] (0x0400):
[RID#8] DP Request [Account #8]: REQ_TRACE: New request. [sssd.nss CID #4]
Flags [0x0001].
(2024-03-22 16:42:35): [be[idm.domain.local]] [dp_attach_req] (0x0400):
[RID#8] Number of active DP request: 1
(2024-03-22 16:42:35): [be[idm.domain.local]] [sss_domain_get_state]
(0x1000): [RID#8] Domain idm.domain.local is Active
(2024-03-22 16:42:35): [be[idm.domain.local]] [sss_domain_get_state]
(0x1000): [RID#8] Domain domain.local is Active
(2024-03-22 16:42:35): [be[idm.domain.local]] [sss_domain_get_state]
(0x1000): [RID#8] Domain idm.domain.local is Active
(2024-03-22 16:42:35): [be[idm.domain.local]] [sss_domain_get_state]
(0x1000): [RID#8] Domain domain.local is Active
(2024-03-22 16:42:35): [be[idm.domain.local]] [sss_domain_get_state]
(0x1000): [RID#8] Domain idm.domain.local is Active
(2024-03-22 16:42:35): [be[idm.domain.local]] [sss_domain_get_state]
(0x1000): [RID#8] Domain domain.local is Active
(2024-03-22 16:42:35): [be[idm.domain.local]] [sdap_id_op_connect_step]
(0x4000): [RID#8] reusing cached connection
(2024-03-22 16:42:35): [be[idm.domain.local]] [sdap_id_conn_data_not_idle]
(0x4000): [RID#8] Marking connection as not idle
(2024-03-22 16:42:35): [be[idm.domain.local]] [ipa_s2n_get_acct_info_send]
(0x0400): [RID#8] Sending request_type: [REQ_FULL_WITH_MEMBERS] for trust
user [user@ad] to IPA server
(2024-03-22 16:42:35): [be[idm.domain.local]] [ipa_s2n_exop_send] (0x0400):
[RID#8] Executing extended operation
(2024-03-22 16:42:35): [be[idm.domain.local]] [ipa_s2n_exop_send] (0x2000):
[RID#8] ldap_extended_operation sent, msgid = 22
(2024-03-22 16:42:35): [be[idm.domain.local]] [sdap_op_add] (0x2000):
[RID#8] New operation 22 timeout 6
(2024-03-22 16:42:35): [be[idm.domain.local]] [sdap_process_result]
(0x2000): Trace: sh[0x55bcce14e400], connected[1], ops[0x55bcce119870],
ldap[0x55bcce14c1c0]
(2024-03-22 16:42:35): [be[idm.domain.local]] [sdap_process_message]
(0x4000): [RID#8] Message type: [LDAP_RES_EXTENDED]
(2024-03-22 16:42:35): [be[idm.domain.local]] [sdap_call_op_callback]
(0x2): [RID#8] Handling LDAP operation [22][server: [xxx:389] IPA EXOP]
took [0.752] milliseconds.
(2024-03-22 16:42:35): [be[idm.domain.local]] [ipa_s2n_exop_done] (0x0400):
[RID#8] ldap_extended_operation result: No such object(32), (null).


but it finds nothing it seems.

on the idm host everything seems to be running:

# ipactl status
Directory Service: RUNNING
krb5kdc Service: RUNNING
kadmin Service: RUNNING
named Service: RUNNING
httpd Service: RUNNING
ipa-custodia Service: RUNNING
smb Service: RUNNING
winbind Service: RUNNING
ipa-otpd Service: RUNNING
ipa-dnskeysyncd Service: RUNNING
ipa: INFO: The ipactl command was successful


And now I don't know what else to try. It seems that the trust agent is not
answering properly, but how do I check this?


So this looks like a different problem. The client talks to IPA server
for s2n request and the server does not find anything. It means you need
to follow normal SSSD debugging process: collect SSSD debug logs at the
client and at the server at the time of the request, check what happened
on the SSSD on the IPA server that caused it to not find the object.

Usually there are:
 - issues talking to AD DCs
 - unresolvable SIDs of group members or groups one is a member of
 - use of domain-local groups

SSSD domain log would have more details, see 
https://sssd.io/troubleshooting/ipa_provider.html






On Fri, Mar 22, 2024 at 4:12 PM Alexander Bokovoy 
wrote:


On Пят, 22 сак 2024, Natxo Asenjo via FreeIPA-users wrote:
>hi,
>
>at work we are having 

[Freeipa-users] Re: upgrade idm servers rhel 7 to 8 problems

[Alexander Bokovoy via FreeIPA-users]

On Пят, 22 сак 2024, Natxo Asenjo via FreeIPA-users wrote:

hi,

at work we are having *interesting* problems with our migration from idm
servers running rhel 7 to new rhel 8 idm servers.

We have a AD -> idm trust in place, this is working properly.

AD is domain.local
IDM is idm.domain.local

We add replicas to the set, and this runs properly. No replication errors.

Basically the problem is we cannot log in to newly joined systems running
rhel 8 as trusted users from AD.

We have a new rhel 8 idm server which has also the trust agent and trust
controller role installed.

We want to login as a trusted AD user to a rhel 8 host which has this new
rhel 8 idm server as its ipa host, we have forced it using this sssd.conf:

[domain/idm.domain.local]

id_provider = ipa
ipa_server = ds.idm.domain.local
ipa_domain = idm.domain.local
ipa_hostname = host.idm.domain.local
auth_provider = ipa
chpass_provider = ipa
access_provider = ipa
cache_credentials = True
ldap_tls_cacert = /etc/ipa/ca.crt
dyndns_update = True
dyndns_iface = ens192
krb5_store_password_if_offline = True
[sssd]
services = nss, pam, ssh, sudo

domains = idm.domain.local
full_name_format = %1$s
debug = 9
[nss]
homedir_substring = /home
override_homedir = /home/%u

[pam]

[sudo]

[autofs]

[ssh]

[pac]

[ifp]

[session_recording]


We also modified krb5.conf on the client to find the IDM realm only on the
rhel 8 idm server, not the rhel 7. So we disabled srv dns autodiscovery for
the IDM.DOMAIN.LOCAL realm:

# cat /etc/krb5.conf
#File modified by ipa-client-install

includedir /etc/krb5.conf.d/
[libdefaults]
 default_realm = IDM.DOMAIN.LOCAL
dns_lookup_realm = true
 rdns = false
 dns_canonicalize_hostname = false
dns_lookup_kdc = true
 ticket_lifetime = 24h
 forwardable = true
 udp_preference_limit = 0
 default_ccache_name = KEYRING:persistent:%{uid}


[realms]
 IDM.DOMAIN.LOCAL = {
   kdc = ds.idm.domain.local:88
   master_kdc = ds.idm.domain.local:88
   admin_server = ds.idm.domain.local:749
   kpasswd_server = ds.idm.domain.local:464
   default_domain = idm.domain.local
   pkinit_anchors = FILE:/var/lib/ipa-client/pki/kdc-ca-bundle.pem
   pkinit_pool = FILE:/var/lib/ipa-client/pki/ca-bundle.pem

 }


[domain_realm]
 .idm.domain.local = IDM.DOMAIN.LOCAL
 idm.domain.local = IDM.DOMAIN.LOCAL
 host.idm.domain.local = IDM.DOMAIN.LOCAL

On the rhel 8 client, I can kinit with the host keytab, this work, I get a
ticket with the host principal.

I can also kinit using a trusted AD user, this works, I get a ticket of the
AD domain.

But as soon as I try logging in from ssh, it does not work. It does not
recognize the user.

Running id trusteduser@ad does not wok either (no such user)

I have run out of ideas, to be honest. I do not know how to troubleshoot
this anymore. The rhel8 idm server finds the users, I can log in there
without any problem too thanks to the rbac rules, but this rhel8 client
simpley will not see the users.


This all sounds like you see SPAKE vs non-SPAKE behavior by the clients.
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/migrating_to_identity_management_on_rhel_8/migrate-7-to-8_migrating
covers this in a yellow warning box:

-
Important

RHEL 8 supports SPAKE and IdP pre-authentication, but RHEL 7 does not.
Having RHEL 8 servers with SPAKE or IdP enabled in a RHEL 7 IdM
deployment may lead to problems such as users not being able to log in.

Red Hat strongly recommends that all servers in an IdM deployment are
migrated as quickly as possible and that older systems should not be
left in operation for extended periods of time.

For more information, see:

https://access.redhat.com/solutions/7053377
https://access.redhat.com/solutions/3529911
-

Specifically, https://access.redhat.com/solutions/7053377 should have
enough technical details to confirm it is the case.


--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Re: Using ipa-ca-install on a replica

[Alexander Bokovoy via FreeIPA-users]

On Чцв, 21 сак 2024, Ian Kumlien wrote:

On Thu, Mar 21, 2024 at 10:22 AM Alexander Bokovoy  wrote:


On Чцв, 21 сак 2024, Ian Kumlien wrote:
>On Thu, Mar 21, 2024 at 9:13 AM Alexander Bokovoy  wrote:
>>
>> On Чцв, 21 сак 2024, Ian Kumlien via FreeIPA-users wrote:
>> >On Wed, Mar 20, 2024 at 9:52 PM Florence Renaud  wrote:
>> >>
>> >>
>> >>
>> >> > On 20 Mar 2024, at 16:38, Ian Kumlien  wrote:
>> >> >
>> >> > On Wed, Mar 20, 2024 at 3:52 PM Ian Kumlien  
wrote:
>> >> >>
>> >> >>> On Wed, Mar 20, 2024 at 11:21 AM Florence Blanc-Renaud 
 wrote:
>> >> >>>
>> >> >>> Hi,
>> >> >>>
>> >> >>> On Wed, Mar 20, 2024 at 10:00 AM Ian Kumlien  
wrote:
>> >> 
>> >>  On Wed, Mar 20, 2024 at 9:45 AM Ian Kumlien  
wrote:
>> >> >
>> >> > So... this one's new:
>> >> >
>> >> > Connection to https://freeipa-1.xerces.lan/ipa/json failed with
>> >> > Insufficient access: SASL(-1): generic failure: GSSAPI Error:
>> >> > Unspecified GSS failure.  Minor code may provide more information
>> >> > (Credential cache is empty)
>> >> >>>
>> >> >>>
>> >> >>> this one can happen if you have an existing ticket in your cache, for 
instance from a previous installation, but that is not valid anymore.
>> >> >>
>> >> >> Ah, ok, i did do kdestroy -A but only on the new machine...
>> >> >>
>> >> >> A new issue that appeared, no user from the old machines can
>> >> >> authenticate at all - still looking in to why it doesn't work
>> >> >
>> >> > Disabling MS-PAC fixed this issue, will have to dig in to why it was 
later =)
>> >> >
>> >> > Any clues?
>> >> Your users are probably missing a SID. Run ipa config-mod —enable-sid 
—add-sids and check with ipa user-show —all —raw that they contain an 
ipantsecurityidentifier attribute.
>> >
>> >Uhm, nope, changed nothing it seems... leaving ms-pac disabled works however
>>
>> There were plenty of discussions on this list in past couple months,
>> including a lot of instructions what to investigate. Have you tried to
>> apply those suggestions?
>
>I haven't found any using google...
>
>> You haven't shown a single log excerpt from IPA servers, be it
>> /var/log/krb5kdc.log or error logs from the directory server.
>
>And i haven't been asked - i assumed it was something due to the upgrade path
>
>Doing kerberos results in:
>Mar 20 16:18:29 freeipa-4.xerces.lan krb5kdc[113624](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.129.0.239: HANDLE_AUTHDATA:
>u...@xerces.lan for krbtgt/xerces@xerces.lan, No such file or
>directory
>
>For ldap authentication, which also fails with ms-pac enabled, i
>haven't been able to find any real log with issues.
>(So, with ms-pac, things that fails for a user: kerberos, ldap,
>freeipa webui. Without ms-pac, everything works)
>
>We don't really use kerberos atm, so potentially leaving it disabled
>could be fine, however i would much more like to get to the bottom of
>this...

This is from one of previous emails I sent here:

---
Basically, I think you have users with UID/GIDs outside of your ID
ranges and therefore those users have no SIDs associated with them and
hence cannot be used for constrained delegation (S4U extensions in
Kerberos) anymore. In addition, most likely your existing ID ranges have
no support for generating SIDs as they most likely lack RID bases.

There were plenty of discussions about it on the list in past few
months. You can look at these articles on the Red Hat's Customer Portal:

https://access.redhat.com/articles/7027037
https://access.redhat.com/solutions/7052703
https://access.redhat.com/solutions/7014959
---

For your case, look first at the KCS 7052703, as it has collection of
the instructions to use for different typical use cases. Article 7027037
is a good visualisation of the ID range structure and requirements to
SID bases.

All those articles are accessible with RHEL subscription. You can get a
free subscription at https://developers.redhat.com/.


I can't seem to register or recover my account, it seems to be
separate from the bugzilla one for some reason
(none of the emails sent are reaching me on gmail)


The account at the customer portal is different from the bugzilla, so
you need to register a separate one.



However, it seems like the UID range issue is what I'm facing, which
is odd, it should never have changed
and it makes you wonder what the largest value is... since currently,
for one user it's off by 1714800229


Show your ID ranges with 'ipa idrange-find'

May be you migrated some users using 'ipa migrate-ds' from a different
installation in the past? That doesn't handle adjusting IDs or SIDs.



--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red 

[Freeipa-users] Re: Using ipa-ca-install on a replica

[Alexander Bokovoy via FreeIPA-users]

On Чцв, 21 сак 2024, Ian Kumlien wrote:

On Thu, Mar 21, 2024 at 9:13 AM Alexander Bokovoy  wrote:


On Чцв, 21 сак 2024, Ian Kumlien via FreeIPA-users wrote:
>On Wed, Mar 20, 2024 at 9:52 PM Florence Renaud  wrote:
>>
>>
>>
>> > On 20 Mar 2024, at 16:38, Ian Kumlien  wrote:
>> >
>> > On Wed, Mar 20, 2024 at 3:52 PM Ian Kumlien  wrote:
>> >>
>> >>> On Wed, Mar 20, 2024 at 11:21 AM Florence Blanc-Renaud  
wrote:
>> >>>
>> >>> Hi,
>> >>>
>> >>> On Wed, Mar 20, 2024 at 10:00 AM Ian Kumlien  
wrote:
>> 
>>  On Wed, Mar 20, 2024 at 9:45 AM Ian Kumlien  
wrote:
>> >
>> > So... this one's new:
>> >
>> > Connection to https://freeipa-1.xerces.lan/ipa/json failed with
>> > Insufficient access: SASL(-1): generic failure: GSSAPI Error:
>> > Unspecified GSS failure.  Minor code may provide more information
>> > (Credential cache is empty)
>> >>>
>> >>>
>> >>> this one can happen if you have an existing ticket in your cache, for 
instance from a previous installation, but that is not valid anymore.
>> >>
>> >> Ah, ok, i did do kdestroy -A but only on the new machine...
>> >>
>> >> A new issue that appeared, no user from the old machines can
>> >> authenticate at all - still looking in to why it doesn't work
>> >
>> > Disabling MS-PAC fixed this issue, will have to dig in to why it was later 
=)
>> >
>> > Any clues?
>> Your users are probably missing a SID. Run ipa config-mod —enable-sid 
—add-sids and check with ipa user-show —all —raw that they contain an 
ipantsecurityidentifier attribute.
>
>Uhm, nope, changed nothing it seems... leaving ms-pac disabled works however

There were plenty of discussions on this list in past couple months,
including a lot of instructions what to investigate. Have you tried to
apply those suggestions?


I haven't found any using google...


You haven't shown a single log excerpt from IPA servers, be it
/var/log/krb5kdc.log or error logs from the directory server.


And i haven't been asked - i assumed it was something due to the upgrade path

Doing kerberos results in:
Mar 20 16:18:29 freeipa-4.xerces.lan krb5kdc[113624](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.129.0.239: HANDLE_AUTHDATA:
u...@xerces.lan for krbtgt/xerces@xerces.lan, No such file or
directory

For ldap authentication, which also fails with ms-pac enabled, i
haven't been able to find any real log with issues.
(So, with ms-pac, things that fails for a user: kerberos, ldap,
freeipa webui. Without ms-pac, everything works)

We don't really use kerberos atm, so potentially leaving it disabled
could be fine, however i would much more like to get to the bottom of
this...


This is from one of previous emails I sent here:

---
Basically, I think you have users with UID/GIDs outside of your ID
ranges and therefore those users have no SIDs associated with them and
hence cannot be used for constrained delegation (S4U extensions in
Kerberos) anymore. In addition, most likely your existing ID ranges have
no support for generating SIDs as they most likely lack RID bases.

There were plenty of discussions about it on the list in past few
months. You can look at these articles on the Red Hat's Customer Portal:

https://access.redhat.com/articles/7027037
https://access.redhat.com/solutions/7052703
https://access.redhat.com/solutions/7014959
---

For your case, look first at the KCS 7052703, as it has collection of
the instructions to use for different typical use cases. Article 7027037
is a good visualisation of the ID range structure and requirements to
SID bases.

All those articles are accessible with RHEL subscription. You can get a
free subscription at https://developers.redhat.com/.

--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Re: Using ipa-ca-install on a replica

[Alexander Bokovoy via FreeIPA-users]

On Чцв, 21 сак 2024, Ian Kumlien via FreeIPA-users wrote:

On Wed, Mar 20, 2024 at 9:52 PM Florence Renaud  wrote:




> On 20 Mar 2024, at 16:38, Ian Kumlien  wrote:
>
> On Wed, Mar 20, 2024 at 3:52 PM Ian Kumlien  wrote:
>>
>>> On Wed, Mar 20, 2024 at 11:21 AM Florence Blanc-Renaud  
wrote:
>>>
>>> Hi,
>>>
>>> On Wed, Mar 20, 2024 at 10:00 AM Ian Kumlien  wrote:

 On Wed, Mar 20, 2024 at 9:45 AM Ian Kumlien  wrote:
>
> So... this one's new:
>
> Connection to https://freeipa-1.xerces.lan/ipa/json failed with
> Insufficient access: SASL(-1): generic failure: GSSAPI Error:
> Unspecified GSS failure.  Minor code may provide more information
> (Credential cache is empty)
>>>
>>>
>>> this one can happen if you have an existing ticket in your cache, for 
instance from a previous installation, but that is not valid anymore.
>>
>> Ah, ok, i did do kdestroy -A but only on the new machine...
>>
>> A new issue that appeared, no user from the old machines can
>> authenticate at all - still looking in to why it doesn't work
>
> Disabling MS-PAC fixed this issue, will have to dig in to why it was later =)
>
> Any clues?
Your users are probably missing a SID. Run ipa config-mod —enable-sid —add-sids 
and check with ipa user-show —all —raw that they contain an 
ipantsecurityidentifier attribute.


Uhm, nope, changed nothing it seems... leaving ms-pac disabled works however


There were plenty of discussions on this list in past couple months,
including a lot of instructions what to investigate. Have you tried to
apply those suggestions?

You haven't shown a single log excerpt from IPA servers, be it
/var/log/krb5kdc.log or error logs from the directory server.

Disabling MS-PAC basically kills protection mechanisms that we have
against a numerous breaches using Kerberos protocol's issues.



--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Re: Support for Azure AD authentication with on-prem AD forest-trust identities

[Alexander Bokovoy via FreeIPA-users]

On Пят, 15 сак 2024, Jonathan Calmels via FreeIPA-users wrote:

So, I got to play around with this and implemented the "workaround" we 
discussed.
I ended up using ksu with sshd ForceCommand to make it more seamless for users.
Here are some of the issues I faced though:

1. IdP requires FAST and I'm not sure how I'm supposed to configure
that correctly in SSSD since I need it for both AD and IPA and can't
set two different krb5_fast_principal. With one, it could work with
cross-realm requests I suppose but it's not ideal. SPAKE 2FA would also
be nice here but doesn't seem supported yet?


No, 2FA SPAKE is not implemented. Even if it would be implemented, it
still needs FAST channel wrapping.


2. I need two distinct usernames per user, e.g. myuser and myuser_idp.
I tried using the same usernames for both AD and IPA users but SSSD
gets really confused depending on what's cached. We use shortnames with
a domain resolution order, so I thought having both usernames alias
could work and SSSD would just prefer the IPA one if it exists. On the
bright side, this allows users to pick the authentication method
depending on which username they choose, so there is that


I think it is also helpful from auditing purposes, a poor man's
replacement of exposing auth indicators at an application level or in
KDC logs. Explicitly different user name helps to hilight the fact that
this user is 2FA-authenticated for login.


3. SSSD localauth plugin gets in the way when it comes to remapping
both principals to the AD user (e.g. for ksu authorization). The IPA
principal gets mapped to myuser_idp and one cannot write custom
aname2lname rules because SSSD is always called first in the krb5
module order. Only way I found is to disable all the SSSD snippet
generation and write my own rules but I would rather avoid that.


Feel free to propose a specific algorithm to extend the plugin.


4. IdP auth doesn't work when the SSSD PAM responder is socket
activated. I haven't really looked into why it fails, but this caught
me off guard at first.


I think it should work. Debug logs would help -- please open an issue,
may be upstream for SSSD, with debug logs to show what's wrong. That
said, I think main responders (nss, pam) should not use socket
activation. Debian packaging was wrong in defaulting to this.




I'm not sure if I should file separate bugs for those, but after all of that it 
works.

Overall, I would still prefer if there was a way to do this natively in
SSSD somehow (i.e. external users shadowed by IPA auth). Having said
that, I understand that this is quite challenging.


Glad that it worked overall. Please file bugs, we can look at what could
be improved. This is indeed a challenging area and a certain level of
hand-helding is still needed so that admins wouldn't go too wild. ;)

--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Re: ipa-getcert request results in CA_REJECTED, on an enrolled host

[Alexander Bokovoy via FreeIPA-users]

On Срд, 13 сак 2024, Bo Lind via FreeIPA-users wrote:

Update!

Our organisation has four IPA servers. I tried to edit
/etc/ipa/default.conf, to point at a different one. Server two didn't
work either, but server three did!


Perhaps some of those are RHEL9?

See https://access.redhat.com/articles/7046409 for some details on what
you are seeing. It also explains what should be done and in which order.

--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Re: ipa-getcert request results in CA_REJECTED, on an enrolled host

[Alexander Bokovoy via FreeIPA-users]

On Аўт, 12 сак 2024, Bo Lind via FreeIPA-users wrote:

root@naughtyhost:~# ipa host-show --all --raw naughtyhost|grep -i canon
 krbcanonicalname: host/naughtyhost.example.local@EXAMPLE.LOCAL

Looks like that part is in order...? Does the capitalization matter?


It does.

When you attempt to do that request, what do you see in the
/var/log/krb5kdc.log on the IPA server, related to requests from this
host?

Typically you'd see something like the sequence below. I am using
'master2.ipa2.test' which is an IPA server in itself as an example here,
but for your case host/master2.ipa2.test would be
host/naughtyhost.example.local and it would talk to your IPA server:

1. Get TGT using the host keytab:
Mar 13 09:36:00 master2.ipa2.test krb5kdc[548787](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.0.192.177: 
NEEDED_PREAUTH: host/master2.ipa2.t...@ipa2.test for 
krbtgt/ipa2.t...@ipa2.test, Additional pre-authentication required
Mar 13 09:36:00 master2.ipa2.test krb5kdc[548787](info): closing down fd 11
Mar 13 09:36:00 master2.ipa2.test krb5kdc[548787](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.0.192.177: ISSUE: 
authtime 1710322560, etypes {rep=aes256-cts-hmac-sha384-192(20), 
tkt=aes256-cts-hmac-sha384-192(20), ses=aes256-cts-hmac-sha384-192(20)}, 
host/master2.ipa2.t...@ipa2.test for krbtgt/ipa2.t...@ipa2.test
Mar 13 09:36:00 master2.ipa2.test krb5kdc[548787](info): closing down fd 11

2. Request a service ticket to IPA API:
Mar 13 09:36:00 master2.ipa2.test krb5kdc[548787](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.0.192.177: ISSUE: 
authtime 1710322560, etypes {rep=aes256-cts-hmac-sha384-192(20), 
tkt=aes256-cts-hmac-sha384-192(20), ses=aes256-cts-hmac-sha384-192(20)}, 
host/master2.ipa2.t...@ipa2.test for HTTP/master2.ipa2.t...@ipa2.test
Mar 13 09:36:00 master2.ipa2.test krb5kdc[548787](info): closing down fd 11

3. IPA API needs to talk to LDAP server so it needs own TGT ticket
first:
Mar 13 09:36:00 master2.ipa2.test krb5kdc[548788](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.0.192.177: 
NEEDED_PREAUTH: HTTP/master2.ipa2.t...@ipa2.test for 
krbtgt/ipa2.t...@ipa2.test, Additional pre-authentication required
Mar 13 09:36:00 master2.ipa2.test krb5kdc[548788](info): closing down fd 11
Mar 13 09:36:00 master2.ipa2.test krb5kdc[548787](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.0.192.177: ISSUE: 
authtime 1710322560, etypes {rep=aes256-cts-hmac-sha384-192(20), 
tkt=aes256-cts-hmac-sha384-192(20), ses=aes256-cts-hmac-sha384-192(20)}, 
HTTP/master2.ipa2.t...@ipa2.test for krbtgt/ipa2.t...@ipa2.test
Mar 13 09:36:00 master2.ipa2.test krb5kdc[548787](info): closing down fd 11

4. And then asks for a service ticket to LDAP service on behalf of the
original Kerberos client (host requesting an operation):
Mar 13 09:36:00 master2.ipa2.test krb5kdc[548787](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.0.192.177: ISSUE: 
authtime 1710322560, etypes {rep=aes256-cts-hmac-sha384-192(20), 
tkt=aes256-cts-hmac-sha1-96(18), ses=aes256-cts-hmac-sha384-192(20)}, 
HTTP/master2.ipa2.t...@ipa2.test for ldap/master2.ipa2.t...@ipa2.test
Mar 13 09:36:00 master2.ipa2.test krb5kdc[548787](info): ... 
CONSTRAINED-DELEGATION s4u-client=host/master2.ipa2.t...@ipa2.test
Mar 13 09:36:00 master2.ipa2.test krb5kdc[548787](info): closing down fd 11

If you'd see any breakage in those steps, show the log.

--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Re: ipa-getcert request results in CA_REJECTED, on an enrolled host

[Alexander Bokovoy via FreeIPA-users]

On Аўт, 12 сак 2024, Bo Lind via FreeIPA-users wrote:

I'm having a weird one. This has worked well on a number of other, identical 
hosts, but one is repeatedly giving me trouble:

root@naughtyhost:~# ipa-getcert request -f /etc/pki/tls/certs/xrdp.pem -k 
/etc/pki/tls/private/xrdp.key -r -w -v
New signing request "20240312125107" added.
State NEWLY_ADDED_READING_KEYINFO, stuck: no.
State SUBMITTING, stuck: no.
State CA_REJECTED, stuck: yes.

root@naughtyhost:~# ipa-getcert list
Number of certificates and requests being tracked: 1.
Request ID '20240312125107':
status: CA_REJECTED
ca-error: Server at https://idm0.example.local/ipa/json denied our 
request, giving up: 2100 (Insufficient access: SASL(-1): generic failure: 
GSSAPI Error: Unspecified GSS failure.  Minor code may provide more information 
(Credential cache is empty)).
stuck: yes
key pair storage: type=FILE,location='/etc/pki/tls/private/xrdp.key'
certificate: type=FILE,location='/etc/pki/tls/certs/xrdp.pem'
CA: IPA
issuer:
subject:
issued: unknown
expires: unknown
pre-save command:
post-save command:
track: yes
auto-renew: yes

I've tried looking in the logfiles on idm0, but couldn't really find anything 
useful.


I think it might be a problem with old host/service objects.
Can you check if 'ipa host-show --all --raw hostname' returns
krbCanonicalName attribute? If it is not there, you can set one with

ipa host-mod hostname --addattr krbcanonicalname=host/hostname@REALM

See https://pagure.io/freeipa/issue/9465 for some details.

--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Re: Automated enrollment of FreeIPA host

[Alexander Bokovoy via FreeIPA-users]

On Аўт, 12 сак 2024, Yuriy Halytskyy wrote:

Awesome, pkinit is exactly what we need, thank you.

Is the `--principal` option for ipa cert-request needed with a
matching rule? e.g. if we have

ipa certmaprule-add pkinit-host --matchrule  ''
--maprule='(fqdn={subject_dns_name})'


With an explicit mapping rule you don't specifically need a principal
in the certificate. The point of a mapping rule is provide an
alternative mapping mechanism to use of the Kerberos principal name in
the certificate. If you have Kerberos principal recorded in the
certificate, use of that is already covered without explicit mapping
rule.



Do I also need to

ipa cert-request example.csr --principal=host/example.com
--certificate-out=example.pem

for pkinit to work?


You can but you don't need to.




Cheers,
Yuriy

On Mon, Mar 11, 2024 at 4:08 AM Alexander Bokovoy  wrote:


On Няд, 10 сак 2024, Yuriy Halytskyy via FreeIPA-users wrote:
>We want to be able to destroy/recreate IPA enrolled hosts without
>using admin credentials.
>
>ipa-client-install with a keytab seems like a good option except it
>generates a new keytab. And there is no non-hacky way of passing this
>new keytab back to terraform. Can we tell it not to generate a new
>keytab on re-enrollment?

This option (--keytab) was supposed to be used as a re-enrollment tool
for existing host. Thus, it forces use of a previously known keytab and
forcibly regenerates it because of the commonly used policy in IPA that
password must only be known to the end-user entity.

You should not be using it to automate enrollments.

>
>Alternatively, we could create a user that has just enough permissions
>to enroll host X but nothing else. What is the minimum set of
>permissions for this?

The enrollment process is split into two parts:

- adding host object
- enrolling actual host: configuring the system and requesting its
   keys

There are two separate permissions for this already:

- 'System: Add Hosts'
- 'System: Enroll a Host'

If you have a system already added to IPA, then only the second
permission for enrollemnt user. Depending on the options you are using
during enrollment, more permissions might be needed. See a link to
ipa-hcc below for details of some of those.

>
>Or is there a better way?

Another option is in newer (as of RHEL 8.4 or RHEL 9.2, I think) IPA
version: use PKINIT authentication to enroll hosts. This allows to map
a certificate to the principal that can enroll the host. You can either
use a certificate that is mapped on the IPA KDC side to this host
identity (e.g. a certificate that has host/ Kebreros principal
in it) or use it to replace a password-based authentication of an
enrollment user who has 'System: Enroll a Host' permission.

See 'PKINIT Options' in ipa-client-install(1) man page and
https://freeipa.readthedocs.io/en/latest/designs/client-install-pkinit.html
design page for more details.

This method is used by the Podengo project's ipa-hcc plugin, for
example, where a host-associated RHEL subscription manager certificate
is used to authenticate against IPA during domain enrollment. See
https://github.com/podengo-project/ipa-hcc for details.




--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland







--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Re: Support for Azure AD authentication with on-prem AD forest-trust identities

[Alexander Bokovoy via FreeIPA-users]

On Аўт, 12 сак 2024, Jonathan Calmels via FreeIPA-users wrote:

Having said that, I'm not even sure if one can request a specific
preauth method today in SSSD.


And by that I mean as a hint before the actual AS_REQ. IIUC this isn't
straightforward to do currently because:
- The PAM conversation happens after the AS_REP and depends on the
 supported auth methods
- There is no password fallback with the idp auth

The other way would be to contact both KDC and somehow keep track of
both until you get the user input, but it gets tricky


There is no explicit way in MIT Kerberos client side to influence which
pre-auth mechanism is used other than forcing configuration externally
to avoid certain choices. There is no API to control what happens at
pre-authentication. All methods available to both KDC and the client
will be tried one by one by the client code until they produce an answer
that can be sent out to the KDC.

This gives us one option, though: an application may register prompt
handlers that a pre-auth method may use to query a user for a detail to
complete the pre-auth and this is something you can influence by
choosing to not respond to a prompt request. This is something that was
broken in SSSD until the past week.

If you have idp or passkey method enabled alongside with a password,
SSSD did not fall. This has been fixed just recently upstream:
https://github.com/SSSD/sssd/issues/7152

We also have a very crude way: don't provide FAST channel, this removes
KDC response for OTP, RADIUS, external IdP, and passkey methods. This
is, obviously, not what you'd want for this situation. Similarly, one
can redefine plugins_base_dir and then play with clpreauth in [plugins]
section to force not using or, instead, using a particular plugin.

All these aren't the things you are looking for. ;)

--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Re: Automated enrollment of FreeIPA host

[Alexander Bokovoy via FreeIPA-users]

On Няд, 10 сак 2024, Yuriy Halytskyy via FreeIPA-users wrote:

We want to be able to destroy/recreate IPA enrolled hosts without
using admin credentials.

ipa-client-install with a keytab seems like a good option except it
generates a new keytab. And there is no non-hacky way of passing this
new keytab back to terraform. Can we tell it not to generate a new
keytab on re-enrollment?


This option (--keytab) was supposed to be used as a re-enrollment tool
for existing host. Thus, it forces use of a previously known keytab and
forcibly regenerates it because of the commonly used policy in IPA that
password must only be known to the end-user entity.

You should not be using it to automate enrollments.



Alternatively, we could create a user that has just enough permissions
to enroll host X but nothing else. What is the minimum set of
permissions for this?


The enrollment process is split into two parts:

- adding host object
- enrolling actual host: configuring the system and requesting its
  keys

There are two separate permissions for this already:

- 'System: Add Hosts'
- 'System: Enroll a Host'

If you have a system already added to IPA, then only the second
permission for enrollemnt user. Depending on the options you are using
during enrollment, more permissions might be needed. See a link to
ipa-hcc below for details of some of those.



Or is there a better way?


Another option is in newer (as of RHEL 8.4 or RHEL 9.2, I think) IPA
version: use PKINIT authentication to enroll hosts. This allows to map
a certificate to the principal that can enroll the host. You can either
use a certificate that is mapped on the IPA KDC side to this host
identity (e.g. a certificate that has host/ Kebreros principal
in it) or use it to replace a password-based authentication of an
enrollment user who has 'System: Enroll a Host' permission.

See 'PKINIT Options' in ipa-client-install(1) man page and
https://freeipa.readthedocs.io/en/latest/designs/client-install-pkinit.html
design page for more details.

This method is used by the Podengo project's ipa-hcc plugin, for
example, where a host-associated RHEL subscription manager certificate
is used to authenticate against IPA during domain enrollment. See
https://github.com/podengo-project/ipa-hcc for details.




--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Re: Support for Azure AD authentication with on-prem AD forest-trust identities

[Alexander Bokovoy via FreeIPA-users]

On Суб, 09 сак 2024, Jonathan Calmels via FreeIPA-users wrote:

Thanks for the detailed answer, glad we didn't miss anything obvious.
I just want to add a bit more clarification on what we were proposing


IPA only responsible for its own users. If authentication relies on an
external identity (e.g. AD user), then authority holding information
about that identity would need to be responsible for its authentication
Kerberos-wise.



This is not supported. Technically, you can use trusted domains'
principals as aliases of IPA principals with

$ ipa user-add-principal ipa_user ad_user(a)AD.DOMAIN

If enterprise principal support is advertised by the client, a KDC would
return the primary principal name in the ticket, which has to be IPA
realm's principal. However, this would make impossible to login as AD
user through IPA KDC because we would find that principal alias and
instead of issuing a cross-realm referral handle it locally.


I understand that, in the case I described, technically IPA doesn't rely on an 
external identity.
The principal alias is still part of the IPA realm, it's just that we "encode" 
the trusted domain in it, it doesn't use the AD realm at all.
All the magic happens in SSSD.

On AD my user principal is: ad_user@AD.DOMAIN
On IPA my user principal is: ad_user\@ad.domain@IPA.DOMAIN (the canonical one, 
it can still have the standard ipa_user@IPA.DOMAIN as an alias)

Nothing changes here, the AD user authenticates through the referral, the IPA user authenticates 
normally in the IPA realm either with "kinit -C ipa_user" or "kinit -E 
ad_user@ad_domain" and gets a TGT from IPA.

Where it changes is on the SSSD side. What we want is effectively something 
akin to:
auth_provider = ipa (for IdP)
id_provider = ad (but really we want ipa here to do the idview)


What we have now in SSSD for this case is

id_provider = ad, because AD domain is a subdomain of IPA
auth_provider = ad

The latter is the same krb5 auth provider in disguise so it will accept
any pre-authentication method negotiated between Kerberos client and
KDC. But it would use a different KDC (AD DC) to do its operations.
I am not sure you can change/force it to a different one right now
except hardcoding IPA KDC in the AD realm configuration.



There would be an option so that SSSD could handle this enterprise
principal encoding and thus switch to the shadow user.  In pseudo code,
it would go something like this when the IPA user authenticates:

pam_authenticate(ipa_user)
 kinit(ipa_user@IPA_REALM) // this gets canonicalized to 
"ad_user\@ad.domain@IPA.DOMAIN"
 aname_to_localname(ad_user\@ad.domain@IPA.DOMAIN) // this gives us 
"ad_user@ad.domain"
 pam_set_item(PAM_USER,  "ad_user@ad.domain") // this effectively switches the 
identity from the IPA user to the AD one going forward
 ...

So the user is authenticated against IPA with a TGT, but its username,
UID, GIDs, etc are fetched from AD.  The Posix information in IPA are
never used (i guess they would if you wanted to by turning off
canonicalization)

I realize this is pretty hacky, but in theory this could work right?


Probably. I'd leave that to answer to Sumit or other SSSD developers on
this list.

If you are using RHEL subscription, it might make sense to open a
customer case and provide more details there, along with a request for
enhancement and point to this thread so that we can connect the dots and
get this request analyzed faster from engineering developemnt priorities
point of view.




A possible solution here would be to use IPA users as jump-host-style
entities:
- login as normal IPA users (without AD aliases), authenticated by an external 
IdP
- do 'ksu' or 'ssh' onto AD users, with the help of .k5user mapping.


Um yeah this could work but this not ideal for users. They would have
to be aware of those two different accounts and how to manage them
(shell, home dir, etc)


It would work today without much changes.


--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Re: Support for Azure AD authentication with on-prem AD forest-trust identities

[Alexander Bokovoy via FreeIPA-users]

Hi,

On Суб, 09 сак 2024, Jonathan Calmels via FreeIPA-users wrote:

We have several deployments of RHEL IdM consisting of a cross-forest
trust with on-prem MS Active Directory.  Users are able to login to the
IdM resources with their Corporate AD credentials (i.e. password or
existing AD ticket).  Users identities (including Posix attributes) are
fetched from AD along with all their group information.

Recently we've had the need to support Azure AD authentication
motivated by several factors such as cloud-joined clients and FIDO2
requirements.  In our case, Azure AD is partially synced with the
on-prem AD through Azure AD connect.

Given our current deployments how can we achieve this?  Namely, how can
we support AAD authentication on top of our current authentication with
our user identities sourced from on-prem AD?

The first thing that comes to mind is the external IdP integration in
IPA, however given the nature of its implementation, this requires that
IdP identities are managed through IdM.  So what we need is effectively
a way to link an IdM user (referenced by the IdP association) to an
external trust user, which doesn't seem possible today.


Correct. It is not possible and will not be possible, in IPA deployment,
without some external entity's help.

IPA only responsible for its own users. If authentication relies on an
external identity (e.g. AD user), then authority holding information
about that identity would need to be responsible for its authentication
Kerberos-wise.




We've tried several things, and glancing at the various software pieces
of the IdM stack, this doesn't look supported. We might have missed
something obvious though.  Nonetheless, the main ideas we had were:

1. Add a reference to the AD trust user in the IdM user through the use
of Kerberos enterprise principals.  Here the idea is to define the IdM
user (for IdP) with a canonical principal name set to the fully
qualified trust user (i.e. ipa user-add idm_user --principal
ad_user\\@ad_domain --idp-user-id aad_user@aad_domain)
This way SSSD could theoretically detect and use the trust user instead of the 
IdM one during authentication.
We've personally tried this but hit a few roadblocks (and this list is probably 
non-exhaustive):
- KDB returns KRB5KDC_ERR_WRONG_REALM on enterprise principals consisting of a 
trusted domain
- krb5_child responder would need to return the new user translation (i.e. 
aname_to_lname of ad_user\@ad_domain@IDM_REALM -> ad_user@ad_domain)
- To support the above, sssd_krb5_localauth_plugin would need to be aware of this 
specific case, or be disabled to simply strip IDM_REALM as opposed to returning 
the IdM user back (i.e. ad_user\@ad_domain@IDM_REALM -> idm_user)
- pam_sss would need to set PAM_USER to the result of this translation and use 
the resulting name for subsequent queries (similar to user hints in 
certificates)
- getAccountInfo would probably need tweaking too (not exactly sure)


This is not supported. Technically, you can use trusted domains'
principals as aliases of IPA principals with

$ ipa user-add-principal ipa_user ad_user@AD.DOMAIN

If enterprise principal support is advertised by the client, a KDC would
return the primary principal name in the ticket, which has to be IPA
realm's principal. However, this would make impossible to login as AD
user through IPA KDC because we would find that principal alias and
instead of issuing a cross-realm referral handle it locally.

On top of that, IPA has no realm aliases, that's why one cannot set
AD_DOMAIN as a realm for IPA principals and expect it working.

The principal aliasing should work to allow AD users to have "shadow"
IPA users they'll map onto with the help of external IdP authentication,
kerberos-wise. It might need more support from SSSD side, though.
Obviously, these IPA users will be then the POSIX users on IPA systems
as they will technically be different from AD users. One might try to
map AD users to these IPA users via ID overrides but it would be a bit
muddy to maintain since there will definitely be a problem with ID
ranges or SSSD expectations.

A possible solution here would be to use IPA users as jump-host-style
entities:
- login as normal IPA users (without AD aliases), authenticated by an external 
IdP
- do 'ksu' or 'ssh' onto AD users, with the help of .k5user mapping.




2. Modify the trust IDView to include the IdP association and signal the fact 
that IdP authentication should be done through IdM and not the trusted KDC.
From there, I'm not sure how this would work on the IdM KDC side since
there wouldn't be any existing principal to authenticate against (maybe
matching enterprise principals could be created dynamically similar to
1.)


It will not work. IPA KDC does not look into ID Views at all -- those
aren't considered Kerberos principals at all. Either you have a Kerberos
in this realm (IPA's) or KDC will route to the known trusted realm
directly or via some known trusted realm and there KDC would 

[Freeipa-users] Re: Login failed due to an unknown reason

[Alexander Bokovoy via FreeIPA-users]

On Аўт, 05 сак 2024, ITreers UA via FreeIPA-users wrote:

As I understand my problem isn't related to SID probably.
All my users obtained correct (as I think) SIDs after the migration.
But I have such different logs for the admin user (was not migrated) and for 
the test.1 user which was migrated from the old FreeIPA 4.6.8 on CentOS7 the 
the new Ubuntu 22.04 docker instance of the FreeIPA 4.10.2 with the same realm, 
but on the different domain.

The migration was made with the command:

ipa migrate-ds --bind-dn="cn=Directory Manager" 
--user-container=cn=users,cn=accounts --group-container=cn=groups,cn=accounts 
--group-objectclass=posixgroup 
--user-ignore-attribute={krbPrincipalName,krbextradata,krblastfailedauth,krblastpwdchange,krblastsuccessfulauth,krbloginfailedcount,krbpasswordexpiration,krbticketflags,krbpwdpolicyreference,mepManagedEntry,ipaNTSecurityIdentifier,pwmlastpwdupdate,pwmeventlog}
 --user-ignore-objectclass={mepOriginEntry,pwmuser,ipaNTUserAttrs} 
--group-ignore-attribute=ipaNTSecurityIdentifier 
--group-ignore-objectclass=ipaNTGroupAttrs --exclude-users={pwm.proxy,pwm.test} 
--exclude-groups={pwm.proxy,pwm.test} --group-overwrite-gid --with-compat 
ldaps://old.somedomain.net

[root@ldap-2 /]# KRB5_TRACE=/dev/stderr kinit admin 2>&1
[7363] 1709655365.522471: Getting initial credentials for ad...@somedomain.net
[7363] 1709655365.522473: Sending unauthenticated request
[7363] 1709655365.522474: Sending request (169 bytes) to SOMEDOMAIN.NET
[7363] 1709655365.522475: Initiating TCP connection to stream 172.18.0.3:88
[7363] 1709655365.522476: Sending TCP request to stream 172.18.0.3:88
[7363] 1709655365.522477: Received answer (526 bytes) from stream 172.18.0.3:88
[7363] 1709655365.522478: Terminating TCP connection to stream 172.18.0.3:88
[7363] 1709655365.522479: Response was from primary KDC
[7363] 1709655365.522480: Received error from KDC: -1765328359/Additional 
pre-authentication required
[7363] 1709655365.522483: Preauthenticating using KDC method data
[7363] 1709655365.522484: Processing preauth types: PA-PK-AS-REQ (16), 
PA-FX-FAST (136), PA-ETYPE-INFO2 (19), PA-PKINIT-KX (147), PA-SPAKE (151), 
PA-ENC-TIMESTAMP (2), PA_AS_FRESHNESS (150), PA-FX-COOKIE (133)
[7363] 1709655365.522485: Selected etype info: etype aes256-sha2, salt "1u\ 
]=_tjHbc>-/e", params ""
[7363] 1709655365.522486: Received cookie: 
MIT1\x00\x00\x00\x01\x1b\xb8\x99\xd8b\x8b\xe8\xc0\xe1\xca\x82\x0c\x9c"\x06\x7f3\x83o]\xbb\x172\xb5A\x053\ni\xd1\x88\x1e&>\xaaS\xd9\x15|\x84\xdb\xe9\xb1azEs\x99\xfb\x91\xaa\xb5\x08\x9c+\xb1\xb6\x02\xba\x85\x08
 
\xa1RV\x7f\xd3\xa3\x0b\x99\x9e\xda\xbap?U\xde\xd3\x9c\x0d\xe9T\x98\xbc+\xc4\xe8|\x7f=\xfa\x1f\\xde\xae\x93\x12\x81m\xc2\xf5cFs\xf7\x12\x157\xb8c\xd1\x11\x9c\x8d\xa8\xf2\x9b\xd5\x94X\xb2%\x08\x91\x11a?L\x03d\xbc5\x9f4GmV\xa96fe
[7363] 1709655365.522487: PKINIT client has no configured identity; giving up
[7363] 1709655365.522488: Preauth module pkinit (147) (info) returned: 0/Success
[7363] 1709655365.522489: PKINIT client received freshness token from KDC
[7363] 1709655365.522490: Preauth module pkinit (150) (info) returned: 0/Success
[7363] 1709655365.522491: PKINIT client has no configured identity; giving up
[7363] 1709655365.522492: Preauth module pkinit (16) (real) returned: 
22/Invalid argument
[7363] 1709655365.522493: SPAKE challenge received with group 1, pubkey 
22D477D5D4218DC8C5FFF38EC21FE6E08D9A6488F3F96D69A3D6D15C929D2EC2
Password for ad...@somedomain.net:
[7363] 1709655418.745247: SPAKE key generated with pubkey 
344A6368A2BE4535EB68237F9996F92FF4418A19661AFA4B5B84CE5780DF909A
[7363] 1709655418.745248: SPAKE algorithm result: 
F630A33BAA4143B978F659D6A401A53174E43A82E6F70140BA99CAC959A2C29F
[7363] 1709655418.745249: SPAKE final transcript hash: 
9CF0C027377C1287D946DB78876076A46B97D95E962AA30A05634184107222F9
[7363] 1709655418.745250: Sending SPAKE response
[7363] 1709655418.745251: Preauth module spake (151) (real) returned: 0/Success
[7363] 1709655418.745252: Produced preauth for next request: PA-FX-COOKIE 
(133), PA-SPAKE (151)
[7363] 1709655418.745253: Sending request (452 bytes) to MEA-DEV.NET
[7363] 1709655418.745254: Initiating TCP connection to stream 172.18.0.3:88
[7363] 1709655418.745255: Sending TCP request to stream 172.18.0.3:88
[7363] 1709655418.745256: Received answer (1761 bytes) from stream 172.18.0.3:88
[7363] 1709655418.745257: Terminating TCP connection to stream 172.18.0.3:88
[7363] 1709655418.745258: Response was from primary KDC
[7363] 1709655418.745259: Processing preauth types: PA-ETYPE-INFO2 (19)
[7363] 1709655418.745260: Selected etype info: etype aes256-sha2, salt "1u\ 
]=_tjHbc>-/e", params ""
[7363] 1709655418.745261: Produced preauth for next request: (empty)
[7363] 1709655418.745262: AS key determined by preauth: aes256-sha2/B7BD
[7363] 1709655418.745263: Decrypted AS reply; session key is: aes256-sha2/5E1A
[7363] 1709655418.745264: FAST negotiation: available
[7363] 1709655418.745265: Resolving unique ccache of type MEMORY

[Freeipa-users] Re: [Freeipa-users](dnssec-keyfroml) of user ZZZ dumped core.

[Alexander Bokovoy via FreeIPA-users]

On Аўт, 05 сак 2024, Harry G Coin via FreeIPA-users wrote:

Update:

This same core dump pattern appears across all freeipa masters running 
dns in this sandbox, ruling out hardware causes.  Ideas?


This is most likely atexit callback issue in softhsmv2. Or, an issue
with openssl callbacks being run automatically. I updated softhsm in
Rawhide recently to include a patch which supposed to fix most of these
problems, contributed by an OpenSSL's developer. We haven't seen issues
like that in rawhide after that yet.

I am planning to add this patch to CentOS 9 Stream soon.

If you have actual coredump, can you send it to me off-list, along with
the details on the packages you used?




On Mon, Mar 4, 2024 at 10:54 PM Harry G Coin via FreeIPA-users 
 wrote:


   FYI.  El9, latest stable.


   Mar 04 22:46:05registry1.1.quietfountain.com  
  ipa-dnskeysyncd[75834]: 
ipaserver.dnssec.bindmgr: INFO attrs: 
   Mar 04 22:46:05registry1.1.quietfountain.com  
  named[1463]: client @0x7fd61803ae68 
10.12.112.3#49016: received notify for zone '0.0.0.0.0.0.a.0.0.8.9.2.4.0.6.2.ip6.arpa'
   Mar 04 22:46:05registry1.1.quietfountain.com  
  named[1463]: client @0x7fd618191538 
fc00:1002:c7::3#41560: received notify for zone 
'0.0.0.0.0.0.a.0.0.8.9.2.4.0.6.2.ip6.arpa'
   Mar 04 22:46:05registry1.1.quietfountain.com  
  dnssec-keyfromlabel[75984]: 
Configuration.cpp(96): Missing log.level in configuration. Using default value: INFO
   Mar 04 22:46:05registry1.1.quietfountain.com  
  dnssec-keyfromlabel[75984]: 
Configuration.cpp(96): Missing slots.mechanisms in configuration. Using default 
value: ALL
   Mar 04 22:46:05registry1.1.quietfountain.com  
  dnssec-keyfromlabel[75984]: 
Configuration.cpp(124): Missing slots.removable in configuration. Using default 
value: false
   Mar 04 22:46:05registry1.1.quietfountain.com  
  systemd[1]: ipa-ods-exporter.service: 
Deactivated successfully.
   Mar 04 22:46:05registry1.1.quietfountain.com  
  systemd[1]: ipa-ods-exporter.service: 
Consumed 4.047s CPU time.
   Mar 04 22:46:05registry1.1.quietfountain.com  
  ipa-dnskeysyncd[75834]: 
ipaserver.dnssec.bindmgr: INFO attrs: 
   Mar 04 22:46:06registry1.1.quietfountain.com  
  dnssec-keyfromlabel[75991]: 
Configuration.cpp(96): Missing log.level in configuration. Using default value: INFO
   Mar 04 22:46:06registry1.1.quietfountain.com  
  dnssec-keyfromlabel[75991]: 
Configuration.cpp(96): Missing slots.mechanisms in configuration. Using default 
value: ALL
   Mar 04 22:46:06registry1.1.quietfountain.com  
  dnssec-keyfromlabel[75991]: 
Configuration.cpp(124): Missing slots.removable in configuration. Using default 
value: false
   Mar 04 22:46:06registry1.1.quietfountain.com  
  named[1463]: client @0x7fd61803ae68 
10.12.112.3#49016: received notify for zone '0.0.0.0.0.0.f.0.0.8.9.2.4.0.6.2.ip6.arpa'
   Mar 04 22:46:06registry1.1.quietfountain.com  
  named[1463]: client @0x7fd618191538 
fc00:1002:c7::3#41560: received notify for zone 
'0.0.0.0.0.0.f.0.0.8.9.2.4.0.6.2.ip6.arpa'
   Mar 04 22:46:06registry1.1.quietfountain.com  
  kernel: dnssec-keyfroml[75991]: 
segfault at 18 ip 7f7fba586284 sp 73e834a8 error 4 in 
libsofthsm2.so[7f7fba4ef000+9b000] likely on CPU 0 (core 0, socket 0)
   Mar 04 22:46:06registry1.1.quietfountain.com  
  kernel: Code: 75 f4 48 8b 53 30 49 89 4c 24 
20 49 89 44 24 10 49 89 54 24 28 48 83 c4 08 4c 89 e0 5b 41 5c c3 66 0f 1f 44 00 00 f3 0f 
1e fa <48> 8b 47 18 48 85 c0 74 44 4c 8d 47 10 4c 89 c7 eb 12 66 2e 0f 1f
   Mar 04 22:46:06registry1.1.quietfountain.com  
  systemd[1]: Started Process Core Dump 
(PID 75992/UID 0).
   Mar 04 22:46:06registry1.1.quietfountain.com  
  systemd-coredump[75993]: Resource 
limits disable core dumping for process 75991 (dnssec-keyfroml).
   Mar 04 22:46:06registry1.1.quietfountain.com  
  systemd-coredump[75993]: [] Process 
75991 (dnssec-keyfroml) of user 984 dumped core.
   Mar 04 22:46:06registry1.1.quietfountain.com  
  
systemd[1]:systemd-coredump@40-75992-0.service: Deactivated successfully.
   Mar 04 22:46:07registry1.1.quietfountain.com  
  ipa-dnskeysyncd[75834]: Traceback (most 
recent call last):
   Mar 04 22:46:07registry1.1.quietfountain.com  

[Freeipa-users] Re: problem allowing Windows Active Directory users to access SMB shares on IPA client machine (IPA has trust with AD)

[Alexander Bokovoy via FreeIPA-users]

On Чцв, 29 лют 2024, Thomas Handler wrote:

Dear Alexander,

thank you for your assistance this is greatly appreciated.

Regarding the logs - the got quite big, not sure if I can attach them
here as a .tgz as I have 972k uncompressed. 


You can send to me directly or upload somewhere and send a link.




But on the client I got an error message that might explain he problem
better (I have obfuscated the domain but not IP addresses):

smb_gss_krb5_import_cred ccache[KCM:162425] failed with [Unspecified GSS 
failure.  Minor code may provide more information: No credentials cache found] 
-the caller may retry after a kinit.
Failed to start GENSEC client mech gse_krb5: NT_STATUS_INTERNAL_ERROR
gensec_spnego_client_negTokenInit_step: Could not find a suitable mechtype in 
NEG_TOKEN_INIT

kinit for the domain user with the credential file worked fine, as the
attempt logged below was done with my user I also retried the same
kinit/smbclient call as root with the same result.


Thank you,

best regards 
Thomas


—— log for smbclient — 

$ KRB5_TRACE=/dev/stderr smbclient -d10 -L ums025.example.com -U 
mq.ad...@example.com --use-kerberos=required --use-krb5-ccache=./file.ccache
Initialising global parameters
rlimit_max: increasing rlimit_max (1024) to minimum Windows limit (16384)
INFO: Current debug levels:
  all: 10
  tdb: 10
  printdrivers: 10
  lanman: 10
  smb: 10
  rpc_parse: 10
…
  dsdb_group_audit: 10
  dsdb_group_json_audit: 10
Processing section "[global]"
doing parameter workgroup = SAMBA
doing parameter security = user
doing parameter passdb backend = tdbsam
doing parameter printing = cups
doing parameter printcap name = cups
doing parameter load printers = yes
doing parameter cups options = raw
doing parameter include = /etc/samba/usershares.conf
Can't find include file /etc/samba/usershares.conf
pm_process() returned Yes
lp_servicenumber: couldn't find homes
added interface virbr0 ip=192.168.122.1 bcast=192.168.122.255 
netmask=255.255.255.0
added interface ens192 ip=10.130.103.38 bcast=10.130.103.255 
netmask=255.255.255.0
Client started (version 4.18.6).
Opening cache file at /var/lib/samba/lock/gencache.tdb
tdb(/var/lib/samba/lock/gencache.tdb): tdb_open_ex: could not open file 
/var/lib/samba/lock/gencache.tdb: Permission denied
gencache_init: Opening user cache file /home/tha/.cache/samba/gencache.tdb.
sitename_fetch: No stored sitename for realm ''
internal_resolve_name: looking up ums025.example.com#20 (sitename (null))
gencache_set_data_blob: Adding cache entry with key=[NBT/UMS025.EXAMPLE.COM#20] 
and timeout=[Thu Jan  1 01:00:00 AM 1970 CET] (-1709223544 seconds in the past)
namecache_fetch: no entry for ums025.example.com#20 found.
resolve_hosts: Attempting host lookup for name ums025.example.com<0x20>
remove_duplicate_addrs2: looking for duplicate address/port pairs
namecache_store: storing 1 address for ums025.example.com#20: 10.130.103.25
gencache_set_data_blob: Adding cache entry with key=[NBT/UMS025.EXAMPLE.COM#20] 
and timeout=[Thu Feb 29 05:30:04 PM 2024 CET] (660 seconds ahead)
internal_resolve_name: returning 1 addresses: 10.130.103.25
Connecting to 10.130.103.25 at port 445
socket options: SO_KEEPALIVE=0, SO_REUSEADDR=0, SO_BROADCAST=0, TCP_NODELAY=1, 
TCP_KEEPCNT=9, TCP_KEEPIDLE=7200, TCP_KEEPINTVL=75, IPTOS_LOWDELAY=0, 
IPTOS_THROUGHPUT=0, SO_REUSEPORT=0, SO_SNDBUF=87040, SO_RCVBUF=367360, 
SO_SNDLOWAT=1, SO_RCVLOWAT=1, SO_SNDTIMEO=0, SO_RCVTIMEO=0, TCP_QUICKACK=1, 
TCP_DEFER_ACCEPT=0, TCP_USER_TIMEOUT=0
 session request ok
 negotiated dialect[SMB3_11] against server[ums025.example.com]
cli_session_setup_spnego_send: Connect to ums025.example.com as 
mq.ad...@example.com using SPNEGO
GENSEC backend 'gssapi_spnego' registered
GENSEC backend 'gssapi_krb5' registered
GENSEC backend 'gssapi_krb5_sasl' registered
GENSEC backend 'spnego' registered
GENSEC backend 'schannel' registered
GENSEC backend 'ncalrpc_as_system' registered
GENSEC backend 'sasl-EXTERNAL' registered
GENSEC backend 'ntlmssp' registered
GENSEC backend 'ntlmssp_resume_ccache' registered
GENSEC backend 'http_basic' registered
GENSEC backend 'http_ntlm' registered
GENSEC backend 'http_negotiate' registered
Starting GENSEC mechanism spnego
Starting GENSEC submechanism gse_krb5
smb_gss_krb5_import_cred ccache[KCM:162425] failed with [Unspecified GSS 
failure.  Minor code may provide more information: No credentials cache found] 
-the caller may retry after a kinit.
Failed to start GENSEC client mech gse_krb5: NT_STATUS_INTERNAL_ERROR
gensec_spnego_client_negTokenInit_step: Could not find a suitable mechtype in 
NEG_TOKEN_INIT
gensec_update_send: spnego[0x55f8e36a9910]: subreq: 0x55f8e36e5de0
gensec_update_done: spnego[0x55f8e36a9910]: NT_STATUS_INVALID_PARAMETER 
tevent_req[0x55f8e36e5de0/../../auth/gensec/spnego.c:1632]: state[3] 
error[-7963671676338569203 (0x917B5ACDC00D)]  state[struct 
gensec_spnego_update_state (0x55f8e36e5fa0)] timer[(nil)] 
finish[../../auth/gensec/spnego.c:1947]
SPNEGO login 

[Freeipa-users] Re: ipa: ERROR: No valid Negotiate header in server response

[Alexander Bokovoy via FreeIPA-users]

On Чцв, 29 лют 2024, Grant Janssen via FreeIPA-users wrote:

It appears I have resolved my certificate expiration 
issue
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org/thread/KFQXY6V4UKYOWCGD4YCZTCSGFWVL3QK7/


But I have a another issue

grant@ef-idm01:~[20240229-10:11][#772]$ klist
Ticket cache: KCM:555
Default principal: gr...@production.efilm.com


Is this user has UID 555?

Can you look at your KDC's krb5kdc.log and see if there is an issue with
HANDLE_AUTHDATA or PAC or S4U operations at the time you run 'ipa
user-find' or similar commands?

Basically, I think you have users with UID/GIDs outside of your ID
ranges and therefore those users have no SIDs associated with them and
hence cannot be used for constrained delegation (S4U extensions in
Kerberos) anymore. In addition, most likely your existing ID ranges have
no support for generating SIDs as they most likely lack RID bases.

There were plenty of discussions about it on the list in past few
months. You can look at these articles on the Red Hat's Customer Portal:

https://access.redhat.com/articles/7027037
https://access.redhat.com/solutions/7052703
https://access.redhat.com/solutions/7014959



Valid starting   Expires  Service principal
02/29/2024 10:11:56  03/01/2024 09:42:34  
krbtgt/production.efilm@production.efilm.com
grant@ef-idm01:~[20240229-10:12][#773]$ ipa user-find roland
ipa: ERROR: No valid Negotiate header in server response
grant@ef-idm01:~[20240229-10:12][#774]$ ipa server-find
ipa: ERROR: No valid Negotiate header in server response
grant@ef-idm01:~[20240229-10:18][#775]$ sudo systemctl status gssproxy.service
[sudo] password for grant:
● gssproxy.service - GSSAPI Proxy Daemon
  Loaded: loaded (/usr/lib/systemd/system/gssproxy.service; disabled; vendor 
preset: disabled)
  Active: active (running) since Tue 2024-02-20 13:57:40 PST; 1 weeks 1 days ago
 Process: 2158008 ExecStart=/usr/sbin/gssproxy -D (code=exited, 
status=0/SUCCESS)
Main PID: 2158009 (gssproxy)
   Tasks: 6 (limit: 74714)
  Memory: 10.5M
  CGroup: /system.slice/gssproxy.service
  └─2158009 /usr/sbin/gssproxy -D

Feb 20 13:57:40 
ef-idm01.production.efilm.com systemd[1]: 
gssproxy.service: Succeeded.
Feb 20 13:57:40 
ef-idm01.production.efilm.com systemd[1]: 
Stopped GSSAPI Proxy Daemon.
Feb 20 13:57:40 
ef-idm01.production.efilm.com systemd[1]: 
Starting GSSAPI Proxy Daemon...
Feb 20 13:57:40 
ef-idm01.production.efilm.com systemd[1]: 
Started GSSAPI Proxy Daemon.
grant@ef-idm01:~[20240229-10:18][#776]$

I searched online for some references and it was suggested I generate the 
/var/lib/ipa/gssproxy/http.keytab
The keytab file appears OKAY to me though.

I would like to get this issue behind me
thanx

- grant






--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Re: problem allowing Windows Active Directory users to access SMB shares on IPA client machine (IPA has trust with AD)

[Alexander Bokovoy via FreeIPA-users]

On Срд, 28 лют 2024, Thomas Handler via FreeIPA-users wrote:


Hi all,

I am facing a problem I got stuck upon.


We have the following setup:

                       +---+            
                       |           |            
                       |    AD     |            
                       |           |            
                       +---+            
+--+          ^                     
|              +--+                     
|    ums012    |                                
|              |                                
|     IPA      |                                
+--+                                
       ^                                        
       |                        +--+
       |                        |              |
       |                        |    ums029    |
       |                        |              |
       |                        |   smbclient  |
       |                        +---+--+
+--++                   |           
|               |                   |           
|    ums025     |                   |           
|               |<--+           
|    samba      |                               
+---+                               

IPA has a trust established with AD which is working fine. Active Directory 
users can logon on Linux machines which are connected to IPA, `id some-ad-user` 
properly shows the AD groups.

ums012 and ums025 are running RHEL 9.3, ums029 is running RHEL 8.9.

ums029 is used as a test client via smbclient.


ums025 was setup following the instructions in 
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/using_external_red_hat_utilities_with_identity_management/setting-up-samba-on-an-idm-domain-member_using-external-red-hat-utilities-with-idm
 

Setup worked fine, all steps went ok. 

But when i switch over to ums029 and try to verify with an ad user I get


kinit 
smbclient -L ums025.idm.example.com -U  --use-kerberos=required
Password for [@EXAMPLE.COM]:
gensec_spnego_client_negTokenInit_step: gse_krb5: creating NEG_TOKEN_INIT for 
cifs/ums025.idm.example.com failed (next[(null)]): NT_STATUS_INVALID_PARAMETER
session setup failed: NT_STATUS_INVALID_PARAMETER


Can you get more details?

It would help to collect debug logs from the samba server as well as the
client at the same time, with 'log level = 10' in smb.conf.

Use something like the following on the client:

kinit -c ./file.ccache 
KRB5_TRACE=/dev/stderr smbclient -d10 -L ... -U  
--use-kerberos=required --use-krb5-ccache=./file.ccache

This will collect information from the client side.

--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Re: Seeking Advice: Limiting User Access in FreeIPA Web Interface

[Alexander Bokovoy via FreeIPA-users]

On Няд, 25 лют 2024, Carlos Eduardo Porter via FreeIPA-users wrote:

So, I did so more research and found this thread from 7 years ago [1] which
I obviously missed and clearly answers my previous question

Quote:
""
 Even with that, I'd not recommend tightening permissions so that users
 would not be able to see other users. There are always ways to break
 through this 'enforcement', even start with the fact that a user could
 actually authenticate with the host principal of their desktop system.
 Access to the identity information is not arbitrated in POSIX
 environment. Any process under any user could ask for other user and
 group identities with standard libc API.

 Security through obscurity never works well in a longer term.

""
  -- Alexander Bokovoy

So I get Alexander's point, although there are still valid reasons to want
to limit other users access to the directory, such as:

- Multiple temporary vendors: you might want to grant them access to some
of your development tools without them being aware of other users or groups
on your organization

- Application Settings: you might have an application that allows you to
set up a single LDAP server, or if you have multiple realms or freeipa
instances you can only use at the time for authentication.

Nonetheless, the point is taken and it seems that for now the best
solution would be not to expose all users to the FreeIPA web interface.

I'm also considering using phpLDAPadmin and grant it access only to
specific groups within the main FreeIPA directory, that way I might be able
to setup different phpLDAPadmin instances for as many LDAP groups and
provide them with limited directory access ( at least from a web interface
point of view, although this might seem foolish ).


What changed since that time, is that Fedora project has created Noggin,
https://github.com/fedora-infra/noggin, a self-service portal for user
management on top of FreeIPA deployment. You might want to look at that
and use it instead.



References:
[1]
https://freeipa-users.redhat.narkive.com/Zz750eoG/limit-regular-user-access-only-to-self-service-portal

On Sat, Feb 24, 2024 at 5:17 AM Carlos Eduardo Porter <
carlosporter2...@gmail.com> wrote:


Hello,

I hope this message finds you well. I'm currently working on deploying
FreeIPA for a small company and have encountered a challenge that I’d like
to share with you, hoping to confirm if I'm on the right track.

My objective is to restrict access within the FreeIPA web interface,
specifically, I want to ensure that only members of a group named
"managers" can view information about other accounts and groups on the
FreeIPA server.

I am aware that this issue might seem familiar as it has been discussed in
this forum previously. Nonetheless, I'm bringing it up again with the
intention of finding a solution that could benefit others facing similar
challenges.

From what I've gathered over the years, altering the default permissions
in FreeIPA, which allow access to all accounts, could potentially lead to
more complications (refer to [1] for details). However, there seems to be a
possibility of achieving this through the correct configuration of
permissions, privileges, and roles in FreeIPA. For instance, setting up
filters that permit a user to view only their own account information.
Despite my efforts, I haven’t been successful in implementing this so far.

Here’s an example of what I've tried:

# Adds a new permission named 'Self Only Access' allowing read, search,
and compare rights limited to user's own attributes
ipa permission-add 'Self Only Access' --right={'read','search','compare'}
--type=user --attrs={'uid','mail','title'} --filter="(uid=\${user})"

# Creates a new privilege called 'Self Read User Privilege'
ipa privilege-add 'Self Read User Privilege' --desc="Privilege for Self
Read User"

# Adds the 'Self Only Access' permission to the 'Self Read User Privilege'
ipa privilege-add-permission 'Self Read User Privilege'
--permissions='Self Only Access'

# Creates a new role named 'CustomSelfReadUserRole' with a description for
the self-read privilege
ipa role-add 'CustomSelfReadUserRole' --desc='Role with Self Read User
Privilege'

# Associates the 'Self Read User Privilege' with the
'CustomSelfReadUserRole'
ipa role-add-privilege 'CustomSelfReadUserRole' --privileges='Self Read
User Privilege'

# Displays the details of the 'CustomSelfReadUserRole'
ipa role-show 'CustomSelfReadUserRole'

# Adds specific users ('user1' and 'user2') as members of the
'CustomSelfReadUserRole'
ipa role-add-member 'CustomSelfReadUserRole' --users={'user1','user2'}


This approach is partly based on a blog entry by Alexander Bokovoy ([2])
about creating permissions in FreeIPA.

Another more drastic measure involves modifying Apache2 to use mod_ldap
and restricting access to the FreeIPA API, as shown below:

# Creating a new configuration file for Apache2 with LDAP settings
cat > /etc/httpd/conf.d/ldap.conf

# 

[Freeipa-users] Re: FreeIPA 4.11.1 radius proxy auth timeout

[Alexander Bokovoy via FreeIPA-users]

On Суб, 24 лют 2024, Lenard Pasztor via FreeIPA-users wrote:

Update2:

Yes, the kdc.conf modification solved the problem, but now I got new
push notifications in every 5 seconds until I hit the approve (or
timeout exceeded. So the duo radius proxy receiving a new try in every
5 seconds. So there is an another timeout. Can somebody give a
suggestion where to look for it?

[root@idm-0 /]# ipa radiusproxy-show duo
 RADIUS proxy server name: duo
 Description: duo
 Server: 10.15.0.32
 Timeout: 30
 Retries: 0


You already found 'otp' pre-authentication mechanism's configuration.

https://github.com/krb5/krb5/blob/master/src/plugins/preauth/otp/otp_state.c#L239-L250

So technically the retries and timeout from the DEFAULT otp
configuration in kdc.conf should be governing it.

--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Re: api authorization stopped working after upgrade to 4.9.12-11 on RHEL8

[Alexander Bokovoy via FreeIPA-users]

On Аўт, 27 лют 2024, Peter Larsen via FreeIPA-users wrote:

On Чцв, 11 сту 2024, Rasto Rickardt wrote:

Thanks, the configs look OK. So check whether users miss SIDs and
regenerate them with

  ipa config-mod --enable-sid --add-sids

as admin.


I've seen a lot of posts with this recommendation. The trouble is, that every command I 
pass to "ipa" fails with the error in this post which core issue is 
S4U2PROXY_EVIDENCE_TKT_WITHOUT_PAC.

So how do you run the config-mod command when "ipa config-mod" failus with the 
exact same error?


Please see https://access.redhat.com/solutions/7052703. It requires RHEL
subscription but will also work with a free RHEL developer subscription
one can obtain at developers.redhat.com


--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Re: SSSD offline and AD authentication issues

[Alexander Bokovoy via FreeIPA-users]

On Чцв, 15 лют 2024, Heidi Hough via FreeIPA-users wrote:

You are correct, debugging was only specified in the [domain/...] section.  I 
have enabled for nss and gathered logs again.  The client and server times are 
indeed in sync.

I initiated my login attempt at approximately 10:16:30.  At approximately 
10:17:10 I was presented with a prompt to enter my password.  After entering my 
password I was again presented with a password prompt.  After entering multiple 
times with no success I waited and eventually the connection attempt timed out.

Server Logs for this attempt
https://privatebin.net/?74adb14729c459fc#EhqWm6x2LVgfnL7iAmLZDFh3TtXpwgsH9wjUfWQYrGyS
Client Logs for this attempt
https://privatebin.net/?1d3532466812bef2#C6ECF2RnRMEXVi7HGLd8iYvhoSmEw2uRs88neb2MG3RQ

It seems like a considerable amount of time is spent searching the AD
groups a user is a member of.  For testing purposes, an AD account was
created that is not a member of any groups.  This user was able to
successfully log in.  What additional steps should be taken to account
for AD's where users are members of many groups?  To add to the
complexity, many of these groups are nested.


If time to resolve all groups is above 10 seconds, then you might want
to increase timeouts. There are three elements in a lookup:

 - SSSD on the client to IPA server's LDAP server
 - IPA server's LDAP server to local SSSD on the IPA server
 - SSSD on the IPA server to AD DCs

The middle one (LDAP server plugin to local SSSD) should have a timeout
that covers time spent in resolving the most complex query issued to AD
DCs. SSSD on the client should be able to handle at least that timeout
too.



I've reviewed this document (https://access.redhat.com/articles/2133801) and 
spent time adjusting parameters with little success.

The sssd.conf on both client and server include the following in the 
[domain/...] section:

subdomain_inherit = ignore_group_members
ignore_group_members = True

Should these be placed somewhere else instead? Are there other options
that should be set to account for large numbers of nested AD groups?


No, these should be OK. The only potential change you might want to do
is to bump a timeout used by the ipa-exdom-extop plugin when it talks to
the SSSD on the server side:

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/tuning_performance_in_identity_management/assembly_tuning-sssd-performance-for-large-idm-ad-trust-deployments_tuning-performance-in-idm#proc_tuning-the-config-timeout-for-the-ipa-extdom-plugin-on-idm-servers_assembly_tuning-sssd-performance-for-large-idm-ad-trust-deployments


It is 10 seconds by default but in your case it looks like the whole set
of operations to reverse resolve all those groups takes around 20-26
seconds. Notice the diffs between 'Looking up ...' and 'Object found,
but needs to be refreshed', most are within the same second but few are
requiring up to 5 seconds. These are actions to do 'initgroups'
operation which is typically run by the client side when you log in, to
build a list of secondary groups for your login process. I guess a first
login would require a lot time due to this information being not yet
available but consequent ones would take much lower time.

$ grep 'CID#8' sssd_nss.log |grep -E '(Looking up|but needs)'
(2024-02-14 10:16:30): [nss] [cache_req_search_send] (0x0400): [CID#8] CR #31: 
Looking up heidi...@ad.contoso.com
(2024-02-14 10:16:30): [nss] [cache_req_search_cache] (0x0400): [CID#8] CR #31: 
Looking up [heidi...@ad.contoso.com] in cache
(2024-02-14 10:16:30): [nss] [cache_req_search_send] (0x0400): [CID#8] CR #31: 
Object found, but needs to be refreshed.
(2024-02-14 10:16:30): [nss] [cache_req_search_send] (0x0400): [CID#8] CR #32: 
Looking up heidi...@ad.contoso.com
(2024-02-14 10:16:30): [nss] [cache_req_search_cache] (0x0400): [CID#8] CR #32: 
Looking up [heidi...@ad.contoso.com] in cache
(2024-02-14 10:16:30): [nss] [cache_req_search_send] (0x0400): [CID#8] CR #32: 
Object found, but needs to be refreshed.
(2024-02-14 10:16:30): [nss] [cache_req_search_send] (0x0400): [CID#8] CR #33: 
Looking up heidi...@ad.contoso.com
(2024-02-14 10:16:30): [nss] [cache_req_search_cache] (0x0400): [CID#8] CR #33: 
Looking up [heidi...@ad.contoso.com] in cache
(2024-02-14 10:16:30): [nss] [cache_req_search_send] (0x0400): [CID#8] CR #33: 
Object found, but needs to be refreshed.
(2024-02-14 10:16:30): [nss] [cache_req_search_send] (0x0400): [CID#8] CR #34: 
Looking up GID:603892...@ad.contoso.com
(2024-02-14 10:16:30): [nss] [cache_req_search_cache] (0x0400): [CID#8] CR #34: 
Looking up [GID:603892...@ad.contoso.com] in cache
(2024-02-14 10:16:30): [nss] [cache_req_search_send] (0x0400): [CID#8] CR #34: 
Object found, but needs to be refreshed.
(2024-02-14 10:16:30): [nss] [cache_req_search_send] (0x0400): [CID#8] CR #35: 
Looking up GID:602655...@ad.contoso.com
(2024-02-14 10:16:30): [nss] [cache_req_search_cache] (0x0400): [CID#8] CR #35: 
Looking 

[Freeipa-users] Re: setup trusted Realm between two freeIPAs

[Alexander Bokovoy via FreeIPA-users]

On Срд, 14 лют 2024, Farshad Allahdadi via FreeIPA-users wrote:

Hi,
I'm going to transfer data between two Hadoop clusters kerberizd/joined
to separate freeIPAs using distcp. The distcp command or any tool
requires to authenticate to both freeIPAs (grant permission to read
from one server and write to other).
My priority is to make the least possible changes to source
cluster/freeIPA which is in production, so I tried to setup trusted
real between these but failed, it seems that trusted realm is only
possible (or documented) between AD and freeIPA. Is it possible to
setup trusted Realm between two freeIPAs(and if yes how to)? What are
the other options to do the job with less impact on source freeIPA?
Also making freeIPAs to be replica for each other is not a good option
for me, because i need to separate them later.


IPA-IPA trust is currently not supported.


--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Re: SSSD offline and AD authentication issues

[Alexander Bokovoy via FreeIPA-users]

On Срд, 14 лют 2024, Heidi Hough via FreeIPA-users wrote:

I had restarted the sssd services on server and client after updating
the ldap_search_timeout value.  I did let it run for much longer,
ensuring sssd services were all reported as online when issuing
systemctl status sssd on both server and client.

You will find logs for a failed login attempt to the freeipa client.
The login attempt took place at 13:26.  I was quite bothered by the
face that the sssd_nss log on the server was not populated during this
attempt, but was populated during the prior attempt that I shared.  Is
there a better way to identify if the sssd_nss service is
running/online?


It depends on what debug level you have used. I suspect you only put
debug_level statement in the [domain/...] section, right? If you want to
get more details from different SSSD components, you need to put
debug_level statements in the separate sections. 


Or use 'sssctl debug-level .. ' which sets debug_level value to all
sections at runtime but it is only active until restart.



You mentioned:
"SSSD on the client sends LDAP search with a specific control to LDAP
server. This request is taken care of by a plugin in LDAP server code
which issues a local request to SSSD using its API."

Is there a way to troubleshoot this specific process?


389-ds accesslog will contain all LDAP connections. You may search there
for 'IPA trusted domain ID mapper' being mentioned. This is an example
from my test environment:

[14/Feb/2024:08:04:37.169019132 +] conn=81003 op=23 EXT 
oid="2.16.840.1.113730.3.8.10.4.2" name="IPA trusted domain ID mapper"
[14/Feb/2024:08:04:37.169182709 +] conn=81003 op=23 RESULT err=32 tag=120 
nentries=0 wtime=0.001993588 optime=0.000164749 etime=0.002157265

In your case I see this on the client side:

(2024-02-13 13:26:55): [be[ipa.subdomain.contoso.com]] 
[ipa_s2n_get_acct_info_send] (0x0400): [RID#150] Sending request_type: 
[REQ_FULL_WITH_MEMBERS] for trust user [heidi-ad] to IPA server
(2024-02-13 13:26:55): [be[ipa.subdomain.contoso.com]] [ipa_s2n_exop_send] 
(0x0400): [RID#150] Executing extended operation
(2024-02-13 13:26:55): [be[ipa.subdomain.contoso.com]] [ipa_s2n_exop_send] 
(0x2000): [RID#150] ldap_extended_operation sent, msgid = 5
(2024-02-13 13:26:55): [be[ipa.subdomain.contoso.com]] [sdap_op_add] (0x2000): 
[RID#150] New operation 5 timeout 10
(2024-02-13 13:27:05): [be[ipa.subdomain.contoso.com]] [sdap_op_timeout] 
(0x1000): [RID#150] Issuing timeout [ldap_opt_timeout] for message id 5
(2024-02-13 13:27:05): [be[ipa.subdomain.contoso.com]] [sdap_call_op_callback] 
(0x3f7c0): [RID#150] LDAP operation [5][server: [172.16.50.102:389] IPA EXOP] 
seems slow, took more than 80% of timeout [10].
(2024-02-13 13:27:05): [be[ipa.subdomain.contoso.com]] [sdap_op_destructor] 
(0x1000): [RID#150] Abandoning operation 5
(2024-02-13 13:27:05): [be[ipa.subdomain.contoso.com]] [ipa_s2n_get_user_done] 
(0x0040): [RID#150] s2n exop request failed.

It is still failing as server side processing takes longer than the
client side timeout (10 seconds). However, server side logs don't have
any corresponding communication at about this time and SSSD domain logs
cut short at 13:27:01. The closest request for 'heidi-ad' account came
at 13:09:20:

$ grep 'Got request for' sssd_ipa.subdomain.contoso.com.log
(2024-02-13 13:09:20): [be[ipa.subdomain.contoso.com]] 
[dp_get_account_info_send] (0x0200): Got request for 
[0x1][BE_REQ_USER][name=heidi...@ad.contoso.com]
(2024-02-13 13:09:20): [be[ipa.subdomain.contoso.com]] 
[dp_get_account_info_send] (0x0200): Got request for 
[0x3][BE_REQ_INITGROUPS][name=heidi...@ad.contoso.com]
(2024-02-13 13:09:21): [be[ipa.subdomain.contoso.com]] 
[dp_get_account_info_send] (0x0200): Got request for 
[0x2][BE_REQ_GROUP][idnumber=603892026]
(2024-02-13 13:09:21): [be[ipa.subdomain.contoso.com]] 
[dp_get_account_info_send] (0x0200): Got request for 
[0x2][BE_REQ_GROUP][idnumber=602655731]
(2024-02-13 13:09:21): [be[ipa.subdomain.contoso.com]] 
[dp_get_account_info_send] (0x0200): Got request for 
[0x2][BE_REQ_GROUP][idnumber=604961401]
(2024-02-13 13:09:22): [be[ipa.subdomain.contoso.com]] 
[dp_get_account_info_send] (0x0200): Got request for 
[0x2][BE_REQ_GROUP][idnumber=602655735]
(2024-02-13 13:09:25): [be[ipa.subdomain.contoso.com]] 
[dp_get_account_info_send] (0x0200): Got request for 
[0x2][BE_REQ_GROUP][idnumber=604859746]
(2024-02-13 13:09:32): [be[ipa.subdomain.contoso.com]] 
[dp_get_account_info_send] (0x0200): Got request for 
[0x2][BE_REQ_GROUP][idnumber=604965529]
(2024-02-13 13:10:50): [be[ipa.subdomain.contoso.com]] 
[dp_get_account_info_send] (0x0200): Got request for 
[0x3][BE_REQ_INITGROUPS][name=a...@ad.contoso.com]
(2024-02-13 13:10:50): [be[ipa.subdomain.contoso.com]] 
[dp_get_account_info_send] (0x0200): Got request for 
[0x3][BE_REQ_INITGROUPS][name=a...@ipa.subdomain.contoso.com]
(2024-02-13 13:10:50): [be[ipa.subdomain.contoso.com]] 
[dp_get_account_info_send] (0x0200): Got request 

[Freeipa-users] Re: SSSD offline and AD authentication issues

[Alexander Bokovoy via FreeIPA-users]

On Пан, 12 лют 2024, Heidi Hough via FreeIPA-users wrote:

I appreciate the feedback.  I added the ldap_search_timeout to both the server 
and client sssd.conf files.  I experimented with different values with no 
additional success.  Please find sanitized client and server sssd logs from my 
login attempt with ldap_search_timeout = 30.

Client
https://privatebin.net/?8b3b376c2cf445ac#DwWqNUD96mcHqBYoNi7u97n9ZZ6ZNYeVDTrut6W91aK6
Server
https://privatebin.net/?f8a35b7c92fae546#DT3sHCD9kY7h3UZrRSBX8VbBkmccRCVkgguaX3NG6bDG


Hi,

it looks like you have restarted the server during the time when a
client request was issued. As a result, not only the server logs contain
no request information, it was not really served and thus failed:

from client side:
(2024-02-12  8:48:40): [be[ipa.subdomain.contoso.com]] 
[dp_get_account_info_send] (0x0200): Got request for 
[0x1][BE_REQ_USER][name=ad-he...@ad.contoso.com]
(2024-02-12  8:48:40): [be[ipa.subdomain.contoso.com]] [dp_attach_req] 
(0x0400): [RID#2] DP Request [Account #2]: REQ_TRACE: New request. Flags 
[0x0001].
(2024-02-12  8:48:40): [be[ipa.subdomain.contoso.com]] [dp_attach_req] 
(0x0400): [RID#2] Number of active DP request: 1
(2024-02-12  8:48:40): [be[ipa.subdomain.contoso.com]] [sss_domain_get_state] 
(0x1000): [RID#2] Domain ipa.subdomain.contoso.com is Active
(2024-02-12  8:48:40): [be[ipa.subdomain.contoso.com]] [sss_domain_get_state] 
(0x1000): [RID#2] Domain ad.contoso.com is Active
(2024-02-12  8:48:40): [be[ipa.subdomain.contoso.com]] [sss_domain_get_state] 
(0x1000): [RID#2] Domain ipa.subdomain.contoso.com is Active
(2024-02-12  8:48:40): [be[ipa.subdomain.contoso.com]] [sss_domain_get_state] 
(0x1000): [RID#2] Domain ad.contoso.com is Active
(2024-02-12  8:48:40): [be[ipa.subdomain.contoso.com]] [sdap_print_server] 
(0x2000): [RID#2] Searching 172.16.50.102:389
(2024-02-12  8:48:40): [be[ipa.subdomain.contoso.com]] [sdap_get_generic_ext_step] 
(0x0400): [RID#2] calling ldap_search_ext with 
[(&(objectClass=ipaUserOverride)(uid=ad-heidi))][cn=Default Trust 
View,cn=views,cn=accounts,dc=ipa,dc
=subdomain,dc=contoso,dc=com].
(2024-02-12  8:48:40): [be[ipa.subdomain.contoso.com]] 
[sdap_get_generic_ext_step] (0x2000): [RID#2] ldap_search_ext called, msgid = 14
(2024-02-12  8:48:40): [be[ipa.subdomain.contoso.com]] [sdap_op_add] (0x2000): 
[RID#2] New operation 14 timeout 30
(2024-02-12  8:48:40): [be[ipa.subdomain.contoso.com]] [sdap_process_result] 
(0x2000): Trace: sh[0x55c25d103380], connected[1], ops[0x55c25d17e390], 
ldap[0x55c25d1006b0]
(2024-02-12  8:48:40): [be[ipa.subdomain.contoso.com]] 
[sdap_get_generic_op_finished] (0x0400): [RID#2] Search result: Success(0), no 
errmsg set
(2024-02-12  8:48:40): [be[ipa.subdomain.contoso.com]] [sdap_op_destructor] 
(0x2000): [RID#2] Operation 14 finished
(2024-02-12  8:48:40): [be[ipa.subdomain.contoso.com]] [sss_domain_get_state] 
(0x1000): [RID#2] Domain ipa.subdomain.contoso.com is Active
(2024-02-12  8:48:40): [be[ipa.subdomain.contoso.com]] [sss_domain_get_state] 
(0x1000): [RID#2] Domain ad.contoso.com is Active
(2024-02-12  8:48:40): [be[ipa.subdomain.contoso.com]] 
[ipa_s2n_get_acct_info_send] (0x0400): [RID#2] Sending request_type: 
[REQ_FULL_WITH_MEMBERS] for trust user [ad-heidi] to IPA server
(2024-02-12  8:48:40): [be[ipa.subdomain.contoso.com]] [ipa_s2n_exop_send] 
(0x0400): [RID#2] Executing extended operation
(2024-02-12  8:48:40): [be[ipa.subdomain.contoso.com]] [ipa_s2n_exop_send] 
(0x2000): [RID#2] ldap_extended_operation sent, msgid = 15
(2024-02-12  8:48:40): [be[ipa.subdomain.contoso.com]] [sdap_op_add] (0x2000): 
[RID#2] New operation 15 timeout 30
(2024-02-12  8:48:40): [be[ipa.subdomain.contoso.com]] [sdap_process_result] 
(0x2000): Trace: sh[0x55c25d103380], connected[1], ops[0x55c25d17e390], 
ldap[0x55c25d1006b0]
(2024-02-12  8:48:40): [be[ipa.subdomain.contoso.com]] [sdap_process_result] 
(0x2000): Trace: end of ldap_result list
(2024-02-12  8:49:03): [be[ipa.subdomain.contoso.com]] [sdap_process_result] 
(0x2000): Trace: sh[0x55c25d103380], connected[1], ops[0x55c25d17e390], 
ldap[0x55c25d1006b0]
(2024-02-12  8:49:03): [be[ipa.subdomain.contoso.com]] [ipa_s2n_exop_done] 
(0x0040): [RID#2] ldap_extended_operation result: Time limit exceeded(3), 
(null).

The request is sent at 8:48:40. Assuming the time is the same, the
server side did not start at that point yet:

(2024-02-12  8:48:24): [be[ipa.subdomain.consoto.com]] [be_ptask_execute] 
(0x0400): Task [Cleanup [id] of ad.contoso.com]: executing task, timeout 30 
seconds
(2024-02-12  8:48:24): [be[ipa.subdomain.consoto.com]] [sysdb_cache_search_users] 
(0x2000): Search users with filter: 
(&(objectCategory=user)(&(!(dataExpireTimestamp=0))(dataExpireTimestamp<=1707756504)(!(lastLogin=*
(2024-02-12  8:48:44): [be[ipa.subdomain.consoto.com]] [server_setup] 
(0x3f7c0): Starting with debug level = 0x3ff0
(2024-02-12  8:48:44): [be[ipa.subdomain.consoto.com]] [server_setup] (0x0400): 
CONFDB: /var/lib/sss/db/config.ldb

[Freeipa-users] Re: Create IPA user via LDAP

[Alexander Bokovoy via FreeIPA-users]

On Пан, 12 лют 2024, Ronald Wimmer via FreeIPA-users wrote:

On 12.02.24 15:54, Ronald Wimmer via FreeIPA-users wrote:

On 12.02.24 14:15, Christian Heimes via FreeIPA-users wrote:

On 12/02/2024 13.32, Ronald Wimmer via FreeIPA-users wrote:

On 12.02.24 13:23, Christian Heimes via FreeIPA-users wrote:

On 12/02/2024 12.47, Ronald Wimmer via FreeIPA-users wrote:

On 12.02.24 12:38, Christian via FreeIPA-users wrote:

On 11/02/2024 22.40, Ronald Wimmer via FreeIPA-users wrote:
Remark: If I set a new password for this particular 
user after the user has been activated, it works.


We are still facing this particular problem and do not 
have any clue why the initial password set by the 
external system does not work. Any ideas/hints here?

Two ideas:

Are you supplying pre-hashed passwords in the correct 
format? 389-DS expects hashed passwords in a specific 
format, e.g. "{PBKDF2-SHA512}10$base64data" for PKBDF2 
with SHA-512 and 100,000 iterations.


IPA cannot create Kerberos keys from a pre-hashed 
passwords. Kerberos does not work until the user's 
Kerberos key is generated from a plain password, e.g. with 
a password change at https://yourserver/ipa/migration/. 
SSSD can also detect the case and generate Kerberos keys.


When you log into LDAP as "cn=Directory Manager", then you 
can read and check the "userPassword" and 
"krbPrincipalKey" entries.


Christian


We are providing plaintext passwords. When the user is 
initially created in the staging area the password does not 
seem to work. When the user is activated and thus moved to 
the right place in the LDAP tree we can set a different 
password that works immediately.


In both cases an LDAP browser reveals that the password gets 
hashed immediately by 389DS. (PBKDF2_SHA256)


This works for me:
$ ipa stageuser-add --setattr 'userpassword=MyPass1234' 
--first test --last user testuser


This creates a staging user, sets their password to 
"MyPass1234", and marks the password as expired. IPA always 
marks passwords as expired when they are touched by a 
different user. They are ways to work around the limitation 
(passSyncManagersDNs / PassSync Service)


$ ipa stageuser-activate testuser

Now "testuser" can ssh into the machine and is forced the 
reset their password.


By the way, you do not need migration mode if you are 
providing cleartext passwords to LDAP.


OK. I see. It might be an expiration issue. But if it was I 
should run into the same issue when modifying a user's password 
(over LDAP) later on.


Maybe Flo, Rob or Alexander could clarify what to expect in 
which scenario and how to disable immediate expiration if 
necessary?


The password expiration is controlled by ipa_pwd_extop plugin. To 
disable password expiration, add the user DN of your service 
account to the "passSyncManagersDNs" attribute of 
cn=ipa_pwd_extop,cn=plugins,cn=config. You have to apply the 
setting to all your servers manually.


I found out that the password is working perfectly fine when ssh-ing 
to an IPA machine. Also su works. But trying to logon to the WebUI 
does not. I do get "The password or username you entered is 
incorrect". Might be related to the fact that the user does not have 
any kerberos specific LDAP attributes(apart from krbCanonicalName 
and krbPrincipalName) after initial creation from the external 
system.


As the password is set in plaintext from the external system there 
should be a possibility for IPA to generate Kerberos keys etc. What 
could I try?


It looks like IPA generates missing attributes after some time. When I 
tried to login to the WebUI just seconds ago it worked. Can the 
generation of missing attributes be triggered manually?


It is triggered as you move the user from staging. The operation is
asynchronous so might take place shortly after the move. There is no
specific way to control it, sorry.

--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Re: reliability of external radius

[Alexander Bokovoy via FreeIPA-users]

On Пан, 12 лют 2024, Charles Hedrick via FreeIPA-users wrote:

Currently our department uses passwords in IPA, with a few users using
OTP. I'm considering using a University radius server for most users.
Are there reliability implications? My concern is what happens if the
radius server is slow to respond or even is down. I'd like users with
accounts in IPA to still work, and I'd hope things would survive
conditions of slow response.


There is one potential issue that we fixed recently in MIT Kerberos:
https://github.com/krb5/krb5/pull/1318

It is not yet part of any release. If you have RHEL subscription, making
it known to RHEL support organization might help to get this fix out
faster.




--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Re: idrange problem

[Alexander Bokovoy via FreeIPA-users]

On Пят, 02 лют 2024, Tomasz Torcz via FreeIPA-users wrote:

On Fri, Feb 02, 2024 at 12:11:58AM +0200, Alexander Bokovoy via FreeIPA-users 
wrote:

On Чцв, 01 лют 2024, Steve Berg via FreeIPA-users wrote:
> Is there anyway to just delete all these SID requirements?  My ipa
> domain doesn't have a trust to anything windows and there's no plan to
> ever set that up.

No.

S4U protocol extensions for Kerberos are requiring PAC buffers presence
as per the MS-SFU spec. The changes came in in 2021 as a part of the
fixes to 'dollar sign attack'. You can get a partial view of that with
https://wiki.samba.org/index.php/Security/Dollar_Ticket_Attack or
several talks we gave over past few years at various conferences. Most
notable:
  - Andrew Bartlett, "sambaXP 2022: The Inside Story on the Dollar Ticket 
Attack"
https://www.youtube.com/watch?v=1BnraIAcybg

  - Andreas Schneider, Alexander Bokovoy, "sambaXP 2023: Samba AD / MIT
Kerberos: path out of experimental"
https://www.youtube.com/watch?v=0_cdYuIYw0o



 Those attacks are against MS Windows (and Samba?)
I would say they're not relevant to majority of FreeIPA deployments,
which have nothing to do with Windows.


You are wrong here. It is a common problem since majority of users do not
understand Kerberos protocol extensions and their use by FreeIPA or
other domain services like Samba AD or Active Directory.

Since its inception, FreeIPA has depended on S4U extensions to Kerberos
to allow IPA services operate on behalf of users. This is used by IPA
API, for example, to allow IPA management framework to talk to LDAP on
behalf of the user and LDAP server to recognize that this connection is
authenticated as the user, not IPA management framework account.

This extension was developed by Microsoft for Active Directory to allow
domain member machines to operate on behalf of the user when mounting
home directories (shares) or allowing web servers to ask for other
resources (file shares or SQL server connections) on behalf of the user.

All these technical elements are part of a constrained delegation
feature that both Active Directory implementations and FreeIPA are using
internally. You can read about constrained delegation forms in more
details in [1].

There are several different attacks that were developed against S4U
extensions and they are protocol level attacks.

A Kerberos ticket received by the service through S4U2Self extension is
supposed to be non-forwardable but 'forwardable' bit is placed in the
area which is under control of the service asking for the ticket.
Hence, a rogue service can flip the 'forwardable' bit and KDC will not
be able to tell the difference: the area is checksummed with a key based
on the service's key. It was supposed to be a protocol extension that
only allowed issuing tickets to itself and not allowing to use it
elsewhere. It is not anymore: this bit flip allows to use a ticket
printed by the rogue service against any other allowed service in the
environment using the second part of S4U extensions, S4U2Proxy. The
latter is the extension used by IPA as the core one for IPA API
operations.

To prevent this attack, a protocol change was added to introduce
additional checksums which aren't under control of the rogue service.
There are actually two separate checksums: one them was found to be
possible to attack via pre-imaging operation against the hash algorithm,
so another one was added to close the problem down.
 
The only way to prevent these attacks on the checksums and Kerberos

ticket properties was by introducing additional details in the tickets
that cannot be controlled by the attackers. This is done via a set of
extensions that handle authorization data (AD) information in the
Kerberos tickets. MS-PAC describes one of AD buffer types and PAC
records are required for S4U operations. Use of S4U operations since
2020 requires several types of PAC records, all protected from
modifications.

On top of that, use of Kerberos tickets without PAC information opens an
easy attack vector to POSIX environments. PAC allows KDC to place
identity details into Kerberos tickets so that Kerberos services can
corelate Kerberos principal with the information they know about
identity of this principal in their environment. Since SSSD and Samba
(winbindd) do explicit SID to POSIX user/group name translation,
information from PAC records can be used to identify not just the
Kerberos principal to POSIX account/group mapping but also to figure out
whether this principal is of right shape (e.g. it is a valid user rather
than a service or a machine account). This prevents mistyping attacks
like mapping a machine account 'root$' to 'root' POSIX user.

People in both white hat and black hat communities weren't really
attacking FreeIPA through these issues because most of the tools they
use lack features required by the Kerberos implementation in FreeIPA.
For example, FreeIPA defaults to newer Kerberos encrypt

[Freeipa-users] Re: Requiring OTP thru PAM+LDAP

[Alexander Bokovoy via FreeIPA-users]

On Пан, 12 лют 2024, G H via FreeIPA-users wrote:

I am using SSSD in LDAP-only mode (no kerberos at all), communicating
with FreeIPA. For certain hosts, I want to require sssd to demand OTP.

Right now, they are allowing password OR password+OTP. But my 'ipa
show-host' output for the hosts in question have "Authentication
Indicators: otp". What do I need to do for sssd to only accept
password+OTP ?


Authentication indicators are Kerberos-only.

The way to enforce OTP use by the LDAP client during bind is by adding a
control OTP_REQUIRED_OID (2.16.840.1.113730.3.8.10.7) during LDAP SASL
bind like how ipa-otpd daemon does:

LDAPControl control = { OTP_REQUIRED_OID, {}, true };
LDAPControl *ctrls[] = { , NULL };

...

cred.bv_val = data->data;
cred.bv_len = data->length;
i = ldap_sasl_bind(verto_get_private(ev), item->user.dn, LDAP_SASL_SIMPLE,
   , ctrls, NULL, >msgid);

I don't think it is possible to do so by SSSD as it is.

I have a proposal https://github.com/freeipa/freeipa/pull/7200 that
enforces OTP over *all* LDAP binds server-side, by effectively assuming
this OID is present always in any client LDAP bind.

--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Re: SSSD offline and AD authentication issues

[Alexander Bokovoy via FreeIPA-users]

On Пят, 09 лют 2024, Heidi Hough via FreeIPA-users wrote:

Hello,

I'm unable to ssh as an AD user to a freeipa client.  I am, however
able to ssh as an AD user to a freeipa server.  I can also ssh to a
freeipa client AND server using a FreeIPA account.  Our IPA domain
(ipa.subdomain.contoso.com) is set up with a one-way trust with
ad.contoso.com.  Our AD is on the larger side with 400,000+ user
accounts.

An ldbsearch on the client cache file returns 42 records, the same
search on the server cache returns 113551 records.  Searching for a
specific user; ldbsearch -H
/var/lib/sss/db/cache_ipa.subdomain.contoso.com.ldb
'(name=heidi...@ad.contoso.com)' returns zero records on the freeipa
client and 1 record on the freeipa server.

Dig commands (dig -t SRV _ldap._tcp.ipa.subdomain.contoso.com and dig
-t SRV _ldap._tcp.ad.contoso.com) also return expected results.

server:sssd.conf
https://privatebin.net/?42cff7bd431068d7#FmeM5p3R88U9oQd98UvoaVHZ3PzeZTGvS5VHxvGtorf

client:sssd.conf
https://privatebin.net/?d4f20faca95236f4#D8WtjwDMaAB932W66YMgW5HtXkdfez1Ht1vzWa9FwnR

I'm not sure what to key in on in the SSSD logs to identify what's
going wrong here and how to resolve it. I've attempted to fiddle with
multiple timeout settings, but haven't identified the right ones.  I do
see SSSD is reported as offline and this very much feels like a
communication issue.  I have uploaded sanitized SSSD logs from
rl9-ipa-client1.in.subdomain.contoso.com and
freeipa2.ipa.subdomain.contoso.com for a failed login attempt at the
following:
https://privatebin.net/?1028b6754421174b#DDDuthsRbLjxt4rS1mr263MmJ2qjhLgLHpyYZJYxLUXC


Thanks for the logs. Can you say where the logs from the IPA server
start from? It would be best if you could provide tarballs of
/var/log/sssd from both the client and the server at the same time
period. With this pastebin it is impossible to differentiate logs from
the client from the logs of the server.

(2024-02-09 11:35:00): [be[ipa.subdomain.contoso.com]] 
[ipa_s2n_get_acct_info_send] (0x0400): [RID#2] Sending request_type: 
[REQ_FULL_WITH_MEMBERS] for trust user [heidi-ad] to IPA server
(2024-02-09 11:35:00): [be[ipa.subdomain.contoso.com]] [ipa_s2n_exop_send] 
(0x0400): [RID#2] Executing extended operation
(2024-02-09 11:35:00): [be[ipa.subdomain.contoso.com]] [ipa_s2n_exop_send] 
(0x2000): [RID#2] ldap_extended_operation sent, msgid = 15
(2024-02-09 11:35:00): [be[ipa.subdomain.contoso.com]] [sdap_op_add] (0x2000): 
[RID#2] New operation 15 timeout 6
(2024-02-09 11:35:00): [be[ipa.subdomain.contoso.com]] [sdap_process_result] 
(0x2000): Trace: sh[0x5591a0d6cde0], connected[1], ops[0x5591a0d7ae80], 
ldap[0x5591a0d721f0]
(2024-02-09 11:35:00): [be[ipa.subdomain.contoso.com]] [sdap_process_result] 
(0x2000): Trace: end of ldap_result list
(2024-02-09 11:35:06): [be[ipa.subdomain.contoso.com]] [sdap_op_timeout] 
(0x1000): [RID#2] Issuing timeout [ldap_opt_timeout] for message id 15
(2024-02-09 11:35:06): [be[ipa.subdomain.contoso.com]] [sdap_call_op_callback] 
(0x3f7c0): [RID#2] LDAP operation [15][server: [172.16.50.102:389] IPA EXOP] 
seems slow, took more than 80% of timeout [6].
(2024-02-09 11:35:06): [be[ipa.subdomain.contoso.com]] [sdap_op_destructor] 
(0x1000): [RID#2] Abandoning operation 15
(2024-02-09 11:35:06): [be[ipa.subdomain.contoso.com]] [ipa_s2n_get_user_done] 
(0x0040): [RID#2] s2n exop request failed.

This says that a client has asked the server to resolve AD user but this
operation took longer than expected timeout of 6 seconds and the client
abandoned the request. You need to get logs from the IPA server at the
same timeframe and see why it failed to complete in time.


ldap_search_timout is by default 6 seconds and you have no modification
of that so this matches client abandoning a search.



Thanks,
Heidi
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue




--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Re: Cannot create users on platform migration: sambaSID failure

[Alexander Bokovoy via FreeIPA-users]

On Пан, 05 лют 2024, Melissa Ferreira da Silva Boiko wrote:

Thanks for the suggestions so far!

I'm documenting this on this thread because I found out why the previous
system had the custom sambaSamAccount attributes: They seem to be necessary
to authenticate SMB shares when FreeIPA is the LDAP backend to a Synology
NAS.  If I try to set LDAP authentication now, I get this error on Synology
DSM:


Issue Details: The LDAP server does not support Samba schema.
...
Recommended action: Enable CIFS plain text password authentication.  [and

if you do], this DSM cannot be the remote mount target of CIFS.

Some past threads on freeipa-users (mostly for TrueNAS) suggest that the
Samba schema attributes are deprecated in favour of something using
Kerberos, but I do not get that option in Synology at all.

I believe the previous sysadmins of our shop must have followed this guide
by Markus Opolka, or a similar HOWTO:
https://blog.cubieserver.de/2018/synology-nas-samba-nfs-and-kerberos-with-freeipa-ldap/


Sadly, this blog is making a lot of wrong suggestions. A particularly
bad one is about a structure of sambaSID value as SIDs have very
specific structure and breaking that would actually break Samba as well.
S-1-5-21- is a prefix for domain SIDs. This means that values after
S-1-5-21- prefix would need to be the domain SID triplet and a relative
identifier, RID:

   S-1-5-21-d1-d2-d3-RID.

Samba expects this.

Another part is that you don't really need that all if you are running
SSSD. In such case you can use idmap_sss module to supply user/groups to
Samba together with SIDs directly:
https://freeipa.readthedocs.io/en/latest/designs/adtrust/samba-domain-member.html

The whole configuration is handled by ipa-client-samba tool on IPA
client (part of freeipa-client-samba package in Fedora).

Sadly, TrueNAS folks also didn't go this way and instead added LDAP
mapping support in their recent beta1 release. This also will not give
you proper SIDs exposed as Samba's pdb_ldap driver does not have ability
to change LDAP attribute mapping and hardcodes the sambaSID/etc
attribute names, making it not compatible with FreeIPA schema.

You'd end up making separate set of FreeIPA-native and Samba-expected
attributes this way. It is a management nightmare because you certainly
want to stick to IPA-generated SIDs as they will be part of the Kerberos
tickets issued by IPA KDC and will be properly accepted by Samba. Using
ipa-client-samba tool and its configuration is best as it seamlessly
connects both Samba and FreeIPA. But both Synology and TrueNAS ignore
it, unfortunately.



That would explain why I couldn't create users with the Web interface in my
new FreeIPA (4.11) instance; this guide necessitates manual setting of the
Samba attributes via command-line `ipa user-add` flags.

However, it is then a mystery to me why user account creation worked via
Web interface in the old (4.5) instance.


It worked due to you adding those attributes and object classes into the
list of user attributes/object classes in IPA configuration.


I'm not sure how to proceed here since CIFS mounting is one of our users'
primary uses of LDAP in the first place.  Maybe I'll recreate the Samba
attributes after all, try to restore the previous values from backups, and
document properly how to create users with the command-line options.


For a normal IPA-enrolled client Samba integration is trivial:

 - install freeipa-client-samba (ipa-client-samba in RHEL)
 - run ipa-client-samba tool
 - check generated /etc/samba/smb.conf, adjust
 - enable smb and winbind systemd services and activate them
 - done.




[]s

Am Mo., 29. Jan. 2024 um 14:52 Uhr schrieb Alexander Bokovoy <
aboko...@redhat.com>:


On Пан, 29 сту 2024, Melissa Ferreira da Silva Boiko via FreeIPA-users
wrote:
>Seems like it has "ipaUserObjectClasses: sambasamaccount" which I see
>mentioned in very old threads about Samba support only.  Here's the
>full config:

Thanks. You can remove sambaSamAccount by running

$ ipa config-mod --delattr=ipaUserObjectClasses=sambaSamAccount

Same applies to shadowAccount which we don't use by default either.

>
>```
>  dn: cn=ipaConfig,cn=etc,dc=example,dc=local
>  ipamaxusernamelength: 32
>  ipahomesrootdir: /home
>  ipadefaultloginshell: /bin/bash
>  ipadefaultprimarygroup: ipausers
>  ipadefaultemaildomain: example.com
>  ipasearchtimelimit: 2
>  ipasearchrecordslimit: 100
>  ipausersearchfields: uid,givenname,sn,telephonenumber,ou,title
>  ipagroupsearchfields: cn,description
>  ipamigrationenabled: FALSE
>  ipacertificatesubjectbase: O=EXAMPLE.LOCAL
>  ipapwdexpadvnotify: 4
>  ipaconfigstring: AllowNThash
>  ipaconfigstring: KDC:Disable Last Success
>  ipaselinuxusermaporder:
guest_u:s0$xguest_u:s0$user_u:s0$staff_u:s0-s0:c0.c1023$unconfined_u:s0-s0:c0.c1023
>  ipaselinuxusermapdefault: unconfined_u:s0-s0:c0.c1023
>  ipakrbauthzdata: MS-PAC
>  ipakrbauthzdata: nfs:NONE
>  ipauserauthtype: disabled
>  ipauserauthtype: password
>  cn: ipaConfig
>  

[Freeipa-users] Re: idrange problem

[Alexander Bokovoy via FreeIPA-users]

On Чцв, 01 лют 2024, Steve Berg via FreeIPA-users wrote:
Is there anyway to just delete all these SID requirements?  My ipa 
domain doesn't have a trust to anything windows and there's no plan to 
ever set that up.


No.

S4U protocol extensions for Kerberos are requiring PAC buffers presence
as per the MS-SFU spec. The changes came in in 2021 as a part of the
fixes to 'dollar sign attack'. You can get a partial view of that with
https://wiki.samba.org/index.php/Security/Dollar_Ticket_Attack or
several talks we gave over past few years at various conferences. Most
notable:
  - Andrew Bartlett, "sambaXP 2022: The Inside Story on the Dollar Ticket 
Attack"
https://www.youtube.com/watch?v=1BnraIAcybg

  - Andreas Schneider, Alexander Bokovoy, "sambaXP 2023: Samba AD / MIT
Kerberos: path out of experimental"
https://www.youtube.com/watch?v=0_cdYuIYw0o

As such, you may be able to disable PAC generation to individual service
principals with 'ipa service-mod --pac-type NONE service_principal' but
if these principals would be using S4U protocol extensions (S4U2Self or
S4U2Proxy), this cannot be done because these extensions require use of
PAC structure and PAC structure requires SIDs. Specifically, FreeIPA API
and Web UI rely on S4U extensions internally.

This is not a theoretical issue in IPA environment. There is working
exploit that can be used to break through when SIDs aren't enforced in
pure Kerberos environment. We fixed it in upstream MIT Kerberos and
FreeIPA some time ago but the change required ABI break which we cannot
allow in RHEL 8 due to details of Kerberos libraries support level. We
had to find a different way.

For deployments using RHEL 8 since RHEL 8.5 SIDs generated by default.
For deployments upgraded to new version, an update needs to be done by
administrators but that requires changes specific to each deployment.
Red Hat support folks wrote two articles which help with the upgrade
process.

https://access.redhat.com/articles/7027037 explains how POSIX ID ranges
and SID information is connected together.

https://access.redhat.com/solutions/7052703 explains how to adjust IPA
deployment to upgrade to enable SIDs.

Both articles available to RHEL subscribers, including users of the free
developer subscription, https://developers.redhat.com/




Been trying to add the RID and it fails but doesn't tell me why it failed.


Can you share what you have tried?




On 2/1/24 11:43, Florence Blanc-Renaud via FreeIPA-users wrote:

Hi,


On Thu, Feb 1, 2024 at 12:51 PM Steve Berg via FreeIPA-users 
 wrote:


   Still not working.  I do not have any trust set up with any active
   directory currently, we have a AD running on the network but that
   and my
   ipa domain don't trust each other in any way.

   Got two idranges setup:
   ---
      Range name: domain_id_range
      First Posix ID of the range: 82440
      Number of IDs in the range: 20
      First RID of the corresponding RID range: 1000
      First RID of the secondary RID range: 1
      Range type: local domain range

      Range name: EDIPIs_id_range
      First Posix ID of the range: 1009210100
      Number of IDs in the range: 619332697
      Range type: local domain range
   ---

The above range is missing RID base and secondary rid base.
You can refer to this KCS: 
https://access.redhat.com/solutions/7052703especially section *3. 
**Fixing ID range issues*. You will have to add ipabaseridand 
ipasecondarybaseridto the range.
RID Values from 1,000-200,999and 100,000,000-100,199,999are already 
taken by the id range domain_id_range, you can pick any values not 
overlapping.

flo



--
//-Fixer of that which is broke-//
//-Home =sb...@mississippi.com -//
//- Sinners can repent, but stupid is forever. -//





--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Re: Cannot create users on platform migration: sambaSID failure

[Alexander Bokovoy via FreeIPA-users]

On Пан, 29 сту 2024, Melissa Ferreira da Silva Boiko via FreeIPA-users wrote:

Seems like it has "ipaUserObjectClasses: sambasamaccount" which I see
mentioned in very old threads about Samba support only.  Here's the
full config:


Thanks. You can remove sambaSamAccount by running

$ ipa config-mod --delattr=ipaUserObjectClasses=sambaSamAccount

Same applies to shadowAccount which we don't use by default either.



```
 dn: cn=ipaConfig,cn=etc,dc=example,dc=local
 ipamaxusernamelength: 32
 ipahomesrootdir: /home
 ipadefaultloginshell: /bin/bash
 ipadefaultprimarygroup: ipausers
 ipadefaultemaildomain: example.com
 ipasearchtimelimit: 2
 ipasearchrecordslimit: 100
 ipausersearchfields: uid,givenname,sn,telephonenumber,ou,title
 ipagroupsearchfields: cn,description
 ipamigrationenabled: FALSE
 ipacertificatesubjectbase: O=EXAMPLE.LOCAL
 ipapwdexpadvnotify: 4
 ipaconfigstring: AllowNThash
 ipaconfigstring: KDC:Disable Last Success
 ipaselinuxusermaporder: 
guest_u:s0$xguest_u:s0$user_u:s0$staff_u:s0-s0:c0.c1023$unconfined_u:s0-s0:c0.c1023
 ipaselinuxusermapdefault: unconfined_u:s0-s0:c0.c1023
 ipakrbauthzdata: MS-PAC
 ipakrbauthzdata: nfs:NONE
 ipauserauthtype: disabled
 ipauserauthtype: password
 cn: ipaConfig
 ipaGroupObjectClasses: top
 ipaGroupObjectClasses: groupofnames
 ipaGroupObjectClasses: nestedgroup
 ipaGroupObjectClasses: ipausergroup
 ipaGroupObjectClasses: ipaobject
 ipaMaxHostnameLength: 64
 ipaUserObjectClasses: top
 ipaUserObjectClasses: person
 ipaUserObjectClasses: organizationalperson
 ipaUserObjectClasses: inetorgperson
 ipaUserObjectClasses: inetuser
 ipaUserObjectClasses: posixaccount
 ipaUserObjectClasses: krbprincipalaux
 ipaUserObjectClasses: krbticketpolicyaux
 ipaUserObjectClasses: ipaobject
 ipaUserObjectClasses: ipasshuser
 ipaUserObjectClasses: sambasamaccount
 ipaUserObjectClasses: shadowAccount
 objectClass: nsContainer
 objectClass: top
 objectClass: ipaGuiConfig
 objectClass: ipaConfigObject
 objectClass: ipaUserAuthTypeClass
 objectClass: ipaNameResolutionData
```

Thanks!
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue




--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Re: Cannot create users on platform migration: sambaSID failure

[Alexander Bokovoy via FreeIPA-users]

On Пан, 29 сту 2024, Melissa Ferreira da Silva Boiko via FreeIPA-users wrote:

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.


Looks like your old deployment had been using custom object classes and
attributes. FreeIPA does not use sambaSID and sambaSamAccount at all.
These attributes and object classes are part of IPA setup but they
aren't used.

FreeIPA uses different set of attributes/object classes for storing
SID-related information for more than a decade. That information is now
mandatory to prevent a number of impersonation attacks that could be
possible in a Kerberized environment without MS-PAC structures in
Kerberos tickets.

Since 'sambaSID' is not used by IPA, it is probably something that your
deployment has been using to add by default. Can you show output of

$ ipa config-show --all --raw

?

--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Re: Is it possible to install FreeIPA on different disk than ('/')

[Alexander Bokovoy via FreeIPA-users]

On Срд, 24 сту 2024, Ronald Wimmer via FreeIPA-users wrote:

On 24.01.24 15:35, Finn Fysj via FreeIPA-users wrote:

Currently our installation of FreeIPA is done on root ('/').
Is it possible to install FreeIPA on different disk & mount path wihtout 
causing too much issues?


FreeIPA consists of several components (389DS, Apache, Dogtag, Samba, 
DNS, ...). I seriously doubt that it would be a good idea to move all 
of these components to non-standard paths.


Not supported, indeed. Deploying a separate VM (or a container) would be
a better solution.



--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Re: FreeIPA or RHEL IdM with Amazon Cognito

[Alexander Bokovoy via FreeIPA-users]

On Срд, 24 сту 2024, Carlos Lopez via FreeIPA-users wrote:

Hi all,

I need to integrate authentication and role access for a few users
between Amazon Cognito and FreeIPA/IdM. The idea is that the user logs
in with Cognito but the access validation, password changes, roles,
etc. are hosted in FreeIPA. The resources where users login are outside
of Amazon (for example our internal password management app). Is this
possible? Could it be an option to use SAML?


IPA can delegate authentication (actually, authorization as in OAuth2
Device Authorization Grant Flow) to an external IdP provider. Amazon
Cognito does not have support for OAuth2 Device Authorization Grant flow
but one can create a separate flow integrated with Cognito:
https://aws.amazon.com/blogs/security/implement-oauth-2-0-device-grant-flow-by-using-amazon-cognito-and-aws-lambda/

See
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/managing_idm_users_groups_hosts_and_access_control_rules/assembly_using-external-identity-providers-to-authenticate-to-idm_managing-users-groups-hosts
for RHEL IdM documentation.

--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Re: cannot login on FreeIPA web GUI: Your session has expired. Please log in again.

[Alexander Bokovoy via FreeIPA-users]

On Срд, 24 сту 2024, Harald Dunkel wrote:

Hi Alex,

On 2024-01-24 08:13:44, Alexander Bokovoy wrote:

On Аўт, 23 сту 2024, Harald Dunkel wrote:

I found one problem by now: Regular UIDs start with 501 in my environment,
for historical reasons. The GIDs are >=1000. When we migrated from good ol'
yellow pages to FreeIPA there was no problem with small UIDs. And in the
BSD and SYSV years before Linux only the UIDs <100 were reserved for system.

Do I have to migrate the existing users between 501 and 999 to new UIDs

1000? I would like to see an error message showing that this is indeed the

problem, first. Surely I would prefer to just adjust the ID ranges instead
of migrating about 90 user accounts.

What would you suggest?


You can add a new local ID range to cover existing UIDs/GIDs. Make sure
to set base RID and secondary base RID when defining a new ID range.

See https://access.redhat.com/articles/7027037 for details.



ACK. One question, though: Shouldn't the

ipa config-mod --enable-sid --add-sids

I had run set the missing ipantsecurityidentifier entries at least
for the users matching the existing address range from 1000 to 9?
It didn't, AFAICT. It didn't show an error message, either.


Looking at the changes between the previously installed freeipa
packages and the version I have right now I got

# rpm -q --changelog ipa-server
* Fri Dec 01 2023 Julien Rische  - 4.9.12-11
- Generate Kerberos PAC as soon as server installation completed
 Resolves: RHEL-16532

* Thu Nov 16 2023 Julien Rische  - 4.9.12-10
- ipa-kdb: Detect and block Bronze-Bit attacks
 Resolves: RHEL-16532
- Fix for CVE-2023-5455
 Resolves: RHEL-12577

* Wed Oct 04 2023 Julien Rische  - 4.9.12-9
:
:

4.9.12-9 was the previous version. It worked fine. Fixing the CVEs
was the reason for the upgrade. Kerberos authentication is fine in
the new setup, too. How comes these changes triggered the problem
about missing ipantsecurityidentifier entries? Is this as intended?


Yes, it was intended. Bronze-bit (CVE-2020-17049) is about Kerberos
constrained delegation (S4U extensions). S4U Kerberos extensions require
presence of MS-PAC structures in Kerberos tickets and to generate MS-PAC
we have to have SIDs. This was already enforced in MIT Kerberos 1.20+ in
RHEL 9 for quite some time.

New RHEL IdM deployments do have SIDs associated with user/group
accounts since RHEL 8.5. If you have older installations, you might not have 
them.
If you have earlier established trust to Active Directory, your IPA
configuration might already permit generating SIDs for new users since
~2013. Still, some user and group accounts from 'legacy' configurations
might not have them and those will be denied accessing any Kerberos
resources protected with constrained delegation. IPA API is one such
resource.

As discussions on this mailing list show, there are plenty of edge
cases, mostly around 'legacy' UID/GIDs and missing ID ranges that would
have covered those IDs. Or ID ranges missing SID-specific attributes
(base RID and secondary base RID) that prevent use of those ranges to
generate SIDs. 


KCS https://access.redhat.com/articles/7027037 describes a lot of those
details, so I would recommend reading through it and investigating your
ID range configuration based on those details.

We also have upstream document that outlines ID mapping usage in
FreeIPA: https://freeipa.readthedocs.io/en/latest/designs/id-mapping.html


--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Re: Different ID ranges cannot login to samba

[Alexander Bokovoy via FreeIPA-users]

On Срд, 24 сту 2024, Rui Gomes via FreeIPA-users wrote:

Hello Everyone,

We are experiencing a strange error, where we have 2 ID ranges. The default
one always worked well with samba, we have add a second ID range that works
perfectly for everything but no user in that range can login to samba.

All the users in the default ID range can authenticate with samba, but no
user on a lower ID 5000-1 manage to authenticate, no obvious errors in
the logs.

Does this ring any bells, we have tried to force samba ID range made no
difference.


If you are doing it similar to
https://freeipa.readthedocs.io/en/latest/designs/adtrust/samba-domain-member.html,
then your ranges need to be known to Samba through idmap configuration.

The problem here is that for a single domain idmap only supports one ID
range in Samba so you cannot say

idmap config ${netbios_name} : range = ${range1_id_min} - ${range1_id_max}
idmap config ${netbios_name} : range = ${range2_id_min} - ${range2_id_max}
idmap config ${netbios_name} : range = ${range3_id_min} - ${range3_id_max}
idmap config ${netbios_name} : range = ${range4_id_min} - ${range4_id_max}
idmap config ${netbios_name} : backend = sss

You would need to choose a range that covers all those ranges together.


--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Re: api authorization stopped working after upgrade to 4.9.12-11 on RHEL8

[Alexander Bokovoy via FreeIPA-users]

On Аўт, 23 сту 2024, Sören R. via FreeIPA-users wrote:

Thanks Alex, your comment helped me a lot and so I could fix the issue.
I had exactly the same issue.

Problem is, that none of my user hat the attribute
"ipantsecurityidentifier".

I found the instruction here:
https://access.redhat.com/documentation/de-de/red_hat_enterprise_linux/8/html/managing_idm_users_groups_hosts_and_access_control_rules/assembly_strengthening-kerberos-security-with-pac-information_managing-users-groups-hosts#con_privilege-attribute-certificate-pac-use-in-idm_assembly_strengthening-kerberos-security-with-pac-information

Procedure
Enable SID usage and trigger the SIDgen task to generate SIDs for
existing users and groups. This task might be resource-intensive:

# kinit admin
# ipa config-mod --enable-sid --add-sids

Verification
Verify that the IdM admin user account entry has an ipantsecurityidentifier 
attribute with a SID that ends with -500, the SID reserved for the domain 
administrator:

[root@server ~]# ipa user-show admin --all | grep ipantsecurityidentifier
 ipantsecurityidentifier: S-1-5-21-2633809701-976279387-419745629-500

After this procedure, my admin user hat the attribute
"ipantsecurityidentifier" and I could successful login to the WebUI.
The issue I encountered was, that not all of my users had been upgraded
with the new attribute. Therefore I had to delete and recreate them.


Good that it worked for you. You didn't need to delete those
users/groups, just make sure their UID and GID numbers are within ID
ranges defined by IPA. You can add a new ID range to help sidgen plugin
to handle those IDs.

See https://access.redhat.com/articles/7027037 for more details. It
needs a RHEL subscription but you can get a free one from
developers.redhat.com.


--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Re: cannot login on FreeIPA web GUI: Your session has expired. Please log in again.

[Alexander Bokovoy via FreeIPA-users]

On Аўт, 23 сту 2024, Harald Dunkel wrote:

Hi Alex,

On 2024-01-23 14:41:30, Alexander Bokovoy wrote:

One issue we identified today together with Fedora infrastructure team
is that staged users (created with 'ipa stageuser-add') will prevent
sidgen plugin to generate entries.



I didn't even know this command.

[root@ipa0 ~]# ipa stageuser-find
---
0 users matched
---

Number of entries returned 0




Still trying to find the right documentation.


All documentation was mentioned already in these threads. Please see at
https://access.redhat.com/articles/7027037 for more details (needs RHEL
subscription, including a free developer subscription).



Thank you for the link.

I found one problem by now: Regular UIDs start with 501 in my environment,
for historical reasons. The GIDs are >=1000. When we migrated from good ol'
yellow pages to FreeIPA there was no problem with small UIDs. And in the
BSD and SYSV years before Linux only the UIDs <100 were reserved for system.

Do I have to migrate the existing users between 501 and 999 to new UIDs

1000? I would like to see an error message showing that this is indeed the

problem, first. Surely I would prefer to just adjust the ID ranges instead
of migrating about 90 user accounts.

What would you suggest?


You can add a new local ID range to cover existing UIDs/GIDs. Make sure
to set base RID and secondary base RID when defining a new ID range.

See https://access.redhat.com/articles/7027037 for details.

--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Re: Can't login to IPA

[Alexander Bokovoy via FreeIPA-users]

On Аўт, 23 сту 2024, Bogdan Stoica via FreeIPA-users wrote:

After upgrading ipa to the latest version, login to webui is no longer
working

I'm using Rocky Linux 8.9 and these are the IPA installed packages:

[root@ipa02 dnssec]# rpm -qa | grep ipa
ipa-server-4.9.12-11.module+el8.9.0+1652+4ee71f6a.x86_64
ipa-server-common-4.9.12-11.module+el8.9.0+1652+4ee71f6a.noarch
libipa_hbac-2.9.1-4.el8_9.x86_64
ipa-client-common-4.9.12-11.module+el8.9.0+1652+4ee71f6a.noarch
ipa-client-4.9.12-11.module+el8.9.0+1652+4ee71f6a.x86_64
python3-libipa_hbac-2.9.1-4.el8_9.x86_64
sssd-ipa-2.9.1-4.el8_9.x86_64
ipa-common-4.9.12-11.module+el8.9.0+1652+4ee71f6a.noarch
python3-ipaclient-4.9.12-11.module+el8.9.0+1652+4ee71f6a.noarch
ipa-server-dns-4.9.12-11.module+el8.9.0+1652+4ee71f6a.noarch
rocky-logos-ipa-86.3-1.el8.noarch
ipa-healthcheck-0.12-3.module+el8.9.0+1434+912e18bd.noarch
python3-ipalib-4.9.12-11.module+el8.9.0+1652+4ee71f6a.noarch
ipa-healthcheck-core-0.12-3.module+el8.9.0+1434+912e18bd.noarch
python3-ipaserver-4.9.12-11.module+el8.9.0+1652+4ee71f6a.noarch
ipa-selinux-4.9.12-11.module+el8.9.0+1652+4ee71f6a.noarch

When trying to run this command (as some users suggested): ipa config-mod
--enable-sid --add-sids

I'm getting this:

ipa: ERROR: cannot connect to 'https://ipa02.shtar.prod1/ipa/session/json':
Exceeded number of tries to forward a request.


There is a plenty of threads about similar symptoms recently. If using
'ipa' tool in a normal way does not work for you, you can follow
https://access.redhat.com/solutions/7052703 which has this case covered
under 'if admin users can't authenticate' subsection. This KCS article
requires RHEL subscription -- you can get a free developer subscription
from https://developers.redhat.com/


--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Re: Upgrade to FreeIPA 4.9.12 on RHEL 8.9 caused web UI login and ipa command to stop working

[Alexander Bokovoy via FreeIPA-users]

On Аўт, 23 сту 2024, Dungan, Scott A. via FreeIPA-users wrote:

I found the answer in this thread:

https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org/thread/5BUG3EVCRQKNF6BC74LA2CL3H2I2EV3P/

Following that, we used ldapmodify to apply the correct values for the
rid-base and secondary-rid-base in the new range. Afterwards, running

ipa config-mod --enable-sid --add-sids

completed, and all users have been assigned sids, although the logs
show a few errors about sids already being used:

Jan 23 10:10:47 idm1.example.com ns-slapd[52294]: 
[23/Jan/2024:10:10:47.671583872 -0800] - ERR - rid_to_sid_with_check - [file 
ipa_sidgen_common.c, line 384]: SID 
[S-1-5-21-437482216-426791213-2761072236-101000116] is already used.
Jan 23 10:10:47 idm1.example.com ns-slapd[52294]: 
[23/Jan/2024:10:10:47.672837572 -0800] - ERR - rid_to_sid_with_check - [file 
ipa_sidgen_common.c, line 384]: SID 
[S-1-5-21-437482216-426791213-2761072236-101000115] is already used.
Jan 23 10:10:47 idm1.example.com ns-slapd[52294]: 
[23/Jan/2024:10:10:47.683585571 -0800] - ERR - rid_to_sid_with_check - [file 
ipa_sidgen_common.c, line 384]: SID 
[S-1-5-21-437482216-426791213-2761072236-101029028] is already used.
Jan 23 10:10:47 idm1.example.com ns-slapd[52294]: 
[23/Jan/2024:10:10:47.703869107 -0800] - ERR - rid_to_sid_with_check - [file 
ipa_sidgen_common.c, line 384]: SID 
[S-1-5-21-437482216-426791213-2761072236-101029021] is already used.
Jan 23 10:10:47 idm1.example.com ns-slapd[52294]: 
[23/Jan/2024:10:10:47.743343711 -0800] - ERR - sidgen_task_thread - [file 
ipa_sidgen_task.c, line 199]: Sidgen task finished [0]

Not sure if we should be concerned about that or not.


Since it doesn't say 'Secondary SID is used as well.', this means a
first choice for that SID was not successful and sidgen plugin switched
to a RID from the secondary RID base. It should be fine in the end -- a
user/group got a unique SID assigned.




-Scott

From: Dungan, Scott A. via FreeIPA-users 
Sent: Tuesday, January 23, 2024 8:05 AM
To: Florence Blanc-Renaud ; FreeIPA users list 

Cc: Dungan, Scott A. 
Subject: [Freeipa-users] Re: Upgrade to FreeIPA 4.9.12 on RHEL 8.9 caused web 
UI login and ipa command to stop working

Thanks, Flo.

I believe we now know what the correct values should be for the rid-base and 
secondary-rid-base, however, we can’t seem to modify the ID range with the 
missing values we created to cover the legacy NIS users:

$ ipa idrange-mod ID.EXAMPLE.COM_legacy_range
ipa: ERROR: This command can not be used to change ID allocation for local IPA 
domain. Run `ipa help idrange` for more information

Nor can we simply delete the range and try again:

ipa idrange-del ID.EXAMPLE.COM_legacy_range
ipa: ERROR: invalid 'ipabaseid,ipaidrangesize': range modification leaving 
objects with ID out of the defined range is not allowed

It seems that we are in a chicken or the egg bind here. Below is the output of 
iprange-find for reference.


3 ranges matched

 Range name: ID.EXAMPLE.COM _id_range
 First Posix ID of the range: 86680
 Number of IDs in the range: 20
 First RID of the corresponding RID range: 1000
 First RID of the secondary RID range: 1
 Range type: local domain range

 Range name: ID.EXAMPLE.COM _legacy_range
 First Posix ID of the range: 1000
 Number of IDs in the range: 98899
 Range type: local domain range

 Range name: ID.EXAMPLE.COM _subid_range
 First Posix ID of the range: 2147483648
 Number of IDs in the range: 2147352576
 First RID of the corresponding RID range: 2147283648
 Domain SID of the trusted domain: S-1-5-21-538032-778436-45698521293
 Range type: Active Directory domain range

Number of entries returned 3


From: Florence Blanc-Renaud mailto:f...@redhat.com>>
Sent: Monday, January 22, 2024 11:50 PM
To: FreeIPA users list 
mailto:freeipa-users@lists.fedorahosted.org>>
Cc: Dungan, Scott A. mailto:sdun...@caltech.edu>>
Subject: Re: [Freeipa-users] Re: Upgrade to FreeIPA 4.9.12 on RHEL 8.9 caused 
web UI login and ipa command to stop working

Hi,

On Tue, Jan 23, 2024 at 1:05 AM Dungan, Scott A. via FreeIPA-users 
mailto:freeipa-users@lists.fedorahosted.org>>
 wrote:
Thanks to Paul for all the leg work on this issue. Based on that, I can confirm 
that we have the same problem after updating to 4.9.12-11 from 4.9.11-7. 
Running the oddjob command to add SIDs to the user accounts fails after 
encountering UIDs outside of the default IPA range. It was able to get the 
admin account working though. We have 294 users with UIDs in the range of 1001 
to 99657. These were migrated from an ancient NIS domain when the IPA domain 
was provisioned. We tried adding a secondary IPA range that covers that scope:

ipa idrange-add ID.EXAMPLE.COM_legacy_range --base-id=1000 --range-size=98899

And then running the oddjob command again, but we get the sidgen errors still, 
plus a error about overlapping rid 

[Freeipa-users] Re: cannot login on FreeIPA web GUI: Your session has expired. Please log in again.

[Alexander Bokovoy via FreeIPA-users]

On Аўт, 23 сту 2024, Harald Dunkel via FreeIPA-users wrote:

Hi Soeren,

On 2024-01-23 14:06:11, Sören R. via FreeIPA-users wrote:

Hi Harri,

did you check your admin user, if the attribute is set?

# ipa user-show admin --all | grep ipantsecurityidentifier



The admin user has this attribute set, but my own account used to access
the web interface hasn't. I am still trying to find a way how to add
this ipantsecurityidentifier attribute to all users, but wasn't there
some kind of builtin supposed to fix this automagically?


No, not automatically because it is a task that goes through all user
accounts one by one and fixes them. It also requires to have properly
defined ID ranges that cover all uidNumber/gidNumber in user/group
entries.

One issue we identified today together with Fedora infrastructure team
is that staged users (created with 'ipa stageuser-add') will prevent
sidgen plugin to generate entries.



Still trying to find the right documentation.


All documentation was mentioned already in these threads. Please see at
https://access.redhat.com/articles/7027037 for more details (needs RHEL
subscription, including a free developer subscription).


--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Re: FreeIPA 2FA OTP FIPS-140-2 Compliance

[Alexander Bokovoy via FreeIPA-users]

On Пят, 19 сту 2024, Valentin Stancu via FreeIPA-users wrote:


Hello,

I've been searching for information on FIPS 140-2 compliance for OTP
token generation in FreeIPA for a while, but I haven't been able to
find anything conclusive.


Generation of a token is done by creating a random binary key using
Python's os.urandom(KEY_LENGTH) where key length is set to 35. This is
part of ipaserver/plugins/otptoken.py:otptoken class parameters
initialization when 'ipatokenotpkey' parameter is not provided by a
client. The rest of OTP token parameters can be overidden as well.

OTPTokenKey('ipatokenotpkey?',
cli_name='key',
label=_('Key'),
doc=_('Token secret (Base32; default: random)'),
default_from=lambda: os.urandom(KEY_LENGTH),
autofill=True,
# force server-side conversion
normalizer=lambda x: x,
flags=('no_display', 'no_update', 'no_search'),
),


Could you tell me if the plugin that generates OTP tokens in FreeIPA is
FIPS-140-2 compliant? If so, from which version has it been compliant?

Could you also provide guidance on how we can verify the algorithms
used by this 2FA component to generate these tokens? (Token generation
system)


FreeIPA itself is an Open Source project, not a product. Upstream does
not provide FIPS compliance assurance.

RHEL IdM is a part of Red Hat Enterprise Linux. A particular set of
fixes that made integrated OTP implementation working in FIPS 140-2 mode
on RHEL were released as part of https://access.redhat.com/errata/RHBA-2018:3187 
Or a specific RFE that was implemented is

https://bugzilla.redhat.com/show_bug.cgi?id=1544679 -- you can start
from there. There are more than just fixes on FreeIPA side, though.

Current FreeIPA code (in daemons/ipa-slapi-plugins/libotp/hotp.c) is
using OpenSSL (since 2020, the original was built with NSS) and does not
implement own crypto primitives.



--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Re: SSSD LDAP provider fails to fetch nested groups (groups member of groups)

[Alexander Bokovoy via FreeIPA-users]

On Чцв, 18 сту 2024, Florence Blanc-Renaud via FreeIPA-users wrote:

Hi,

On Thu, Jan 18, 2024 at 12:03 PM Finn Fysj via FreeIPA-users <
freeipa-users@lists.fedorahosted.org> wrote:


I'm experiencing problems on my RHEL 9 instance when looking up members of
group using getent group . I can only get users which has
direct access to a group, and no the "user groups" part of the group.



My sssd.conf:
[domain/]
id_provider = ldap
auth_provider = ldap
chpass_provider = ldap
sudo_provider = ldap

If your provider is LDAP (and not IPA), you should ask on this mailing

list instead: sssd-us...@lists.fedorahosted.org (see
https://sssd.io/community.html).


If the server side is IPA, why the client is configured with LDAP
provider?

I also do not see in the configuration above whether you have configured
SSSD to use authentication when talking to LDAP server (IPA?). Did you
simply omit them in the email or they are fully missing?

E.g. 'ldap_default_bind_dn' and 'ldap_default_authtok' are missing.

Without authenticated bind, one cannot see member values:

dn: cn=groups,cn=accounts,dc=ipa,dc=example
aci: (targetattr = "member || memberhost || memberof || memberuid || memberuser")(targetfilter = 
"(|(objectclass=ipausergroup)(objectclass=posixgroup))")(version 3.0;acl "permission:System: Read Group 
Membership";allow (compare,read,search) userdn = "ldap:///all;;)

For any POSIX group you can only read those attributes when
authenticated.


flo

ldap_uri = ldaps:/ipa.example.com

ldap_schema = rfc2307bis

ldap_search_base = dc=example,dc=com
ldap_sudo_search_base = ou=sudoers,dc=example,dc=com
ldap_user_search_base = cn=users,cn=accounts,dc=example,dc=com
ldap_group_search_base = cn=groups,cn=accounts,dc=example,dc=com

[sssd]
services = nss, pam, sudo
domains = default

[nss]
homedir_substring = /home

[pam]

[sudo]
--
___
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
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue






--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Re: Seeking an advice on migrating freeipa environment from centos 7 to Almalinux 9

[Alexander Bokovoy via FreeIPA-users]

On Пят, 19 сту 2024, Polavarapu Manideep Sai via FreeIPA-users wrote:

Hi Team,

Seeking an advice on migrating freeipa environment from centos 7 to Almalinux 9

Consider there are  4 servers 1 as IPA master and rest are replicas


 1.  master.ipa.example.com [centos 7.9 IPA 4.6.8]
 2.  Replica1.ipa.example.com [centos 7.9 IPA 4.6.8]
 3.  Replica2.ipa.example.com [centos 7.9 IPA 4.6.8]
 4.  Replica3.ipa.example.com [centos 7.9 IPA 4.6.8]

What is the best approach to migrate it to alma Linux 9

As we all know in place upgrade is not possible

Gone through below link, but still looking for an advice, what happens
to existing replicas and its ipa clients after promoting Almalinux 8/9
server as IPA master server? does replication work in case of higher
version of ipa master[4.10.2, Almalinux] and lower version of ipa
replica [4.6.8,Centos 7] ? any impact on functionality of existing
replicas servers of [centos 7.9 IPA 4.6.8]?

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/migrating_to_identity_management_on_rhel_8/migrate-7-to-8_migrating#doc-wrapper

As I tested we can integrate ipa clients of lower version [4.6.8,centso
7]   to ipa-server of higher version [4.10.2, Alma linux]

As I tested we can't add replica of lower version[4.6.8,centso 7]  to
ipa-server of higher version[4.10.2, Alma linux]


Upgrade all your IPA servers to Alma Linux 8 first, then upgrade them
all to Alma Linux 9. There is no other way. It is related to security
and crypto policy improvements across RHEL 9.




--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Re: Allow users from AD trust to run ipa commands

[Alexander Bokovoy via FreeIPA-users]

On Пят, 19 сту 2024, Yuriy Halytskyy via FreeIPA-users wrote:

Hi,

At first I've just created an external group, added the user, and
added that group to a role but that didn't work. Then I stumbled
across this while googling:

ipa idoverrideuser-add 'Default Trust View' username@DOMAIN

And it works, the user can use IPA commands with AD kerberos ticket
and roles apply properly. But I cannot for the life of me figure out
what that did and are there any other consequences.

Documentation talks about using ID views to override user properties
but this doesn't specify any properties to override. Also, it says the
view is applied to all AD users, but in that case why do I need to run
that command?


You need to look at design pages that most new FreeIPA features have.

https://freeipa.readthedocs.io/en/latest/designs/adtrust/admin-ipa-as-trusted-user.html


--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Re: Create IPA user via LDAP

[Alexander Bokovoy via FreeIPA-users]

On Чцв, 18 сту 2024, Ronald Wimmer wrote:

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/html/managing_idm_users_groups_hosts_and_access_control_rules/configuring-idm-for-external-provisioning-of-users_managing-users-groups-hosts#doc-wrapper



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.



So. Am I right that our options are to use LDAP with a cleartext 
passwort or use the IPA API?


That's what I wrote you above, yes.


--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Re: web login failed after upgrade

[Alexander Bokovoy via FreeIPA-users]

On Чцв, 18 сту 2024, 彭勇 via FreeIPA-users wrote:

when we upgrade ipa-server-4.9.12-9 to ipa-server-4.9.12-11 on RHEL 8, we
can't login to web. the web give me message: “Your session has expired.
Please log in again.”


Read the thread: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org/thread/YIZGY45MPYTPJ6FQXLU6XNS7OBRI6GQU/




we check the error_log

[Thu Jan 18 21:56:42.535394 2024] [auth_gssapi:error] [pid 11025:tid
139639453087488] [client 118.184.176.67:30891] Failed to unseal session
data!, referer: https://id1.netegn.com/ipa/xml
[Thu Jan 18 21:56:43.113937 2024] [wsgi:error] [pid 11021:tid
139639621613312] [remote 118.184.176.67:30891] 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)
[Thu Jan 18 21:56:43.611962 2024] [wsgi:error] [pid 11023:tid
139639621613312] [remote 118.184.176.67:30893] 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)

all three ipa server failed. we can't resolve the problem, we restore the
snapshot and it recovery.

we install RHEL 9.3 with ipa-server-4.10.2-5，set it as replicator of master
ipa server, it has same problem.


--
Peng Yong





--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Re: Upgrade to FreeIPA 4.9.12 on RHEL 8.9 caused web UI login and ipa command to stop working

[Alexander Bokovoy via FreeIPA-users]

On Срд, 17 сту 2024, Alexander Bokovoy via FreeIPA-users wrote:

On Срд, 17 сту 2024, Paul Nickerson via FreeIPA-users wrote:

I have two FreeIPA servers in a cluster, both running on RHEL 8.9. They
started on RHEL 8.0 I believe, and have been upgrading in-place since
then. I recently restarted the FreeIPA services, which triggered an
ipa-server-upgrade to upgrade from 4.9.11 to 4.9.12. When that ran, it
errored out on some expired certificates, which I fixed with
ipa-cert-fix, and then the ipa-server-upgrade's finished successfully.

Now, when I or any of my users try to log on to the web UI, we get the error "Your 
session has expired. Please log in again."
Also, when I try to run any ipa command on the command line, I get the error:
ipa: ERROR: cannot connect to 'any of the configured servers': 
https://ipa01.semi.example.net/ipa/session/json, 
https://ipa02.semi.example.net/ipa/session/json

I've traced down lots of errors, and I think this one is the most relevant:
401 Unauthorized: Insufficient access: SASL(-1): generic failure: GSSAPI Error: 
Unspecified GSS failure.  Minor code may provide more information (Credential 
cache is empty)
I see it in /var/log/httpd/error_log, in the body of the HTTP response from 
https://ipa01.semi.example.net/ipa/session/json in my web browser, and in the 
output from the command ipa --debug

Also, in /var/log/krb5kdc.log, I see:
Jan 17 01:14:47 ipa01.semi.example.net krb5kdc[55855](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)}) 172.16.121.5: 
S4U2PROXY_EVIDENCE_TKT_WITHOUT_PAC: authtime 1705454084, etypes 
{rep=UNSUPPORTED:(0)} HTTP/ipa01.semi.example@semi.example.net for 
ldap/ipa01.semi.example@semi.example.net, KDC policy rejects request

I have krb5 1.18.2 installed. disable_pac is not present in
/var/kerberos/krb5kdc/kdc.conf.

I think I'm experiencing the same issue seen in the recent thread at
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org/thread/DLYLL54LBTT4FVJLIFFWVAPQOEU4GWW7/
(subject line "api authorization stopped working after upgrade to
4.9.12-11 on RHEL8").

I don't think any of my users or groups have an SID
(ipantsecurityidentifier). This FreeIPA cluster was installed on RHEL
8.0 (or thereabouts), and the servers have been upgraded in-place since
then. We've never integrated with any Active Directory or Microsoft
product.


FreeIPA generates SIDs by default since FreeIPA 4.9.8. It is configured
to do so on new installations even when integration with AD is not
considered, due to tightened requirements to process constrained
delegation in Kerberos.



This command has no output, showing that even the admin user does not have an 
SID:
ldapsearch -H ldap://ipa01.semi.example.net:389/ -x -D "cn=Directory Manager" 
-W -b cn=users,cn=accounts,dc=semi,dc=example,dc=net uid=admin '*' + | grep -i 
ipantsecurityidentifier

The solution from the other thread, and from
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/managing_idm_users_groups_hosts_and_access_control_rules/assembly_strengthening-kerberos-security-with-pac-information_managing-users-groups-hosts#proc_enabling-security-identifiers-sids-in-idm_assembly_strengthening-kerberos-security-with-pac-information,
does not work for me, since the ipa command doesn't work, not even for
the admin user:

[r...@ipa01.semi.example.net ~]
# kinit admin
Password for ad...@semi.example.net:
[r...@ipa01.semi.example.net ~]
# ipa config-mod --enable-sid --add-sids
ipa: ERROR: cannot connect to 'any of the configured servers': 
https://ipa01.semi.example.net/ipa/json, https://ipa02.semi.example.net/ipa/json

I found an alternative method at 
https://freeipa.readthedocs.io/en/latest/designs/adtrust/sidconfig.html#troubleshooting-and-debugging,
 but this also does not work for me:

[r...@ipa01.semi.example.net ~]
# ldapmodify -H ldapi://%2Frun%2Fslapd-SEMI-EXAMPLE-NET.socket -f 
/tmp/ipa-sidgen-task-run.ldif
SASL/GSSAPI authentication started
SASL username: ad...@semi.example.net
SASL SSF: 256
SASL data security layer installed.
adding new entry "cn=sidgen,cn=ipa-sidgen-task,cn=tasks,cn=config"
ldap_add: No such object (32)

I think ipa-sidgen-task does not exist in my LDAP directory, but I'm
not sure if I understand how this is supposed to work. I don't see
ipa-sidgen-task or anything like it from this search: ldapsearch -H
ldap://ipa01.semi.example.net:389/ -x -D "cn=Directory Manager" -W -b
cn=config | grep cn=tasks

Can anyone help me here? I think if I could get a
ipantsecurityidentifier attribute properly set up on my user or on the
admin user, then I would be able to use the ipa command to get SID's
enabled and created everywhere.


You'd need to enable SID generation first, then run those tasks. Without
sidgen plugins enabled, 

[Freeipa-users] Re: Upgrade to FreeIPA 4.9.12 on RHEL 8.9 caused web UI login and ipa command to stop working

[Alexander Bokovoy via FreeIPA-users]

On Срд, 17 сту 2024, Paul Nickerson via FreeIPA-users wrote:

I have two FreeIPA servers in a cluster, both running on RHEL 8.9. They
started on RHEL 8.0 I believe, and have been upgrading in-place since
then. I recently restarted the FreeIPA services, which triggered an
ipa-server-upgrade to upgrade from 4.9.11 to 4.9.12. When that ran, it
errored out on some expired certificates, which I fixed with
ipa-cert-fix, and then the ipa-server-upgrade's finished successfully.

Now, when I or any of my users try to log on to the web UI, we get the error "Your 
session has expired. Please log in again."
Also, when I try to run any ipa command on the command line, I get the error:
ipa: ERROR: cannot connect to 'any of the configured servers': 
https://ipa01.semi.example.net/ipa/session/json, 
https://ipa02.semi.example.net/ipa/session/json

I've traced down lots of errors, and I think this one is the most relevant:
401 Unauthorized: Insufficient access: SASL(-1): generic failure: GSSAPI Error: 
Unspecified GSS failure.  Minor code may provide more information (Credential 
cache is empty)
I see it in /var/log/httpd/error_log, in the body of the HTTP response from 
https://ipa01.semi.example.net/ipa/session/json in my web browser, and in the 
output from the command ipa --debug

Also, in /var/log/krb5kdc.log, I see:
Jan 17 01:14:47 ipa01.semi.example.net krb5kdc[55855](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)}) 172.16.121.5: 
S4U2PROXY_EVIDENCE_TKT_WITHOUT_PAC: authtime 1705454084, etypes 
{rep=UNSUPPORTED:(0)} HTTP/ipa01.semi.example@semi.example.net for 
ldap/ipa01.semi.example@semi.example.net, KDC policy rejects request

I have krb5 1.18.2 installed. disable_pac is not present in
/var/kerberos/krb5kdc/kdc.conf.

I think I'm experiencing the same issue seen in the recent thread at
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org/thread/DLYLL54LBTT4FVJLIFFWVAPQOEU4GWW7/
(subject line "api authorization stopped working after upgrade to
4.9.12-11 on RHEL8").

I don't think any of my users or groups have an SID
(ipantsecurityidentifier). This FreeIPA cluster was installed on RHEL
8.0 (or thereabouts), and the servers have been upgraded in-place since
then. We've never integrated with any Active Directory or Microsoft
product.


FreeIPA generates SIDs by default since FreeIPA 4.9.8. It is configured
to do so on new installations even when integration with AD is not
considered, due to tightened requirements to process constrained
delegation in Kerberos.



This command has no output, showing that even the admin user does not have an 
SID:
ldapsearch -H ldap://ipa01.semi.example.net:389/ -x -D "cn=Directory Manager" 
-W -b cn=users,cn=accounts,dc=semi,dc=example,dc=net uid=admin '*' + | grep -i 
ipantsecurityidentifier

The solution from the other thread, and from
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/managing_idm_users_groups_hosts_and_access_control_rules/assembly_strengthening-kerberos-security-with-pac-information_managing-users-groups-hosts#proc_enabling-security-identifiers-sids-in-idm_assembly_strengthening-kerberos-security-with-pac-information,
does not work for me, since the ipa command doesn't work, not even for
the admin user:

[r...@ipa01.semi.example.net ~]
# kinit admin
Password for ad...@semi.example.net:
[r...@ipa01.semi.example.net ~]
# ipa config-mod --enable-sid --add-sids
ipa: ERROR: cannot connect to 'any of the configured servers': 
https://ipa01.semi.example.net/ipa/json, https://ipa02.semi.example.net/ipa/json

I found an alternative method at 
https://freeipa.readthedocs.io/en/latest/designs/adtrust/sidconfig.html#troubleshooting-and-debugging,
 but this also does not work for me:

[r...@ipa01.semi.example.net ~]
# ldapmodify -H ldapi://%2Frun%2Fslapd-SEMI-EXAMPLE-NET.socket -f 
/tmp/ipa-sidgen-task-run.ldif
SASL/GSSAPI authentication started
SASL username: ad...@semi.example.net
SASL SSF: 256
SASL data security layer installed.
adding new entry "cn=sidgen,cn=ipa-sidgen-task,cn=tasks,cn=config"
ldap_add: No such object (32)

I think ipa-sidgen-task does not exist in my LDAP directory, but I'm
not sure if I understand how this is supposed to work. I don't see
ipa-sidgen-task or anything like it from this search: ldapsearch -H
ldap://ipa01.semi.example.net:389/ -x -D "cn=Directory Manager" -W -b
cn=config | grep cn=tasks

Can anyone help me here? I think if I could get a
ipantsecurityidentifier attribute properly set up on my user or on the
admin user, then I would be able to use the ipa command to get SID's
enabled and created everywhere.


You'd need to enable SID generation first, then run those tasks. Without
sidgen plugins enabled, one cannot initiate SID generation.

Please follow the command Rob pointed you to. If that one fails, please provide
more 

[Freeipa-users] Re: Is there any way to disable TOTP watermark support?

[Alexander Bokovoy via FreeIPA-users]

On Срд, 17 сту 2024, Heo Paul via FreeIPA-users wrote:

I use the core server (fedora 39, ipa-version : 4.11.0)

I know that freeipa server adds TOTP watermark support since 4.1 version.
But for some reason, I need to reuse otp-code from generated with TOPT for 
short time to login but it fails with otp watermark.
Are there any ways to disable the feature from server side?


No, TOTP watermark is essenital and cannot be disabled.

--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Re: api authorization stopped working after upgrade to 4.9.12-11 on RHEL8

[Alexander Bokovoy via FreeIPA-users]

On Чцв, 11 сту 2024, Rasto Rickardt wrote:

Hello Alexander,

all packages should be current with default RHEL configuration:


Thanks, the configs look OK. So check whether users miss SIDs and
regenerate them with 


 ipa config-mod --enable-sid --add-sids

as admin.



krb5-workstation-1.18.2-26.el8_9.x86_64
krb5-pkinit-1.18.2-26.el8_9.x86_64
sssd-krb5-2.9.1-4.el8_9.x86_64
krb5-libs-1.18.2-26.el8_9.x86_64
krb5-server-1.18.2-26.el8_9.x86_64
sssd-krb5-common-2.9.1-4.el8_9.x86_64

cat  /var/kerberos/krb5kdc/kdc.conf
[kdcdefaults]
kdc_ports = 88
kdc_tcp_ports = 88
restrict_anonymous_to_tgt = true
spake_preauth_kdc_challenge = edwards25519

[realms]
ID.EXAMPLE.COM = {
 master_key_type = aes256-cts
 max_life = 7d
 max_renewable_life = 14d
 acl_file = /var/kerberos/krb5kdc/kadm5.acl
 dict_file = /usr/share/dict/words
 default_principal_flags = +preauth
;  admin_keytab = /var/kerberos/krb5kdc/kadm5.keytab
 pkinit_identity = 
FILE:/var/kerberos/krb5kdc/kdc.crt,/var/kerberos/krb5kdc/kdc.key

 pkinit_anchors = FILE:/var/kerberos/krb5kdc/kdc.crt
 pkinit_anchors = FILE:/var/kerberos/krb5kdc/cacert.pem
 pkinit_pool = FILE:/var/lib/ipa-client/pki/ca-bundle.pem
 pkinit_indicator = pkinit
 spake_preauth_indicator = hardened
 encrypted_challenge_indicator = hardened
}
[libdefaults]
spake_preauth_kdc_challenge = edwards25519

/etc/krb5.conf and conf.d are in attached file.

I do not see disable_pac anywhere.

Thank you,

Rasto


The error below tells that a user ticket did not have a PAC associated:

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@id.example.com for 
ldap/ipa7.id.example@id.example.com, KDC policy rejects 
request


Can you also share your client and server's Kerberos configurations?
configs and which rpms are used.

It looks like either SID is missing in the user account and KDC is
forced to ignore that (disable_pac = true in the realm configuration in
kdc.conf). Or some flags are set on IPA services to force ignoring PAC
checks. PAC presence is required for constrained delegation
operations and we now enforce it for krb5 1.18 as well.







--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Re: api authorization stopped working after upgrade to 4.9.12-11 on RHEL8

[Alexander Bokovoy via FreeIPA-users]

On Чцв, 11 сту 2024, Rasto Rickardt via FreeIPA-users wrote:

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.


The error below tells that a user ticket did not have a PAC associated:

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@id.example.com for 
ldap/ipa7.id.example@id.example.com, KDC policy rejects request


Can you also share your client and server's Kerberos configurations?
configs and which rpms are used.

It looks like either SID is missing in the user account and KDC is
forced to ignore that (disable_pac = true in the realm configuration in
kdc.conf). Or some flags are set on IPA services to force ignoring PAC
checks. PAC presence is required for constrained delegation
operations and we now enforce it for krb5 1.18 as well.



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: 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: ipa2.id.example.com/ipa/session/json: 401 Unauthorized>
ipa: INFO: Connection to https://ipa2.id.example.com/ipa/session/json 
failed with 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: 
rricka...@id.example.com for krbtgt/id.example@id.example.com, 
Additional pre-authentication required

Jan 11 17:41:35 

[Freeipa-users] Re: Freeipa sudo

[Alexander Bokovoy via FreeIPA-users]

On Чцв, 11 сту 2024, Dmitry Krasov via FreeIPA-users wrote:

sssd_dom.loc.log
https://codeshare.io/qP8rYx

sssd_pam.log
https://codeshare.io/eVgexb


Is this user ('desktop') a member of any administrative groups?

(2024-01-11 15:01:26): [be[dom.loc]] [hbac_eval_user_element] (0x1000): 
[RID#101] [2] groups for [desk...@dom.loc]
(2024-01-11 15:01:26): [be[dom.loc]] [hbac_eval_user_element] (0x1000): 
[RID#101] Added group [ipausers] for user [desktop]
(2024-01-11 15:01:26): [be[dom.loc]] [hbac_eval_user_element] (0x1000): 
[RID#101] Added group [desktop22043] for user [desktop]

(2024-01-11 15:01:26): [be[dom.loc]] [hbac_req_debug_print] (0x2000): [RID#98]  
REQUEST:
(2024-01-11 15:01:26): [be[dom.loc]] [hbac_request_element_debug_print] 
(0x2000): [RID#98]  service [gdm-password]
(2024-01-11 15:01:26): [be[dom.loc]] [hbac_request_element_debug_print] 
(0x2000): [RID#98]  service_group (none)
(2024-01-11 15:01:26): [be[dom.loc]] [hbac_request_element_debug_print] 
(0x2000): [RID#98]  user [desktop]
(2024-01-11 15:01:26): [be[dom.loc]] [hbac_request_element_debug_print] 
(0x2000): [RID#98]  user_group:
(2024-01-11 15:01:26): [be[dom.loc]] [hbac_request_element_debug_print] 
(0x2000): [RID#98]  [ipausers]
(2024-01-11 15:01:26): [be[dom.loc]] [hbac_request_element_debug_print] 
(0x2000): [RID#98]  [desktop22043]
(2024-01-11 15:01:26): [be[dom.loc]] [hbac_request_element_debug_print] 
(0x2000): [RID#98]  targethost [desktop22043.dom.loc]
(2024-01-11 15:01:26): [be[dom.loc]] [hbac_request_element_debug_print] 
(0x2000): [RID#98]  targethost_group:
(2024-01-11 15:01:26): [be[dom.loc]] [hbac_request_element_debug_print] 
(0x2000): [RID#98]  [desktop22043]
(2024-01-11 15:01:26): [be[dom.loc]] [hbac_request_element_debug_print] 
(0x2000): [RID#98]  srchost_group (none)
(2024-01-11 15:01:26): [be[dom.loc]] [hbac_req_debug_print] (0x2000): [RID#98]  
request time 2024-01-11 15:01:26
(2024-01-11 15:01:26): [be[dom.loc]] [hbac_rule_debug_print] (0x2000): [RID#98] 
RULE [allow_all] [ENABLED]:
(2024-01-11 15:01:26): [be[dom.loc]] [hbac_rule_debug_print] (0x2000): [RID#98] 
services:
(2024-01-11 15:01:26): [be[dom.loc]] [hbac_rule_element_debug_print] (0x2000): 
[RID#98] category [0x1] [ALL]
(2024-01-11 15:01:26): [be[dom.loc]] [hbac_rule_debug_print] (0x2000): [RID#98] 
users:
(2024-01-11 15:01:26): [be[dom.loc]] [hbac_rule_element_debug_print] (0x2000): 
[RID#98] category [0x1] [ALL]
(2024-01-11 15:01:26): [be[dom.loc]] [hbac_rule_debug_print] (0x2000): [RID#98] 
targethosts:
(2024-01-11 15:01:26): [be[dom.loc]] [hbac_rule_element_debug_print] (0x2000): 
[RID#98] category [0x1] [ALL]
(2024-01-11 15:01:26): [be[dom.loc]] [hbac_rule_debug_print] (0x2000): [RID#98] 
srchosts:
(2024-01-11 15:01:26): [be[dom.loc]] [hbac_rule_element_debug_print] (0x2000): 
[RID#98] category [0x1] [ALL]
(2024-01-11 15:01:26): [be[dom.loc]] [hbac_evaluate] (0x0100): [RID#98] ALLOWED 
by rule [allow_all].

It seems it is a member of only two groups.

From your previous log, polkit was unable to authorize access using own
rules:

16:33:38 desktop22043.dom.loc polkitd(authority=local)[587]: Operator of 
unix-session:4
FAILED to authenticate to gain authorization for action 
org.fortinet.fortitray.quit for
unix-process:3948:18923 [sh -c pkexec /bin/bash 
/opt/forticlient/stop-forticlient.sh]
(owned by unix-user:desktop)

IIRC, if you didn't modify them, polkit default configuration is to
allow only administrative users to operate as another user
(allow_active=auth_admin in polkit actions, see
https://manpages.ubuntu.com/manpages/jammy/man8/polkit.8.html for
details). The meaning of an administrative user is defined in polkit
rules. For example, https://www.freeipa.org/page/Howto/FreeIPA_PolicyKit
describes how you can add a rule that matches a certain IPA group
(really, any group membership known on the system).

You can check which actions are allowed for your user 'desktop' by
running

$ pkaction

as that user in their logged-in session.


See
https://www.admin-magazine.com/Articles/Assigning-Privileges-with-sudo-and-PolicyKit
for somewhat detailed explanation how this all works -- this is general
enough to work with or without FreeIPA.

--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
--
___
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: 

[Freeipa-users] Re: FreeIPA Upgrade - overwrites custom authselect config

[Alexander Bokovoy via FreeIPA-users]

On Чцв, 11 сту 2024, Finn Fysj via FreeIPA-users wrote:

I can see how you were confused but it's covered in "FreeIPA 3.3.0 or
newer" where you run yum update [free]ipa-server. We recommend updating
all packages and not just IPA. ipa-server-upgrade runs as part of the
package install process.


Since it's recommended to run "yum update [free]ipa-server", why does the "FreeIPA 
4.2.0 or newer" section even exists as an options?

(I'm sorry to be such a 'pita'.)


The pages at freeipa.org were written in early project days, more or
less. Design pages weren't updated since implementation was done or
documentation was added to RHEL IdM documentation.

For few past years design pages get added to IPA source code directly
and can be seen at https://freeipa.readthedocs.io. This does not apply
to old pages in Mediawiki we used to use for freeipa.org website.

You can submit an update through
https://github.com/freeipa/freeipa.github.io as we migrated to github
site from mediawiki some time last year.


Primary documentation for the project is maintained as RHEL IdM
documentation, split between multiple RHEL releases:

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9

You need to choose 'Identity management' category in the 'Category'
checkboxes. This way the books will be filtered to show only RHEL IdM
documentation.

The documentation there is a living creature, some parts of 'old' RHEL 7
documentation aren't ported to RHEL 8 and RHEL 9 because a concept to
how documentation would be presented is different. Most of RHEL 7 docs
related to IPA management still apply, of course.

For example, update documentation for RHEL 9 version is
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/installing_identity_management/update-downgrade-ipa_installing-identity-management

We have this mentioned partially on 
https://www.freeipa.org/page/Documentation.html


--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Re: FreeIPA Upgrade - overwrites custom authselect config

[Alexander Bokovoy via FreeIPA-users]

On Чцв, 11 сту 2024, Finn Fysj via FreeIPA-users wrote:

Finn Fysj via FreeIPA-users wrote:

If you have a custom profile then what would checking for 9.3 help? And
note, we don't recommend or support custom profiles. IPA is very
opinionated about the configuration it expects.


I can see how you were confused but it's covered in "FreeIPA 3.3.0 or
newer" where you run yum update [free]ipa-server. We recommend updating
all packages and not just IPA. ipa-server-upgrade runs as part of the
package install process.

rob


1. Checking for 9.3 would know that the system is using authselect.
2. IPA could only check if the custom profile fulfill the requirements, which 
is sssd and sudo feature enabled.

I understand that IPA is very opinionated about config specs, but some need to 
follow security benchmarks.


You can always help upstream by submitting a PR that implements what you
propose.

Since authselect supports introspection, of some kind, that could
theoretically be used to look at whether base of the profile is
compatible with what we expect.

--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Re: Freeipa sudo

[Alexander Bokovoy via FreeIPA-users]

On Срд, 10 сту 2024, Dmitry Krasov via FreeIPA-users wrote:

HBAC allow_all enabled. I think everything default, only sudo rule from video.

I did debug level 3...


Please use debug level 9 and provide full logs somewhere.
You can send the link to logs/logs themselves off list, I'll continue in
this thread with findings.



sssd_dom.loc.log:

(2024-01-10 16:14:08): [be[dom.loc]] [sdap_dyndns_dns_addrs_done] (0x0040): 
[RID#62] Could not receive list of current addresses [5]: Input/output error
(2024-01-10 16:14:08): [be[dom.loc]] [ipa_dyndns_sdap_update_done] (0x0040): 
[RID#62] Dynamic DNS update failed [5]: Input/output error

(2024-01-10 16:14:08): [be[dom.loc]] [be_ptask_done] (0x0040): [RID#62] Task 
[Dyndns update]: failed with [5]: Input/output error
** PREVIOUS MESSAGE WAS TRIGGERED BY THE FOLLOWING 
BACKTRACE:
  *  (2024-01-10 16:14:08): [be[dom.loc]] [sdap_id_op_destroy] (0x4000): 
[RID#62] releasing operation connection
  *  (2024-01-10 16:14:08): [be[dom.loc]] [be_ptask_done] (0x0040): [RID#62] 
Task [Dyndns update]: failed with [5]: Input/output error
** BACKTRACE DUMP ENDS HERE 
*

(2024-01-10 16:14:09): [be[dom.loc]] [ipa_id_get_account_info_orig_done] 
(0x0080): [RID#69] Object not found, ending request
(2024-01-10 16:21:58): [be[dom.loc]] [ipa_hbac_evaluate_rules] (0x0080): 
[RID#94] Access granted by HBAC rule [allow_all]
(2024-01-10 16:21:58): [be[dom.loc]] [ipa_deskprofile_get_config_done] 
(0x0080): [RID#96] Server doesn't support Desktop Profile.
(2024-01-10 16:21:58): [be[dom.loc]] [ipa_hbac_evaluate_rules] (0x0080): 
[RID#97] Access granted by HBAC rule [allow_all]
-

sssd_pam.log:

(2024-01-10 16:28:09): [pam] [orderly_shutdown] (0x1f7c0): SIGTERM: killing 
children
(2024-01-10 16:28:09): [pam] [orderly_shutdown] (0x1f7c0): Shutting down (status = 
0)(2024-01-10 16:28:24): [pam] [server_setup] (0x1f7c0): Starting with deb>
(2024-01-10 16:28:25): [pam] [cache_req_common_process_dp_reply] (0x0040): 
[CID#1] CR #1: Could not get account info [1432158212]: SSSD is offline
-

journalctl -xe when I trying to close forticlient (doing privileged action) and 
close auth window:

16:31:26 desktop22043.dom.loc audit[800]: AVC apparmor="ALLOWED" operation="open" class="file" profile="/usr/sbin/sssd" 
name="/proc/3949/cmdline" pid=800 comm="sssd_nss" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
16:31:26 desktop22043.dom.loc kernel: audit: type=1400 audit(1704889886.433:219): apparmor="ALLOWED" operation="open" 
class="file" profile="/usr/sbin/sssd" name="/proc/3949/cmdline" pid=800 comm="sssd_nss" requested_mask="r" 
denied_mask="r" fsuid=0 ouid=0
16:31:26 desktop22043.dom.loc audit[800]: AVC apparmor="ALLOWED" operation="open" class="file" profile="/usr/sbin/sssd" 
name="/proc/3952/cmdline" pid=800 comm="sssd_nss" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
16:31:26 desktop22043.dom.loc kernel: audit: type=1400 audit(1704889886.497:220): apparmor="ALLOWED" operation="open" 
class="file" profile="/usr/sbin/sssd" name="/proc/3952/cmdline" pid=800 comm="sssd_nss" requested_mask="r" 
denied_mask="r" fsuid=0 ouid=0

auth windows closed:
16:33:38 desktop22043.dom.loc polkitd(authority=local)[587]: Operator of 
unix-session:4 FAILED to authenticate to gain authorization for action 
org.fortinet.fortitray.quit for unix-process:3948:18923 [sh -c pkexec /bin/bash 
/opt/forticlient/stop-forticlient.sh] (owned by unix-user:desktop)
16:33:38 desktop22043.dom.loc pkexec[3949]: desktop: Error executing command as 
another user: Request dismissed [USER=root] [TTY=unknown] [CWD=/home/desktop] 
[COMMAND=/bin/bash /opt/forticlient/stop-forticlient.sh]
16:33:38 desktop22043.dom.loc Fortitray.desktop[3949]: Error executing command 
as another user: Request dismissed
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue




--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
--
___
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 Upgrade - overwrites custom authselect config

[Alexander Bokovoy via FreeIPA-users]

On Срд, 10 сту 2024, Finn Fysj via FreeIPA-users wrote:

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?


It should tell you what upgrade step is that prior to running the
command.

I think this is about migration to authselect. Upgrade code considers
whether migration from authconfig is needed and if we didn't record that
migration already happened, we perform it. The default configuration is
'authselect select sssd with-sudo --force'.

You can avoid re-running this upgrade part by adding a section

[authcfg]
migrated_to_authselect = True

to /var/lib/ipa/sysupgrade/sysupgrade.state

and rerunning the upgrade.



The upgrade in my case fails because I've set made following files immutable: 
/etc/authselect/{password-auth,system-auth}.



--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue




--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Re: Freeipa sudo

[Alexander Bokovoy via FreeIPA-users]

On Аўт, 09 сту 2024, Dmitry Krasov via FreeIPA-users wrote:

https://youtu.be/kwQrBfuzEcg?si=aLOfs5j3xXYoiWjL

"desktop" user is freeipa user, and local sudo admin through sudo rule.
"user special" is a local user, and local sudo admin.
---
sssd.log:


Please follow https://sssd.io/troubleshooting/basics.html on how to
collect logs. You need sssd_*.log logs, in particular, sssd_dom.loc.log
(for your domain dom.loc).

Other things to check: if you have disabled HBAC rule 'allow_all', then
you need to create explicit HBAC rules for each PAM service involved.
Assuming you have HBAC rule for 'sudo', do you have one for other PAM
services used by those tools?

You can find what services were attempted by looking into the system
journal with journalctl.



(2024-01-09 14:27:28): [sssd] [server_setup] (0x1f7c0): Starting with debug 
level = 0x0070
(2024-01-09 15:03:43): [sssd] [monitor_quit_signal] (0x1f7c0): Monitor received 
Завершено: terminating childr>
(2024-01-09 15:03:43): [sssd] [monitor_quit] (0x1f7c0): Returned with: 0
(2024-01-09 15:03:43): [sssd] [monitor_quit] (0x1f7c0): Terminating [pac][807]
(2024-01-09 15:03:43): [sssd] [monitor_quit] (0x1f7c0): Child [pac] exited 
gracefully
(2024-01-09 15:03:43): [sssd] [monitor_quit] (0x1f7c0): Terminating [sudo][806]
(2024-01-09 15:03:43): [sssd] [monitor_quit] (0x1f7c0): Child [sudo] exited 
gracefully
(2024-01-09 15:03:43): [sssd] [monitor_quit] (0x1f7c0): Terminating [ssh][805]
(2024-01-09 15:03:43): [sssd] [monitor_quit] (0x1f7c0): Child [ssh] exited 
gracefully
(2024-01-09 15:03:43): [sssd] [monitor_quit] (0x1f7c0): Terminating [pam][804]
(2024-01-09 15:03:43): [sssd] [monitor_quit] (0x1f7c0): Child [pam] exited 
gracefully
(2024-01-09 15:03:43): [sssd] [monitor_quit] (0x1f7c0): Terminating [nss][803]
(2024-01-09 15:03:43): [sssd] [monitor_quit] (0x1f7c0): Child [nss] exited 
gracefully
(2024-01-09 15:03:43): [sssd] [monitor_quit] (0x1f7c0): Terminating 
[dom.loc][745]
(2024-01-09 15:03:43): [sssd] [monitor_quit] (0x1f7c0): Child [dom.loc] exited 
gracefully
(2024-01-09 15:03:58): [sssd] [server_setup] (0x1f7c0): Starting with debug 
level = 0x0070
(2024-01-09 15:14:22): [sssd] [monitor_quit_signal] (0x1f7c0): Monitor received 
Завершено: terminating childr>
(2024-01-09 15:14:22): [sssd] [monitor_quit] (0x1f7c0): Returned with: 0
(2024-01-09 15:14:22): [sssd] [monitor_quit] (0x1f7c0): Terminating [pac][809]
(2024-01-09 15:14:22): [sssd] [monitor_quit] (0x1f7c0): Child [pac] exited 
gracefully
(2024-01-09 15:14:22): [sssd] [monitor_quit] (0x1f7c0): Terminating [sudo][808]
(2024-01-09 15:14:22): [sssd] [monitor_quit] (0x1f7c0): Child [sudo] exited 
gracefully
(2024-01-09 15:14:22): [sssd] [monitor_quit] (0x1f7c0): Terminating [ssh][807]
(2024-01-09 15:14:22): [sssd] [monitor_quit] (0x1f7c0): Child [ssh] exited 
gracefully
(2024-01-09 15:14:22): [sssd] [monitor_quit] (0x1f7c0): Terminating [pam][806]
(2024-01-09 15:14:22): [sssd] [monitor_quit] (0x1f7c0): Child [pam] exited 
gracefully
(2024-01-09 15:14:22): [sssd] [monitor_quit] (0x1f7c0): Terminating [nss][805]
(2024-01-09 15:14:22): [sssd] [monitor_quit] (0x1f7c0): Child [nss] exited 
gracefully
(2024-01-09 15:14:22): [sssd] [monitor_quit] (0x1f7c0): Terminating 
[dom.loc][748]
(2024-01-09 15:14:22): [sssd] [monitor_quit] (0x1f7c0): Child [dom.loc] exited 
gracefully
(2024-01-09 15:14:38): [sssd] [server_setup] (0x1f7c0): Starting with debug 
level = 0x0070
(2024-01-09 15:20:12): [sssd] [monitor_quit_signal] (0x1f7c0): Monitor received 
Завершено: terminating childr>
(2024-01-09 15:20:12): [sssd] [monitor_quit] (0x1f7c0): Returned with: 0
(2024-01-09 15:20:12): [sssd] [monitor_quit] (0x1f7c0): Terminating [pac][805]
(2024-01-09 15:20:12): [sssd] [monitor_quit] (0x1f7c0): Child [pac] exited 
gracefully
(2024-01-09 15:20:12): [sssd] [monitor_quit] (0x1f7c0): Terminating [sudo][804]
(2024-01-09 15:20:12): [sssd] [monitor_quit] (0x1f7c0): Child [sudo] exited 
gracefully
(2024-01-09 15:20:12): [sssd] [monitor_quit] (0x1f7c0): Terminating [ssh][803]
(2024-01-09 15:20:12): [sssd] [monitor_quit] (0x1f7c0): Child [ssh] exited 
gracefully
(2024-01-09 15:20:12): [sssd] [monitor_quit] (0x1f7c0): Terminating [pam][802]
(2024-01-09 15:20:12): [sssd] [monitor_quit] (0x1f7c0): Child [pam] exited 
gracefully
(2024-01-09 15:20:12): [sssd] [monitor_quit] (0x1f7c0): Terminating [nss][801]
(2024-01-09 15:20:12): [sssd] [monitor_quit] (0x1f7c0): Child [nss] exited 
gracefully
(2024-01-09 15:20:12): [sssd] [monitor_quit] (0x1f7c0): Terminating 
[dom.loc][755]
(2024-01-09 15:20:12): [sssd] [monitor_quit] (0x1f7c0): Child [dom.loc] exited 
gracefully
(2024-01-09 15:20:32): [sssd] [server_setup] (0x1f7c0): Starting with debug 
level = 0x0070
(2024-01-09 15:22:06): [sssd] [monitor_quit_signal] (0x1f7c0): Monitor received 
Завершено: terminating childr>
(2024-01-09 15:22:06): [sssd] [monitor_quit] (0x1f7c0): Returned with: 0
(2024-01-09 15:22:06): [sssd] [monitor_quit] (0x1f7c0): Terminating [pac][806]

[Freeipa-users] Re: Freeipa sudo

[Alexander Bokovoy via FreeIPA-users]

On Пят, 05 сту 2024, Dmitry Krasov via FreeIPA-users wrote:

Hello.

The FreeIpa user has sudo rights on a Ubuntu 2204 desktop machine that
is in the FreeIpa Linux domain. It can do sudo su, sudo apt install…

But when starting some services and basic installation of applications
from the market (in general, when it comes to gui admin rights), it
asks the local administrator password.

How can I fix this so the user’s password was requested from FreeIpa or
not at all?  --


Please provide more details. A demonstration of what exactly is being
done would definitely help, as well as journald logs (and sssd debug
logs).

It is unclear what do you mean by 'installation of applicaiton from the
market', for example. What is that? If this means using snap or flatpak,
how those get integrated to the system?

I suspect what you see is that some of PAM services on your Ubuntu
system have no pam_sss reference and thus don't even invoke SSSD to
perform authorization/authentication.



--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Re: Create IPA user via LDAP

[Alexander Bokovoy via FreeIPA-users]

On Аўт, 19 сне 2023, Ronald Wimmer 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/html/managing_idm_users_groups_hosts_and_access_control_rules/configuring-idm-for-external-provisioning-of-users_managing-users-groups-hosts#doc-wrapper


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.


Set them non-hashed. Why external system hashes them in LDIF?


--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Re: krb5kdc: No such file or directory

[Alexander Bokovoy via FreeIPA-users]

On Аўт, 02 сту 2024, Roberto Cornacchia via FreeIPA-users wrote:

Hi there, clients are having trouble with kerberos authentication:

$ kinit -V user
Using existing cache: xx:y
Using principal: u...@sub.example.com 
Password for u...@sub.example.com :
kinit: Generic error (see e-text) while getting initial credentials

On the ipa server, /var/log/krb5kdc.log says:

Dec 24 14:40:34 ipa01.sub.example.com krb5kdc[3324](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)}) <
IP>: NEEDED_PREAUTH: u...@sub.example.com
 for krbtgt/sub.example@sub.example.com,
Additional pre-authentication required
Dec 24 14:40:34 ipa01.sub.example.com krb5kdc[3324](info): closing down fd
11
Dec 24 14:40:51 ipa01.sub.example.com krb5kdc[3324](info): AS_REQ :
handle_authdata (2)
Dec 24 14:40:51 ipa01.sub.example.com krb5kdc[3324](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)}) <
IP>: HANDLE_AUTHDATA: user 
@SUB.EXAMPLE.COM  for krbtgt/
sub.example@sub.example.com, No such file or directory


^^^ this means the user roberto has no SID assigned. Look into numerous
discussions on this mailing list in 2023, there are plenty of suggested
actions in those threads.


Dec 24 14:40:51 ipa01.sub.example.com krb5kdc[3324](info): closing down fd
11
Dec 24 14:40:57 ipa01.sub.example.com krb5kdc[3324](info): AS_REQ (4 etypes
{aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17),
aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19)}) <
IP>: NEEDED_PREAUTH: ldap/
ipa01.sub.example@sub.example.com for krbtgt/
sub.example@sub.example.com, Additional pre-authentication required
Dec 24 14:40:57 ipa01.sub.example.com krb5kdc[3324](info): closing down fd
11
Dec 24 14:40:57 ipa01.sub.example.com krb5kdc[3324](info): AS_REQ (4 etypes
{aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17),
aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19)}) <
IP>: ISSUE: authtime 1703425257, etypes
{rep=aes256-cts-hmac-sha1-96(18), tkt=aes256-cts-hmac-sha1-96(18),
ses=aes256-cts-hmac-sha1-96(18)},
ldap/ipa01.sub.example@sub.example.com for
krbtgt/sub.example@sub.example.com
Dec 24 14:40:57 ipa01.sub.example.com krb5kdc[3324](info): closing down fd
11
Dec 24 14:40:57 ipa01.sub.example.com krb5kdc[3324](info): TGS_REQ (4
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)}) <
IP>: ISSUE: authtime 1703425257, etypes
{rep=aes256-cts-hmac-sha1-96(18), tkt=aes256-cts-hmac-sha1-96(18),
ses=aes256-cts-hmac-sha1-96(18)},
ldap/ipa01.sub.example@sub.example.com for
ldap/ipa02.sub.example@sub.example.com
Dec 24 14:40:57 ipa01.sub.example.com krb5kdc[3324](info): closing down fd
11

There are 2 ipa servers, ipa01 (Rocky 9.3, ipa 4.10.2) and ipa02 (Rock 9.1,
ipa4.10.0), both with CA and DNS. ipa02 is CRL master.
On both, ipa-healthcheck doesn't find any issue.

Also: kinit fails from within ipa01, succeeds from within ipa02.

The issue seems to be in ipa01, and I have already tried to reinstall it
from scratch. One thing that is different is the version.

Could you please help me figure out what's wrong?

Best regards,
Roberto





--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Re: possible issue with ipa-backup on RHEL 9.3

[Alexander Bokovoy via FreeIPA-users]

On Пят, 22 сне 2023, Charles Hedrick via FreeIPA-users wrote:

A bit more info. Looking at errors, a normal backup terminates with

[20/Dec/2023:23:01:32.943228301 -0500] - INFO - archive_copyfile - Copying 
/etc/dirsrv/slapd-CS-RUTGERS-EDU/pwdfile.txt to /var/lib/dirsrv/slapd-\
CS-RUTGERS-EDU/bak/CS-RUTGERS-EDU/config_files/pwdfile.txt
[20/Dec/2023:23:01:32.957342035 -0500] - INFO - archive_copyfile - Copying 
/etc/dirsrv/slapd-CS-RUTGERS-EDU/certmap.conf to /var/lib/dirsrv/slapd\
-CS-RUTGERS-EDU/bak/CS-RUTGERS-EDU/config_files/certmap.conf
[20/Dec/2023:23:01:32.969828971 -0500] - INFO - archive_copyfile - Copying 
/etc/dirsrv/slapd-CS-RUTGERS-EDU/slapd-collations.conf to /var/lib/dir\
srv/slapd-CS-RUTGERS-EDU/bak/CS-RUTGERS-EDU/config_files/slapd-collations.conf
[20/Dec/2023:23:01:32.983763256 -0500] - INFO - task_backup_thread - Backup 
finished.
[2

The backup that hung is missing the last line, "Backup finished." ldap
stopped giving normal responses about a minute later, according to the
access log.


This looks like a thing internal to 389-ds. If you'd see it reproduced,
make sure to have debuginfo packages for 389-ds and freeipa installed
and then attempt to get a backtrace from 389-ds processes before you'd
kill them.




From: Charles Hedrick
Sent: Friday, December 22, 2023 9:56 AM
To: freeipa-users@lists.fedorahosted.org 
Subject: possible issue with ipa-backup on RHEL 9.3

I just upgraded one of three servers from RHEL 9.2. to 9.3. I have a clone of 
our three servers, on which all three have been upgraded to 9.3.

All of the servers run a cron job

/sbin/ipa-backup --online --data > /usr/local/scripts/ipa-backup.log 2>&1

The LDAP server hung (needed kill -9) at about the time that job ran, on the 
production server but not the testing copy. Obviously I can't prove that the 
backup caused the hang, but it's suspicious. I've commented out the cron job, 
since the backup isn't actually all the useful. If we have to restore we'd use 
a snapshot of the VM.

The backup completed successfully on the clone. On the production server it 
failed. Here is the log:

Preparing backup on krb4.cs.rutgers.edu
Local roles match globally used roles, proceeding.
Backing up userRoot in CS-RUTGERS-EDU to LDIF
Waiting for LDIF to finish
Backing up CS-RUTGERS-EDU
Waiting for BAK to finish
cannot connect to 'ldapi://%2Frun%2Fslapd-CS-RUTGERS-EDU.socket':
The ipa-backup command failed. See /var/log/ipabackup.log for more information

I'm wondering whether there's a bug that only happens under load.

We're been doing this in production for years with no trouble up to RHEL 9.2.






--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Re: Grant extra permissions to System Accounts

[Alexander Bokovoy via FreeIPA-users]

On Аўт, 19 сне 2023, RA via FreeIPA-users wrote:

Hi,

I created a System Account as indicated at
https://www.freeipa.org/page/HowTo/LDAP#system-accounts and it works as
expected (it is used to perform LDAP bind for authentication in my
email application). The problem comes when I try to use it to read
additional attributes (required by postfix-ldap) in my users, for
example, mailAlternateAddress (it is not able to read the attribute).

As a workaround, I created a "regular" LDAP user and assigned the
permissions/roles required and it works, however, I don't think that a
dedicated user should be created to perform this task, am I wrong?

Considering the scenario described, I have a couple of questions: 
1. Is it possible to grant permissions to a System Account to read

those attributes? (I tried to add it to the roles/permissions using
memberOf but it didn't allow to add those attributes, I got a
permissions error even if I used my admin account to run ldapmodify)

2. What would be the "correct" way to do the configuration? (I mean
regular user? other?)


What you can do is to create a group, assign role/permission/privilege
to that group and manually add your system account to the group as a
member. To do so, the system account object should have nsMember
objectclass so that memberof plugin could add back a 'memberof:
DN-of-a-group' attribute to the system account one.

This way you can manage attributes' access to any system account. The
only drawback is that membership would be a manual operation to
add/remove using --addattr and --delattr options of `ipa group-mod`.

# ipa group-add sysaccount-members --nonposix

Added group "sysaccount-members"

  Group name: sysaccount-members

# ipa group-mod sysaccount-members  --addattr 
member=uid=sudo,cn=sysaccounts,cn=etc,dc=ipa1,dc=test
---
Modified group "sysaccount-members"
---
  Group name: sysaccount-members

# ipa group-show sysaccount-members --raw --all
  dn: cn=sysaccount-members,cn=groups,cn=accounts,dc=ipa1,dc=test
  cn: sysaccount-members
  member: uid=sudo,cn=sysaccounts,cn=etc,dc=ipa1,dc=test
  ipaUniqueID: a095e746-9f07-11ee-930c-fa163e1382c3
  objectClass: top
  objectClass: groupofnames
  objectClass: nestedgroup
  objectClass: ipausergroup
  objectClass: ipaobject


# ldapsearch -Y EXTERNAL -H ldapi://%2Frun%2Fslapd-IPA1-TEST.socket  -b  
uid=sudo,cn=sysaccounts,cn=etc,dc=ipa1,dc=test
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
# extended LDIF
#
# LDAPv3
# base  with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# sudo, sysaccounts, etc, ipa1.test
dn: uid=sudo,cn=sysaccounts,cn=etc,dc=ipa1,dc=test
objectClass: account
objectClass: simplesecurityobject
objectClass: top
objectClass: nsMemberOf
uid: sudo
userPassword:: some value
memberOf: cn=sysaccount-members,cn=groups,cn=accounts,dc=ipa1,dc=test

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1


I am adding the group with --non-posix option to avoid spending IDs for
this group as it will only be used in LDAP access controls and does not
need to be POSIX one.

--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Re: How to change default OTP algorithm from sha1 to sha256 or sha512

[Alexander Bokovoy via FreeIPA-users]

On Няд, 17 сне 2023, Jeff Kirkley via FreeIPA-users wrote:

Hello,

 Very new to freeipa but find it to be very powerful and very capable.
 I have been using Keycloak for some time now and am interested in
 using FreeIPA as a OTP password provider (if possible).

 I am running FreeIPA 4.10.2 and am having problems with a
 plain/regular user creating a OTP token from the GUI and the created
 token is based as SHA1.  I would like for it to be either SHA256 or
 SHA512.  I have spent many hours scouring the web and am unable to
 find where this is a user-selectable option under the user's login.
 I am also unable to find it in any of the settings while logged in as
 admin.  I did make a change to:

/usr/share/ipa/ui/js/freeipa/app.js

and changed the default to sha512 and if I were to login as admin and
create a new token for a user (testuser), I do have a GUI ability to
choose the strength of the OTP token.  However, this is not presented
to a normal user (belonging to only ipausers group).

How do I change/enable this ability for a plain user to login to
freeipa server, create a OTP token and change the hash strength?


https://pagure.io/freeipa/issue/6430 covers our state. There is also a
helpful table in the link
https://gist.github.com/gwelch-contegix/afa52c7b45693a19c198ab0bfb886fe2
about the state of authenticators that support (or rather not) other OTP
algorithms. Until that state changes, making a different default is
counter-productive as in most cases people will have to handle an
increasing amount of end user complaints about them not being able to
use a new OTP token in their software.

There is currently no plan to change existing FreeIPA Web UI to add that
default. You can already choose OTP algorithm when creating a token
from IPA CLI/API. New Web UI which hopefully will be put in production
next year will have ability to select the OTP algorithm.


--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Re: External IDP Configuration with OIDC - Zitadel

[Alexander Bokovoy via FreeIPA-users]

On Чцв, 14 сне 2023, Russ Long via FreeIPA-users wrote:

AHA! That did it. Changing to "Device Code" was what I needed.

I will get a FreeIPA docs PR together with an example of this setup if
you think that would be useful for others.


We don't really have IdP-specific documents. The workshop session uses
Keycloak to simplify demo setup. What you can do is to submit a pull
request to FreeIPA website:
https://github.com/freeipa/freeipa.github.io/tree/main/src/page, into
one of howto chapters.


--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Re: External IDP Configuration with OIDC - Zitadel

[Alexander Bokovoy via FreeIPA-users]

On Чцв, 14 сне 2023, Russ Long via FreeIPA-users wrote:

Thanks Alexander.

I did associate the IDP with the user account, and allowed that user to use the 
idp auth type.

That troubleshooting section helped, I was able to find this response after 
increasing the oidc debug level:

{"error":"unauthorized_client","error_description":"client missing grant type 
authorization_code"}

I'm unsure if this is something I need to change on the IPA or zitadel side.


On Zitadel side. See
https://zitadel.com/docs/guides/solution-scenarios/device-authorization
for an example of configuring the OIDC client on Zitadel side. Note that
you should add grant for 'Device Code'.


--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Re: External IDP Configuration with OIDC - Zitadel

[Alexander Bokovoy via FreeIPA-users]

On Чцв, 14 сне 2023, Alexander Bokovoy via FreeIPA-users wrote:

On Чцв, 14 сне 2023, Russ Long via FreeIPA-users wrote:

I'm working on trying to setup an external IDP using Zitadel, a newer open 
source IDP.

I honestly don't know enough about OIDC to figure out why this isn't working 
properly, so I'm hoping someone with some OIDC knowledge might be able to help 
me out.

IDP config in freeipa:
rlong@master:~$ ipa idp-show Zitadel
Identity Provider reference name: Zitadel
Authorization URI: https://DOMAIN.COM/oauth/v2/authorize
Device authorization URI: https://DOMAIN.COM/oauth/v2/device_authorization
Token URI: https://DOMAIN.COM/oauth/v2/token
User info URI: https://DOMAIN.COM/oidc/v1/userinfo
Client identifier: CLIENT_ID
Scope: name email profile
External IdP user identifier attribute: name

Testing user is setup for External IDP authentication, using the Username from 
Zitadel.

I might be missing where to look for errors, but I can't even find any
errors when I attempt to ssh to a host using the testing user.


Chapter 12 of the FreeIPA workshop covers troubleshooting as well:
https://freeipa.readthedocs.io/en/latest/workshop/12-external-idp-support.html

I assume you did associate the Zitadel IdP with a specific user account
and allowed that user to use 'idp' authentication type:
https://freeipa.readthedocs.io/en/latest/workshop/12-external-idp-support.html#associate-idp-reference-with-ipa-user

The rest please see in the troubleshooting section.


Another (obvious, right?) thing to check is that your IPA client (ssh
server) system actually has support for idp pre-authentication method.
This means it has SSSD that provides this krb5 pre-authentication
method: https://sssd.io/release-notes/sssd-2.7.0.html or later.


--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Re: External IDP Configuration with OIDC - Zitadel

[Alexander Bokovoy via FreeIPA-users]

On Чцв, 14 сне 2023, Russ Long via FreeIPA-users wrote:

I'm working on trying to setup an external IDP using Zitadel, a newer open 
source IDP.

I honestly don't know enough about OIDC to figure out why this isn't working 
properly, so I'm hoping someone with some OIDC knowledge might be able to help 
me out.

IDP config in freeipa:
rlong@master:~$ ipa idp-show Zitadel
 Identity Provider reference name: Zitadel
 Authorization URI: https://DOMAIN.COM/oauth/v2/authorize
 Device authorization URI: https://DOMAIN.COM/oauth/v2/device_authorization
 Token URI: https://DOMAIN.COM/oauth/v2/token
 User info URI: https://DOMAIN.COM/oidc/v1/userinfo
 Client identifier: CLIENT_ID
 Scope: name email profile
 External IdP user identifier attribute: name

Testing user is setup for External IDP authentication, using the Username from 
Zitadel.

I might be missing where to look for errors, but I can't even find any
errors when I attempt to ssh to a host using the testing user.


Chapter 12 of the FreeIPA workshop covers troubleshooting as well:
https://freeipa.readthedocs.io/en/latest/workshop/12-external-idp-support.html

I assume you did associate the Zitadel IdP with a specific user account
and allowed that user to use 'idp' authentication type:
https://freeipa.readthedocs.io/en/latest/workshop/12-external-idp-support.html#associate-idp-reference-with-ipa-user

The rest please see in the troubleshooting section.

--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Re: Create IPA user via LDAP

[Alexander Bokovoy via FreeIPA-users]

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/html/managing_idm_users_groups_hosts_and_access_control_rules/configuring-idm-for-external-provisioning-of-users_managing-users-groups-hosts#doc-wrapper



--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Re: Kerberos authentication only works with aes256-cts-hmac-sha1-96 for Windows 10 joined to RHEL IDM

[Alexander Bokovoy via FreeIPA-users]

On Пят, 01 сне 2023, Deepak Ramanath via FreeIPA-users wrote:


Thank you Alexander for your response and for clarifying on the observed 
behaviour.


I don't see any problem above: tickets requested by the client with IP
192.168.124.55 were issued by the KDC, so clearly they've got common
enctypes between them.


If the initial AS, TGT and TGS have agreed upon the common encryption
types, at what stage is the denial occurring? Because, I do not see any
logs when it is unsuccessful.


IPA KDC defaults to RFC8009 and only falls back to SHA-1-based ones
for trust to Active Directory. There are few places in MIT Kerberos KDC
where a choice of the signature or encryption type is made based on the
strongest key available for the krbtgt/... principal, which is always a
SHA-2-based one for new IPA deployments. For cross-realm operations we
have special logic to fall back to SHA-1-based ones for AD DCs. For
in-realm operations we don't and shouldn't as it would be a security
issue (downgrade of encryption algorithm to a less secure one).


So if I understand this correctly, despite having permitted_enctypes
set to all of these, aes256-cts-hmac-sha384-192,
aes128-cts-hmac-sha256-128, aes256-cts-hmac-sha1-96,
aes128-cts-hmac-sha1-96, camellia256-cts-cmac, camellia128-cts-cmac,
KDC prefers the strongest encryption, which perhaps is the
aes256-cts-hmac-sha384-192. Obviously the Windows OS does not support
this type.  If this is the case, how are the AS, TGT and TGS successful
and not the final login?


Windows does not just use Kerberos to perform the login. It does use DCE
RPC calls against domain controller. Have you looked at the Samba logs?


--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Re: Issues with password based authentication on IPA

[Alexander Bokovoy via FreeIPA-users]

On Пят, 01 сне 2023, Pradeep KNS wrote:

Hey Alexander,

I have tried installing a new IPA server with my expected ranges on my new
site and its working fine.Thanks for the document.

I have observed a couple of errors. POSIX ID's 4248,4141,4121,4258..etc.
all are my infra group id's.


[30/Nov/2023:05:17:36.931522914 -0500] - ERR - sidgen_task_thread - [file
ipa_sidgen_task.c, line 194]: Sidgen task starts ...
[30/Nov/2023:05:17:36.933841900 -0500] - ERR - sidgen_task_thread - [file
ipa_sidgen_task.c, line 199]: Sidgen task finished [0].
[30/Nov/2023:05:17:41.443256202 -0500] - ERR - schema-compat-plugin -
warning: no entries set up under ou=sudoers,dc=alpha-grep,dc=com
[30/Nov/2023:05:17:41.449472986 -0500] - ERR - schema-compat-plugin -
warning: no entries set up under cn=ng, cn=compat,dc=alpha-grep,dc=com
[30/Nov/2023:05:17:41.456705946 -0500] - ERR - schema-compat-plugin -
warning: no entries set up under cn=computers,
cn=compat,dc=alpha-grep,dc=com
[30/Nov/2023:05:17:41.457666134 -0500] - ERR - schema-compat-plugin -
Finished plugin initialization.
[30/Nov/2023:05:27:02.337803787 -0500] - ERR - find_sid_for_ldap_entry -
[file ipa_sidgen_common.c, line 521]: Cannot convert Posix ID [4141] into
an unused SID.


4141 is below base ID for the only ID range that could be used (starting
with 5000). You need to add a range similar to your $REALM_id_range but
which covers all these POSIX UID/GIDs.


[30/Nov/2023:05:27:02.338927487 -0500] - ERR - ipa_sidgen_add_post_op -
[file ipa_sidgen.c, line 149]: Cannot add SID to new entry.
[30/Nov/2023:06:03:06.173948392 -0500] - ERR - find_sid_for_ldap_entry -
[file ipa_sidgen_common.c, line 521]: Cannot convert Posix ID [4121] into
an unused SID.


Same here.


[30/Nov/2023:06:03:06.174922473 -0500] - ERR - ipa_sidgen_add_post_op -
[file ipa_sidgen.c, line 149]: Cannot add SID to new entry.
[30/Nov/2023:06:22:36.616707461 -0500] - ERR - rid_to_sid_with_check -
[file ipa_sidgen_common.c, line 384]: SID
[S-1-5-21-3258431096-680571367-3483437258-16054] is already used.


This SID is already used by some other object.


[30/Nov/2023:06:24:53.185373410 -0500] - ERR - find_sid_for_ldap_entry -
[file ipa_sidgen_common.c, line 521]: Cannot convert Posix ID [4258] into
an unused SID.


Same here -- 4258 is below 5000.


[30/Nov/2023:06:24:53.186107898 -0500] - ERR - ipa_sidgen_add_post_op -
[file ipa_sidgen.c, line 149]: Cannot add SID to new entry.
[30/Nov/2023:07:07:48.738323141 -0500] - ERR - find_sid_for_ldap_entry -
[file ipa_sidgen_common.c, line 521]: Cannot convert Posix ID [4249] into
an unused SID.


Same here.


[30/Nov/2023:07:07:48.739492958 -0500] - ERR - ipa_sidgen_add_post_op -
[file ipa_sidgen.c, line 149]: Cannot add SID to new entry.
[30/Nov/2023:08:10:33.205867886 -0500] - ERR - find_sid_for_ldap_entry -
[file ipa_sidgen_common.c, line 521]: Cannot convert Posix ID [4249] into
an unused SID.
[30/Nov/2023:08:10:33.206759596 -0500] - ERR - ipa_sidgen_add_post_op -
[file ipa_sidgen.c, line 149]: Cannot add SID to new entry.
[30/Nov/2023:08:33:53.787156179 -0500] - ERR - find_sid_for_ldap_entry -
[file ipa_sidgen_common.c, line 521]: Cannot convert Posix ID [4249] into
an unused SID.
[30/Nov/2023:08:33:53.788186638 -0500] - ERR - ipa_sidgen_add_post_op -
[file ipa_sidgen.c, line 149]: Cannot add SID to new entry.
[root@ipa- ~]#


[root@ipa-~]# ipa user-show test --all --raw
 dn: uid=test,cn=users,cn=accounts,dc=$REAL
 uid: test
 givenname: test
 sn: test
 cn: test
 initials: TE
 homedirectory: /home/test
 gecos: Test
 loginshell: /bin/bash
 krbcanonicalname: test@$REALM.COM
 krbprincipalname: kpradeep@$REALM.COM
 uidnumber: 5708
 gidnumber: 4141
 sshpubkeyfp:
 nsaccountlock: FALSE
 has_password: TRUE
 has_keytab: TRUE
 displayName: Test
 ipaNTSecurityIdentifier: S-1-5-21-3258431096-680571367-3483437258-1708
 ipaSshPubKey: 
 ipaUniqueID: 
 krbExtraData: 
 krbLastAdminUnlock: 20231130174441Z
 krbLastPwdChange: 20231130174540Z
 krbLoginFailedCount: 0
 krbPasswordExpiration: 20240228174540Z
 krbTicketFlags: 128
 memberof: cn=admin,cn=groups,cn=accounts,dc=$real
 memberof: cn=ipausers,cn=groups,cn=accounts,dc=$real
 memberofindirect:
ipaUniqueID=8c81c2c6-8f6b-11ee-b685-a68c8b95f346,cn=sudorules,cn=sudo,dc=$real
 mepManagedEntry: cn=test,cn=groups,cn=accounts,dc=$real
 objectClass: top
 objectClass: person
 objectClass: organizationalperson
 objectClass: inetorgperson
 objectClass: inetuser
 objectClass: posixaccount
 objectClass: krbprincipalaux
 objectClass: krbticketpolicyaux
 objectClass: ipaobject
 objectClass: ipasshuser
 objectClass: ipaSshGroupOfPubKeys
 objectClass: mepOriginEntry
 objectClass: ipantuserattrs


[root@ipa- ~]# ipa idrange-find --all --raw

2 ranges matched

 dn: cn=$REALM_id_range,cn=ranges,cn=etc,dc=$real
 cn: $REALM_id_range
 ipabaseid: 5000
 ipaidrangesize: 1995001
 ipabaserid: 1000
 ipasecondarybaserid: 1
 iparangetype: ipa-local
 objectclass: top
 objectclass: ipaIDrange
 objectclass: 

[Freeipa-users] Re: Kerberos authentication only works with aes256-cts-hmac-sha1-96 for Windows 10 joined to RHEL IDM

[Alexander Bokovoy via FreeIPA-users]

On Пят, 01 сне 2023, Deepak Ramanath via FreeIPA-users wrote:

I have a Windows 10 server joined to a RedHat IDM (RHEL 8.9) realm
using Kerberos. When a user tries to authenticate on a Windows 10
server, the following error is shown


Just to be clear, we explicitly do not support this use case. Any
success on this path is a mistake of yours. ;)


"We cannot sign you in with this credential because your domain isn't
available"

On the IDM, looking at the `/var/log/krb5kdc.log`, I see the following...

Nov 30 23:08:17 idm.server.local krb5kdc[11775](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), UNSUPPORTED:(-135), 
UNSUPPORTED:des-cbc-md5(3)})
192.168.124.55: NEEDED_PREAUTH: win.user(a)server.local for
krbtgt/server.local(a)server.local, Additional pre-authentication required
Nov 30 23:08:17 idm.server.local krb5kdc[11774](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), UNSUPPORTED:(-135), 
UNSUPPORTED:des-cbc-md5(3)})
192.168.124.55: ISSUE: authtime 1701385697, etypes 
{rep=aes256-cts-hmac-sha1-96(18),
tkt=aes256-cts-hmac-sha384-192(20), ses=aes256-cts-hmac-sha1-96(18)},
win.user(a)server.local for krbtgt/server.local(a)server.local
Nov 30 23:08:17 idm.server.local krb5kdc[11775](info): TGS_REQ (5 etypes
{aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17), 
DEPRECATED:arcfour-hmac(23),
DEPRECATED:arcfour-hmac-exp(24), UNSUPPORTED:(-135)}) 192.168.124.55: ISSUE: 
authtime
1701385697, etypes {rep=aes256-cts-hmac-sha1-96(18), 
tkt=aes256-cts-hmac-sha1-96(18),
ses=aes256-cts-hmac-sha1-96(18)}, win.user(a)server.local for
host/win-server.server.local(a)server.local


I don't see any problem above: tickets requested by the client with IP
192.168.124.55 were issued by the KDC, so clearly they've got common
enctypes between them.


In the `/etc/crypto-policies/back-ends/krb5.config`, `libdefaults` has been set 
to

[libdefaults]
permitted_enctypes = aes256-cts-hmac-sha384-192 aes128-cts-hmac-sha256-128
aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 camellia256-cts-cmac 
camellia128-cts-cmac

Interestingly, if all encryption types are removed except 
aes256-cts-hmac-sha1-96 from the
permitted_enctypes, the authentication on Windows 10 is successful.

Any idea why only setting to aes256-cts-hmac-sha1-96 works while a list of 
supported
methods including aes256-cts-hmac-sha1-96 does not?


Windows systems do not support RFC8009 encryption types (SHA-2-based) at
all. Microsoft engineer gave a hint they are working on their support
for ~2025 but it will not be backported.

IPA KDC defaults to RFC8009 and only falls back to SHA-1-based ones
for trust to Active Directory. There are few places in MIT Kerberos KDC
where a choice of the signature or encryption type is made based on the
strongest key available for the krbtgt/... principal, which is always a
SHA-2-based one for new IPA deployments. For cross-realm operations we
have special logic to fall back to SHA-1-based ones for AD DCs. For
in-realm operations we don't and shouldn't as it would be a security
issue (downgrade of encryption algorithm to a less secure one).


--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Re: Constrained delegation for host/service principals broken on RHEL 8 servers?

[Alexander Bokovoy via FreeIPA-users]

On Чцв, 07 вер 2023, Sam Morris via FreeIPA-users wrote:

On 07/09/2023 13:35, Alexander Bokovoy via FreeIPA-users wrote:

On Чцв, 07 вер 2023, Sam Morris wrote:
On Wed, Sep 06, 2023 at 02:50:32PM +0300, Alexander Bokovoy via 
FreeIPA-users wrote:

It would help to see logs (krb5kdc.log) from RHEL8 servers for this
communication, both on ipa5/ipa6 and back to xoanon.


I've created a script to test this automatically.


Thank you!

I filed https://pagure.io/freeipa/issue/9448 to track this issue.
I'll be on vacation next week and Julien (krb5 maintainer) is on
vacation too, so we'll look at it after we are both back to work.


You're welcome, enjoy your vacation!


I want to close down a loop here. We ended up implementing a dynamic
Kerberos PAC ticket signature enforcement mechanism to address
cross-version interoperability issue.

https://access.redhat.com/articles/7046409 documents fixes to this
issue, thanks to Julien (krb5 maintainer). If you don't have free RHEL
developer subscription, then one can be subscribed to at
https://developers.redhat.com/about.


--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue