[Beowulf] Cluster Authentication (LDAP,NIS,AD)

[Robert Taylor]

Hi cluster gurus. I want to pick the your collective brains.
Right now, where I work, we have and isilon, and netapp, which we use for
our small 250core compute cluster.

We have NIS for authentication and automount maps on the cluster side, and
AD for authentication on the windows side, and LDAP for yet for other
things to authenticate against.
The storage is connected to both nis and AD, and does it's best to match
the two sides up.
We have had some odd issues with authentication as of late with sources
getting out of sync, which has brought up the discussion for consolidating
down to a single source of truth, which would be AD. RFC2307 talks about
stuffing NIS data into LDAP/AD, and there are commercial products such as
centrify that can do it.

Does anyone run an entirely AD authentication environment with their
compute cluster
authenticating against it and using it for automount maps and such?
Can you tell me what were your reasons for going that way, and any snags
that you hit on the way?

We've just started looking at it, so I'm on the beginning of this road.

Any responses is appreciated.

Thanks.

rgt

[Lachlan Musicman]

Post by Robert Taylor
Hi cluster gurus. I want to pick the your collective brains.
Right now, where I work, we have and isilon, and netapp, which we use for
our small 250core compute cluster.
We have NIS for authentication and automount maps on the cluster side, and
AD for authentication on the windows side, and LDAP for yet for other
things to authenticate against.
The storage is connected to both nis and AD, and does it's best to match
the two sides up.
We have had some odd issues with authentication as of late with sources
getting out of sync, which has brought up the discussion for consolidating
down to a single source of truth, which would be AD. RFC2307 talks about
stuffing NIS data into LDAP/AD, and there are commercial products such as
centrify that can do it.
Does anyone run an entirely AD authentication environment with their
compute cluster
authenticating against it and using it for automount maps and such?
Can you tell me what were your reasons for going that way, and any snags
that you hit on the way?

Robert,

We were asked/tasked with this a couple of years ago.

It took almost two years of shaking out the issues, but FreeIPA/SSSD in a
one-way trust with AD has worked excellently for 18 months. Our SLURM
cluster is on CentOS 7.4, and we needed to use the COPR version of SSSD
(1.16.x) rather than the version in the repos (1.15.x) but otherwise is
fine. Would absolutely recommend.

Note that a lot of the issues we saw were directly related to our AD,
rather than any problems with FreeIPA and SSSD. For example for a long time
our AD login names had spaces in them (! would not recommend), and the age
and size of the AD instance also lead to a few issues. Nothing that
couldn't be worked around. The devs and community are excellent at
responding to requests for help. It's a RedHat product. so if you have a
subscription it would be even easier.


Cheers
L.

------
"The antidote to apocalypticism is *apocalyptic civics*. Apocalyptic civics
is the insistence that we cannot ignore the truth, nor should we panic
about it. It is a shared consciousness that our institutions have failed
and our ecosystem is collapsing, yet we are still here — and we are
creative agents who can shape our destinies. Apocalyptic civics is the
conviction that the only way out is through, and the only way through is
together. "

*Greg Bloom* @greggish
https://twitter.com/greggish/status/873177525903609857

[Nick Evans]

Hi Robert,

We are currently running our HPC, servers and desktops with storage needs
serviced by an Isilon. We have CIFS and NFS capabilities both of which use
the AD for authentication.

Currently our cluster is Centos 6.8 NFS and SSH authenticating off of the
AD using SSSD. We also have a number of Centos 7.4 machines that are
mapping NFS with AD auth from SSSD.

The only thing to watch is the Isilon has the Lookup UID setting by default
set to off so you can quite quickly run into the NFS 16 group limit but
other than that ours has be rock solid.

Nick

Post by Lachlan Musicman

Post by Robert Taylor
Hi cluster gurus. I want to pick the your collective brains.
Right now, where I work, we have and isilon, and netapp, which we use for
our small 250core compute cluster.
We have NIS for authentication and automount maps on the cluster side,
and AD for authentication on the windows side, and LDAP for yet for other
things to authenticate against.
The storage is connected to both nis and AD, and does it's best to match
the two sides up.
We have had some odd issues with authentication as of late with sources
getting out of sync, which has brought up the discussion for consolidating
down to a single source of truth, which would be AD. RFC2307 talks about
stuffing NIS data into LDAP/AD, and there are commercial products such as
centrify that can do it.
Does anyone run an entirely AD authentication environment with their
compute cluster
authenticating against it and using it for automount maps and such?
Can you tell me what were your reasons for going that way, and any snags
that you hit on the way?

Robert,
We were asked/tasked with this a couple of years ago.
It took almost two years of shaking out the issues, but FreeIPA/SSSD in a
one-way trust with AD has worked excellently for 18 months. Our SLURM
cluster is on CentOS 7.4, and we needed to use the COPR version of SSSD
(1.16.x) rather than the version in the repos (1.15.x) but otherwise is
fine. Would absolutely recommend.
Note that a lot of the issues we saw were directly related to our AD,
rather than any problems with FreeIPA and SSSD. For example for a long time
our AD login names had spaces in them (! would not recommend), and the age
and size of the AD instance also lead to a few issues. Nothing that
couldn't be worked around. The devs and community are excellent at
responding to requests for help. It's a RedHat product. so if you have a
subscription it would be even easier.
Cheers
L.
------
"The antidote to apocalypticism is *apocalyptic civics*. Apocalyptic
civics is the insistence that we cannot ignore the truth, nor should we
panic about it. It is a shared consciousness that our institutions have
failed and our ecosystem is collapsing, yet we are still here — and we are
creative agents who can shape our destinies. Apocalyptic civics is the
conviction that the only way out is through, and the only way through is
together. "
status/873177525903609857
_______________________________________________
To change your subscription (digest mode or unsubscribe) visit
http://www.beowulf.org/mailman/listinfo/beowulf

[John Hearns via Beowulf]

Robert,
I will back up what Lachlan said.
I set up a new HPC facility for the University of Greenwich in the UK,
which uses sssd to authenticate against a campus AD.
One thing to remember - campus wide you have everyone in the AD. SO do the
following:

a) create a new group called 'HPC-users'and restrict the logins to
HPC-users only (and maybe HPC-admins also!)

b) you can automate the creation of home directories using a PAM plugin on
Redhat
See https://access.redhat.com/discussions/903523
I recommend against the oddjob version of pam_mkhomedir - ti did nto behave
too well, and the 'normal' version worked just fine.

Also you might want an /etc/profile.d script which wil create areas on your
scratch/parallel storage for users when they first log in

Where I work as the moment we use nslcd rather than sssd. I Was told there
was an issue with sssd, but I forget what it was exactly.

One tip with sssd, I found that when initially working with it I had to do
a wipe of the cache and a forced reload.
The documentation is there on how to do that. Do not be afraid to do this -
the procedure sounds scary but works perfectly well.
sssd caches things quite aggressively so you might have to restart it to
get the 'ground truth' sometimes.

sssd also has a very odd behaviour when you have a very large number of
groups (probably as MIT has)
It creates a huge sparse file for groups (or something similar). The file
looks scarily big - but being sparse of course it is not really.
Just a quirk of how it works I gather, sont let my comment put you off.

Post by Nick Evans
Hi Robert,
We are currently running our HPC, servers and desktops with storage needs
serviced by an Isilon. We have CIFS and NFS capabilities both of which use
the AD for authentication.
Currently our cluster is Centos 6.8 NFS and SSH authenticating off of the
AD using SSSD. We also have a number of Centos 7.4 machines that are
mapping NFS with AD auth from SSSD.
The only thing to watch is the Isilon has the Lookup UID setting by
default set to off so you can quite quickly run into the NFS 16 group limit
but other than that ours has be rock solid.
Nick

Post by Lachlan Musicman

Post by Robert Taylor
Hi cluster gurus. I want to pick the your collective brains.
Right now, where I work, we have and isilon, and netapp, which we use
for our small 250core compute cluster.
We have NIS for authentication and automount maps on the cluster side,
and AD for authentication on the windows side, and LDAP for yet for other
things to authenticate against.
The storage is connected to both nis and AD, and does it's best to match
the two sides up.
We have had some odd issues with authentication as of late with sources
getting out of sync, which has brought up the discussion for consolidating
down to a single source of truth, which would be AD. RFC2307 talks about
stuffing NIS data into LDAP/AD, and there are commercial products such as
centrify that can do it.
Does anyone run an entirely AD authentication environment with their
compute cluster
authenticating against it and using it for automount maps and such?
Can you tell me what were your reasons for going that way, and any snags
that you hit on the way?

Robert,
We were asked/tasked with this a couple of years ago.
It took almost two years of shaking out the issues, but FreeIPA/SSSD in a
one-way trust with AD has worked excellently for 18 months. Our SLURM
cluster is on CentOS 7.4, and we needed to use the COPR version of SSSD
(1.16.x) rather than the version in the repos (1.15.x) but otherwise is
fine. Would absolutely recommend.
Note that a lot of the issues we saw were directly related to our AD,
rather than any problems with FreeIPA and SSSD. For example for a long time
our AD login names had spaces in them (! would not recommend), and the age
and size of the AD instance also lead to a few issues. Nothing that
couldn't be worked around. The devs and community are excellent at
responding to requests for help. It's a RedHat product. so if you have a
subscription it would be even easier.
Cheers
L.
------
"The antidote to apocalypticism is *apocalyptic civics*. Apocalyptic
civics is the insistence that we cannot ignore the truth, nor should we
panic about it. It is a shared consciousness that our institutions have
failed and our ecosystem is collapsing, yet we are still here — and we are
creative agents who can shape our destinies. Apocalyptic civics is the
conviction that the only way out is through, and the only way through is
together. "
tatus/873177525903609857
_______________________________________________
To change your subscription (digest mode or unsubscribe) visit
http://www.beowulf.org/mailman/listinfo/beowulf

_______________________________________________
To change your subscription (digest mode or unsubscribe) visit
http://www.beowulf.org/mailman/listinfo/beowulf

[Skylar Thompson]

We are an AD shop, with users, groups, and automounter maps (for a short
while longer at least[1]) in the directory. I think once you get to
around schema level 2003R2 you'll be using RFC2307bis (biggest
difference from RFC2307 is that it supports nested groups) which is
basically what modern Linux distributions will be expecting. I can't
think of any serious problems we've had it with it, though I work on the
UNIX side so for me it really does just look like a LDAP/Krb5 server.

I'm not a fan of Microsoft in general, but AD is one of the few products
that they've actually gotten right. In particular, the replication just
works --- in the 11 years we've been running AD, I can't think of a
single time our domain servers got out of sync.

[1] For automounter maps, we're in the process of moving from LDAP to
program maps. Due to some internal complexities, we need to support
multiple definitions for a single mount point, which is easiest to
accomplish with a client-side program map.

Skylar

Post by Robert Taylor
Hi cluster gurus. I want to pick the your collective brains.
Right now, where I work, we have and isilon, and netapp, which we use
for our small 250core compute cluster.
We have NIS for authentication and automount maps on the cluster side,
and AD for authentication on the windows side, and LDAP for yet for
other things to authenticate against.  
The storage is connected to both nis and AD, and does it's best to match
the two sides up. 
We have had some odd issues with authentication as of late with sources
getting out of sync, which has brought up the discussion for
consolidating down to a single source of truth, which would be AD.
RFC2307 talks about stuffing NIS data into LDAP/AD, and there are
commercial products such as centrify that can do it. 
Does anyone run an entirely AD authentication environment with their
compute cluster
authenticating against it and using it for automount maps and such?
Can you tell me what were your reasons for going that way, and any snags
that you hit on the way?
We've just started looking at it, so I'm on the beginning of this road. 
Any responses is appreciated. 
Thanks.
rgt
_______________________________________________
To change your subscription (digest mode or unsubscribe) visit http://www.beowulf.org/mailman/listinfo/beowulf

_______________________________________________
Beowulf mailing list, ***@beowulf.org sponsored by Penguin Computing
To change your subscription (digest mode or unsubscribe) visit ht

[John Hearns via Beowulf]

Skylar, I admit my ignorance. What is a program map?
Where I work now extensively uses automounter maps for bind mounts.
I may well learn something useful here.

Post by Skylar Thompson
We are an AD shop, with users, groups, and automounter maps (for a short
while longer at least[1]) in the directory. I think once you get to
around schema level 2003R2 you'll be using RFC2307bis (biggest
difference from RFC2307 is that it supports nested groups) which is
basically what modern Linux distributions will be expecting. I can't
think of any serious problems we've had it with it, though I work on the
UNIX side so for me it really does just look like a LDAP/Krb5 server.
I'm not a fan of Microsoft in general, but AD is one of the few products
that they've actually gotten right. In particular, the replication just
works --- in the 11 years we've been running AD, I can't think of a
single time our domain servers got out of sync.
[1] For automounter maps, we're in the process of moving from LDAP to
program maps. Due to some internal complexities, we need to support
multiple definitions for a single mount point, which is easiest to
accomplish with a client-side program map.
Skylar

Post by Robert Taylor
Hi cluster gurus. I want to pick the your collective brains.
Right now, where I work, we have and isilon, and netapp, which we use
for our small 250core compute cluster.
We have NIS for authentication and automount maps on the cluster side,
and AD for authentication on the windows side, and LDAP for yet for
other things to authenticate against.
The storage is connected to both nis and AD, and does it's best to match
the two sides up.
We have had some odd issues with authentication as of late with sources
getting out of sync, which has brought up the discussion for
consolidating down to a single source of truth, which would be AD.
RFC2307 talks about stuffing NIS data into LDAP/AD, and there are
commercial products such as centrify that can do it.
Does anyone run an entirely AD authentication environment with their
compute cluster
authenticating against it and using it for automount maps and such?
Can you tell me what were your reasons for going that way, and any snags
that you hit on the way?
We've just started looking at it, so I'm on the beginning of this road.
Any responses is appreciated.
Thanks.
rgt
_______________________________________________
To change your subscription (digest mode or unsubscribe) visit

http://www.beowulf.org/mailman/listinfo/beowulf
_______________________________________________
To change your subscription (digest mode or unsubscribe) visit
http://www.beowulf.org/mailman/listinfo/beowulf

[Skylar Thompson]

It's a mechanism for having the automounter process run an executable as
part of the mount process. The executable takes in the map key as its
sole argument (i.e. /net/foo/bar would produce bar as an argument) and
then will print the mount parameters over STDOUT. We use a Python script
with a YAML configuration file (easy to edit and validate) but it can be
any executable type.

I don't know that this is available for amd, but it is for autofs.

Skylar

Post by John Hearns via Beowulf
Skylar, I admit my ignorance. What is a program map?
Where I work now extensively uses automounter maps for bind mounts.
I may well learn something useful here.
We are an AD shop, with users, groups, and automounter maps (for a short
while longer at least[1]) in the directory. I think once you get to
around schema level 2003R2 you'll be using RFC2307bis (biggest
difference from RFC2307 is that it supports nested groups) which is
basically what modern Linux distributions will be expecting. I can't
think of any serious problems we've had it with it, though I work on the
UNIX side so for me it really does just look like a LDAP/Krb5 server.
I'm not a fan of Microsoft in general, but AD is one of the few products
that they've actually gotten right. In particular, the replication just
works --- in the 11 years we've been running AD, I can't think of a
single time our domain servers got out of sync.
[1] For automounter maps, we're in the process of moving from LDAP to
program maps. Due to some internal complexities, we need to support
multiple definitions for a single mount point, which is easiest to
accomplish with a client-side program map.
Skylar

Post by Robert Taylor
Hi cluster gurus. I want to pick the your collective brains.
Right now, where I work, we have and isilon, and netapp, which we use
for our small 250core compute cluster.
We have NIS for authentication and automount maps on the cluster side,
and AD for authentication on the windows side, and LDAP for yet for
other things to authenticate against.  
The storage is connected to both nis and AD, and does it's best to

match

Post by Robert Taylor
the two sides up. 
We have had some odd issues with authentication as of late with

sources

Post by Robert Taylor
getting out of sync, which has brought up the discussion for
consolidating down to a single source of truth, which would be AD.
RFC2307 talks about stuffing NIS data into LDAP/AD, and there are
commercial products such as centrify that can do it. 
Does anyone run an entirely AD authentication environment with their
compute cluster
authenticating against it and using it for automount maps and such?
Can you tell me what were your reasons for going that way, and any

snags

Post by Robert Taylor
that you hit on the way?
We've just started looking at it, so I'm on the beginning of this

road. 

Post by Robert Taylor
Any responses is appreciated. 
Thanks.
rgt
_______________________________________________
To change your subscription (digest mode or unsubscribe) visit

http://www.beowulf.org/mailman/listinfo/beowulf
<http://www.beowulf.org/mailman/listinfo/beowulf>
_______________________________________________
To change your subscription (digest mode or unsubscribe) visit
http://www.beowulf.org/mailman/listinfo/beowulf
<http://www.beowulf.org/mailman/listinfo/beowulf>
_______________________________________________
To change your subscription (digest mode or unsubscribe) visit http://www.beowulf.org/mailman/listinfo/beowulf

_______________________________________________
Beowulf mailing list, ***@beowulf.org sponsored by Penguin Computing
To change your subscription (digest mode or unsubscrib