AD Conditional Forwarder to IdM failure
by Jeremy Tourville
I am following the directions from here:
Section: 32.6.4. Configuring DNS forwarding in AD
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/...
I get an error message from AD DNS "The server with this IP Address is not authoritative for the required zone"
This error makes me think there is a problem with my IdM DNS server.
My setup is AD integrated and a one way trust is established with AD. I was able to create a forwarder from IdM to AD without issue.
My domains:
AD = gsil.mil
IdM = idm.gsil.mil
I have been reading:
86.1. Supported DNS zone types
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/...
and
6.1. The two roles of an IdM DNS server
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/...
as well as several articles on DNS forwarding vs DNS delegation for AD.
This is a step that I was able to make work with no issues in a previous setup/installation.
Red Hat documentation states:
86.1 Supported DNS Zone Types
"Forward DNS zones
From the perspective of IdM, forward DNS zones do not contain any authoritative data. In fact, a forward "zone" usually only contains two pieces of information:
- A domain name
- The IP address of a DNS server associated with the domain "
6.1. The two roles of an IdM DNS server
By default, the Berkeley Internet Name Domain (BIND) service integrated with IdM acts as both an authoritative and a recursive DNS server:
Authoritative DNS server
When a DNS client queries a name belonging to a DNS zone for which the IdM server is authoritative, BIND replies with data contained in the configured zone. Authoritative data always takes precedence over any other data.
I am still having some confusion why this is not working. Can someone enlighten me?
1 year, 3 months
Cannot Login with IPA user account
by Damola Azeez
After setting up my IPA environment, I am unable to log in successfully on some of my Linux servers. When I check /var/log/secure for authentication logs, I see the errors below
Dec 30 12:18:31 e-recondbtest su: pam_sss(su-l:auth): authentication failure; logname=dazeez uid=1001 euid=0 tty=pts/1 ruser=dazeez rhost= user=daazeez
Dec 30 12:18:31 e-recondbtest su: pam_sss(su-l:auth): received for user daazeez: 6 (Permission denied)
Dec 30 12:18:46 e-recondbtest su: pam_sss(su-l:auth): authentication failure; logname=dazeez uid=1001 euid=0 tty=pts/1 ruser=dazeez rhost= user=daazeez
Dec 30 12:18:46 e-recondbtest su: pam_sss(su-l:auth): received for user daazeez: 6 (Permission denied)
From the root user, I can switch to the user (daazeez) but when I try sudo, inputting password return authentication failed
Host: oracle linux 7.4
IPA server: IPA, version: 4.9.8
1 year, 3 months
DNS issues when installing a replica
by Francis Augusto Medeiros-Logeay
Hi,
I am managing now to install a replica, but I am facing these issues, and feel things are not working as it should, as changes in one replica are not replicating on the others.
I am getting this when installing the replica:
Replica DNS records could not be added on master: Insufficient access: Insufficient 'add' privilege to add the entry 'idnsname=freeipa02,idnsname=francis.local.,cn=dns,dc=ipa,dc=med-lo’
This, together with "Lookup failed: Preferred host freeipa02.francis.local does not provide DNS.” and with "Lookup failed: Preferred host freeipa02.francis.local does not provide CA.” , are really preventing me to install a problem-free replica.
Any clues on how to solve it? I tried this: https://access.redhat.com/solutions/4094761 but it didn’t help.
Best,
Francis
1 year, 3 months
Password resets seem to not be working?
by Tom Spettigue
Hey all -
I'm having an issue whereby password resets for users don't appear to be working... fully. It's odd because, if, through the web interface, I click "Actions", and then "Reset Password", and set it to some temporary password, I can then login to an IPA client server with that password. That server then prompts me to reset the user's password - confirming, to me, that the password reset "signal" has indeed been sent to that server. I then do the password reset, and can then log into that AND OTHER client servers with that password, suggesting that the password reset has worked!
BUT. When I try to connect to that user via LDAP, using that same password, I get "Invalid credentials (49)". Further, if I try a `kinit $USER` from any of those CLIENT servers, and punch in the password, it seems fine! But whenever I try the SAME `kinit $user` command from the IPA servers, I get `kinit: Password incorrect while getting initial credentials`, which is... deeply troubling, to say the least.
What on Earth is going on?
1 year, 3 months
Grant sudo to users only on their own workstations
by Ranbir
We have many users that run GNU/Linux workstations. At the moment
everyone is using local accounts. We want to convert them to IPA
clients and still allow them sudo privileges on their own workstations.
It's easy to grant them access to their workstations by making them all
a member of a "workstation" AD group and letting them login with ssh,
GNOME, etc. What's less obvious is how to centrally give them sudo
access only on their own workstations.
I could create an HBAC rule per person to give them sudo privileges to
their own workstation, but then I'll have to make hundreds of rules.
The only solution appears to be to keep the access (i.e. ssh, desktop
environment) centrally controlled in IPA, but make the custom sudo
access locally controlled. Is this the only way to do what I want?
Thanks in advance.
--
Ranbir
1 year, 3 months
DNS Global Forwarder
by Francis Augusto Medeiros-Logeay
Hi,
I’ve read a bit about how DNS and FreeIPA work, and I have it working fine.
Now that I have replicas on another premise, I can’t seem to set a Global Forwarder individually on the replicas. So if I have a 192.168.1.1 on my premise A, it gets copied to premise B, which won’t be reachable on the latter.
Any tips on how to deal with such situations? Or am I misunderstanding something here?
Best,
Francis
1 year, 3 months
Replica install: LDAP error: Can't contact LDAP server - no response received
by Francis Augusto Medeiros-Logeay
Hi,
I am trying to create a replica, but somehow I keep getting this error:
[26/39]: setting up initial replication
Starting replication, please wait until this has completed.
Update in progress, 14 seconds elapsed
[ldap://free02.ipa.local:389] reports: Update failed! Status: [Error
(-1) - LDAP error: Can't contact LDAP server - no response received]
I am joining it this way:
sudo ipa-replica-install -w mypass -n ipa.local --server
free02.ipa.local --hostname freeipa02.francis.local --ntp-pool
ntp.uio.no --force-join --setup-dns --auto-forwarders --skip-conncheck
What can I do to investigate it?
I see that the 389 port is reachable from the server on which I want to
install a replica.
Any tips would be welcome!
Best,
--
Francis Augusto Medeiros-Logeay
Oslo, Norway
1 year, 3 months
Users can login only sometimes with a IPA-AD trust
by tizo
We have an IPA-AD trust up and running. The IPA domain is
idm.fnr.gub.uy and the AD (Samba) domain is smb.fnr.gub.uy. Our users
belong to AD.
We have a couple of Ubuntu 22.04 IPA clients configured. In the first
one, all works like a charm, and AD users can login without problems.
In the second one, AD users can login sometimes, and sometimes not.
The log /var/log/sssd/krb5_child.log is completely empty in the first
case. In the second one, we have the following when a user cannot
login:
(2023-01-04 11:42:11): [krb5_child[4430]] [get_and_save_tgt] (0x0020):
[RID#19] 1725: [-1765328353][Decrypt integrity check failed]
********************** PREVIOUS MESSAGE WAS TRIGGERED BY THE FOLLOWING
BACKTRACE:
* (2023-01-04 11:42:10): [krb5_child[4430]] [main] (0x0400):
[RID#19] krb5_child started.
* (2023-01-04 11:42:10): [krb5_child[4430]] [unpack_buffer]
(0x1000): [RID#19] total buffer size: [134]
* (2023-01-04 11:42:10): [krb5_child[4430]] [unpack_buffer]
(0x0100): [RID#19] cmd [241 (auth)] uid [700000003] gid [700000005]
validate [true] enterprise principal [false] offline [false] UPN
[mduffour(a)SMB.FNR.GUB.UY]
* (2023-01-04 11:42:10): [krb5_child[4430]] [unpack_buffer]
(0x2000): [RID#19] No old ccache
* (2023-01-04 11:42:10): [krb5_child[4430]] [unpack_buffer]
(0x0100): [RID#19] ccname: [KEYRING:persistent:700000003] old_ccname:
[not set] keytab: [/etc/krb5.keytab]
* (2023-01-04 11:42:10): [krb5_child[4430]] [k5c_precreate_ccache]
(0x4000): [RID#19] Recreating ccache
* (2023-01-04 11:42:10): [krb5_child[4430]] [k5c_setup_fast]
(0x0100): [RID#19] Fast principal is set to
[host/laptingw02.idm.fnr.gub.uy(a)IDM.FNR.GUB.UY]
* (2023-01-04 11:42:10): [krb5_child[4430]]
[find_principal_in_keytab] (0x4000): [RID#19] Trying to find principal
host/laptingw02.idm.fnr.gub.uy(a)IDM.FNR.GUB.UY in keytab.
* (2023-01-04 11:42:10): [krb5_child[4430]] [match_principal]
(0x1000): [RID#19] Principal matched to the sample
(host/laptingw02.idm.fnr.gub.uy(a)IDM.FNR.GUB.UY).
* (2023-01-04 11:42:10): [krb5_child[4430]] [check_fast_ccache]
(0x0200): [RID#19] FAST TGT is still valid.
* (2023-01-04 11:42:10): [krb5_child[4430]]
[privileged_krb5_setup] (0x0080): [RID#19] Cannot open the PAC
responder socket
* (2023-01-04 11:42:10): [krb5_child[4430]] [become_user]
(0x0200): [RID#19] Trying to become user [700000003][700000005].
* (2023-01-04 11:42:10): [krb5_child[4430]] [main] (0x2000):
[RID#19] Running as [700000003][700000005].
* (2023-01-04 11:42:10): [krb5_child[4430]] [set_lifetime_options]
(0x0100): [RID#19] No specific renewable lifetime requested.
* (2023-01-04 11:42:10): [krb5_child[4430]] [set_lifetime_options]
(0x0100): [RID#19] No specific lifetime requested.
* (2023-01-04 11:42:10): [krb5_child[4430]]
[set_canonicalize_option] (0x0100): [RID#19] Canonicalization is set
to [true]
* (2023-01-04 11:42:10): [krb5_child[4430]] [main] (0x0400):
[RID#19] Will perform auth
* (2023-01-04 11:42:10): [krb5_child[4430]] [main] (0x0400):
[RID#19] Will perform online auth
* (2023-01-04 11:42:10): [krb5_child[4430]] [tgt_req_child]
(0x1000): [RID#19] Attempting to get a TGT
* (2023-01-04 11:42:10): [krb5_child[4430]] [get_and_save_tgt]
(0x0400): [RID#19] Attempting kinit for realm [SMB.FNR.GUB.UY]
* (2023-01-04 11:42:11): [krb5_child[4430]] [sss_krb5_responder]
(0x4000): [RID#19] Got question [password].
* (2023-01-04 11:42:11): [krb5_child[4430]] [get_and_save_tgt]
(0x0020): [RID#19] 1725: [-1765328353][Decrypt integrity check failed]
********************** BACKTRACE DUMP ENDS HERE
*********************************
(2023-01-04 11:42:11): [krb5_child[4430]] [map_krb5_error] (0x0020):
[RID#19] 1854: [-1765328353][Decrypt integrity check failed]
And the following when the same user is able to login:
(2023-01-04 11:42:29): [krb5_child[4432]] [validate_tgt] (0x0040):
[RID#21] sss_send_pac failed, group membership for user with principal
[mduffour(a)SMB.FNR.GUB.UY] might not be correct.
********************** PREVIOUS MESSAGE WAS TRIGGERED BY THE FOLLOWING
BACKTRACE:
* (2023-01-04 11:42:28): [krb5_child[4432]] [main] (0x0400):
[RID#21] krb5_child started.
* (2023-01-04 11:42:28): [krb5_child[4432]] [unpack_buffer]
(0x1000): [RID#21] total buffer size: [134]
* (2023-01-04 11:42:28): [krb5_child[4432]] [unpack_buffer]
(0x0100): [RID#21] cmd [241 (auth)] uid [700000003] gid [700000005]
validate [true] enterprise principal [false] offline [false] UPN
[mduffour(a)SMB.FNR.GUB.UY]
* (2023-01-04 11:42:28): [krb5_child[4432]] [unpack_buffer]
(0x2000): [RID#21] No old ccache
* (2023-01-04 11:42:28): [krb5_child[4432]] [unpack_buffer]
(0x0100): [RID#21] ccname: [KEYRING:persistent:700000003] old_ccname:
[not set] keytab: [/etc/krb5.keytab]
* (2023-01-04 11:42:28): [krb5_child[4432]] [k5c_precreate_ccache]
(0x4000): [RID#21] Recreating ccache
* (2023-01-04 11:42:28): [krb5_child[4432]] [k5c_setup_fast]
(0x0100): [RID#21] Fast principal is set to
[host/laptingw02.idm.fnr.gub.uy(a)IDM.FNR.GUB.UY]
* (2023-01-04 11:42:28): [krb5_child[4432]]
[find_principal_in_keytab] (0x4000): [RID#21] Trying to find principal
host/laptingw02.idm.fnr.gub.uy(a)IDM.FNR.GUB.UY in keytab.
* (2023-01-04 11:42:28): [krb5_child[4432]] [match_principal]
(0x1000): [RID#21] Principal matched to the sample
(host/laptingw02.idm.fnr.gub.uy(a)IDM.FNR.GUB.UY).
* (2023-01-04 11:42:28): [krb5_child[4432]] [check_fast_ccache]
(0x0200): [RID#21] FAST TGT is still valid.
* (2023-01-04 11:42:28): [krb5_child[4432]]
[privileged_krb5_setup] (0x0080): [RID#21] Cannot open the PAC
responder socket
* (2023-01-04 11:42:28): [krb5_child[4432]] [become_user]
(0x0200): [RID#21] Trying to become user [700000003][700000005].
* (2023-01-04 11:42:28): [krb5_child[4432]] [main] (0x2000):
[RID#21] Running as [700000003][700000005].
* (2023-01-04 11:42:28): [krb5_child[4432]] [set_lifetime_options]
(0x0100): [RID#21] No specific renewable lifetime requested.
* (2023-01-04 11:42:28): [krb5_child[4432]] [set_lifetime_options]
(0x0100): [RID#21] No specific lifetime requested.
* (2023-01-04 11:42:28): [krb5_child[4432]]
[set_canonicalize_option] (0x0100): [RID#21] Canonicalization is set
to [true]
* (2023-01-04 11:42:28): [krb5_child[4432]] [main] (0x0400):
[RID#21] Will perform auth
* (2023-01-04 11:42:28): [krb5_child[4432]] [main] (0x0400):
[RID#21] Will perform online auth
* (2023-01-04 11:42:28): [krb5_child[4432]] [tgt_req_child]
(0x1000): [RID#21] Attempting to get a TGT
* (2023-01-04 11:42:28): [krb5_child[4432]] [get_and_save_tgt]
(0x0400): [RID#21] Attempting kinit for realm [SMB.FNR.GUB.UY]
* (2023-01-04 11:42:28): [krb5_child[4432]] [sss_krb5_responder]
(0x4000): [RID#21] Got question [password].
* (2023-01-04 11:42:28): [krb5_child[4432]]
[sss_krb5_expire_callback_func] (0x2000): [RID#21] exp_time:
[10276087]
* (2023-01-04 11:42:28): [krb5_child[4432]] [validate_tgt]
(0x2000): [RID#21] Keytab entry with the realm of the credential not
found in keytab. Using the last entry.
* (2023-01-04 11:42:29): [krb5_child[4432]] [validate_tgt]
(0x0400): [RID#21] TGT verified using key for
[host/laptingw02.idm.fnr.gub.uy(a)IDM.FNR.GUB.UY].
* (2023-01-04 11:42:29): [krb5_child[4432]] [sss_send_pac]
(0x0080): [RID#21] failed to contact PAC responder
* (2023-01-04 11:42:29): [krb5_child[4432]] [validate_tgt]
(0x0040): [RID#21] sss_send_pac failed, group membership for user with
principal [mduffour(a)SMB.FNR.GUB.UY] might not be correct.
********************** BACKTRACE DUMP ENDS HERE
*********************************
I have tried clearing all sssd caches (even removing
/var/lib/sss/db/*), restarting all the servers, uninstalling ipa
client and configuring it again, etc. The behaviour is always the
same.
Any help is appreciated. Thanks very much,
tizo
1 year, 3 months
