Linux-AD Direct Integration with SSSD & Kerberos

Hi Fellow Members,

We are trying to integrate a Linux (Rocky Linux 8.5) with Active Directory Domain with the direct integration using SSSD. While most of this has been successful in fetching the user accounts and groups etc. as we continued to expand the scope further (to NFS v4 mounts with Kerberos auth) we started running into challenges and it backtracked us almost to krb5.conf

Would this group recommend any standard/recommended krb5.conf since we tried a few random not sure which is the correct config to use now.

For domain joining, using the command:

realm join -U Administrator@fractal.com FRACTAL.COM --verbose

With different configs and trials resulted in the below mix of errors (latest to oldest order).

  1. Couldn't get kerberos ticket for: Administrator@fractal.com: Cannot find KDC for realm "fractal.com"

  2. Couldn't authenticate as: Administrator@fractal.com: Preauthentication failed

  3. Couldn't get kerberos ticket for: Administrator@fractal.com: KDC reply did not match expectations

  4. Couldn't authenticate with keytab while discovering which salt to use: WKS013$@FRACTAL.COM: Client 'WKS013$@FRACTAL.COM' not found in Kerberos database

Any thoughts on narrowing this down to get fixed and working will be appreciated.

Thanks,
Bhavik

Adding below the krb5.conf for more details and context,

# To opt out of the system crypto-policies configuration of krb5, remove the
# symlink at /etc/krb5.conf.d/crypto-policies which will not be recreated.
includedir /etc/krb5.conf.d/

[logging]
    default = FILE:/var/log/krb5libs.log
    kdc = FILE:/var/log/krb5kdc.log
    admin_server = FILE:/var/log/kadmind.log

[libdefaults]
    default_realm = FRACTAL.COM
    dns_lookup_realm = false
    dns_lookup_kdc = false
    ticket_lifetime = 24h
    renew_lifetime = 7d
    forwardable = true
    #rdns = false
    #pkinit_anchors = FILE:/etc/pki/tls/certs/ca-bundle.crt
    #spake_preauth_groups = edwards25519
    #default_ccache_name = KEYRING:persistent:%{uid}
    #default_tgs_enctypes = arcfour-hmac-md5 des-cbc-crc des-cbc-md5
    #default_tkt_enctypes = arcfour-hmac-md5 des-cbc-crc des-cbc-md5

[realms]
# EXAMPLE.COM = {
#     kdc = kerberos.example.com
#     admin_server = kerberos.example.com
# }
FRACTAL.COM = {
    kdc = fprdc.fractal.com
    admin_server = fprdc.fractal.com
    default_domain = FRACTAL.COM
}

[domain_realm]
# .example.com = EXAMPLE.COM
# example.com = EXAMPLE.COM
.fractal.com = FRACTAL.COM
Fractal.com = FRACTAL.COM

Couldn’t wait to get this working, so my further effort lead to a successful joining of the domain, yet I observed a few errors for which I am pasting the error snippets below and attaching the complete log for the curious ones :slight_smile:

BTW, it turned out to be the case sensitivity for the domain name in the realm join command string - for user@domain.com instead it was supposedly expecting user@DOMAIN.COM.

However, we will be eager to get more feedback and fixes to the below-listed errors which still were reported by the realm join command despite the Successfully enrolled machine in realm.

 * Encryption type [16] not permitted.
 * Encryption type [3] not permitted.
 * Encryption type [1] not permitted.

–
! Failed to update Kerberos configuration, not fatal, please check manually: Setting attribute standard::type not supported

[error] [/etc/authselect/nsswitch.conf] has unexpected content!

and realm list giving:

FRACTAL.COM
 type: kerberos
 realm-name: FRACTAL.COM
 domain-name: fractal.com
 configured: kerberos-member
 server-software: active-directory
 client-software: sssd
 required-package: oddjob
 required-package: oddjob-mkhomedir
 required-package: sssd
 required-package: adcli
 required-package: samba-common-tools
 login-formats: %U@fractal.com
 login-policy: allow-realm-logins

realm expects a kerberos domain. That means the realm name is always in caps.

Ensure you have the following packages installed (most are installed as deps):

  • realmd
  • sssd
  • oddjob
  • oddjob-mkhomedir
  • adcli
  • samba-common-tools
  • krb5-workstation

Have you modified the system’s crypto policy? Are you running your system in FIPS mode? You may want to ensure your crypto policies are configured to work properly with your AD domain. If rc4 is still used in your AD environment (this is highly likely) you may need to adjust your crypto policy to support it, like update-crypto-policies --set DEFAULT:AD-SUPPORT for example.

Your machine is also out of date. Please update to 8.6.

noted! and lesson learned the hard way :slight_smile: thanks @nazunalika

Yes, we have the mentioned packages installed, i.e.,
rpm -qa | grep "realmd\|sssd\|oddjob\|oddjob-mkhomedir\|adcli\|samba-common-tools\|krb5-workstation" | sort

adcli-0.8.2-12.el8.x86_64
krb5-workstation-1.18.2-14.el8.x86_64
oddjob-0.34.7-1.el8.x86_64
oddjob-mkhomedir-0.34.7-1.el8.x86_64
python3-sssdconfig-2.6.2-4.el8_6.1.noarch
realmd-0.16.3-23.el8.x86_64
samba-common-tools-4.15.5-8.el8_6.x86_64
sssd-2.6.2-4.el8_6.1.x86_64
sssd-ad-2.6.2-4.el8_6.1.x86_64
sssd-client-2.6.2-4.el8_6.1.x86_64
sssd-common-2.6.2-4.el8_6.1.x86_64
sssd-common-pac-2.6.2-4.el8_6.1.x86_64
sssd-dbus-2.6.2-4.el8_6.1.x86_64
sssd-ipa-2.6.2-4.el8_6.1.x86_64
sssd-kcm-2.6.2-4.el8_6.1.x86_64
sssd-krb5-2.6.2-4.el8_6.1.x86_64
sssd-krb5-common-2.6.2-4.el8_6.1.x86_64
sssd-ldap-2.6.2-4.el8_6.1.x86_64
sssd-nfs-idmap-2.5.2-2.el8_5.4.x86_64
sssd-proxy-2.6.2-4.el8_6.1.x86_64
sssd-tools-2.6.2-4.el8_6.1.x86_64

No, it is seem to be already configured with AD Support.

cat /etc/crypto-policies/config 
DEFAULT:AD-SUPPORT

and

ls -lah /proc/sys/crypto/fips_enabled
-r--r--r-- 1 root root 0 Aug  9 00:34 /proc/sys/crypto/fips_enabled

not sure what this means but yeah if we should tune/tweak anything please suggest.

so currently we tried running

getent passwd username
for a few AD users and they all seem to be returning the info,

bsukhadia:*:1517601129:1517600514:Bhavik Sukhadia:/home/FRACTAL.COM/bsukhadia:/bin/bash

However, another strange problem we are observing is with the NFS v4 mounts with sec=krb5 - the mounts are visible in df -hT output but when switching the user to AD user account the df -hT command is not showing the mounted disk.

And when I traced the command execution further I learned that has something to do with,

stat("/run/user/0/gvfs", 0x7ffd161496b0) = -1 EACCES (Permission denied)
stat("/fs/shows", 0x7ffd16149e10) = -1 EACCES (Permission denied)

/fs/shows mounted with type nfs4 (rw,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=krb5,clientaddr=192.168.x.x,local_lock=none,addr=192.168.x.x)

ls -lah /run/user/969/

ls: cannot access '/run/user/969/gvfs': Permission denied
total 0
drwx------ 7 lightdm lightdm 180 Aug  9 01:05 .
drwxr-xr-x 3 root    root     60 Aug  9 01:05 ..
srw-rw-rw- 1 lightdm lightdm   0 Aug  9 01:05 bus
drwx------ 3 lightdm lightdm  60 Aug  9 01:05 dbus-1
drwx------ 2 lightdm lightdm  60 Aug  9 01:05 dconf
d????????? ? ?       ?         ?            ? gvfs
srw-rw-rw- 1 lightdm lightdm   0 Aug  9 01:05 pipewire-0
drwx------ 2 lightdm lightdm  80 Aug  9 01:05 pulse
drwxr-xr-x 2 lightdm lightdm  80 Aug  9 01:05 systems

And at the moment I am a bit clueless as to how I fix this if this is causing non-root users to not see the mounted disks when running df -hT - which is an immediate debugging step for us to see the mounts in AD users accounts.

Any thoughts will be very helpful.

Thanks,
Bhavik

Some more info in continuation of my previous post,

group owner for mount point /fs/shows is domain users and the mounted disk exists, that’s validated with mount command output:

fileserver:/ifs/shows on /fs/shows type nfs4 (rw,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=krb5,clientaddr=192.168.x.x,local_lock=none,addr=192.168.x.x)

yet, when doing df -hT with a domain user account the /fs/shows is not appearing in the list. And when attempting to access is manually, it is resulting in below behavior,

ls -lah /fs/shows
ls: cannot open directory '/fs/shows': Stale file handle

after a few re-repetitive manual attempts with the Stale file handle message, it is resulting into,

ls -lah /fs/shows
ls: cannot access '/fs/shows': Permission denied

despite the mount point and share has the group owner is domain users, permissions are 770 for /fs/shows.

so, not sure what’s exactly off here and how can we troubleshoot/debug this further?

Also, results of the attempt to mount the same share over cifs and sec=krb5,

mount -t cifs -o domain=fractal,username=bsukhadia,sec=krb5 //fileserver/shows /fs/shows

error messsages from dmesg

[ 4477.925369] CIFS: Attempting to mount \\fileserver\shows
[ 4539.270516] CIFS: Attempting to mount \\fileserver\shows
[ 4539.294621] CIFS: VFS: Verify user has a krb5 ticket and keyutils is installed
[ 4539.294623] CIFS: VFS: \\fileserver Send error in SessSetup = -126
[ 4539.294628] CIFS: VFS: cifs_mount failed w/return code = -126

However, the cifs mounts are working fine without sec=krb5.

How do I ask the oddjobd.service to copy the default skel contents too when creating a new user home directory?

While everything seems to work fine, for now, the default /etc/skel files are not getting copied over to the newly created user’s home directory.

Also tried this manual configuration,
file: /etc/authselect/system-auth

changed:

session optional pam_oddjob_mkhomedir.so

to,

session optional pam_oddjob_mkhomedir.so skel=/etc/skel umask=0022

but did not help change the behavior and the daemon still creates the new home folder but does not copy the skel files!

I would recommend using the authselect command to set up your pam files. See the authselect command, as well as the sub-commands select, list, list-features, enable-feature, disable-feature, create-profile, apply-changes.

Yes, using the same. Given below is the current config status,

authselect current 
Profile ID: sssd
Enabled features:
- with-mkhomedir

Also when tried declaring the skel_dir option into sssd.conf it resulted into:

[sssd] [sss_ini_call_validators] (0x0020): [rule/allowed_domain_options]: Attribute 'skel_dir' is not allowed in section 'domain/FRACTAL.COM'. Check for typos.

Setting skel_dir is unnecessary as the default is /etc/skel already. With that being said, you can only set it if you are using id_provider=local for a domain section. As you are using ad, you cannot set it.

I have had the greatest success when using the simplest possible krb5.conf, with only libdefaults (with default_realm set to the realm of course) and logging stanza, and the rest automatically discovered using dns_lookup_*.

Thank you for your suggestions @nazunalika and @blank. There has been a little bit of back and forth with the setup we have been trying to get working.

I am noticing a few random error messages (pasted below) and am somewhat unsure as to how we validate if our integration, in place, is a correct, stable, and error-free baseline or do we still need to tune and fix what parameters to ensure it is in a correct state? Because despite these errors the commands such as getent passwd aduser, sssctl user-checks aduser -a auth as well as the xfce4-lighdm logins and file-system access (NFS v4, sec=krb5) seem to be working fine.

Please find below the error messages in question and any suggestions on how these errors are affecting our SSSD integration and how can these be resolved will be greatly appreciated.

systemctl status sssd.service -l

â—Ź sssd.service - System Security Services Daemon
   Loaded: loaded (/usr/lib/systemd/system/sssd.service; enabled; vendor preset: enabled)
   Active: active (running) since Tue 2022-08-23 18:42:23 IST; 22h ago
 Main PID: 1144 (sssd)
    Tasks: 5 (limit: 410652)
   Memory: 88.5M
   CGroup: /system.slice/sssd.service
           ├─1144 /usr/sbin/sssd -i --logger=files
           ├─1259 /usr/libexec/sssd/sssd_be --domain implicit_files --uid 0 --gid 0 --logger=files
           ├─1260 /usr/libexec/sssd/sssd_be --domain FRACTALPICTURE.STUDIO --uid 0 --gid 0 --logger=files
           ├─1335 /usr/libexec/sssd/sssd_nss --uid 0 --gid 0 --logger=files
           └─1337 /usr/libexec/sssd/sssd_pam --uid 0 --gid 0 --logger=files

Aug 23 18:42:27 rockyel86 sssd[1947]: update failed: REFUSED
Aug 23 18:42:28 rockyel86 adcli[1905]: GSSAPI client step 1
Aug 23 18:42:28 rockyel86 adcli[1905]: GSSAPI client step 1
Aug 23 18:42:28 rockyel86 adcli[1905]: GSSAPI client step 1
Aug 24 06:42:27 rockyel86 sssd[45699]: ; TSIG error with server: tsig verify failure
Aug 24 06:42:27 rockyel86 sssd[45699]: update failed: REFUSED
Aug 24 06:42:27 rockyel86 sssd[45703]: ; TSIG error with server: tsig verify failure
Aug 24 06:42:27 rockyel86 sssd[45703]: update failed: REFUSED
Aug 24 06:42:27 rockyel86 sssd[45707]: ; TSIG error with server: tsig verify failure
Aug 24 06:42:27 rockyel86 sssd[45707]: update failed: REFUSED

(2022-08-23 18:42:27): [be[FRACTAL.COM]] [sbus_issue_request_done] (0x0040): sssd.dataprovider.getAccountDomain: Error [1432158212]: SSSD is offline

(2022-08-23 18:42:23): [be[FRACTAL.COM]] [sdap_id_op_connect_done] (0x0040): [RID#2] Failed to connect, going offline (5 [Input/output error])

* (2022-08-23 18:42:23): [be[FRACTAL.COM]] [be_resolve_server_done] (0x1000): Server [NULL] resolution failed: [5]: Input/output error

* (2022-08-23 18:42:23): [be[FRACTAL.COM]] [be_resolve_server_process] (0x0080): Couldn't resolve server (ADC.FRACTAL.COM), resolver returned [5]: Input/output error

(2022-08-23 18:42:23): [be[FRACTAL.COM]] [resolv_gethostbyname_done] (0x0040): querying hosts database failed [5]: Input/output error

* (2022-08-20 4:19:06): [be[FRACTAL.COM]] [dp_req_reply_std] (0x1000): [RID#11] DP Request [AccountDomain #11]: Returning [Internal Error]: 3,1432158300,GetAccountDomain() not supported

Additionally, rpcclient tests also seem successful, so this is more so confusing,

  1. What are those error messages in my previous post all about?
  2. How OR What functions of SSSD-AD (direct) integration will it affect/impact?
  3. And what needs to be done to get it fixed?
[bhavik@rockyel86 ~]$ rpcclient rdc.fractal.com --use-kerberos
Password for [bhavik@FRACTAL.COM]:
rpcclient $> srvinfo
        RDC.FRACWk Sv PDC Tim NT     
        platform_id     :       500
        os version      :       10.0
        server type     :       0x80102b
rpcclient $> getusername 
Account Name: bhavik, Authority Name: FRACTAL
rpcclient $>

TSIG error with server: tsig verify failure

Those are for DNS updates. Your client can’t do DNS updates for its own records, thus, update refused. Set dyndns_update = false in your sssd.conf and the messages will go away.

Without seeing the rest of the logs I can only guess that the resolve issues could be part of being unable to do failover/find SRV records for the domain to failover to the next domain controller.

1 Like

Right so disabling dyndns_update would be probably one way to fix it, but in our environment, we are using Active Directory DNS service for Linux clients which would be using AD-DHCP as well as static IP configurations in some cases, and for that, we believe we will need the dyndns_update to be enabled and working so fixing this error would be necessary with dyndns_update = true, isn’t it?

Also, please find below our sssd.conf for your perusal,

[sssd]
domains = FRACTAL.COM
config_file_version = 2
services = nss, pam

[domain/FRACTAL.COM]
#debug_level = 9
ad_domain = FRACTAL.COM
ad_server = RDC.FRACTAL.COM
ad_backup_server = RDC.FRACTAL.COM, ADC.FRACTAL.COM
krb5_realm = FRACTAL.COM
realmd_tags = manages-system joined-with-adcli 
cache_credentials = True
id_provider = ad
krb5_store_password_if_offline = True
default_shell = /bin/bash
ldap_id_mapping = True
fallback_homedir = /fs/althome/uat/%u
access_provider = ad

ad_hostname = rockyel86.fractal.com
use_fully_qualified_names = False
override_homedir = /fs/althome/uat/%u
auth_provider = ad
chpass_provider = ad
ldap_schema = ad
enumerate = False
ad_gpo_map_network = +nx
#
# https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/windows_integration_guide/sssd-dyndns
dyndns_update = true
dyndns_refresh_interval = 43200
dyndns_update_ptr = true
dyndns_ttl = 3600

Also, below snippet from the sssd logs sssd_FRACTAL.COM.log for some more insights and context,

   *  (2022-08-24 19:25:58): [be[FRACTAL.COM]] [be_nsupdate_create_fwd_msg] (0x0400): [RID#6]  -- Begin nsupdate message --

update delete rockyel86.fractal.com. in A
update add rockyel86.fractal.com. 3600 in A 192.168.0.214
send
update delete rockyel86.fractal.com. in AAAA
send
 -- End nsupdate message --
   *  (2022-08-24 19:25:58): [be[FRACTAL.COM]] [child_handler_setup] (0x2000): [RID#6] Setting up signal handler up for pid [1927]
   *  (2022-08-24 19:25:58): [be[FRACTAL.COM]] [child_handler_setup] (0x2000): [RID#6] Signal handler set up for pid [1927]
   *  (2022-08-24 19:25:58): [be[FRACTAL.COM]] [write_pipe_handler] (0x0400): [RID#6] All data has been sent!
   *  (2022-08-24 19:25:58): [be[FRACTAL.COM]] [nsupdate_child_stdin_done] (0x1000): [RID#6] Sending nsupdate data complete
   *  (2022-08-24 19:25:58): [be[FRACTAL.COM]] [ad_online_cb] (0x0400): [RID#6] The AD provider is online
   *  (2022-08-24 19:25:58): [be[FRACTAL.COM]] [child_sig_handler] (0x1000): [RID#6] Waiting for child [1927].
   *  (2022-08-24 19:25:58): [be[FRACTAL.COM]] [child_sig_handler] (0x0020): [RID#6] child [1927] failed with status [2].
********************** BACKTRACE DUMP ENDS HERE *********************************

Any thoughts on how can this be debugged further to narrow down to the root cause and get it fixed and working?

Thanks,

Also, tried doing the manual nsupdate from the shell, and that’s also resulted in the status: REFUSED,

nsupdate -D

setup_system()
reset_system()
user_interaction()
> update delete rockyel86.fractal.com. in AAAA
do_next_command()
evaluate_update()
update_addordelete()
> update add rockyel86.fractal.com. 3600 in A 192.168.0.214
do_next_command()
evaluate_update()
update_addordelete()
> show
do_next_command()
show_message()
Outgoing update query:
;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id:      0
;; flags:; ZONE: 0, PREREQ: 0, UPDATE: 0, ADDITIONAL: 0
;; UPDATE SECTION:
rockyel86.fractal.com. 0 ANY	AAAA	
rockyel86.fractal.com. 3600 IN A	192.168.0.214

> send
do_next_command()
start_update()
recvsoa()
About to create rcvmsg
show_message()
Reply from SOA query:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id:   4045
;; flags: qr aa rd ra; QUESTION: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; QUESTION SECTION:
;rockyel86.fractal.com. IN	SOA

;; AUTHORITY SECTION:
fractal.com.	3600	IN	SOA	rdc.fractal.com. hostmaster.fractal.com. 14656 900 600 86400 3600

;; ADDITIONAL SECTION:
rdc.fractal.com. 3600 IN A	192.168.0.4

Found zone name: fractal.com
The master is: rdc.fractal.com
send_update()
Sending update to 192.168.0.4#53
show_message()
Outgoing update query:
;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id:  65300
;; flags:; ZONE: 1, PREREQ: 0, UPDATE: 2, ADDITIONAL: 0
;; UPDATE SECTION:
rockyel86.fractal.com. 0 ANY	AAAA	
rockyel86.fractal.com. 3600 IN A	192.168.0.214

Out of recvsoa
update_completed()
show_message()

Reply from update query:
;; ->>HEADER<<- opcode: UPDATE, status: REFUSED, id:  65300
;; flags: qr; ZONE: 1, PREREQ: 0, UPDATE: 2, ADDITIONAL: 0
;; ZONE SECTION:
;fractal.com.		IN	SOA

;; UPDATE SECTION:
rockyel86.fractal.com. 0 ANY	AAAA	
rockyel86.fractal.com. 3600 IN A	192.168.0.214

done_update()
reset_system()
user_interaction()
>

You will need to ensure that computer accounts are allowed to change their own DNS entries. These permissions will need to be verified on the AD side. This is what the TSIG was referring to; that is the mechanism that assists in authenticating and making changes to DNS. Manual updates failing is expected as you are not providing authentication to make the changes.

As I can only perform guess work with the data you’re providing, you will need to turn on debug level 9 and provide the logs after you have performed your testing. This would be the starting point. Without deeper logs (and thus more information), we can only take guesses to the cause of your issues. Also please review this page on troubleshooting sssd.

You will need to ensure that computer accounts are allowed to change their own DNS entries. These permissions will need to be verified on the AD side. This is what the TSIG was referring to; that is the mechanism that assists in authenticating and making changes to DNS.

Sure, we will check this from the AD end as to what permissions are required to be granted to the computer accounts by comparing the same with Windows computer account permissions.

If we want the manual nsupdate to be successful, what/how can we supply the client-side authentication credentials to test/validate this?

Also, this is the sssd_FRACTAL.COM.log for more details.

Just to keep this thread updated, for now we are opting for disabling the dynamic DNS updates from the SSSD due to the GSS-TSIG error due to which we are unable to send the dynamic and secured DNS updates to our AD-DNS server.

sssd.conf

[domain/FRACTAL.COM]
dyndns_update = False

side note: supposedly we would need to do ktpass for AD-DNS and take the output keytab file and merge it on the Linux (running sssd) client with other existing keytab files and test the sssd-dyndns_updates.

and so far everything looks good, in terms of the login to Linux machine with AD user accounts, access to the file server with NFS4, sec=krb5, running software applications, etc.

However, there’s one strange problem we are observing is, when using NOMACHINE NX with a domain user account and mostly after a system reboot, that respective user is unable to do interactive /GUI login due to the access to (nfs4 sec=krb5) home directory permission denied error.

Strangely enough, the NX and SSH access still works with the AD user and password. Initially we thought that’s to do with the permission on the file server but that’s not the case, because, when we login with the same user account from a different (Linux) machine the same mounted home folder is not giving any permissions issues.

Pasted below is the debug details from rpcdebug -vv -m nfs with all the flags vfs dircache lookupcache pagecache proc xdr file root callback client mount fscache pnfs pnfs_ld state

----snip----
Aug 30 23:21:24 fprdsk022 kernel: decode_getfattr_attrs: xdr returned 0
Aug 30 23:21:24 fprdsk022 kernel: decode_getfattr_generic: xdr returned 0
Aug 30 23:21:24 fprdsk022 kernel: nfs4_free_slot: slotid 0 highest_used_slotid 4294967295
Aug 30 23:21:24 fprdsk022 kernel: NFS: nfs_update_inode(0:51/4492239111 fh_crc=0x8100096d ct=2 info=0x427e7f)
Aug 30 23:21:24 fprdsk022 kernel: NFS: (0:51/4492239111) revalidation complete
Aug 30 23:21:24 fprdsk022 kernel: NFS: permission(0:51/4492239111), mask=0x1, res=-13
----snip----

BTW, We have looked through almost all the recommended Kerberos configurations for NX and seems the NX itself is working fine without any issues even when the GUI login is login user out due to home directory access issues!

Any thoughts on what might be going off here and preventing the access to NFS4 (sec=krb5) home directories? Only for a select user from the select machine.

1 Like