7:21 a.m.
On 2/21/2019 11:34 AM, Tom wrote:
Sent from my iPhone
> On Feb 21, 2019, at 8:43 AM, Daniel Gryniewicz <dang(a)redhat.com> wrote:
>
>> On 2/21/19 8:07 AM, TomK wrote:
>> Hey All,
>> Wondering if there would be a cross domain issue if KRB5 is enabled on NFS
Ganesha and thereby causing an issue if the NFS Ganesha servers are on say, domain
aaa.123.xyz while the clients are on domain bbb.123.xyz?
>> Users get a permission denied on clients when accessing the remote mount and
while checking I see it's owned by nobody / nobody rather then their user and group.
>> The client is on a different DNS domain and ownership comes through with
nobody/nobody. Hence clients get a permission denied accessing the folder I'm
thinking. However the ONLY thing different that stands out ATM is the domains being
different.
>> Wondering if anyone ran into a similar experience and could share their solution?
Do I need to add the realm to the /etc/krb5.conf config on the NFS Ganesha servers
perhaps?
>
> So, I believe that the clients and servers need to be in the same KRB5 domain. This
would likely be 123.xyz in your case, rather than using the sub-domains.
K.
Will have to add the realm section etc then. Need the one nfs server shared between two
kdc ‘s . I have a separate kdc per subdomain. ABC.xyz is the ad dc in this case.
Apologies, I misread I think. Thinking you mean there's only one domain
configuration option in the NFS Ganesha config hence why NFS Ganesha
only supports a single domain?
/etc/ganesha/ganesha.conf
NFSv4 {
Lease_Lifetime = 20 ;
IdmapConf = "/etc/idmapd.conf" ;
DomainName = "b.abc.123" ;
}
NFS_KRB5 {
PrincipalName = "nfs/nfs01.b.abc.123(a)B.ABC.123" ;
KeytabPath = /etc/krb5.keytab ;
Active_krb5 = YES ;
}
# cat /etc/idmapd.conf
[General]
Domain = b.abc.123
[Mapping]
[Translation]
[Static]
[UMICH_SCHEMA]
LDAP_server = ldap-server.local.domain.edu
LDAP_base = dc=local,dc=domain,dc=edu
You have new mail in /var/spool/mail/root
The user is the same account on the second subdomain but the trust with
the AD DC through which it's served is formed with a separate Linux KDC
on that domain.
Perhaps this diagram will come through correctly
sam(a)abc.123 <-- IPA KDC 1 (a.abc.123) -> AD DC (abc.123)
sam(a)abc.123 <-- IPA KDC 2 (b.abc.123) -----^
The NFS cluster is shared between IPA KDC 1 and 2 .
So in this case, if I wanted this scenario to work, guessing I may have
to create a separate NFS cluster and extend the Gluster FS over 3 new
additional nodes on domain a.abc.123 to ensure the same user's files and
storage is always in sync across domain / kerberos realm.
Reason for all this is that we're testing options for isolating certain
software / projects from other domains (keeping them contained within a
specific realm). The software can modify the KDC extensively and hence
why we prefer it has it's own KDC.
--
Cheers,
Tom K.
-------------------------------------------------------------------------------------
Living on earth is expensive, but it includes a free trip around the sun.
>
> Daniel
> _______________________________________________
> Support mailing list -- support(a)lists.nfs-ganesha.org
> To unsubscribe send an email to support-leave(a)lists.nfs-ganesha.org
_______________________________________________
Support mailing list -- support(a)lists.nfs-ganesha.org
To unsubscribe send an email to support-leave(a)lists.nfs-ganesha.org