Reenrolling IPA client in split-brain environment
by William Faulk
I have an IdM environment where one of the replicas stopped replicating out. A number of clients were enrolled into this replica. They are currently working fine, since they're basically only ever talking to that replica. But I need to fix that replica, and the only feasible solution at this point seems to be a re-initialization. But that means that these clients' enrollments will disappear.
Is there any way to get a client in this state to re-enroll into a different replica that doesn't yet know about it, in such a way that it won't have an interruption in the IdM services it consumes? I only have four systems in this state, so I can reasonably make manual changes to support this, as long as they won't be snowflakes in the long term.
--
William Faulk
13 hours, 49 minutes
Fedora 40: new warning in ipa-healthckeck
by Jochen Kellner
Hi,
I've upgraded my freeipa server to Fedora 40 (the system was installed
several releases ago). After the upgrade I get the following new warning
from ipa-healthcheck:
{
"source": "ipahealthcheck.ds.backends",
"check": "BackendsCheck",
"result": "WARNING",
"uuid": "875db8e3-029c-46f7-87e5-bf9a216d9637",
"when": "20240426184431Z",
"duration": "0.031642",
"kw": {
"key": "DSBLE0005",
"items": [
"nsslapd-dbcachesize",
"nsslapd-db-logdirectory",
"nsslapd-db-transaction-wait",
"nsslapd-db-checkpoint-interval",
"nsslapd-db-compactdb-interval",
"nsslapd-db-compactdb-time",
"nsslapd-db-transaction-batch-val",
"nsslapd-db-transaction-batch-min-wait",
"nsslapd-db-transaction-batch-max-wait",
"nsslapd-db-logbuf-size",
"nsslapd-db-page-size",
"nsslapd-db-locks",
"nsslapd-db-locks-monitoring-enabled",
"nsslapd-db-locks-monitoring-threshold",
"nsslapd-db-locks-monitoring-pause",
"nsslapd-db-private-import-mem",
"nsslapd-db-deadlock-policy"
],
"msg": "Found configuration attributes that are not applicable for the configured backend type."
}
},
According to
https://www.port389.org/docs/389ds/FAQ/Berkeley-DB-deprecation.html the
bdb backend is deprecated. The system was installed with
389-ds-base < 1.4.4.9-1.fc33.x86_64 (I see the upgrade to that version
in /var/log/dnf.rpm.log*. Since 3.0 new installations should use LMBD as
the backend. Is that true for new installations?
What is the desired action that I should take?
I can remove the options from the dirsrv configuration. Should I?
Shall I switch to lmdb manually? Or is that something that
ipa-server-upgrade should be doing?
Otherwise I can suppress the message in ipa-healthcheck for now. But I
guess I should fix my installation before the deprecated support really
gets dropped... Is deploying a new replica and decommisioning the old
server we the preferred action?
Jochen
--
This space is intentionally left blank.
3 days, 16 hours
IPA replica cannot lookup AD trust users (worked before)
by slek kus
Hi, the only replica cannot retrieve AD trust users (one way trust). Trust agent had been installed on this replica.
I noticed this issue, since clients that point to the replica started to fail authenticating users. This replica worked OK before.
All functions and syncs except for the AD user lookup. overrides are synced over but replica cannot find the user.
Can't get it fixed. Is this repairable? Can I uninstall the replica and reinstall?
[root@idm01 ~]# ipa server-role-find
-----------------------
10 server roles matched
-----------------------
Server name: idm01.linux.redacted.domain
Role name: AD trust agent
Role status: enabled
Server name: idm02.linux.redacted.domain
Role name: AD trust agent
Role status: enabled
Server name: idm01.linux.redacted.domain
Role name: AD trust controller
Role status: enabled
Server name: idm02.linux.redacted.domain
Role name: AD trust controller
Role status: enabled
<...>
On the main server, the AD user can be looked up. On the "replica" it returns empty.
working on main server:
[root@idm01 ~]# getent passwd testuser(a)subdoma.redacted.domain
testuser@subdomA.redacted.domain:*:683005154:683005154:CHANGED:/home/testuser:/usr/bin/bash
Checking the sssd_doamin.log of the replica, I see the message that the domain is not active while fetching ad user. Further in the same log there's mention of another subdomain be inactive.
The trust is wirth a AD forest with 2 subdomains.
-----
(2024-04-25 16:40:11): [be[linux.redacted.domain]] [ipa_srv_ad_acct_lookup_done] (0x0040): [RID#34] ipa_get_*_acct request failed: [1432158277]: Subdomain is inactive.
* ... skipping repetitive backtrace ...
<...>
(2024-04-25 16:39:44): [be[linux.redacted.domain]] [resolv_discover_srv_done] (0x0040): [RID#33] SRV query failed [11]: Could not contact DNS servers
* ... skipping repetitive backtrace ...
(2024-04-25 16:39:44): [be[linux.redacted.domain]] [fo_discover_servers_primary_done] (0x0040): [RID#33] Unable to retrieve primary servers [1432158238]: SRV lookup error
* ... skipping repetitive backtrace ...
(2024-04-25 16:39:44): [be[linux.redacted.domain]] [resolve_srv_done] (0x0040): [RID#33] Unable to resolve SRV [1432158238]: SRV lookup error
* ... skipping repetitive backtrace ...
(2024-04-25 16:39:44): [be[linux.redacted.domain]] [fo_resolve_service_send] (0x0020): [RID#33] No available servers for service 'sd_SUBDOMB.redacted.domain'
* ... skipping repetitive backtrace ...
(2024-04-25 16:39:44): [be[linux.redacted.domain]] [ipa_srv_ad_acct_lookup_done] (0x0040): [RID#33] ipa_get_*_acct request failed: [1432158277]: Subdomain is inactive.
********************** PREVIOUS MESSAGE WAS TRIGGERED BY THE FOLLOWING BACKTRACE:
* (2024-04-25 16:39:44): [be[linux.redacted.domain]] [be_resolve_server_done] (0x1000): [RID#33] Server [NULL] resolution failed: [5]: Input/output error
* (2024-04-25 16:39:44): [be[linux.redacted.domain]] [sdap_id_op_connect_done] (0x0400): [RID#33] Failed to connect to server, but ignore mark offline is enabled.
* (2024-04-25 16:39:44): [be[linux.redacted.domain]] [sdap_id_op_connect_done] (0x4000): [RID#33] notify error to op #1: 5 [Input/output error]
* (2024-04-25 16:39:44): [be[linux.redacted.domain]] [be_mark_dom_offline] (0x1000): [RID#33] Marking subdomain SUBDOMB.redacted.domain offline
* (2024-04-25 16:39:44): [be[linux.redacted.domain]] [be_mark_subdom_offline] (0x1000): [RID#33] Marking subdomain SUBDOMB.redacted.domain as inactive
* (2024-04-25 16:39:44): [be[linux.redacted.domain]] [ipa_srv_ad_acct_lookup_done] (0x0040): [RID#33] ipa_get_*_acct request failed: [1432158277]: Subdomain is inactive.
********************** BACKTRACE DUMP ENDS HERE *********************************
There are not replication issues:
----
[root@idm01 ~]# ipa-healthcheck --source=ipahealthcheck.ds.replication
[
{
"source": "ipahealthcheck.ds.replication",
"check": "ReplicationCheck",
"result": "WARNING",
"uuid": "4a5341db-bf65-4350-bf2c-c81872db536b",
"when": "20240425145134Z",
"duration": "0.391402",
"kw": {
"key": "DSREPLLE0002",
"items": [
"Replication",
"Conflict Entries"
],
"msg": "There were 1 conflict entries found under the replication suffix \"dc=linux,dc=redacted,dc=domain\"."
}
}
]
4 days, 1 hour
Re: Password expired is not requested with Ubuntu clients
by Sumit Bose
Am Fri, Apr 19, 2024 at 05:03:46PM +0000 schrieb Carlos Lopez:
> Of course. Here it is:
>
> # PAM configuration for the Secure Shell service
>
> # Standard Un*x authentication.
> @include common-auth
>
> # Disallow non-root logins when /etc/nologin exists.
> account required pam_nologin.so
>
> # Uncomment and edit /etc/security/access.conf if you need to set complex
> # access limits that are hard to express in sshd_config.
> # account required pam_access.so
>
> # Standard Un*x authorization.
> @include common-account
>
> # SELinux needs to be the first session rule. This ensures that any
> # lingering context has been cleared. Without this it is possible that a
> # module could execute code in the wrong domain.
> session [success=ok ignore=ignore module_unknown=ignore default=bad] pam_selinux.so close
>
> # Set the loginuid process attribute.
> session required pam_loginuid.so
>
> # Create a new session keyring.
> session optional pam_keyinit.so force revoke
>
> # Standard Un*x session setup and teardown.
> @include common-session
>
> # Print the message of the day upon successful login.
> # This includes a dynamically generated part from /run/motd.dynamic
> # and a static (admin-editable) part from /etc/motd.
> session optional pam_motd.so motd=/run/motd.dynamic
> session optional pam_motd.so noupdate
>
> # Print the status of the user's mailbox upon successful login.
> session optional pam_mail.so standard noenv # [1]
>
> # Set up user limits from /etc/security/limits.conf.
> session required pam_limits.so
>
> # Read environment variables from /etc/environment and
> # /etc/security/pam_env.conf.
> session required pam_env.so # [1]
> # In Debian 4.0 (etch), locale-related environment variables were moved to
> # /etc/default/locale, so read that as well.
> session required pam_env.so user_readenv=1 envfile=/etc/default/locale
>
> # SELinux needs to intervene at login time to ensure that the process starts
> # in the proper default security context. Only sessions which are intended
> # to run in the user's context should be run after this.
> session [success=ok ignore=ignore module_unknown=ignore default=bad] pam_selinux.so open
>
> # Standard Un*x password updating.
> @include common-password
>
> and common-account:
>
> #
> # /etc/pam.d/common-account - authorization settings common to all services
> #
> # This file is included from other service-specific PAM config files,
> # and should contain a list of the authorization modules that define
> # the central access policy for use on the system. The default is to
> # only deny service to users whose accounts are expired in /etc/shadow.
> #
> # As of pam 1.0.1-6, this file is managed by pam-auth-update by default.
> # To take advantage of this, it is recommended that you configure any
> # local modules either before or after the default block, and use
> # pam-auth-update to manage selection of other modules. See
> # pam-auth-update(8) for details.
> #
>
> # here are the per-package modules (the "Primary" block)
> account [success=1 new_authtok_reqd=done default=ignore] pam_unix.so
> # here's the fallback if no module succeeds
> account requisite pam_deny.so
> # prime the stack with a positive return value if there isn't one already;
> # this avoids us returning an error just because nothing sets a success code
> # since the modules above will each just jump around
> account required pam_permit.so
> # and here are more per-package modules (the "Additional" block)
> # end of pam-auth-update config
Hi,
so pam_sss.so is not called at all which would explain the behavior. I
assume pam_sss.so is listed in common-auth. Did you add it on your own
to common-auth or was it added by a system utility e.g. pam-auth-update?
bye,
Sumit
>
> Best regards,
> C. L. Martinez
>
> ________________________________________
> From: Sumit Bose <sbose(a)redhat.com>
> Sent: 19 April 2024 17:46
> To: FreeIPA users list
> Cc: Carlos Lopez
> Subject: Re: [Freeipa-users] Password expired is not requested with Ubuntu clients
>
> Am Fri, Apr 19, 2024 at 08:56:36AM +0000 schrieb Carlos Lopez via FreeIPA-users:
> > Good morning,
> >
> > I have configured some Ubuntu clientes to authenticate via Kerberos against my RHEL9 IdM server. Everything works correctly: clients are authenticated, etc.
> >
> > The problem comes when a user's password has expired. In the IdM server logs it is clear that the user must change the password:
> >
> > 2024-04-19T08:38:20.946335+00:00 rhelidmsrv01 krb5kdc[21392]: AS_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), DEPRECATED:des3-cbc-sha1(16), DEPRECATED:arcfour-hmac(23), camellia128-cts-cmac(25), camellia256-cts-cmac(26)}) 172.19.11.14: REQUIRED PWCHANGE: user1(a)MYDOM.ORG for krbtgt/MYDOM.ORG(a)MYDOM.ORG, Password has expired
> > 2024-04-19T08:38:20.946413+00:00 rhelidmsrv01 krb5kdc[21392]: closing down fd 13
> > 2024-04-19T08:38:20.946712+00:00 rhelidmsrv01 krb5kdc[21392]: AS_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), DEPRECATED:des3-cbc-sha1(16), DEPRECATED:arcfour-hmac(23), camellia128-cts-cmac(25), camellia256-cts-cmac(26)}) 172.19.11.14: NEEDED_PREAUTH: user1(a)MYDOM.ORG for kadmin/changepw(a)MYDOM.ORG, Additional pre-authentication required
> > 2024-04-19T08:38:20.946747+00:00 rhelidmsrv01 krb5kdc[21392]: closing down fd 13
> > 2024-04-19T08:38:20.950691+00:00 rhelidmsrv01 krb5kdc[21392]: AS_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), DEPRECATED:des3-cbc-sha1(16), DEPRECATED:arcfour-hmac(23), camellia128-cts-cmac(25), camellia256-cts-cmac(26)}) 172.19.11.14: ISSUE: authtime 1713515900, etypes {rep=aes256-cts-hmac-sha1-96(18), tkt=aes256-cts-hmac-sha384-192(20), ses=aes256-cts-hmac-sha1-96(18)}, user1(a)MYDOM.ORG for kadmin/changepw(a)MYDOM.ORG
> >
> > But when accessing to Ubuntu client via ssh, it never prompts to change the password and you can log in.
>
> Hi,
>
> can you share your PAM configuration for the sshd service. I'm asking
> because the change of expired passwords in handled in the 'account'
> section and I guess with your configuration (local users with
> authentication by SSSD) pam_sss.so is not called for local users during
> 'account'.
>
> bye,
> Sumit
>
> >
> > My sssd's config in Ubuntu client is:
> >
> > [sssd]
> > config_file_version = 2
> > services = pam
> > domains = mydom.org
> >
> > [pam]
> > pam_pwd_expiration_warning = 2
> >
> > [domain/mydom.org]
> > id_provider = proxy
> > proxy_lib_name = files
> > auth_provider = krb5
> > chpass_provider = krb5
> > krb5_server = rhelidmsrv01.mydom.org
> > krb5_kpasswd = rhelidmsrv01.mydom.org
> > krb5_realm = mydom.org
> > krb5_ccname_template = KEYRING:persistent:%U
> > krb5_validate = true
> > cache_credentials = true
> >
> > What could be the problem?
> >
> > Best regards,
> > C. L. Martinez
> > --
> > _______________________________________________
> > FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
> > To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org
> > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedoraho...
> > Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
>
4 days, 4 hours
LDAP conflicts after yum update on Almalinux 8.9
by Lee Csk
After performing a usual Yum update's on multiple IPA servers (not at the same time, one server reportedly started hanging), we started observing "LDAP Conflicts" in multiple IPA replication servers:
az2-replica.noc.net
| LDAP Conflicts | 9 | FAIL |
mi2-replica.noc.net:
| LDAP Conflicts | 9 | FAIL |
mi1-replica.noc.net:
| LDAP Conflicts | 9 | FAIL |
az1-replica.noc.net:
| LDAP Conflicts | 10 | FAIL |
sg1-replicate.noc.net:
| LDAP Conflicts | 3 | FAIL |
sg2-replica.noc.net
| LDAP Conflicts | 3 | FAIL |
The "Replication status" while reports OK, we observe also flapping at times between OK and FAIL too.
We have tried to follow on one of the replication servers: https://access.redhat.com/documentation/en-us/red_hat_directory_server/11...
- by removing the orphan entry, however the replication broke completely on it (ipa service couldn't start back up), requiring a full re-install of that specific replica.
]$ sudo -u admin /home/admin/.local/bin/cipa -H localhost |grep "LDAP Conflicts"
| LDAP Conflicts | 0 | OK |
$ dsconf -D "cn=Directory Manager" ldap://$(hostname) repl-conflict list-glue "dc=noc,dc=net"
Enter password for cn=Directory Manager on ldap://az1-replica.noc.net:
dn: cn=sg1-replica.noc.net,cn=masters,cn=ipa,cn=etc,dc=noc,dc=net
cn: sg1-replica.noc.net
ipaLocation: idnsname=singapore,cn=locations,cn=etc,dc=noc,dc=net
ipaMaxDomainLevel: 1
ipaMinDomainLevel: 1
ipaReplTopoManagedSuffix: dc=noc,dc=net
nsds5replconflict: deletedEntryHasChildren
objectClass: top
objectClass: nsContainer
objectClass: ipaReplTopoManagedServer
objectClass: ipaConfigObject
objectClass: ipaSupportedDomainLevelConfig
objectClass: ipalocationmember
objectClass: extensibleobject
objectClass: glue
$ ldapsearch -H ldaps://$(hostname) -W -D 'cn=Directory Manager' '(&(objectClass=ldapSubEntry)(nsds5ReplConflict=*))' nsds5ReplConflict
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base <dc=noc,dc=net> (default) with scope subtree
# filter: (&(objectClass=ldapSubEntry)(nsds5ReplConflict=*))
# requesting: nsds5ReplConflict
#
# sg1-replica.noc.net + 039c4293-257f11ed-a255f732-cfd01100, masters, ipa, etc, noc.net
dn: cn=sg1-replica.noc.net+nsuniqueid=039c4293-257f11ed-a255f732-cfd01100,cn=masters,cn=ipa,cn=etc,dc=noc,dc=net
nsds5ReplConflict: namingConflict (ADD) cn=sg1-replica.noc.net,cn=masters,cn=ipa,cn=etc,dc=noc,dc=net
# HTTP/mi1-replica.noc.net(a)noc.NET + 0264df8b-fca611ee-a3cba8b9-8a6b8039,services, accounts, noc.net
dn: krbprincipalname=HTTP/mi1-replica.noc.net@NOC.NET+nsuniqueid=0264df8b-fca611ee-a3cba8b9-8a6b8039,cn=services,cn=accounts,dc=noc,dc=net
nsds5ReplConflict: namingConflict (ADD) krbprincipalname=http/mi1-ipaca.noc.net(a)noc.net,cn=services,cn=accounts,dc=noc,dc=net
# search result
search: 2
result: 0 Success
# numResponses: 3
# numEntries: 2
OR:
az1-replica.noc.net:/$ ldapsearch -H ldap://$(hostname) -D "cn=Directory Manager" -W -b "dc=noc,dc=net" "(&(objectClass=ldapSubEntry)(nsds5ReplConflict=*))" \* nsds5ReplConflict
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base <dc=noc,dc=net> with scope subtree
# filter: (&(objectClass=ldapSubEntry)(nsds5ReplConflict=*))
# requesting: * nsds5ReplConflict
#
# sg1-replica.noc.net + 039c4293-257f11ed-a255f732-cfd01100, masters, ipa,
etc, noc.net
dn: cn=sg1-replica.noc.net+nsuniqueid=039c4293-257f11ed-a255f732-cfd01100
,cn=masters,cn=ipa,cn=etc,dc=noc,dc=net
ipaLocation: idnsname=singapore,cn=locations,cn=etc,dc=noc,dc=net
objectClass: top
objectClass: nsContainer
objectClass: ipaReplTopoManagedServer
objectClass: ipaConfigObject
objectClass: ipaSupportedDomainLevelConfig
objectClass: ldapsubentry
objectClass: ipalocationmember
cn: sg1-replica.noc.net
ipaReplTopoManagedSuffix: dc=noc,dc=net
ipaMinDomainLevel: 1
ipaMaxDomainLevel: 1
nsds5ReplConflict: namingConflict (ADD) cn=sg1-replica.noc.net,cn=masters
,cn=ipa,cn=etc,dc=noc,dc=net
# search result
search: 2
result: 0 Success
# numResponses: 2
# numEntries: 1
We expect: | LDAP Conflicts | 0 | OK |
Running versions:
ipa-server-4.9.12-14.module_el8.9.0+3785+2238a12a.alma.1.x86_64
ipa-client-4.9.12-14.module_el8.9.0+3785+2238a12a.alma.1.x86_64
389-ds-base-1.4.3.37-2.module_el8.9.0+3710+3183c30a.alma.1.x86_64
krb5-server-1.18.2-26.el8_9.x86_64
The yum update happened from:
ipa-server-4.9.12-11.module_el8.9.0+3715+e4197dc9.alma.1.x86_64
to:
ipa-server-4.9.12-14.module_el8.9.0+3785+2238a12a.alma.1.x86_64
Please advise, how its best to resolve these "LDAP Conflicts".
How to remove, or retain if its the case?
Thanks,
Lee
5 days
autofs freezes system after update to F40.
by Albert Szostkiewicz
Yesterday I've upgraded F38-F49, all went fine, no issues. Today I tried F39-f40 and system freezes on autofs. Got some sssd errors, and i assume it might be all related (?).
There are no errors from autofs side itself, only warning:
"autofs.service: Referenced but unset environment variable evaluates to an empty string: OPTIONS"
. As soon as I enable autofs, all system is frozen (although my nfs mounts are set to 'soft').
I am getting those errors, which I have reported here (https://github.com/SSSD/sssd/issues/7314) as I saw something similar being reported year ago:
/var/log/sssd/krb5_child.log
(2024-04-24 14:15:14): [krb5_child[13003]] [sss_krb5_expire_callback_func] (0x0020): [RID#97] Time to expire out of range.
********************** PREVIOUS MESSAGE WAS TRIGGERED BY THE FOLLOWING BACKTRACE:
* (2024-04-24 14:15:14): [krb5_child[13003]] [main] (0x0400): [RID#97] krb5_child started.
* (2024-04-24 14:15:14): [krb5_child[13003]] [unpack_buffer] (0x1000): [RID#97] total buffer size: [113]
* (2024-04-24 14:15:14): [krb5_child[13003]] [unpack_buffer] (0x0100): [RID#97] cmd [241 (auth)] uid [1907400001] gid [1907400001] validate [true] enterprise principal [false] offline [false] UPN [user(a)DOMAIN.COM]
* (2024-04-24 14:15:14): [krb5_child[13003]] [unpack_buffer] (0x0100): [RID#97] ccname: [KCM:] old_ccname: [KCM:] keytab: [/etc/krb5.keytab]
* (2024-04-24 14:15:14): [krb5_child[13003]] [switch_creds] (0x0200): [RID#97] Switch workstation(a)domain.com to [1907400001][1907400001].
* (2024-04-24 14:15:14): [krb5_child[13003]] [switch_creds] (0x0200): [RID#97] Switch workstation(a)domain.com to [0][0].
* (2024-04-24 14:15:14): [krb5_child[13003]] [k5c_check_old_ccache] (0x4000): [RID#97] Ccache_file is [KCM:] and is active and TGT is valid.
* (2024-04-24 14:15:14): [krb5_child[13003]] [k5c_setup_fast] (0x0100): [RID#97] Fast principal is set to [host/workstation(a)domain.com]
* (2024-04-24 14:15:14): [krb5_child[13003]] [find_principal_in_keytab] (0x4000): [RID#97] Trying to find principal host/workstation(a)domain.com in keytab.
* (2024-04-24 14:15:14): [krb5_child[13003]] [match_principal] (0x1000): [RID#97] Principal matched to the sample (host/workstation(a)domain.com).
* (2024-04-24 14:15:14): [krb5_child[13003]] [check_fast_ccache] (0x0200): [RID#97] FAST TGT is still valid.
* (2024-04-24 14:15:14): [krb5_child[13003]] [become_workstation(a)domain.com] (0x0200): [RID#97] Trying to become workstation(a)domain.com [1907400001][1907400001].
* (2024-04-24 14:15:14): [krb5_child[13003]] [main] (0x2000): [RID#97] Running as [1907400001][1907400001].
* (2024-04-24 14:15:14): [krb5_child[13003]] [set_lifetime_options] (0x0100): [RID#97] No specific renewable lifetime requested.
* (2024-04-24 14:15:14): [krb5_child[13003]] [set_lifetime_options] (0x0100): [RID#97] No specific lifetime requested.
* (2024-04-24 14:15:14): [krb5_child[13003]] [set_canonicalize_option] (0x0100): [RID#97] Canonicalization is set to [true]
* (2024-04-24 14:15:14): [krb5_child[13003]] [main] (0x0400): [RID#97] Will perform auth
* (2024-04-24 14:15:14): [krb5_child[13003]] [main] (0x0400): [RID#97] Will perform online auth
* (2024-04-24 14:15:14): [krb5_child[13003]] [tgt_req_child] (0x1000): [RID#97] Attempting to get a TGT
* (2024-04-24 14:15:14): [krb5_child[13003]] [get_and_save_tgt] (0x0400): [RID#97] Attempting kinit for realm [DOMAIN.COM]
* (2024-04-24 14:15:14): [krb5_child[13003]] [sss_krb5_responder] (0x4000): [RID#97] Got question [password].
* (2024-04-24 14:15:14): [krb5_child[13003]] [sss_krb5_expire_callback_func] (0x0020): [RID#97] Time to expire out of range.
********************** BACKTRACE DUMP ENDS HERE *********************************
(2024-04-24 14:15:14): [krb5_child[13003]] [sss_extract_pac] (0x0040): [RID#97] No PAC authdata available.
********************** PREVIOUS MESSAGE WAS TRIGGERED BY THE FOLLOWING BACKTRACE:
* (2024-04-24 14:15:14): [krb5_child[13003]] [validate_tgt] (0x2000): [RID#97] Found keytab entry with the realm of the credential.
* (2024-04-24 14:15:14): [krb5_child[13003]] [validate_tgt] (0x0400): [RID#97] TGT verified using key for [host/workstation(a)domain.com].
* (2024-04-24 14:15:14): [krb5_child[13003]] [sss_extract_pac] (0x0040): [RID#97] No PAC authdata available.
********************** BACKTRACE DUMP ENDS HERE *********************************
(2024-04-24 14:15:14): [krb5_child[13003]] [validate_tgt] (0x0040): [RID#97] sss_extract_and_send_pac failed, group membership for workstation(a)domain.com with principal [user(a)DOMAIN.COM] might not be correct.
5 days, 11 hours
Error adding cross trust between FreeIPA and Zentyal (Samba)
by Joyce Babu
I am trying to setup cross trust between IPA and Samba. When I try to run
ipa trust-add --type=ad ad.example.org --admin Administrator --password --range-type=ipa-ad-trust
The command aborts with error
ipa: ERROR: CIFS server communication error: code "3221225473", message "{Operation Failed} The requested operation was unsuccessful." (both may be "None")
Samba log on the Zentyal server has the following error message
Kerberos: Client (Administrator(a)AD.EXAMPLE.ORG) from ipv4:10.15.5.2:41504 has no common enctypes with KDC to use for the session key
6 days, 21 hours
User Agreement Description Field
by Riccardo Rotondo
Hi,
I defined an Agreement in the web-ui and I can see loaded in noggin.
I was wondering if the description support html, markdown or any other syntax in order to put an url clickable in the description.
I made some tests but with no luck.
Thank you in advance.
Riccardo
1 week
Not possible to delete ID views from Default Trust View if user is no longer present in AD
by LHEUREUX Bernard
Hello,
I’m trying to delete some anchors on Default Trust View on a FreeIPA with trust to an AD and, I always get the message “…@... user not found »
Effectively those users are no longer part of the organization and have been removed from the AD, but how could I clean them in the Default Trust View
Thanks for your help.
---
Bernard Lheureux
Win S.A.
________________________________
1/Conformément à notre certification ISO 27001, ce message et toute pièce jointe sont la propriété exclusive de Win. L’information contenue dans cet e- mail peut s’avérer confidentielle et dès lors protégée de toute divulgation. Si vous avez reçu cette communication par erreur, veuillez nous en informer immédiatement en répondant à ce message et en le supprimant de votre ordinateur, sans le copier ni le divulguer.
2/L’acceptation de toute offre commerciale (quel qu’en soit le support) emporte l’adhésion aux descriptifs (notamment techniques) inhérents aux solutions offertes, ainsi qu’aux conditions commerciales générales de Win, consultables via https://www.win.be/cgv
DISCLAIMER : https://www.win.be/fr-win/disclaimer.htm
1 week
Question regarding “Samba on an IdM domain member”
by Thomas Handler
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_lin... 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.
Thank you.
Best regards,
Thomas
1 week
