from:"Alexander Bokovoy via FreeIPA\-users"

[Freeipa-users] Re: converting admin account to service account or disable its webui login.

2024-09-13 Thread Alexander Bokovoy via FreeIPA-users


On Пят, 13 вер 2024, Tolgay Gul via FreeIPA-users wrote:

Thanks,

The idea is not to create a new admin account—I don't think I put that
in my question, or it is unclear. I need to disable all the shared
usernames but find a way to host registrations on the freeipa via a
command.

ipa-client-install --mkhomedir --server=auth.abc --domain bbb.abs.com--realm 
BBB.ABC.COM --force-join -U 
--another-way-without-password-or-username-like-ssh-key-or-kerberors-authentication


You need to have some users that have rights to deploy hosts.

Effectively, these users will need to be granted permissions similar to
what admins group membership grants you.

Being a member of admins group does not mean these users 'share
usernames'. They have their own accounts, with their own ways of
authenticating. They share set of permissions granted to them via
membership of admins group.


--
/ 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: ipaDomainResolutionOrder in SSSD not found in bind DN

2024-09-12 Thread Alexander Bokovoy via FreeIPA-users


On Чцв, 12 вер 2024, Daniel Pätzold via FreeIPA-users wrote:

Hi, i am using docker image freeipa/freeipa-server:almalinux-9

and did use docker-compose.yml:

...

    hostname: ipa.example.com
    environment:
  IPA_SERVER_HOSTNAME: ipa.example.com
  TZ: "Europe/Berlin"
  PASSWORD: 'XXX'
#  DEBUG_NO_EXIT: 1
    command:
  - -U
  - --domain=clients.ipa.example.com
# Must match the last part of the Domain-Name and must be upper case and
routed to the domain
  - --realm=EXAMPLE.COM


This is a mistake: you should keep the realm and the primary domain the
same. Do not make deviate from this rule. 


Another mistake is that you are trying to use a IPA server hostname
equal to the domain name: ipa.example.com while clearly there is going
to be a domain clients.ipa.example.com, so ipa.example.com is a domain
zone.

IPA server installer derives --domain from hostname's if unspecified
(.e.g ipa.example.com -> domain.com -> base DN will be
dc=example,dc=com). It also prevents having a hostname equal to the DNS
domain.

But if --domain was specified, it will use that value to generate base DN
(dc=clients,dc=ipa,dc=example,dc=com). The problem is that all the rest
of the code expects realm be equal to primary domain and thus base DN be
dc=example,dc=com.

If you want to deploy in clients.ipa.example.com but still use
EXAMPLE.COM, don't specify --domain other than example.com. Create
initial server in a DNS zone that is accessible prior to installation or
will be directly created during installation if installing with
integrated DNS. Make sure that the DNS domain which is equal to the one
of Kerberos realm is owned by you (or created by the integrated DNS).

Integrated DNS case (--setup-dns) is important to understand because you
are deploying DNS zone for --domain value here. IPA installer will not
create any other DNS zone inside this new DNS zone and it will not
create a DNS zone for the hostname of IPA server if it is outside of the
primary DNS domain as well. DNS zone equal to Kerberos realm must have
corresponding DNS records pointing to IPA servers. If not using
integrated DNS, a sample zone file will be generated.

In general:

 - DNS zones will have to exist prior to deployment or expected to be
   created during the deployment. However, only DNS zone for
   the primary domain will be created by IPA installer. (Reverse zones
   are a different story but it is not relevant here).

 - There is a direct relationship between primary domain (specified with
   --domain), Kerberos realm (--realm), and LDAP base DN. Primary IPA
   domain must always be equal to IPA Kerberos realm. DNS zone for the
   primary domain must be owned by IPA deployment in a sense that no
   other Kerberos realm would be using it and DNS records for IPA
   Kerberos realm should be present in it.

 - if you want to deploy IPA clients outside of the primary IPA DNS
   domain, it is enough to specify --domain  to
   allow autodiscovery, regardless of the DNS domain used. Man page for
   ipa-client-install has a lot of details about that.

 - if you want to deploy IPA replicas outside of the primary IPA DNS
   domain, make sure to use proper --domain for the primary domain, not
   your DNS domain of the replica.

Most of these details are already described at
https://www.freeipa.org/page/Deployment_Recommendations



  - --http-pin=XXX
  - --dirsrv-pin=XXX
  - --setup-dns
#  - --no-host-dns
# Both passwords will be taken from env PASSWORD:
#  - --ds-password=SOMEThinK
#  - --admin-password=SOMEThinK
#NTP - not needed, this is the server which time is taken from
/etc/localtime see volumes
#This server has also a chrony-daemon running here to sync time
  - --no-ntp
#  - --ntp-server=172.0.0.11
  - --auto-forwarders
#  - --forwarder=192.168.178.1
#Error: Unable to determine the amount of available RAM
  - --skip-mem-check

...

where ipa-server-install is called with arguments of "command:"

The DNS is set up right :

DNS Resource Records: clients.ipa.example.com.
...

The service is setup to be on hostname: Service:
DNS/ipa.example@example.com

But for LDAP i cannot see ressources, only the service in freeipa:
Service: ldap/ipa.example@example.com

Using  an Browser (jxplorer) to access LDAP, connecting to
cn=etc,dc=clients,dc=ipa,dc=example,dc=com i can see a "changelog"
directly after connecting

cn  changelog
objectClass nsContainer
objectClass top

changeNumber45
changeTime  20240911092231Z
changeType  modify
objectClass changelogentry
objectClass extensibleObject
objectClass top
targetDnidnsname=clients.ipa.example.com.,cn=dns,dc=example,dc=com
changes (non string data)
targetuniqueid  64af5c10xxx

Don't know what that means, but it seems like it redirects to
cn=etc,dc=example,dc=com, as the directory list is showing
dc=example,dc=com only.

in cmd ldapsearch still, i cannot query
cn=etc,dc=clients,dc=ipa,dc=ex

[Freeipa-users] Re: Cert renewal fails, error 4001 ipa: Certificate Authority not found

2024-09-11 Thread Alexander Bokovoy via FreeIPA-users


On Аўт, 10 вер 2024, N A via FreeIPA-users wrote:

Alexander, we appreciate your help.

Running ipa-server-upgrade did indeed fix the issue and we were able to
successfully run getcert resubmit -i  on the replica to renew the
expiring certificates.


Thanks for reporting back the progress. 
Glad that it worked for 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: Cert renewal fails, error 4001 ipa: Certificate Authority not found

2024-09-10 Thread Alexander Bokovoy via FreeIPA-users

On Аўт, 10 вер 2024, N A via FreeIPA-users wrote:

Alexander, thank you for your time looking over this issue and posting
your suggestion. We have some followup questions regarding this method.

How long does the upgrade take, and will the IPA server be unavailable
during that time? Do we have to do this on both FreeIPA instances?
If the upgrade errors, is it easy to revert or might we get stuck in a
bad state?

The documentation has more details and suggestions. I was unable to find
a similar document for RHEL 7 in a quick search, so there is RHEL 9
version:

https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/installing_identity_management/update-downgrade-ipa_installing-identity-management#updating_idm_packages

ipa-server-upgrade is typically run behind the scenes during each
package upgrade. If IPA detects that a particular system has RPM
packages upgraded, on next IPA service restart it will run
ipa-server-upgrade automatically.

IPA server will be unavailable for operations during the time when
ipa-server-upgrade runs.

Typically, again, data upgrade should not lead to a broken situation --
no more than it was before the upgrade started. Especially in this case
where you are not updating actual executables but rather would be
running upgrade process to identify and add missing entries.

There is no guarantee. After all, FreeIPA is provided under GNU GPL v3
licence which has sections 15-17 that are explicit about disclaimer of
warranty, limitation of liability, and their interpretation.

--
/ 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: Cert renewal fails, error 4001 ipa: Certificate Authority not found

2024-09-09 Thread Alexander Bokovoy via FreeIPA-users


On Пан, 09 вер 2024, Nick Allen via FreeIPA-users wrote:

Hello, we have two FreeIPA servers, one is configured as CA master. We
noticed the 2-year expiration of the certificates on one of the replicas is
approaching and the auto-renewal is failing with a CA_UNREACHABLE status,
error code 4001.

Note that these two FreeIPA servers are replicas of a since decommissioned
original that was removed from the topology a while back.

Per Florence's suggestion to add debug logs to http daemon and resending a
cert request (thank you), we see the following errors in
/var/log/httpd/error_log:


This all sounds like IPA CA LDAP entry is missing. It should be added by
the upgrade code, even in IPA 4.6 series.

You can run manually as root on that server:

# ipa-server-upgrade

This should add CA entries. On my system I do have them already do
running ipa-server-upgrade only looks them up:

[10/Sep/2024:05:42:30.192479317 +] conn=5 op=249 SRCH 
base="cn=cas,cn=ca,dc=ipa1,dc=test" scope=0 filter="(objectClass=*)" attrs=ALL
[10/Sep/2024:05:42:30.192674713 +] conn=5 op=249 RESULT err=0 tag=101 
nentries=1 wtime=0.92394 optime=0.000196278 etime=0.000287429
[10/Sep/2024:05:42:30.192957674 +] conn=5 op=250 SRCH 
base="cn=ipa,cn=cas,cn=ca,dc=ipa1,dc=test" scope=0 filter="(objectClass=*)" 
attrs=ALL
[10/Sep/2024:05:42:30.193043505 +] conn=5 op=250 RESULT err=0 tag=101 
nentries=1 wtime=0.96161 optime=0.87393 etime=0.000182432

On your system I'd imagine cn=ipa,cn=cas,cn=ca, will not be found
(err=32) and will then follow up with the creation of that entry. You
will see that in the dirsrv logs.




[Mon Sep 09 15:16:37.590119 2024] [:error] [pid 148275] ipa: DEBUG: WSGI
wsgi_dispatch.__call__:
[Mon Sep 09 15:16:37.590182 2024] [:error] [pid 148275] ipa: DEBUG:
KerberosWSGIExecutioner.__call__:
[Mon Sep 09 15:16:37.598332 2024] [:error] [pid 148275] ipa: DEBUG: Created
connection context.ldap2_139787230862608
[Mon Sep 09 15:16:37.598389 2024] [:error] [pid 148275] ipa: DEBUG: WSGI
WSGIExecutioner.__call__:
[Mon Sep 09 15:16:37.603355 2024] [:error] [pid 148275] ipa: DEBUG: raw:
cert_request(u'xxx', profile_id=u'caIPAserviceCert',
principal=u'ldap/host.company.local@COMPANY.LOCAL', add=True,
version=u'2.51')
[Mon Sep 09 15:16:37.603985 2024] [:error] [pid 148275] ipa: DEBUG:
cert_request(, request_type=u'pkcs10',
profile_id=u'caIPAserviceCert', cacn=u'ipa',
principal=ipapython.kerberos.Principal('ldap/host.company.local@COMPANY.LOCAL'),
add=True, chain=False, all=False, raw=False, version=u'2.51')
[Mon Sep 09 15:16:37.604207 2024] [:error] [pid 148275] ipa: DEBUG: raw:
ca_is_enabled(version=u'2.237')
[Mon Sep 09 15:16:37.604264 2024] [:error] [pid 148275] ipa: DEBUG:
ca_is_enabled(version=u'2.237')
[Mon Sep 09 15:16:37.605642 2024] [:error] [pid 148275] ipa: DEBUG:
retrieving schema for SchemaCache
url=ldapi://%2fvar%2frun%2fslapd-COMPANY-LOCAL.socket
conn=
[Mon Sep 09 15:16:37.851204 2024] [:error] [pid 148275] ipa: DEBUG: raw:
ca_show(u'ipa', chain=False, all=False, version=u'2.237')
[Mon Sep 09 15:16:37.851345 2024] [:error] [pid 148275] ipa: DEBUG:
ca_show(u'ipa', rights=False, chain=False, all=False, raw=False,
version=u'2.237')
[Mon Sep 09 15:16:37.851457 2024] [:error] [pid 148275] ipa: DEBUG: raw:
ca_is_enabled(version=u'2.237')
[Mon Sep 09 15:16:37.851521 2024] [:error] [pid 148275] ipa: DEBUG:
ca_is_enabled(version=u'2.237')
[Mon Sep 09 15:16:37.858466 2024] [:error] [pid 148275] ipa: DEBUG: WSGI
wsgi_execute PublicError: Traceback (most recent call last):
[Mon Sep 09 15:16:37.858486 2024] [:error] [pid 148275]   File
"/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 369, in
wsgi_execute
[Mon Sep 09 15:16:37.858489 2024] [:error] [pid 148275] result =
command(*args, **options)
[Mon Sep 09 15:16:37.858506 2024] [:error] [pid 148275]   File
"/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 450, in __call__
[Mon Sep 09 15:16:37.858510 2024] [:error] [pid 148275] return
self.__do_call(*args, **options)
[Mon Sep 09 15:16:37.858512 2024] [:error] [pid 148275]   File
"/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 478, in
__do_call
[Mon Sep 09 15:16:37.858515 2024] [:error] [pid 148275] ret =
self.run(*args, **options)
[Mon Sep 09 15:16:37.858518 2024] [:error] [pid 148275]   File
"/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 800, in run
[Mon Sep 09 15:16:37.858520 2024] [:error] [pid 148275] return
self.execute(*args, **options)
[Mon Sep 09 15:16:37.858522 2024] [:error] [pid 148275]   File
"/usr/lib/python2.7/site-packages/ipaserver/plugins/cert.py", line 657, in
execute
[Mon Sep 09 15:16:37.858525 2024] [:error] [pid 148275] ca_obj =
api.Command.ca_show(ca, all=all, chain=chain)['result']
[Mon Sep 09 15:16:37.858527 2024] [:error] [pid 148275]   File
"/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 450, in __call__
[Mon Sep 09 15:16:37.858530 2024] [:error] [pid 148275] return
self.__do_call(*args, **opti

[Freeipa-users] Re: FreeIPA / sudo rules / option / secure_path

2024-09-03 Thread Alexander Bokovoy via FreeIPA-users


On Аўт, 03 вер 2024, alexey safonov via FreeIPA-users wrote:

Hi,

I've checked all related output in Google search and this mailing
list, but still have no answer to a question, why secure_path option
is ignored by IPA?

here is what I have in IPA
 Sudo Option: !requiretty, !authenticate,
secure_path=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin

here is the output

[aaa@ ~]$ sudo printenv PATH
/sbin:/bin:/usr/sbin:/usr/bin

for some reason that path is only taken from /etc/sudoers file


IPA LDAP is just a store for SUDO rules. The heavy lifting is done by
SSSD sudoers plugin. You can use
https://sssd.io/troubleshooting/sudo.html to generate SUDO and SSSD logs
and see whether a particular rule or options are present and sent to
SUDO for processing.



--
/ 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: krb5PrincipalName - is it there?

2024-08-28 Thread Alexander Bokovoy via FreeIPA-users

On Срд, 28 жні 2024, Francis Augusto Medeiros-Logeay wrote:

On 28 Aug 2024, at 15:37, Alexander Bokovoy wrote:

On Срд, 28 жні 2024, Francis Augusto Medeiros-Logeay via FreeIPA-users wrote:

On 28 Aug 2024, at 15:02, Rob Crittenden wrote:

Francis Augusto Medeiros-Logeay via FreeIPA-users wrote:

Hi,

I have configured Keycloak with FreeIPA for kerberos authentication.

It has worked fine, but today I noticed something:

Keycloak seems to look up krb5PrincipalName attribute to look for the
user principal. However, I don't see that attribute when I perform an
ldapsearch. Is it there at all?

I also tried to remove this from keycloak, because it says that when
this is empty it will just look for the username instead of user@domain.
But somehow it adds krb5PrincipalName again.

Is it keycloak that has a problem by not allowing me to remove
krb5PrincipalName, or is it FreeIPA that somehow lost that attribute?

Best,
Francis

Looks like a Keycloak issue. Check out
https://github.com/keycloak/keycloak/issues/25294

Thanks. But should I have this atteibute in Freeipa? I dont see it when
performance en ldapsearch.

Keycloak allows you to configure what LDAP attributes correspond to what
properties. Use proper LDAP attribute for FreeIPA, in this case it is
krbPrincipalName. This can be chosen by setting LDAP vendor to 'rhds'.

I tried that. But I don’t see that attribute either on ldapsearch.
Maybe I am not using the right permissions when searching.

Most likely you are searching without authentication. The basic ACI we
have to allow krbprincipalname read/search/compare to all authenticated
LDAP binds:

aci: (targetattr = "krbcanonicalname || krblastpwdchange || krbpasswordexpiration || krbprincipalaliases ||
krbprincipalexpiration || krbprincipalname || krbprincipaltype || nsaccountlock")(targetfilter =
"(objectclass=posixaccount)")(version 3.0;acl "permission:System: Read User Kerberos
Attributes";allow (compare,read,search) userdn = "ldap:///all";;)

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

[Freeipa-users] Re: krb5PrincipalName - is it there?

2024-08-28 Thread Alexander Bokovoy via FreeIPA-users


On Срд, 28 жні 2024, Francis Augusto Medeiros-Logeay via FreeIPA-users wrote:




On 28 Aug 2024, at 15:02, Rob Crittenden  wrote:

Francis Augusto Medeiros-Logeay via FreeIPA-users wrote:

Hi,

I have configured Keycloak with FreeIPA for kerberos authentication.

It has worked fine, but today I noticed something:

Keycloak seems to look up krb5PrincipalName attribute to look for the
user principal. However, I don't see that attribute when I perform an
ldapsearch. Is it there at all?

I also tried to remove this from keycloak, because it says that when
this is empty it will just look for the username instead of user@domain.
But somehow it adds krb5PrincipalName again.

Is it keycloak that has a problem by not allowing me to remove
krb5PrincipalName, or is it FreeIPA that somehow lost that attribute?

Best,
Francis



Looks like a Keycloak issue. Check out
https://github.com/keycloak/keycloak/issues/25294


Thanks. But should I have this atteibute in Freeipa? I dont see it when 
performance en ldapsearch.


Keycloak allows you to configure what LDAP attributes correspond to what
properties. Use proper LDAP attribute for FreeIPA, in this case it is
krbPrincipalName. This can be chosen by setting LDAP vendor to 'rhds'.


--
/ 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: Running FreeIPA in same Domain as AD without any interaction

2024-08-28 Thread Alexander Bokovoy via FreeIPA-users


On Срд, 28 жні 2024, patrik uytterhoeven via FreeIPA-users wrote:

Hi,

I would like to know if i can install the FreeIPA for my linux servers
in same domain that is being used by AD for the windows servers without
any trusts between both servers I like to keep the domain the same name
but also want to be sure that this will not create any conflicts


We do not support that, for various reasons. This will create conflicts
at the very fundamental level.

1. AD domain controller owns its DNS domain. Any host in the same DNS
domain is considered belonging to this AD domain. Child DNS domains
(DNS subdomains, e.g. sub.example.com for example.com) can belong
either to the AD domain within the same forest or to a separate
forest.

2. Each AD forest has at least one DNS domain associated with it. When
trust is established between two forests (cross-forest trust),
forest root level domain controllers from both sides check the other
forest's list of associated DNS domains for conflicts with their
own lists.

3. Note also that AD customary expects that forest root level DNS domain
has the same name as the realm. E.g., CORP.FOO realm should have
forest root level DNS domain corp.foo. AD DC will attempt to do
service discovery via DNS by taking the realm name and using it as
DNS domain name. Thus, at least the DNS domain named as IPA realm
must have enough SRV/TXT records to point to proper KDC and DC
records for IPA.

On Linux side, both MIT Kerberos and Heimdal Kerberos depend on DNS
discovery for a number of features. While there are ways to disable some
of the discovery process, it cannot be avoided completely. We do not
support that in FreeIPA. For manual configuration it means a nightmare
of maintaining such setup that you'd always have to have DNS to realm
and KDC mappings manual.

In addition to that, login of AD users to IPA systems will not be
possible. Both would have the same Kerberos realm and cannot be
distinguished in the configuration. SSSD does not support this kind of
setup 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: authselect profile sssd and with-faillock feature

2024-08-27 Thread Alexander Bokovoy via FreeIPA-users


On Аўт, 27 жні 2024, Ranbir via FreeIPA-users wrote:

Hello,

Is it possible to enable the sssd profile feature, "with-faillock", for
local accounts, even root, on a freeipa enrolled AlmaLinux 8 host in a
freeipa domain that's in a trust with AD? What a mouthful.

I can enable "with-faillock", but it appears to enable it for local and
trusted users. Please correct me if I'm wrong.


Did you look into man page faillock.conf(5)?

   local_users_only
   Only track failed user authentications attempts for local
   users in /etc/passwd and ignore centralized (AD, IdM, LDAP,
   etc.) users. The faillock(8) command will also no longer
   track user failed authentication attempts. Enabling this
   option will prevent a double-lockout scenario where a user is
   locked out locally and in the centralized mechanism.

You don't need to modify PAM configuration for changing these settings,
as they can be updated independently in /etc/security/faillock.conf



--
/ 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: Passkeys and SSH

2024-08-25 Thread Alexander Bokovoy via FreeIPA-users


Please do not drop the mailing list discussion.

On Sun, 25 Aug 2024, Entrepreneur AJ wrote:
How would this effect FreeIPA as it was that server I was connecting 
to via SSH?


As I said, you'd use Kerberos authentication to authenticate to that
server, not your SSH key or a passkey on the server. And for
authentication once you logged into that server, you'd use your Kerberos
ticket as well, through pam_sss_gss use.

I'd recommend you to read through both SSSD and FreeIPA design pages for
passkey authentication.

https://sssd.io/design-pages/passkey_authentication.html
https://sssd.io/design-pages/passkey_kerberos.html
https://freeipa.readthedocs.io/en/latest/designs/passkeys.html





On 25/08/2024 15:22, Alexander Bokovoy wrote:

On Sun, 25 Aug 2024, Entrepreneur AJ via FreeIPA-users wrote:

Hi All,

I have setup a new instance of FreeIPA yesterday on Fedora 40 
VPS, all seems to be well.
I have reinstalled my laptop and enrolled it to the new install, 
all seems to be well.
I have enrolled my Yubikey as a passkey, didn't initially work 
turned out passkey support doesn't work with SDDM so no kde, 
tried with basic gnome install didn't work found I had to change 
lightdm to gdm for it to work.
I generated a new resident SSH key on my yubikey and added it to 
FreeIPA which allowed ssh to work with my key.
I then tried to run a sudo command on the remote vps which is 
allowed as I have a sudo rule in place which works locally.


Issue is it then asks for my passkey and pin but can't receive 
the data from my passkey because I am running over ssh.


Is there a work around so I don't need my passkey to use sudo on 
remote nodes eg VPS's and servers but require it for laptops and 
desktops where the user is physically in front of?


Passkey authentication requires local key presence and is supposed to be
used on the system where you have that key. In IPA environments it means
also that if you are online, you'd get a Kerberos ticket granting ticket
as a result of the successful login with a passkey.

That Kerberos ticket can then be used to request a service ticket and
authenticate against remote SSH servers. Not using your SSH key but the
actual Kerberos ticket.

You can also allow forwarding that Kerberos ticket granting ticket to
the SSH server, with ssh's option '-o GSSAPIDelegateCredentials=yes'.
This is typically not recommended but can be done. If you do so, then on
the SSH server you can use the Kerberos ticket to request a service
ticket and authenticate over PAM, with pam_sss_gss module.

On Fedora and RHEL-like systems you can use 'authselect' to enable
pam_sss_gss usage:

# authselect enable-feature with-gssapi

You also need to enable list of allowed PAM services in sssd.conf, this
is what authselect will tell you once you run that command. Man page for
pam_sss_gss(8) gives some examples for sudo.

You can also limit what kind of the initial Kerberos ticket could be
used to authenticate over the PAM with pam_sss_gss. For example, you can
force use of passkey-obtained Kerberos tickets and nothing else for sudo
access:

---
[domain/my.ipadomain.com]
pam_gssapi_services = sudo, sudo-i

[pam]
pam_gssapi_indicators_map = sudo:passkey, sudo-i:passkey








--
/ 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: Passkeys and SSH

2024-08-25 Thread Alexander Bokovoy via FreeIPA-users


On Sun, 25 Aug 2024, Entrepreneur AJ via FreeIPA-users wrote:

Hi All,

I have setup a new instance of FreeIPA yesterday on Fedora 40 VPS, all seems to 
be well.
I have reinstalled my laptop and enrolled it to the new install, all seems to 
be well.
I have enrolled my Yubikey as a passkey, didn't initially work turned out 
passkey support doesn't work with SDDM so no kde, tried with basic gnome 
install didn't work found I had to change lightdm to gdm for it to work.
I generated a new resident SSH key on my yubikey and added it to FreeIPA which 
allowed ssh to work with my key.
I then tried to run a sudo command on the remote vps which is allowed as I have 
a sudo rule in place which works locally.

Issue is it then asks for my passkey and pin but can't receive the data from my 
passkey because I am running over ssh.

Is there a work around so I don't need my passkey to use sudo on remote nodes 
eg VPS's and servers but require it for laptops and desktops where the user is 
physically in front of?


Passkey authentication requires local key presence and is supposed to be
used on the system where you have that key. In IPA environments it means
also that if you are online, you'd get a Kerberos ticket granting ticket
as a result of the successful login with a passkey.

That Kerberos ticket can then be used to request a service ticket and
authenticate against remote SSH servers. Not using your SSH key but the
actual Kerberos ticket.

You can also allow forwarding that Kerberos ticket granting ticket to
the SSH server, with ssh's option '-o GSSAPIDelegateCredentials=yes'.
This is typically not recommended but can be done. If you do so, then on
the SSH server you can use the Kerberos ticket to request a service
ticket and authenticate over PAM, with pam_sss_gss module.

On Fedora and RHEL-like systems you can use 'authselect' to enable
pam_sss_gss usage:

# authselect enable-feature with-gssapi

You also need to enable list of allowed PAM services in sssd.conf, this
is what authselect will tell you once you run that command. Man page for
pam_sss_gss(8) gives some examples for sudo.

You can also limit what kind of the initial Kerberos ticket could be
used to authenticate over the PAM with pam_sss_gss. For example, you can
force use of passkey-obtained Kerberos tickets and nothing else for sudo
access:

---
[domain/my.ipadomain.com]
pam_gssapi_services = sudo, sudo-i

[pam]
pam_gssapi_indicators_map = sudo:passkey, sudo-i:passkey


--
/ 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] FreeIPA 4.12.2

2024-08-22 Thread Alexander Bokovoy via FreeIPA-users

The FreeIPA team would like to announce FreeIPA 4.12.2 release!

It can be downloaded from http://www.freeipa.org/page/Downloads. Builds for
Fedora distributions will be available from the official repository soon.

Full release notes are available at:
https://www.freeipa.org/release-notes/4-12-2.html

-- 
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
--
___
FreeIPA-devel mailing list -- freeipa-de...@lists.fedorahosted.org
To unsubscribe send an email to freeipa-devel-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-de...@lists.fedorahosted.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue
-- 
___
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 logging grok filters

2024-08-19 Thread Alexander Bokovoy via FreeIPA-users

On Tue, 20 Aug 2024, Djerk Geurts wrote:

On 20 Aug 2024, at 08:16, Alexander Bokovoy wrote:

On Tue, 20 Aug 2024, Natxo Asenjo via FreeIPA-users wrote:

hi,

On Mon, Aug 19, 2024 at 6:33 PM Djerk Geurts via FreeIPA-users <
freeipa-users@lists.fedorahosted.org> wrote:

Hi all,

I’m following these instructions:
https://www.freeipa.org/page/Howto/Centralised_Logging_with_Logstash/ElasticSearch/Kibana

To try and ingest IPA logs into Elasticsearch. And just found that the
content of the grok filters (FWGROK and AUDITAVC) aren’t listed. Would
anyone know where one might find these? A google search for these two terms
yields only the listed page, which doesn’t provide their content.

for FWGROK I could not find anything yet, but the other one you can find in
the archive, it seems:

https://listman.redhat.com/archives/freeipa-users/2014-June/012100.html

I think these are just ways of setting up matches for grok filters.
The whole thing is described in
https://www.freeipa.org/page/Centralized_Logging and heavily relies on
the research that Peter Schiffer did a decade ago. His scripts and
configurations are linked from the page and still available in the
github repositories he provides:

https://github.com/pschiffe/ipa-log-config -- configuration of the
IPA servers and clients on RHEL7. It needs updates, obviously, but
should have enough details.

https://github.com/pschiffe/rsyslog-elasticsearch-kibana --
pre-configured dashboards with elasticsearch and kibana.

May be Peter could give more details? To me it looked like those rules
for the firewall and auditd events were mostly coming out of logstash
distribution from that period of time, maybe?

Quite true, thank you for the GitHub link. All these pages appear quite
dated and I’ll be happy to propose updates when I get things working on
my servers. Others must have working configs based on current IPA and
Elastic versions, but at least I’m learning a lot in trying to get
proper logging in place.

I’ve since found both Duncan’s grok filters here:
https://gist.github.com/duncaninnes/cc54bc01ed45fcd77961

Now that I have the filters, I’m working through “_grokparsefailure”
errors. Which, as you suggest, is unsurprising since these articles
were written a decade ago.

Glad to hear you've got a progress!

Once you are ready to submit updates, they can be done as pull requests
to https://github.com/freeipa/freeipa.github.io. The specific pages are
https://github.com/freeipa/freeipa.github.io/blob/main/src/page/Centralized_Logging.rst
and
https://github.com/freeipa/freeipa.github.io/blob/main/src/page/Howto/Centralised_Logging_with_Logstash/ElasticSearch/Kibana.rst

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

[Freeipa-users] Re: FreeIPA logging grok filters

2024-08-19 Thread Alexander Bokovoy via FreeIPA-users


On Tue, 20 Aug 2024, Natxo Asenjo via FreeIPA-users wrote:

hi,


On Mon, Aug 19, 2024 at 6:33 PM Djerk Geurts via FreeIPA-users <
freeipa-users@lists.fedorahosted.org> wrote:


Hi all,

I’m following these instructions:
https://www.freeipa.org/page/Howto/Centralised_Logging_with_Logstash/ElasticSearch/Kibana

To try and ingest IPA logs into Elasticsearch. And just found that the
content of the grok filters (FWGROK and AUDITAVC) aren’t listed. Would
anyone know where one might find these? A google search for these two terms
yields only the listed page, which doesn’t provide their content.



for FWGROK I could not find anything yet, but the other one you can find in
the archive, it seems:

https://listman.redhat.com/archives/freeipa-users/2014-June/012100.html


I think these are just ways of setting up matches for grok filters. 


The whole thing is described in
https://www.freeipa.org/page/Centralized_Logging and heavily relies on
the research that Peter Schiffer did a decade ago. His scripts and
configurations are linked from the page and still available in the
github repositories he provides:

https://github.com/pschiffe/ipa-log-config -- configuration of the
IPA servers and clients on RHEL7. It needs updates, obviously, but
should have enough details.

https://github.com/pschiffe/rsyslog-elasticsearch-kibana --
pre-configured dashboards with elasticsearch and kibana.

May be Peter could give more details? To me it looked like those rules
for the firewall and auditd events were mostly coming out of logstash
distribution from that period of time, maybe?





--
/ 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-client-install (4.9.11) confused about chrony

2024-08-19 Thread Alexander Bokovoy via FreeIPA-users


On Пан, 19 жні 2024, Harald Dunkel via FreeIPA-users wrote:

PS:

root@srvl048:~# ipa-client-install --uninstall --no-ntp


The options specified along with --uninstall will not make effect. They
only affect installing process.


Unenrolling client from IPA server
Removing Kerberos service principals from /etc/krb5.keytab
Disabling client Kerberos and LDAP configurations
Redundant SSSD configuration file /etc/sssd/sssd.conf was moved to 
/etc/sssd/sssd.conf.deleted
Restoring client configuration files
Unconfiguring the NIS domain.
nscd daemon is not installed, skip configuration
nslcd daemon is not installed, skip configuration
CalledProcessError(Command ['/bin/systemctl', 'stop', 'chrony.service'] 
returned non-zero exit status 5: 'Failed to stop chrony.service: Unit 
chrony.service not loaded.\n')
The ipa-client-install command failed. See /var/log/ipaclient-uninstall.log for 
more information


This is because we already have backed up the state of chrony before,
during installation. You can look at /var/lib/ipa-client/sysrestore for
the details, there would be a section in one of files describing
'chrony' module and this is its called.

There is another problem: an attempt to restore time synchornisation
service happens anyway. If data in /var/lib/ipa-client/sysrestore
contains 'chrony' module, it will attempt to restore state of the chrony
and restore files from the backup prior to installation.


--
/ 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-client-install (4.9.11) confused about chrony

2024-08-19 Thread Alexander Bokovoy via FreeIPA-users


On Пан, 19 жні 2024, Harald Dunkel wrote:

On 2024-08-19 09:40:18, Alexander Bokovoy wrote:


You need to say 'ipa-client-install -N' to prevent configuring NTP.
Looks like you didn't do that.



You mean ipa-client install (without --no-ntp) restarts chrony even
if it was instructed in the confirmation dialog to not change the
chrony configuration, and then it is expected to die if chrony isn't
installed?


If you are not using --no-ntp (-N), ipa-client-install will configure
chrony. The question you get asked is whether you want to specify NTP
servers/pool addresses manually or we should discover them. The chrony
will still be configured, just with autodetection of the content or by
manually provided addresses.


Maybe it is just me, but I am a little bit confused about this
approach.


The phrase itself might be confusing in the sense that it does not make
it clear it will be configuring chrony in either case as you have not
specified --no-ntp.

--
/ 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-client-install (4.9.11) confused about chrony

2024-08-19 Thread Alexander Bokovoy via FreeIPA-users


On Пан, 19 жні 2024, Harald Dunkel via FreeIPA-users wrote:

Hi folks,

running ipa-client-install in an LXC container I stumbled over this:

root@debian12:~# ipa-client-install
This program will set up IPA client.
Version 4.9.11

WARNING: conflicting time&date synchronization service 'ntp' will be disabled 
in favor of chronyd

Discovery was successful!
Do you want to configure chrony with NTP server or pool address? [no]: no
Client hostname: debian12.vs.example.com
Realm: EXAMPLE.COM
DNS Domain: example.com
IPA Server: ipa1.example.com
BaseDN: dc=example,dc=com

Continue to configure the system with these values? [no]: yes
Synchronizing time
Augeas failed to configure file /etc/chrony/chrony.conf
Using default chrony configuration.
CalledProcessError(Command ['/bin/systemctl', 'restart', 'chrony.service'] 
returned non-zero exit status 5: 'Failed to restart chrony.service: Unit 
chrony.service not found.\n')
The ipa-client-install command failed. See /var/log/ipaclient-install.log for 
more information


This seems weird. First it asks about configuring chrony, which was
denied, and yet it fails due to the chrony configuration.


You need to say 'ipa-client-install -N' to prevent configuring NTP.
Looks like you didn't do that.



?

This is the freeipa client package 4.9.11 backported to Debian 12.
There is neither crony nor ntp or systemd-timesyncd installed. The
clock is managed on the host.

It is pretty unfortunate that freeipa tries to "mess around" with
the clock, anyway. Keep it simple. I understand that Kerberos might
run into problems when the clock is out-of-sync, but this is very
well documented, and obviously freeipa cannot take all ntp-clones
into account.


Use proper options to ipa-client-install to express your needs.

The question about whether chrony needs to configure NTP server/pool
addresses is asked when a general ask for configuring NTP is there.
That defaults to 'true' so you need to say '-N' to change this setting.

The question 'Do you want to configure chrony with NTP server or pool
address?' is really meant to ask you about specific NTP servers/pool
addresses, not the fact that Chrony would not be configured.

--
/ 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: Server not found in Kerberos database

2024-08-14 Thread Alexander Bokovoy via FreeIPA-users


On Срд, 14 жні 2024, Michael Schindhelm via FreeIPA-users wrote:

Hi,
I'm trying to setup freeipa as replacment for our old NIS infrastructure.

The setup looks like this:
AD domain = domain.com
IPA domain = ipa.domain.com
IPA server = freeipa.domain.com
Client = ubuntu-test.domain.com

I've installed the freeipa server and AD trust. Everything is working
on the freeipa server (login of IPA users, login of AD users).  On the
clients (tested 2 different clients, both ubuntu 22.04) neither login
of IPA users or AD users works.


That's expected. Have you read
https://www.freeipa.org/page/V4/IPA_Client_in_Active_Directory_DNS_domain
?

This is the same as 
https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/installing_trust_between_idm_and_ad/assembly_configuring-idm-clients-in-an-active-directory-dns-domain_installing-trust-between-idm-and-ad#assembly_configuring-idm-clients-in-an-active-directory-dns-domain_installing-trust-between-idm-and-ad,
 although may be a bit more technical.

In general, don't put IPA servers (not clients!) into DNS domains owned
by Active Directory deployments. This is a direct way to hard to
diagnoze and sometimes impossible to fix problems. It is not supported.



From the client logs:
(2024-08-14 08:55:52): [be[ipa.domain.com]] [sasl_bind_send] (0x0100): [RID#13] 
Executing sasl bind mech: GSSAPI, user: host/ubuntu-test.domain.com
(2024-08-14 08:55:52): [be[ipa.domain.com]] [sasl_bind_send] (0x0020): [RID#13] 
ldap_sasl_interactive_bind_s failed (-2)[Local error]
(2024-08-14 08:55:52): [be[ipa.domain.com]] [sasl_bind_send] (0x0080): [RID#13] 
Extended failure message: [SASL(-1): generic failure: GSSAPI Error: Unspecified 
GSS failure.  Minor code may provide more information (Server 
krbtgt/domain@ipa.domain.com not found in Kerberos database)]
(2024-08-14 08:55:52): [be[ipa.domain.com]] [sdap_cli_connect_recv] (0x0040): 
[RID#13] Unable to establish connection [1432158227]: Authentication Failed

From the freeipa krb5kdc logs:
Aug 14 08:55:52 freeipa.domain.com krb5kdc[1238](info): TGS_REQ (8 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), 
UNSUPPORTED:des3-hmac-sha1(16), DEPRECATED:arcfour-hmac(23), 
camellia128-cts-cmac(25), camellia256-cts-cmac(26)}) 10.42.0.167: 
UNKNOWN_SERVER: authtime 0,  host/ubuntu-test.domain@ipa.domain.com for 
krbtgt/domain@ipa.domain.com, Server not found in Kerberos database

Both use the same NTP server. DNS is working fine (SRV and TXT entries
are there and resolvable from the server and the client). I've read the
documentation about installation, troubleshooting and AD trust on the
freeipa page and also at RedHat Idm.

Do you have any ideas how I can further troubleshoot and fix this? I'm out of 
ideas.


Your client thinks IPA LDAP server belongs to AD realm and thus to contact it,
the client needs a cross-realm ticket which it tried first to obtain from
IPA realm. You probably only have a one-way trust (AD -> IPA) and IPA
KDC cannot give this ticket. Even it were a two-way trust, then
obtaining that ticket wouldn't help either: next step the client would
request a service ticket to ldap/freeipa.domain@domain.com which
your AD DC will not be able to answer because it has no clue about
freeipa.domain.com machine.

So your deployment choices to have freeipa.domain.com server in AD
deployment's DNS domain shoot you into the feet.

--
/ 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: Best path to returning attribute distinguishedName to an AD-specific tool such as Splunk SA-ldapsearch

2024-08-07 Thread Alexander Bokovoy via FreeIPA-users


On Срд, 07 жні 2024, Matt Trimboli via FreeIPA-users wrote:

So I can make useful ldap queries and lovely Splunk dashboards so I'm
interested in making useful ldap queries that a Splunk add-on
(SA-ldapsearch) can consume. Even though it's called ldapsearch, it's
really meant for AD, but it almost works with IPA. Right now I can't
get past the configuration screen where it tests the connection. There
are no errors in the IPA ldap logs but on the Splunk side it complains
that

"Result: distinguishedName: undefined"

Some quick comparisons showed me that IPA calls the attribute 'dn' and
AD has both 'dn' and 'distinguishedName'. My guess is that if IPA gave
this Splunk plugin the distinguishedName attribute in the result, it
would let me proceed (until the next error, possibly.)

Can anyone point me toward the easiest way to try this? compat plugin?
something easier? I don't yet have experience tweaking the schema, but
I'm willing to learn.


I don't think you can do anything with it other than asking Splunk to
expect 'dn' or 'distinguishedName' in the output. 


'distinguishedName' is an alias to 'dn' attribute. It is pretty much
fundamental attribute in LDAP and 389-ds handles it without a problem:

-
$ ldapsearch -H ldap://ipa.demo1.freeipa.org -x -b dc=demo1,dc=freeipa,dc=org 
'(uid=admin)' distinguishedName
# extended LDIF
#
# LDAPv3
# base  with scope subtree
# filter: (uid=admin)
# requesting: distinguishedName
#

# admin, users, accounts, demo1.freeipa.org
dn: uid=admin,cn=users,cn=accounts,dc=demo1,dc=freeipa,dc=org

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1


However, 389-ds returns you a primary name of the attribute because
that's how it supposed to be. It accepts an aliased name in the search.

I guess this plugin is written with assumption that if certain attribute
was asked by a specific name, distinguishedName, then a result is
returned with this name, instead of the attribute's primary name. This
is not defined in the set of LDAP specifications. In fact,
https://www.rfc-editor.org/rfc/rfc4517#section-3.3.9 only defines an
attribute 'DN' with the LDAP-specific encoding of 'distinguishedName'
rule from the string representation of the distinguished names from
RFC4514. In LDAP RFC there is no attribute named 'distinguishedName' but
it is a common use that 'dn' and 'distinguishedName' are aliases in LDAP
queries.



--
/ 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: 2FA not working with OpenVPN Free IPA Integration

2024-07-10 Thread Alexander Bokovoy via FreeIPA-users


On Срд, 10 ліп 2024, Tinku Goyal via FreeIPA-users wrote:

The password is being changed using the IPA server UI for the IPA
users. Post password change users are able to login to the IPA portal
and linux servers as well but not able to authenticate with the OpenVPN
via the plugin.

Also, same is happening for the new users, if I create a new user in
IPA and try login to the OpenVPN with that user with 2FA enabled, it is
not working.

While authentication, it is going for Pre-authentication and I found
these in kerberos logs for a user for both attempts (with 2FA enabled
and without). This users password was resetted recently and post that
it started having issues.

Without OTP it is working and with OTP it is failing.


Can you provide debug SSSD logs from the openvpn host?



Without OTP

Jul 10 02:34:24 newvpn1 krb5kdc[1446773](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.18.20.5: 
NEEDED_PREAUTH: asingh@TINKU.LOCAL for krbtgt/TINKU.LOCAL@TINKU.LOCAL, 
Additional pre-authentication required
Jul 10 02:34:25 newvpn1 krb5kdc[1446774](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.18.20.5: 
NEEDED_PREAUTH: asingh@TINKU.LOCAL for krbtgt/TINKU.LOCAL@TINKU.LOCAL, 
Additional pre-authentication required
Jul 10 02:34:25 newvpn1 krb5kdc[1446774](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.18.20.5: 
NEEDED_PREAUTH: asingh@TINKU.LOCAL for krbtgt/TINKU.LOCAL@TINKU.LOCAL, 
Additional pre-authentication required
Jul 10 02:34:26 newvpn1 krb5kdc[1446774](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.18.20.5: 
NEEDED_PREAUTH: asingh@TINKU.LOCAL for krbtgt/TINKU.LOCAL@TINKU.LOCAL, 
Additional pre-authentication required
Jul 10 02:34:26 newvpn1 krb5kdc[1446774](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.18.20.5: ISSUE: 
authtime 1720559066, etypes {rep=aes256-cts-hmac-sha1-96(18), 
tkt=aes256-cts-hmac-sha1-96(18), ses=aes256-cts-hmac-sha1-96(18)}, 
asingh@TINKU.LOCAL for krbtgt/TINKU.LOCAL@TINKU.LOCAL
Jul 10 02:34:27 newvpn1 krb5kdc[1446774](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.18.20.5: ISSUE: 
authtime 1720559066, etypes {rep=aes256-cts-hmac-sha1-96(18), 
tkt=aes256-cts-hmac-sha1-96(18), ses=aes256-cts-hmac-sha1-96(18)}, 
asingh@TINKU.LOCAL for host/newvpn.TINKU.local@TINKU.LOCAL


With OTP Failure

Jul 10 02:33:25 newvpn1 krb5kdc[1446774](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.18.20.5: 
NEEDED_PREAUTH: asingh@TINKU.LOCAL for krbtgt/TINKU.LOCAL@TINKU.LOCAL, 
Additional pre-authentication required
Jul 10 02:33:25 newvpn1 krb5kdc[1446773](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.18.20.5: 
NEEDED_PREAUTH: asingh@TINKU.LOCAL for krbtgt/TINKU.LOCAL@TINKU.LOCAL, 
Additional pre-authentication required
Jul 10 02:33:26 newvpn1 krb5kdc[1446774](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.18.20.5: 
NEEDED_PREAUTH: asingh@TINKU.LOCAL for krbtgt/TINKU.LOCAL@TINKU.LOCAL, 
Additional pre-authentication required
Jul 10 02:33:26 newvpn1 krb5kdc[1446774](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.18.20.5: 
NEEDED_PREAUTH: asingh@TINKU.LOCAL for krbtgt/TINKU.LOCAL@TINKU.LOCAL, 
Additional pre-authentication required
Jul 10 02:33:27 newvpn1 krb5kdc[1446774](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.18.20.5: 
PREAUTH_FAILED: asingh@TINKU.LOCAL for krbtgt/TINKU.LOCAL@TINKU.LOCAL,

[Freeipa-users] Re: freeipa role delegation before delete and upgrade

2024-07-10 Thread Alexander Bokovoy via FreeIPA-users


On Срд, 10 ліп 2024, John Michelle via FreeIPA-users wrote:

thanks , but i would migrate to rocky 8.10 , so i ask for delegation
when i delete ipa01 from topology and replace them by NEW rocky OS Vm


Please read and use the migration guide I pointed you to. RockyLinux
8.10 is a RHEL 8 clone. From the migration documentation point of view
you can treat it as 'RHEL 8'.


--
/ 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 role delegation before delete and upgrade

2024-07-10 Thread Alexander Bokovoy via FreeIPA-users


On Срд, 10 ліп 2024, John Michelle via FreeIPA-users wrote:

i use freeipa 4.6.8


Ok, my comment stands: we don't have NTP server support since that time
and the rest is described in the migration guide.


--
/ 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 role delegation before delete and upgrade

2024-07-10 Thread Alexander Bokovoy via FreeIPA-users


On Срд, 10 ліп 2024, John Michelle via FreeIPA-users wrote:

Hello

I ve 3 Freeipa Server, replicated in each other as a topology.


What versions of the IPA and OS are these?



[root@ipa001 ~] ipa-replica-manage list
ipa03.domain.local: master
ipa02.domain.local: master
ipa01.domain.local: master
this is the output of the command ipa find role :

[root@ipa001 ~]# ipa server-role-find --server ipa001.domain.local
--
6 rôles serveur correspondants
--
 Nom du serveur: ipa01.domain.local
 Nom du rôle: CA server
 État du rôle: enabled

 Nom du serveur: ipa01.domain.local
 Nom du rôle: DNS server
 État du rôle: enabled

 Nom du serveur: ipa01.domain.local
 Nom du rôle: NTP server
 État du rôle: enabled

 Nom du serveur: ipa01.domain.local
 Nom du rôle: AD trust agent
 État du rôle: absent

 Nom du serveur: ipa01.domain.local
 Nom du rôle: KRA server
 État du rôle: absent

 Nom du serveur: ipa01.domain.local
 Nom du rôle: AD trust controller
 État du rôle: absent

Nombre d'entrées renvoyées 6

[root@ipa01 ~]# ipa server-role-find --server ipa02.domain.local
--
6 rôles serveur correspondants
--
 Nom du serveur: ipa02.domain.local
 Nom du rôle: CA server
 État du rôle: enabled

 Nom du serveur: ipa02.domain.local
 Nom du rôle: DNS server
 État du rôle: enabled

 Nom du serveur: ipa02.domain.local
 Nom du rôle: NTP server
 État du rôle: absent

 Nom du serveur: ipa02.domain.local
 Nom du rôle: AD trust agent
 État du rôle: absent

 Nom du serveur: ipa02.domain.local
 Nom du rôle: KRA server
 État du rôle: absent

 Nom du serveur: ipa02.domain.local
 Nom du rôle: AD trust controller
 État du rôle: absent

Nombre d'entrées renvoyées 6

[root@ipa01 ~]# ipa server-role-find --server ipa03.domain.local
--
6 rôles serveur correspondants
--
 Nom du serveur: ipa03.domain.local
 Nom du rôle: CA server
 État du rôle: configured

 Nom du serveur: ipa03.domain.local
 Nom du rôle: DNS server
 État du rôle: enabled

 Nom du serveur: ipa03.domain.local
 Nom du rôle: NTP server
 État du rôle: absent

 Nom du serveur: ipa03.domain.local
 Nom du rôle: AD trust agent
 État du rôle: absent

 Nom du serveur: ipa03.domain.local
 Nom du rôle: KRA server
 État du rôle: absent

 Nom du serveur: ipa03.domain.local
 Nom du rôle: AD trust controller
 État du rôle: absent

Nombre d'entrées renvoyées 6

[root@ipa01 ~]#
when i delete the ipa01 server, i will lose the ntp role. i want to
delegate the ntp role to the 2 servers, but i don't know what NTP
server is configured in the IPA01.


Since ~2018 and https://pagure.io/freeipa/issue/7024 FreeIPA does not
provide NTP server role and it is removed on upgrades. Whatever NTP
server is used by the system is 'good enough'.



also, i see that the CA server role is configured, Any idea to see that
configuration and know why this role is not enabled ? can i see all
configuration and know what options is selected to install replicas ? (
--no-forwarders, etc )



You should look at the migration guides. See 
https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/8/html/migrating_to_identity_management_on_rhel_8/migrate-7-to-8_migrating

Migration guide has important steps described for any IPA server
migration.

--
/ 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: 2FA not working with OpenVPN Free IPA Integration

2024-07-10 Thread Alexander Bokovoy via FreeIPA-users


On Аўт, 09 ліп 2024, Tinku Goyal via FreeIPA-users wrote:

My setup includes a set of FreeIPA servers running on 4.9.2 version and
a OpenVPN configured for the users to connect to VPN.  Previously I was
using IPA version 4.6.8 on CentOS7 and now installed IPA replica on
4.9.2 on OL8 and decommissioned the old one.

I am using openvpn-plugin-auth-pam.so with login pam file to
authenticate the IPA users logging in to OpenVPN.

when I am resetting the password of users now, then users are not able
to login to OpenVPN with 2FA (password+otp) whereas, with otp disabled
it is working

for old users for whom password is not resetted recently after change
in IPA cluster, their authentication is working through OpenVPN
with/without OTP both.

All users(old + users whose password is resetted recently) are able to
login to linux servers using password and OTP both combination, its
just not authenticating in OpenVPN.

I have tried multiple things but still couldn't able to get it work.


I don't see in openvpn auth-pam.c plugin code any handling of a password
change request during authentication.

Debug logs from SSSD and probably LDAP server for an attempt where a
password change is requested would be needed.
Please look at https://sssd.io/troubleshooting/basics.html for basics on
how to configure debug logs in SSSD.


--
/ 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 docker ccaches

2024-07-09 Thread Alexander Bokovoy via FreeIPA-users


On Аўт, 09 ліп 2024, Paavo Nugin via FreeIPA-users wrote:

Hello!

I'm trying to migrate away from our old IPA server running on Centos 7.
After solving multiple problems I've reached the following setup:
ipa.domain - old centos 7 VM
ipa1.domain - new replica, rocky 8 freeipa docker container running on Ubuntu 
22.04 (because AFAIK it's not supported to go straight from 7 to 9)
ipa2.domain - new replica, rocky 9 freeipa docker container running on Ubuntu 
22.04

Mostly everything seems to work fine, I can authenticate against any of 3 
servers but I've hit annoying problem that I've haven't yet solved despite 
extensive google-fu.

So scenario is as follows:
1) kinit on my laptop - works ok (ubuntu 22.04)
2) use firefox to access https://ipa2.domain - SSO works perfectly without 
asking any credentials.
3) restart ipa2.domain container
4) hit f5 in firefox - login screen, asks for username and password - not 
working quite as expected.

No amount of kdestroy or kinit against any of 3 servers will solve it
(I don't have IPA DNS setup and set servers manually in krb5.conf). I
can login with entering username and password manually but SSO won't
work (but SSO works perfectly against ipa.domain and ipa1.domain).
Same scenario is happening with ipa1.domain when I restart it. I'm not
really eager to restart ipa.domain since our users are using it but I'm
99% sure that it wont have the same problem since it's not running in
container and previous restarts have not produced such issue.  What
helps - deleting cookies in browser - then SSO starts to work again -
until next restart of container.

httpd/error_log:
[Tue Jul 09 14:51:00.648879 2024] [wsgi:error] [pid 322:tid 550] [remote 
myIP:38914] ipa: DEBUG: WSGI wsgi_dispatch.__call__:
[Tue Jul 09 14:51:00.649030 2024] [wsgi:error] [pid 322:tid 550] [remote 
myIP:38914] ipa: DEBUG: WSGI jsonserver_i18n_messages.__call__:
[Tue Jul 09 14:51:00.649309 2024] [wsgi:error] [pid 322:tid 550] [remote 
myIP:38914] ipa: DEBUG: WSGI jsonserver.__call__:
[Tue Jul 09 14:51:00.649343 2024] [wsgi:error] [pid 322:tid 550] [remote 
myIP:38914] ipa: DEBUG: WSGI WSGIExecutioner.__call__:
[Tue Jul 09 14:51:00.655929 2024] [wsgi:error] [pid 322:tid 550] [remote 
myIP:38914] ipa: DEBUG: raw: i18n_messages(version='2.253')
[Tue Jul 09 14:51:00.656035 2024] [wsgi:error] [pid 322:tid 550] [remote 
myIP:38914] ipa: DEBUG: i18n_messages(version='2.253')
[Tue Jul 09 14:51:00.660245 2024] [wsgi:error] [pid 322:tid 550] [remote 
myIP:38914] ipa: INFO: [jsonserver_i18n_messages] UNKNOWN: 
i18n_messages(version='2.253'): SUCCESS
[Tue Jul 09 14:51:00.660291 2024] [wsgi:error] [pid 322:tid 550] [remote 
myIP:38914] ipa: DEBUG: [jsonserver_i18n_messages] UNKNOWN: 
i18n_messages(version='2.253'): SUCCESS etime=10778664
[Tue Jul 09 14:51:00.801704 2024] [:warn] [pid 326:tid 408] [client myIP:38908] 
KRB5CCNAME file (/run/ipa/ccaches/myuser@DOMAIN-8gyvGu) lookup failed!, 
referer: https://ipa2.domain/ipa/ui/
[Tue Jul 09 14:51:00.802729 2024] [wsgi:error] [pid 321:tid 553] [remote 
myIP:38908] ipa: DEBUG: WSGI wsgi_dispatch.__call__:
[Tue Jul 09 14:51:00.802792 2024] [wsgi:error] [pid 321:tid 553] [remote 
myIP:38908] ipa: DEBUG: WSGI jsonserver_session.__call__:
[Tue Jul 09 14:51:00.802861 2024] [wsgi:error] [pid 321:tid 553] [remote 
myIP:38908] ipa: DEBUG: Valid Referer https://ipa2.domain/ipa/ui/
[Tue Jul 09 14:51:00.806518 2024] [wsgi:error] [pid 321:tid 553] [remote 
myIP:38908] ipa: DEBUG: ccache expired or invalid, deleting session, need login
[Tue Jul 09 14:51:00.806570 2024] [wsgi:error] [pid 321:tid 553] [remote 
myIP:38908] ipa: DEBUG: 401 Unauthorized need login
[Tue Jul 09 14:51:00.818339 2024] [:warn] [pid 466:tid 486] [client myIP:38914] 
KRB5CCNAME file (/run/ipa/ccaches/myuser@DOMAIN-8gyvGu) lookup failed!, 
referer: https://ipa2.domain/ipa/ui/
[Tue Jul 09 14:51:00.819251 2024] [wsgi:error] [pid 324:tid 556] [remote 
myIP:38914] ipa: DEBUG: WSGI wsgi_dispatch.__call__:
[Tue Jul 09 14:51:00.819313 2024] [wsgi:error] [pid 324:tid 556] [remote 
myIP:38914] ipa: DEBUG: WSGI KerberosLogin.__call__:
[Tue Jul 09 14:51:00.819378 2024] [wsgi:error] [pid 324:tid 556] [remote 
myIP:38914] ipa: DEBUG: Valid Referer https://ipa2.domain/ipa/ui/
[Tue Jul 09 14:51:00.822213 2024] [wsgi:error] [pid 324:tid 556] [remote 
myIP:38914] ipa: DEBUG: ccache expired or invalid, deleting session, need login
[Tue Jul 09 14:51:00.822279 2024] [wsgi:error] [pid 324:tid 556] [remote 
:38914] ipa: DEBUG: 401 Unauthorized need login

/run/ipa/ccaches/ folder is indeed empty. When I delete cookies and are
able to log on then I see files created in that folder but they
disappear after container restart.


# mount |grep /run
tmpfs on /run type tmpfs 
(rw,nosuid,nodev,seclabel,size=800996k,nr_inodes=819200,mode=755,inode64)
tmpfs on /run/user/0 type tmpfs 
(rw,nosuid,nodev,relatime,seclabel,size=400496k,nr_inodes=100124,mode=700,inode64)

This is on VM and in container it will be the same, so /run is gone when
container

[Freeipa-users] Re: demo1.freeipa.org

2024-07-09 Thread Alexander Bokovoy via FreeIPA-users


On Аўт, 09 ліп 2024, veck zuo via FreeIPA-users wrote:

I am deploying the freeIPA demo follwing below link.

https://www.freeipa.org/page/Demo

[root@localhost ~]# ping www.google.com
PING www.google.com (142.250.196.68) 56(84) bytes of data.
64 bytes from maa03s46-in-f4.1e100.net (142.250.196.68): icmp_seq=1 ttl=128 
time=347 ms
64 bytes from maa03s46-in-f4.1e100.net (142.250.196.68): icmp_seq=2 ttl=128 
time=348 ms
^C
--- www.google.com ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 346.995/347.316/347.637/0.321 ms
[root@localhost ~]#


[root@localhost ~]# ipa-client-install --domain demo1.freeipa.org -p admin -w 
Secret123
This program will set up IPA client.
Version 4.9.13

Skip ipa.demo1.freeipa.org: LDAP server is not responding, unable to verify if 
this is an IPA server
Skip ipa.demo1.freeipa.org: LDAP server is not responding, unable to verify if 
this is an IPA server
Provide your IPA server name (ex: ipa.example.com): ^CThe ipa-client-install 
command failed. See /var/log/ipaclient-install.log for more information


This really looks like your network is filtering out access to LDAP
ports on ipa.demo1.freeipa.org.

$ nmap ipa.demo1.freeipa.org
Starting Nmap 7.95 ( https://nmap.org ) at 2024-07-09 15:01 EEST
Nmap scan report for ipa.demo1.freeipa.org (52.57.162.88)
Host is up (0.030s latency).
Not shown: 991 filtered tcp ports (no-response)
PORT STATE  SERVICE
22/tcp   open   ssh
53/tcp   open   domain
80/tcp   open   http
88/tcp   open   kerberos-sec
389/tcp  open   ldap
443/tcp  open   https
464/tcp  open   kpasswd5
636/tcp  open   ldapssl
9090/tcp closed zeus-admin

Nmap done: 1 IP address (1 host up) scanned in 4.98 seconds

and I have no problem reaching it:

$ ldapsearch -x -H ldap://ipa.demo1.freeipa.org -b '' -s base
# extended LDIF
#
# LDAPv3
# base <> with scope baseObject
# filter: (objectclass=*)
# requesting: ALL
#

#
dn:
objectClass: top
namingContexts: dc=demo1,dc=freeipa,dc=org
namingContexts: cn=changelog
namingContexts: o=ipaca
defaultnamingcontext: dc=demo1,dc=freeipa,dc=org




--
/ 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: zone_journal_compact: could not get zone size: not found

2024-07-09 Thread Alexander Bokovoy via FreeIPA-users


On Аўт, 09 ліп 2024, Kees Bakker via FreeIPA-users wrote:

Hi,

At the moment I have three FreeIPA systems (replicas), recently
installed with CentOS 9-Stream.
All three of these show this message at irregular intervals.

Jul 03 07:50:44 iparep5.example.com named[541]: zone example.com/IN: 
zone_journal_compact: could not get zone size: not found
Jul 03 07:50:51 iparep5.example.com named[541]: zone 
16.16.172.in-addr.arpa/IN: zone_journal_compact: could not get zone 
size: not found
Jul 03 07:51:03 iparep5.example.com named[541]: zone 
17.16.172.in-addr.arpa/IN: zone_journal_compact: could not get zone 
size: not found
Jul 03 07:51:34 iparep5.example.com named[541]: zone 
29.16.172.in-addr.arpa/IN: zone_journal_compact: could not get zone 
size: not found
Jul 03 07:52:12 iparep5.example.com named[541]: zone 
30.16.172.in-addr.arpa/IN: zone_journal_compact: could not get zone 
size: not found
Jul 03 08:03:51 iparep5.example.com named[541]: zone example.com/IN: 
zone_journal_compact: could not get zone size: not found
Jul 03 08:04:52 iparep5.example.com named[541]: zone 
29.16.172.in-addr.arpa/IN: zone_journal_compact: could not get zone 
size: not found
Jul 03 08:06:30 iparep5.example.com named[541]: zone 
30.16.172.in-addr.arpa/IN: zone_journal_compact: could not get zone 
size: not found
Jul 03 08:18:42 iparep5.example.com named[541]: zone example.com/IN: 
zone_journal_compact: could not get zone size: not found
Jul 03 08:20:19 iparep5.example.com named[541]: zone 
29.16.172.in-addr.arpa/IN: zone_journal_compact: could not get zone 
size: not found
Jul 03 08:26:23 iparep5.example.com named[541]: zone 
30.16.172.in-addr.arpa/IN: zone_journal_compact: could not get zone 
size: not found
Jul 03 08:34:12 iparep5.example.com named[541]: zone example.com/IN: 
zone_journal_compact: could not get zone size: not found
Jul 03 08:34:50 iparep5.example.com named[541]: zone 
29.16.172.in-addr.arpa/IN: zone_journal_compact: could not get zone 
size: not found


After posting this on the bind-users mailing list I did a bit more 
debugging. It turns out that the message is caused by the fact that 
bind-dyndb-ldap does not implement the getsize method. Now why didn't 
I see this message on my CentOS 8-Stream system? Well, it is because 
the bind package went from 9.11.26 to 9.16.23. In that newer version a 
new function zone_journal_compact was added which does the following:


zone.c:
journalsize= zone->journalsize;
if(journalsize== -1) {
journalsize= DNS_JOURNAL_SIZE_MAX;
dns_db_currentversion(db, &ver);
result= dns_db_getsize(db, ver, NULL, &dbsize);
dns_db_closeversion(db, &ver, false);
if(result!= ISC_R_SUCCESS) {
dns_zone_log(zone, ISC_LOG_ERROR,
"zone_journal_compact: "
"could not get zone size: %s",
isc_result_totext(result));
} elseif(dbsize< DNS_JOURNAL_SIZE_MAX/ 2) {
journalsize= (int32_t)dbsize* 2;
}
}
and dns_db_getsize executes this:
isc_result_t
dns_db_getsize(dns_db_t*db, dns_dbversion_t*version, uint64_t*records,
uint64_t*bytes) {
REQUIRE(DNS_DB_VALID(db));
REQUIRE(dns_db_iszone(db));
if(db->methods->getsize!= NULL) {
return((db->methods->getsize)(db, version, records, bytes));
}
return(ISC_R_NOTFOUND);
}
However, the getsize method is not implemented. Thus you'll get the 
above mentioned messages. I'm surprised that nobody reported this. 
Everybody with FreeIPA + DNS + CentOS 9-Stream should be getting these 
messages. The messages are colored in red in journalctl, as if this is 
a serious problem. Is it? Or can I ignore this message? -- Kees


Thanks for the analysis. Judging by the code, it is supposed to tell how
many records are in the database and what is their total size in bytes.
This is used in zone maintenance, mostly for zone journal handling. The
latter has less need for bind-dyndb-ldap -backed zones because their
content is not stored locally (in DB files) and can be modified outside
of Bind anyway, so journal data is not valid for it.

Bind expects that some backends might have no getsize() method -- there
are few internal backends such as caches that have no getsize()
implementation. So it is not really a requirement.

The message in zone_journal_compact() would really best be a warning,
not an error.


--
/ 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: CentOS 7 - named-pkcs11 crashes / won't start after patches/security upgrades

2024-07-05 Thread Alexander Bokovoy via FreeIPA-users


On Wed, 03 Jul 2024, Braden McGrath via FreeIPA-users wrote:

Rob Crittenden wrote:

It appears that the centos 7 builds were done incorrectly. Given it is
EOL it is not likely to be addressed. We have little influence in centos.
rob


Ugh, that's what I was a little afraid of. Guess it's just that much
more of a reason I need to migrate to new servers.  I saw your
post/reply elsewhere on this list to someone asking how to
migrate/upgrade, linking to official RHEL8 docs.

Unfortunately my non-profit doesn't have the money for RHEL, so I was
looking at either Rocky or Alma, because trying to run FreeIPA Server
on top of Ubuntu/Debian just feels wrong and fraught with peril.
FreeIPA-client seems to work OK-enough on .deb systems but I'd be
afraid of trying to run the Server side there... or is this a
completely unfounded and stupid fear? (The org is almost 100% Ubuntu,
with the exception of our FreeIPA VMs and two business apps that
require CentOS7.)


If you are interested in the support, it still makes sense to talk to
Red Hat people because there are often ways to get substantial
discounts. IPA support is included into standard RHEL subscription
support.

With Rocky or AlmaLinux I am not aware of any specific support for IPA.
May be companies behind those projects provide something similar in
their commercial offerings but I am not sure. The only venue you'd be
open to is this mailing list. From my experience, Alma/Rocky do rebuilds
of what comes from CentOS Stream or RHEL and they hardly test those
rebuilds beyond basic installation. We know that because AlmaLinux 8.10
builds are broken right now as can be seen in a separate thread.

With Ubuntu or Debian it is pretty much the same or even worse because
there is a single maintainer heroically uplifting the whole set of
packages.



I'm guessing that the process to move from CentOS7 over to Alma or
Rocky would be pretty similar to the "non RHEL7 to RHEL8" procedure?


No. AlmaLinux attempts to be RHEL compatible so you need to look into
'RHEL 7 to RHEL 8' migration 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: Install freeipa client on fedora12

2024-07-02 Thread Alexander Bokovoy via FreeIPA-users

On Аўт, 02 ліп 2024, Elhamsadat Azarian wrote:

Hi Mr. Bokovy
Thanks for your reply.
So it means, i can't have freeipa control on feora12 servers? Isn't it?

Please do not drop the mailing list off the discussion.

Since Fedora Linux 12 is not a supported version of Fedora anymore, for
more than 12.5 years, there is nothing can be done with existing code.

You, of course, may try to set things up for older environments
yourself. However, I do not recommend keeping such old systems online,
it is not a reasonable approach. Please consider updating.

On Tue, 2 Jul 2024, 11:24 Alexander Bokovoy,  wrote:

On Аўт, 02 ліп 2024, Elhamsadat Azarian via FreeIPA-users wrote:
>Hi
>we have a network contains some Fedora12 and Oracle linux 9
>i am going to install FreeIPA server on oracle linux9 and others(Fedora12
and oraclelinux9) connect it as clients.
>i couldn't find a package for fedora12 as freeipa client!
>can you guide me is it possible that having FreeIPA in this network?

Fedora Linux 12 was released in 2009 and its end of life happened in
December 2010. FreeIPA has not been packaged in Fedora at that time.

--
/ 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: Install freeipa client on fedora12

2024-07-02 Thread Alexander Bokovoy via FreeIPA-users


On Аўт, 02 ліп 2024, Elhamsadat Azarian via FreeIPA-users wrote:

Hi
we have a network contains some Fedora12 and Oracle linux 9
i am going to install FreeIPA server on oracle linux9 and others(Fedora12 and 
oraclelinux9) connect it as clients.
i couldn't find a package for fedora12 as freeipa client!
can you guide me is it possible that having FreeIPA in this network?


Fedora Linux 12 was released in 2009 and its end of life happened in
December 2010. FreeIPA has not been packaged in Fedora at that time.



--
/ 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: SMB share with IPA ID Views user and group mapping

2024-06-24 Thread Alexander Bokovoy via FreeIPA-users

On Аўт, 18 чэр 2024, Yossi Hayat via FreeIPA-users wrote:

Hi,

To centrally manage all credentials from Active Directory, we
configured FreeIPA integration with Active Directory to authenticate
users to IPA-joined Linux machines via SSSD using AD credentials.

The Linux machines have NFS shares mounted on their local filesystems
which we use to work in a sharable way. We have configured FreeIPA "ID
Views" for each user to override the AD-originating generic UID and GID
with shorter UID and GID values. This is to preserve IPA-authenticated
users' NFS permissions that were inherited from the previous Linux
directory management system (NIS) we used and for simplicity.
When working locally or remotely (SSH/VNC) on the Linux machines,
everything is working as expected with no issues.

Our problem is with SMB - We need to share the NFS shares over SMB for
direct File Explorer access for Windows users. For this purpose, we
have an Ubuntu machine we use as an SMB server. The server is joined
to IPA as a client and has all NFS shares mounted locally on its
filesystem.
The ideal way is to somehow configure SMB to forward authentication to
IPA (as it was a local/SSH authentication to the server) and map the ID
views user and group IDs to preserve permissions. We searched all over
the internet and didn't find a working solution for this use case.

Is this supported? If yes, how can this be implemented?

Re-exporting NFS via SMB is not supported.

For normal SMB shares of a non-network disk content, if you set things
up as described in [1], access to those shares will be supported from
Linux systems enrolled into IPA domain. For access from Windows systems
there is currently no support: some operations might work but any
attempt to resolve user/group identities and configure permissions from
Windows clients will not work/might fail.

[1]
https://docs.redhat.com/en/documentation/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

--
/ 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: Prevent domain-local groups from being mapped at all

2024-06-24 Thread Alexander Bokovoy via FreeIPA-users


On Пан, 24 чэр 2024, Ronald Wimmer via FreeIPA-users wrote:
Is there a way for preventing AD domain-local groups from being mapped 
into IPA? From time to time colleagues try to use AD groups with scope 
'domain local'. Personally, I do not see a use case for these groups 
mapped into IPA...


There is no way to prevent those, at least right now. SSSD does not give
us a type of a group when group is requested.


--
/ 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 upgrade failed

2024-06-23 Thread Alexander Bokovoy via FreeIPA-users


On Няд, 23 чэр 2024, Johannes Falke via FreeIPA-users wrote:
  How did you actually manage to resolve this issue? I'm seeing the same   
  thing trying to upgrade either f35->f37 or f35->f36 (and NO ldap errors).
  On f35, freeipa says it's healthy.   


Just a reminder: this is a mailing list, not a forum. If you are using
lists.fedorahosted.org web interface, make sure to check the box to
quote the email you are answering to because otherwise this message
appears without a reference to the thread you are trying to reply to.

As such, this email contains no reference to existing discussion of the
same topic and it is literally impossible to identify what do you mean
by 'resolve this issue'.

Also, lists.fedorahosted.org web interface gives you a way to search the
list archives and see the whole discussion there. It should help in
searching for successful resolutions of many problems. If you still
cannot find a solution, please make sure to include enough details in
your new email thread to provide information that will allow list
members to help 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: replica in DMZ with trust-agent

2024-06-21 Thread Alexander Bokovoy via FreeIPA-users


On Fri, 21 Jun 2024, slek kus via FreeIPA-users wrote:

Hi I deployed a third replica in a dmz network for clients that do not route to 
the main ipa masters. Not sure if this is a workable setup.
I can join clients using --fixed-primary and can logon with AD (one-way trust). 
This third replica has the trust-agent role.
I might be approaching this incorrectly. Posting here for advise, has anyone 
attepted this and how to approach?
It seems to be working, except the sudo rules.

I have posted a diagram here: https://ibb.co/WkQj9yD


It would be best if you could provide actual logs, not pictures. And
ideally those logs should come from both a client and a server.


--
/ 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

2024-06-19 Thread Alexander Bokovoy via FreeIPA-users

On Срд, 19 чэр 2024, Ronald Wimmer via FreeIPA-users wrote:

On 17.06.24 19:53, Rob Crittenden wrote:

Ronald Wimmer wrote:

On 13.06.24 14:30, Rob Crittenden wrote:

Ronald Wimmer via FreeIPA-users wrote:

On 13.02.24 21:04, Ronald Wimmer via FreeIPA-users wrote:

On 13.02.24 18:54, Christian Heimes via FreeIPA-users wrote:

On 13/02/2024 18.03, Ronald Wimmer via FreeIPA-users wrote:

On 13.02.24 17:47, Rob Crittenden wrote:

I don't think it's possible to speculate without knowing your
process.

This requires the cleartext password so assuming you create the
staged
user then immediately active them, that would be the time to do the
bind. Otherwise you have to store cleartext passwords and that is a
recipe for disaster.

User is created by an external tool. User activation in IPA is done
by a script on one of the IPA servers periodically. Sadly, the
external tool cannot do an initial LDAP bind in order to create a
users's krb LDAP attributes. I am looking for a simple way these
properties are created.

Sure I could say a user has to SSH somewhere but why can't that
happen if a user tries to login to IPA's WebGUI and the krb
properties are missing? Or is there another option for users to
accomplish this?

Because the IPA WebUI uses the Kerberos extension S4U2Proxy under the
hood. It allows the WebUI to talk to the LDAP server on behalf of the
user. This feature require a proper Kerberos credentials. See
https://www.freeipa.org/page/V4/Service_Constraint_Delegation

I already mentioned the recommended option to archive this a while
ago. You may have missed the piece of information in this very long
thread. IPA servers have a special /ipa/migration route (e.g.
https://ipa.demo1.freeipa.org/ipa/migration/) for password migration.
Under the hood the endpoint just does an LDAP bind with username and
password. You can ask your users to either log into a machine with
ssh or go to the migration page.

I did indeed miss that vital information. It is more than sufficient
for our needs.

Thanks a lot guys. All scenarios that need to be working in our
environment do actually work now.

Did something change on the IPA side? Newly created users cannot login
to the WebGUI anymore. They get a "Your session has expired" error.
Might have to do with this thread:
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org/thread/YFPMHCWA7R47ZSI75EZKCMSWLH5QYH4P/?sort=date

You don't provide enough information to tell. Did you upgrade versions?

Per the link, do your users have SIDs?

I was asking in an unspecific way because I knew that you would have
some sort of suspicion...

You were absolutely right. The user does not have a SID. Which
information do you need in order to further investigate the problem?

There are a bunch of threads in freeipa-users that describe how to
troubleshoot this.

I am aware of that. But in https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org/message/YWYKIOASONMTJS2BOBKXZN5ZGB6LW7L4/
Alexander states "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." Is this already fixed? Yes? No?
How can we possibly prevent this from happening again in the future?

This is already fixed upstream:
https://pagure.io/freeipa/issue/9517

and it is released in RHEL 9.4/9.3.z/9.2.z/9.0.z and RHEL
8.10z/8.9z/8.8z/8.6z. Also fixed in Fedora 39-41.

if you specific problems, make sure to provide concrete logs or talk to
your support organization, if you have access to one.

[Freeipa-users] Re: Certificate problem

2024-06-12 Thread Alexander Bokovoy via FreeIPA-users


On Срд, 12 чэр 2024, Yavor Marinov wrote:

Hey Alex,

thanks for your reply, I've downloaded the new Letsencrypt certs, installed
them with ipa-cacert-manage install but can't update with ipa-certupdate as
it gives

Connection to https://login.example.net/ipa/json failed with [SSL:
CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local
issuer certificate (_ssl.c:1129)

Again any idea how to proceed further with this will be appreciated.


Look at /etc/httpd/conf.d/ssl.conf, it should have line like 


SSLCACertificateFile /etc/ipa/ca.crt

inside the default vhost.

That is the file that will be eventually updated by the ipa-certupdate.
What you could do is to add your new Let's Encrypt chain to this file,
restart httpd, and try again.

Please make sure to back the file first so that you can get back to it
if needed.



On Wed, Jun 12, 2024 at 12:07 PM Alexander Bokovoy 
wrote:


On Срд, 12 чэр 2024, Yavor Marinov via FreeIPA-users wrote:
>Hello all,
>
>I've tried to look over the list for the problem I have, but it seems I
>can't find anything related. We are using FreeIPA 4.11 on Alma9 with
>Letsencrypt certificates. Until now I didn't had issues renewing
>certificates (using https://github.com/freeipa/freeipa-letsencrypt for
>renewing certificates) but since last night's renewal I can't get in to
>login into webui and can't enroll any new resources. The error i got from
>webui is standart Login failed due to an unknown reason   and there are no
>errors in pki-tomcat. In apache's error logs the following error is
>produced:
>
>[Wed Jun 12 13:58:11.298021 2024] [wsgi:error] [pid 211427:tid 211669]
>[remote 91.239.13.253:34362] ipa: INFO: 401 Unauthorized:
>HTTPSConnectionPool(host='login.example.net', port=443): Max retries
>exceeded with url: /ipa/session/cookie (Caused by
>SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED]
>certificate verify failed: unable to get local issuer certificate
>(_ssl.c:1129)')))
>
>Trying with curl to reach some of the certificates with
>
>curl https://login.example.net:443/ca/rest/certs/1
>
>returns error "unable to get local issuer certificate". However, reaching
>the IPA webui using Chrome doesn't return an error "ERROR_UNKNOWN_ISSUER"
>but FireFox reports that the certificate is unknown.

This is not about IPA CA, this is about IPA web server not knowning
about new Let's Encrypt's CA chain which changed recently.

See https://github.com/freeipa/freeipa-letsencrypt/pull/49.




--
/ 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: Certificate problem

2024-06-12 Thread Alexander Bokovoy via FreeIPA-users


On Срд, 12 чэр 2024, Yavor Marinov via FreeIPA-users wrote:

Hello all,

I've tried to look over the list for the problem I have, but it seems I
can't find anything related. We are using FreeIPA 4.11 on Alma9 with
Letsencrypt certificates. Until now I didn't had issues renewing
certificates (using https://github.com/freeipa/freeipa-letsencrypt for
renewing certificates) but since last night's renewal I can't get in to
login into webui and can't enroll any new resources. The error i got from
webui is standart Login failed due to an unknown reason   and there are no
errors in pki-tomcat. In apache's error logs the following error is
produced:

[Wed Jun 12 13:58:11.298021 2024] [wsgi:error] [pid 211427:tid 211669]
[remote 91.239.13.253:34362] ipa: INFO: 401 Unauthorized:
HTTPSConnectionPool(host='login.example.net', port=443): Max retries
exceeded with url: /ipa/session/cookie (Caused by
SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED]
certificate verify failed: unable to get local issuer certificate
(_ssl.c:1129)')))

Trying with curl to reach some of the certificates with

curl https://login.example.net:443/ca/rest/certs/1

returns error "unable to get local issuer certificate". However, reaching
the IPA webui using Chrome doesn't return an error "ERROR_UNKNOWN_ISSUER"
but FireFox reports that the certificate is unknown.


This is not about IPA CA, this is about IPA web server not knowning
about new Let's Encrypt's CA chain which changed recently.

See https://github.com/freeipa/freeipa-letsencrypt/pull/49.




--
/ 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

2024-05-30 Thread Alexander Bokovoy via FreeIPA-users


On Пят, 31 мая 2024, seojeong kim via FreeIPA-users wrote:

/etc/sssd/sssd.conf
[sssd]
reconnection_retries = 0
config_file_version = 2
services = nss, sudo, pam, ssh
domains = example.com
[nss]
homedir_substring = /home
[pam]
#debug_level = 10
[sudo]
#debug_level = 7
[autofs]
[ssh]
[pac]
[ifp]
[secrets]
[session_recording]
[prompting/password]
password_prompt = Password :
[prompting/2fa]
single_prompt = False
first_prompt = 2fa_Password :
second_prompt = 2fa_Otp :


For the user whose  ipauserauthtype is 'otp',
when sssd_be is online,   two prompt inputs work. I should put password / otp 
separately.
But when sssd_be if offline,   there is only one prompt   like   'Password :"
I wonder why it works like this way,


You keep asking the same question while you've got answers on it already
in this thread. Also, please keep the context and quote an email you are
answering to.


Is there is any way to get two prompt asking separately in offline mode as well?


No.

--
/ 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

2024-05-29 Thread 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: R

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

2024-05-26 Thread 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

2024-05-26 Thread 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

2024-05-26 Thread 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_prin

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

2024-05-25 Thread 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

2024-05-24 Thread 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

2024-05-24 Thread 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

2024-05-22 Thread 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

2024-05-14 Thread 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

2024-05-14 Thread 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/

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

2024-05-02 Thread 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'

2024-04-30 Thread 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)

2024-04-26 Thread 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)

2024-04-26 Thread 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”

2024-04-23 Thread 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

2024-04-16 Thread 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

2024-04-04 Thread 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?

2024-04-04 Thread 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"

2024-03-31 Thread 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

2024-03-25 Thread 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

2024-03-25 Thread 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

2024-03-25 Thread 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 [0x1][BE_REQ_USER][name=

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

2024-03-25 Thread 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. Yes

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

2024-03-25 Thread 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

2024-03-22 Thread 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 *in

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

2024-03-22 Thread 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

2024-03-21 Thread 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 Ha

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

2024-03-21 Thread 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

2024-03-21 Thread 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

2024-03-15 Thread 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

2024-03-13 Thread 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

2024-03-13 Thread 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

2024-03-12 Thread 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

2024-03-12 Thread 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

2024-03-12 Thread 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

2024-03-10 Thread 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

2024-03-10 Thread 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.

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

2024-03-09 Thread 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

2024-03-05 Thread 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
[7363

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

2024-03-05 Thread 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)

2024-02-29 Thread 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 faile

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

2024-02-29 Thread 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)

2024-02-29 Thread 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

2024-02-29 Thread 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

# Load

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

2024-02-27 Thread 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

2024-02-27 Thread 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

2024-02-15 Thread 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 u

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

2024-02-14 Thread 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

2024-02-14 Thread 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 f

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

2024-02-12 Thread 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
(202

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

2024-02-12 Thread 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

2024-02-12 Thread 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

2024-02-12 Thread 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 im

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

2024-02-12 Thread 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[] = { &control, 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,
   &cred, ctrls, NULL, &item->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

2024-02-10 Thread 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

2024-02-07 Thread 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
>  ipa

[Freeipa-users] Re: idrange problem

2024-02-01 Thread 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

2024-01-29 Thread 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

2024-01-29 Thread 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 ('/')

2024-01-24 Thread 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

2024-01-24 Thread 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

1 2 3 4 5 6 7 8 9 10 >

1 - 100 of 1324 matches

Mail list logo