CentOS - Jun 2018 - Specifying different options for different " smb" type gvfs mount

On 06/21/2018 05:09 AM, John Hodrien wrote:
> On Thu, 21 Jun 2018, Toralf Lund wrote:
>
>> I known that I might use mount.cifs and related "fstab"
entries as an
>> alternative, but its password handling seems a lot less convenient.
>
> If you're in an AD environment, you can probably do nicely with 
> mount.cifs:
> sec=krb5,multiuser
> That way you don't have to deal with usernames/passwords at all. 
Interesting.? Seems like a lot of setup, but it's interesting.? I didn't
know SMB supported this:

https://access.redhat.com/solutions/279183

On Thu, 21 Jun 2018, Gordon Messmer wrote:
> On 06/21/2018 05:09 AM, John Hodrien wrote:
>>  On Thu, 21 Jun 2018, Toralf Lund wrote:
>>
>>>  I known that I might use mount.cifs and related "fstab"
entries as an
>>>  alternative, but its password handling seems a lot less
convenient.
>>
>>  If you're in an AD environment, you can probably do nicely with
>>  mount.cifs:
>>  sec=krb5,multiuser
>>  That way you don't have to deal with usernames/passwords at all. 
>
> Interesting.? Seems like a lot of setup, but it's interesting.? I
didn't know
> SMB supported this:
>
> https://access.redhat.com/solutions/279183
That article makes it sound a whole lot harder than it is, as almost all of
that is pre done in later versions of CentOS.

You don't have to configure the upcall stuff as it's already done, you
don't
need to generate a credential cache for root as it can just use the keytab,
and if you've already setup a machine to talk to AD with SSSD you've
probably
done everything else.

Paired with wildcard automount entries, and you end up in a very usable setup
with minimal config.

jh

On 06/22/2018 01:24 AM, John Hodrien wrote:
>
> Paired with wildcard automount entries, and you end up in a very 
> usable setup
> with minimal config. 

Cool.? Thanks for clarifying!