samba - Jun 2019 - Fwd: Re: Fwd: Re: Kerberos and NTLMv2 authentication

On 18/06/2019 17:24, Edouard Guign? via samba wrote:
> "winbind refresh tickets = yes" did not help for my case.
>
It always has for myself, I have never had to refresh any kerberos 
machine tickets manually

Rowland

Hello,

I mean that i added "winbind refresh tickets = yes" in smb.cnf, but
does
not seem to be link with my problem (Kerberos and NTLMv2 authentication).

After several test, without changing content of smb.conf (except for 
winbind refresh tickets = yes) :

0. nsswitch.conf
passwd:???? files sss
shadow:???? files sss
group:????? files sss

That's working (share is accessible from windows 7, permissions and acls 
working)
But in in log, I see only NTLMv2 Auth

1. nsswitch.conf
passwd:???? files winbind
shadow:???? files
group:????? files winbind

That's not working (share is not accessible from windows 7, access denied)

2. nsswitch.conf
passwd:???? files sss winbind
shadow:???? files sss
group:????? files sss winbind

not working (share is accessible but it take time to see permissions 
acls from security tab on windows 7)


Le 18/06/2019 ? 13:59, Rowland penny via samba a ?crit?:
> On 18/06/2019 17:24, Edouard Guign? via samba wrote:
>> "winbind refresh tickets = yes" did not help for my case.
>>
> It always has for myself, I have never had to refresh any kerberos 
> machine tickets manually
>
> Rowland
>
>
>

On 18/06/2019 19:02, Edouard Guign? via samba wrote:
> Hello,
>
> I mean that i added "winbind refresh tickets = yes" in smb.cnf,
but
> does not seem to be link with my problem (Kerberos and NTLMv2 
> authentication).
>
> After several test, without changing content of smb.conf (except for 
> winbind refresh tickets = yes) :
>
> 0. nsswitch.conf
> passwd:???? files sss
> shadow:???? files sss
> group:????? files sss
>
> That's working (share is accessible from windows 7, permissions and 
> acls working)
> But in in log, I see only NTLMv2 Auth
>
> 1. nsswitch.conf
> passwd:???? files winbind
> shadow:???? files
> group:????? files winbind
>
> That's not working (share is not accessible from windows 7, access 
> denied)
>
> 2. nsswitch.conf
> passwd:???? files sss winbind
> shadow:???? files sss
> group:????? files sss winbind
>
> not working (share is accessible but it take time to see permissions 
> acls from security tab on windows 7)
>
You are using the winbind 'ad' backend according to the smb.conf you 
posted earlier, have you given your AD users a uidNumber attribute 
containing a unique number inside the ' 10000-14999' range ? and have 
you also given 'Domain Users' a gidNumber attribute containing a number 
inside the same range ?

Do you really want to use a different primary group for your Unix users 
over Samba (when they connect to a Samba share) ?

If not, remove 'idmap config MYDOMAIN : unix_primary_group = yes'

If all the above is correct, it should work.

Rowland

On 6/18/19 11:59 AM, Rowland penny via samba wrote:
> On 18/06/2019 17:24, Edouard Guign? via samba wrote:
>> "winbind refresh tickets = yes" did not help for my case.
>>
> It always has for myself, I have never had to refresh any kerberos 
> machine tickets manually
> 
Are you only ever authenticating against a Samba AD domain controller, 
though?  Windows AD in the wild can be a pain in the ass.  For example, 
I stop reading whenever I see RF2307 or adding POSIX attributes to 
Windows AD -- our AD domain admins can't (or possibly won't) accommodate
this.


> Rowland
> 
> 
>

Hello,

Yes in my case, this is a Windows AD with RF2307 POSIX attributes.
Do you mean this is suitable to use winbindd only against a Samba AD
domain controller ?

I will make test tomorrow because Rowland found some errors in my domain
range gid.
This can explain why I cannot access to the share with winbindd.
(with sssd, it is possible... sssd doesn't seem to take care of domain
range ; but I get always NTLMv2 instead of Kerberos with sssd).
>
>
> On 6/18/19 11:59 AM, Rowland penny via samba wrote:
>> On 18/06/2019 17:24, Edouard Guign? via samba wrote:
>>> "winbind refresh tickets = yes" did not help for my case.
>>>
>> It always has for myself, I have never had to refresh any kerberos
>> machine tickets manually
>>
>
> Are you only ever authenticating against a Samba AD domain controller,
> though?  Windows AD in the wild can be a pain in the ass.  For example,
> I stop reading whenever I see RF2307 or adding POSIX attributes to
> Windows AD -- our AD domain admins can't (or possibly won't)
accommodate
> this.
>
>
>
>> Rowland
>>
>>
>>
>
> --
> To unsubscribe from this list go to the following URL and read the
> instructions:  https://lists.samba.org/mailman/options/samba
>
>

On 18/06/2019 22:45, Goetz, Patrick G via samba wrote:
> Are you only ever authenticating against a Samba AD domain controller,
> though?  Windows AD in the wild can be a pain in the ass.  For example,
> I stop reading whenever I see RF2307 or adding POSIX attributes to
> Windows AD -- our AD domain admins can't (or possibly won't)
accommodate
> this.
If that is the case, use the winbind 'rid' or 'autorid' backend,
these
do not require adding anything to AD.

Rowland

Hai, 

Im attempting not to be rude.. But.. 
> -----Oorspronkelijk bericht-----
> 
> Are you only ever authenticating against a Samba AD domain controller, 
> though?  Windows AD in the wild can be a pain in the ass.  For example, 
> I stop reading whenever I see RF2307 or adding POSIX attributes to 
> Windows AD -- our AD domain admins can't (or possibly won't)
accommodate this.
So your admins dont know how to use RSAT, it that what your saying? 
Or are they just lazy.. 

https://www.server-world.info/en/note?os=Windows_Server_2019&p=active_directory&f=12
Its just a pain to register the used UID/GID numbers. 

Just saying, 

(sorry) 

Greetz, 

Louis

On 6/19/19 2:16 AM, L.P.H. van Belle via samba wrote:
> 
> So your admins dont know how to use RSAT, it that what your saying?
> Or are they just lazy..
> 
>
https://www.server-world.info/en/note?os=Windows_Server_2019&p=active_directory&f=12
> Its just a pain to register the used UID/GID numbers.
> 
It's a bit more complicated than that.  There are about 50,000 students 
at any time at the university, with ~25% changing every year.  So in 
this case there are hundreds of thousands of user accounts that have to 
be managed indefinitely (because you can't just delete the account after 
students leave).  To manage this, the university has a central identity 
authority, and this is the source of the problem, in this case:  the 
users in the AD domain are episodically (daily) sourced from the 
identity authority, and the way they do this is to just flush the 
records and repopulate.  Even if we did add the POSIX stuff to the AD 
DB, it would get flushed on next reload.

But yeah, there's probably a way to work around this.  Wouldn't call it 
the greatest IT department, and getting steadily worse as they continue 
to low ball salaries and attempt to outsource everything to the cloud. 
In any case, it's not something I control or can do anything about.