[Freeipa-users] Re: AD Trust with multiple replicas
El sáb, 23 abr 2022 a las 23:55, Alexander Bokovoy () escribió: > > On la, 23 huhti 2022, Cyrus via FreeIPA-users wrote: > >Hello!, > > > >I'm looking to deploy a multisite setup of FreeIPA, it would be 4 > >sites and 2 nodes per site. Alongside FreeIPA, there will also be: > >- a pair of Samba4 controllers per site that I would like to setup trust with > >- sites 5 & 6 from a third party running Windows 2019 AD (single > >domain, DR setup), with which I also need to setup an AD trust. > > > >Is it required that my 8 replicas establish trust with all Samba4 and > >Windows 2019 servers? > > You are using wrong terminology and mixing up preparation of the > replicas with actual trust agreement. Please read > https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/planning_identity_management/planning-a-cross-forest-trust-between-idm-and-ad_planning-identity-management#trust-controllers-and-trust-agents_planning-a-cross-forest-trust-between-idm-and-ad > > You do not need to establish trust again and again from different > replicas. > > In short, trust between IPA and an Active Directory forest is > established once, there is no need to re-establish it multiple times > from different replicas. A replica that can establish trust is called > 'Trust Controller'. A replica that can use trust to resolve users and > groups is called 'Trust Agent'. If you need to ensure that users and > groups from trusted forests can be resolved everywhere, then all those > replicas need to be trust agents. You don't need to re-establish trust > or to make all of those replicas trust controllers. > > So all you need to do is: > > - make at least one Trust Controller > - use a Trust Controller to designate other replicas Trust Agents > - establish trust to the Active Directory forest(s) > > Then all clients connected to Trust Agents and Trust Controllers will be > able to resolve users and groups from trusted forests. > > > > -- > / Alexander Bokovoy > Sr. Principal Software Engineer > Security / Identity Management Engineering > Red Hat Limited, Finland > Good night Alexander, Thanks a lot for the clarification. After reading the documentation, my understanding is that if my users reside on that trusted external domain, I will need to have connectivity from all my FreeIPA nodes (regardless of Trust Controller or Trust Agent role) in order to authenticate those users with my FreeIPA managed machines.. Regards, CI.- ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
[Freeipa-users] Trouble with IPA tools
Howdy. I've been a long-time user of freeipa and have had a small instance running at home via fedora packages for the past 5 years or so. Its actually hard to know just how long I've had it running, but that's besides the point; for what feels like ages I've never had to really mess with it and it kept on ticking. Until recently. I'm no longer able to use the ipa command line tool or the webui. The webui correctly rejects any invalid passwords with an invalid password message, but any /correct/ credentials simply says "Your session has expired. Please log in again.". All of my clients are using the same NTP server as the server, nothing it out of sync, and caches have been cleared multiple times. I know this isn't a browser issue, because of the next point: I can't use the ipa command on my server anymore. Here's a brief sample of one such attempt: [root@io kdc]# kinit admin Password for ad...@malloc.hackerbots.net: [root@io kdc]# ipa -d ipa: DEBUG: Loading Index file from '/var/lib/ipa-client/sysrestore/sysrestore.index' ipa: DEBUG: Loading StateFile from '/var/lib/ipa-client/sysrestore/sysrestore.state' ipa: DEBUG: Loading StateFile from '/var/lib/ipa-client/sysrestore/sysrestore.state' ipa: DEBUG: failed to find session_cookie in persistent storage for principal 'ad...@malloc.hackerbots.net' ipa: DEBUG: trying https://io.malloc.hackerbots.net/ipa/json ipa: DEBUG: Created connection context.rpcclient_139701656917472 ipa: DEBUG: [try 1]: Forwarding 'schema' to json server 'https://io.malloc.hackerbots.net/ipa/json' ipa: DEBUG: New HTTP connection (io.malloc.hackerbots.net) ipa: DEBUG: received Set-Cookie ()'['ipa_session=MagBearerToken=lflo9aPGmula4dSW7i8LbiI7ZNH%2bSycMGOGpqZiZkD0bydWnWfzv7bSuTIzsvdQGPas3BatwwBmREuVlVM0iT0%2by2tto74XdZXXYrv4MhOFT7q3vECladuGsQgqInfrIeLG4a8LMQ0CqE8exLdtttJtt%2fydt1lHzsbHCTigV7TS8CF%2bnZ7558549uo5rJtG%2f6YXG7p0zzhQ4hUYOPwjR%2byux%2bIQhK5PeVu3TKnofFZk%3d;path=/ipa;httponly;secure;']' ipa: DEBUG: storing cookie 'ipa_session=MagBearerToken=lflo9aPGmula4dSW7i8LbiI7ZNH%2bSycMGOGpqZiZkD0bydWnWfzv7bSuTIzsvdQGPas3BatwwBmREuVlVM0iT0%2by2tto74XdZXXYrv4MhOFT7q3vECladuGsQgqInfrIeLG4a8LMQ0CqE8exLdtttJtt%2fydt1lHzsbHCTigV7TS8CF%2bnZ7558549uo5rJtG%2f6YXG7p0zzhQ4hUYOPwjR%2byux%2bIQhK5PeVu3TKnofFZk%3d;' for principal ad...@malloc.hackerbots.net ipa: DEBUG: Destroyed connection context.rpcclient_139701656917472 ipa: ERROR: Insufficient access: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Credential cache is empty) Wish I could say how long its been like this or what I did to break it, but again, its been running for so long that I've never really had to check in on it! This is a Fedora 32 server that has gone through several distro upgrades over the years and through each one, freeipa kept running without issue. I'm certain that at some point in the last year I've upgraded a package that broke this, but there is no way to check. Kerberos continues to work fine; I can login to other services and change passwords and whatnot. ldapsearch returns results and I can bind to it, and other services that utilize ldap for authentication still work great. Except for, of course, the freeipa web app. It looks like freeipa hasn't seen a new release in quite some time, so I'm prepared to do a bunch of debugging myself if anyone could point me in the right directions. Additionally, here's the apache error_log with debug=true in /etc/ipa/server.conf: [Mon Apr 18 10:57:31.776194 2022] [ssl:info] [pid 1989623:tid 1989819] [client 127.0.0.1:42826] AH01964: Connection to child 8 established (server io.malloc.hackerbots.net:443) [Mon Apr 18 10:57:31.776376 2022] [ssl:debug] [pid 1989623:tid 1989819] ssl_engine_kernel.c(2374): [client 127.0.0.1:42826] AH02043: SSL virtual host for servername io.malloc.hackerbots.net found [Mon Apr 18 10:57:31.779851 2022] [ssl:debug] [pid 1989623:tid 1989819] ssl_engine_kernel.c(2254): [client 127.0.0.1:42826] AH02041: Protocol: TLSv1.3, Cipher: TLS_AES_256_GCM_SHA384 (256/256 bits) [Mon Apr 18 10:57:31.779966 2022] [socache_shmcb:debug] [pid 1989623:tid 1989819] mod_socache_shmcb.c(493): AH00831: socache_shmcb_store (0x4a -> subcache 10) [Mon Apr 18 10:57:31.779974 2022] [socache_shmcb:debug] [pid 1989623:tid 1989819] mod_socache_shmcb.c(847): AH00847: insert happened at idx=2, data=(378:410) [Mon Apr 18 10:57:31.779977 2022] [socache_shmcb:debug] [pid 1989623:tid 1989819] mod_socache_shmcb.c(850): AH00848: finished insert, subcache: idx_pos/idx_used=0/3, data_pos/data_used=0/595 [Mon Apr 18 10:57:31.779981 2022] [socache_shmcb:debug] [pid 1989623:tid 1989819] mod_socache_shmcb.c(515): AH00834: leaving socache_shmcb_store successfully [Mon Apr 18 10:57:31.780083 2022] [socache_shmcb:debug] [pid 1989623:tid 1989819] mod_socache_shmcb.c(493): AH00831: socache_shmcb_store (0xde -> subcache 30) [Mon Apr 18 10:57:31.780088 2022] [socache_shmcb:debug] [pid 1989623:tid
[Freeipa-users] Re: Azure AD / Azure AD Connect / FreeIPA sync
Hi Alexander, On Thu, 7 Apr 2022 at 09:30, Alexander Bokovoy wrote: > On to, 07 huhti 2022, Mike Mercier wrote: > >Hi, > > > >The following microsoft document > > > > > https://docs.microsoft.com/en-us/azure/active-directory/fundamentals/sync-ldap > > > >states it is possible (with a warning) to use Azure AD Connect to > >synchronize with LDAP. I figured since FreeIPA was using 389ds in the > >background it might be possible. > > Well, I am not sure what it going to give you in terms of a usability of > this solution. Nobody on my team ever tested it so it is definitely not > supported in RHEL IdM case. > > This link describes Microsoft instructions: > > https://docs.microsoft.com/en-us/microsoft-identity-manager/reference/microsoft-identity-manager-2016-connector-genericldap > > I'd note, though, that in case you'd try to follow their instructions, > you would need to enable unhashed passwords to be stored in the > changelog. See nsslapd-unhashed-pw-switch option in RHDS documentation. > > As far as I understand, this would give you ability to use IPA accounts > in Azure AD IdP, right? E.g. keep users in IPA, let them login to Azure > AD protected applications? > What I was specifically hoping for was the following: 1. Store all user accounts/groups in Azure AD 2. Have the Azure AD information synchronized with FreeIPA 3. Have the ability to use the synchronized information with FreeIPA a. As an example, delegate a user to manage a specific part of the DNS hierarchy But with your comment below, this doesn't sound possible? > This, however, wouldn't give you ability to login to IPA-enrolled > systems by authenticating against Azure AD. > > > > > >Thank you for the information. > > > >Mike > > > > > >On Thu, 7 Apr 2022 at 08:45, Alexander Bokovoy > wrote: > > > >> On to, 07 huhti 2022, Mike Mercier via FreeIPA-users wrote: > >> >Hello, > >> > > >> >I was wondering if anyone has tried to synchronize FreeIPA to Azure AD > >> >using the 'Azure AD Connect' tool? > >> > > >> > > >> > https://docs.microsoft.com/en-us/azure/active-directory/hybrid/whatis-azure-ad-connect > >> > >> This is not supported. > >> > >> >I know the capability to sync with Active Directory is there, but I *do > >> >not* want to configure a Microsoft AD environment. > >> > >> Azure AD Connect only works with on-premise AD environment, so you are > >> confusing yourself. ;) > >> > >> In short, this tool is irrelevant for FreeIPA as it is built for AD, not > >> IPA. > >> > >> -- > >> / 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 > Thanks, Mike ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
[Freeipa-users] FreeIPA 4.9.9
The FreeIPA team would like to announce FreeIPA 4.9.9 release! It can be downloaded from http://www.freeipa.org/page/Downloads. Builds for Fedora distributions will be available from the official repository soon. == Highlights in 4.9.9 * 6524: Vault key archival using AES The vault plugin now uses AES-128-CBC as default wrapping algorithm for the transport of secrets. * 9084: ipa-client-automount --no-sssd broken with authselect 1.3.0 The command ipa-client-automount does not support any more the --no-sssd option. As a consequence, the command always configures the client to use SSSD for automount. * 9095: After ipa-restore, a hidden server is not made visible When a hidden server is restored using ipa-restore, it is now always made visible by marking all its services as enabled instead of hidden. * 9106: Nightly failure (rawhide) when calling kinit admin OpenLDAP 2.6+ removed -h and -p options from OpenLDAP command line utilities (ldapadd/ldapmodify/...). FreeIPA now uses only -H url option to specify the target server and protocol to use. * 9107: Enable ipa-ccache-sweep.timer during server installation New installations of IPA now enable the ipa-ccache-sweep.timer that is removing expired credential caches from the filesystem. === Bug fixes FreeIPA 4.9.9 is a stabilization release for the features delivered as a part of 4.9 version series. There are more than 50 bug-fixes since FreeIPA 4.9.8 release. Details of the bug-fixes can be seen in the list of resolved tickets below. == Upgrading Upgrade instructions are available on Upgrade page. == Feedback Please provide comments, bugs and other feedback via the freeipa-users mailing list (https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/) or #freeipa channel on libera.chat. == Resolved tickets * https://pagure.io/freeipa/issue/6524[#6524] Vault key archival using AES * https://pagure.io/freeipa/issue/7671[#7671] Remove --no-sssd and --noac options * https://pagure.io/freeipa/issue/8001[#8001] Need default authentication indicators for SPAKE, PKINIT and encrypted challenge preauth * https://pagure.io/freeipa/issue/8361[#8361] Add support for managing subuids and subgids in FreeIPA * https://pagure.io/freeipa/issue/8506[#8506] (https://bugzilla.redhat.com/show_bug.cgi?id=1930038[rhbz#1930038]) Nightly failure in ipa-server-install --uninstall: org.freedesktop.DBus.Error.NoReply * https://pagure.io/freeipa/issue/8582[#8582] Nightly test failure in test_replica_promotion.py::TestHiddenReplicaPromotion::test_ipahealthcheck_hidden_replica - ClonesConnectivyAndDataCheck * https://pagure.io/freeipa/issue/8605[#8605] (https://bugzilla.redhat.com/show_bug.cgi?id=1903250[rhbz#1903250]) backtrace using ipa-replica-manage * https://pagure.io/freeipa/issue/8807[#8807] (https://bugzilla.redhat.com/show_bug.cgi?id=1688267[rhbz#1688267]) [RFE] IPA to allow setting a new range type. * https://pagure.io/freeipa/issue/8865[#8865] [Tracker] ipa-replica-install fails on 2nd run (f35+) * https://pagure.io/freeipa/issue/8899[#8899] (https://bugzilla.redhat.com/show_bug.cgi?id=2061957[rhbz#2061957]) healthcheck 0.9 warns about permissions of /var/log/ipaupgrade.log * https://pagure.io/freeipa/issue/8906[#8906] (https://bugzilla.redhat.com/show_bug.cgi?id=1731484[rhbz#1731484]) support for SHA384withRSA signing algo missing * https://pagure.io/freeipa/issue/8962[#8962] (https://bugzilla.redhat.com/show_bug.cgi?id=1966289[rhbz#1966289]) Info about searchrecordslimit set search limit to 10,000 after upgrade * https://pagure.io/freeipa/issue/9004[#9004] Can't use --delattr with a date value * https://pagure.io/freeipa/issue/9009[#9009] Nightly failure (rawhide) in webui_tests: yaml.load() now requires Loader * https://pagure.io/freeipa/issue/9014[#9014] 'init/tmpfilesd/ipa.conf.in' hardcodes apache group * https://pagure.io/freeipa/issue/9024[#9024] Nightly failure (updates-testing) in test_fips.py::TestInstallFIPS * https://pagure.io/freeipa/issue/9031[#9031] Harden FreeIPA KDC processing of PAC buffers * https://pagure.io/freeipa/issue/9038[#9038] (https://bugzilla.redhat.com/show_bug.cgi?id=1825010[rhbz#1825010]) Concerns regarding 'ipa pwpolicy-mod --minlife 24 --maxlife 1' * https://pagure.io/freeipa/issue/9044[#9044] Random nightly failure in test_otp.py::TestOTPToken::test_check_otpd_after_idle_timeout * https://pagure.io/freeipa/issue/9047[#9047] Add automation for ipa-replica-conncheck in upstream tests * https://pagure.io/freeipa/issue/9051[#9051] Nightly test failure (selinux/updates-testing) in ipa-restore * https://pagure.io/freeipa/issue/9052[#9052] Nightly test failure (updates-testing) in test_ipa_cert_fix.py::TestCertFixReplica teardown * https://pagure.io/freeipa/issue/9054[#9054] [ipatests] ipa-healthcheck and URI RRs * https://pagure.io/freeipa/issue/9063[#9063] (https://bugzilla.redhat.com/show_bug.cgi?id=2031825[rhbz#2031825]) Changing default pac type to
[Freeipa-users] Re: Strategy to renew TGT - any thoughts?
Hi Francis, I think with a minor change of logic this issue is rather simple with a bit of scripting and some user training. Rather than getting a new ticket after the old one expires, look for a ticket that expires within X minutes where your other renewal criteria are still met. While that original ticket is active, issue a 'kinit -R' for the user principal. Obviously if your ticket is approaching the end of it's renewable life, you have your original problem again which is where the user training comes into play. To address that I'd ensure that a) the renewal lifetime is long enough to run your longest running long job plus one day (or 3 if some long jobs are started on a Friday with no operators available for the weekend) and b) you have users who execute these kinds of jobs get a new ticket the next work day even if, but especially if, a job is still running). That should cover almost all cases. If you can tell the difference between one of these long jobs and regular interactive activity, you can notify the use (or just flat execute kinit for them) since there are at the computer to answer any prompts for renewal. After adjusting the renewal lifetimes for user tickets, I'd create a script that does this renewal then executes all the remaining user parameters. In the script if the 'kinit -R' fails execute a regular kinit for the principal in use. Train your uses to always start their jobs with this script rather an directly invoking the jobs and they'll always be running the job in an environment where they have enough time to execute the job under a valid ticket that the user has just renewed or they'll be back to the computer before the current one expires to get a new one of the job run takes days. That should handle all the cases except one like the user starting a long job and leaving for long holiday. If you still use a system script to renew almost expired tickets with jobs running, you would even handle that case. To everyone else, thanks for all the great effort on FreeIPA. It has been a fantastic addition to my little network. Best regards, Eric OpenPGP_0x6D7B90C58CAE3115.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature publickey - Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
