samba - Apr 2015 - Samba as AD member can not validate domain user

Hi!

Wheh domain user tries to access file server (samba4, member of AD domain)
server logs such error:

2015/04/05 21:13:01.095178,  1]  
../source3/auth/user_krb5.c:164(get_user_from_kerberos_info)
Username DOMAINwusername is invalid on this system

[2015/04/05 21:13:01.095200,  1]  
../source3/auth/auth_generic.c:99(auth3_generate_session_info_pac)
Failed to map kerberos principal to system user (NT_STATUS_LOGON_FAILURE)

which, on one hand, is right - such UNIX user does not exist on the  
file server. If I try to access file server as user registered both in  
AD domain and file server's local passwd/shadow, I succed.

Does it mean that I have to have all intended users to be registered  
as local UNIX users on file server, and, if I plan to manage share  
permissions using domain groups, I have to make "mirror" groups  
locally as well?

Janis

Hi!
> When domain user tries to access file server (samba4, member of AD domain)
> server logs such error:
>
> 2015/04/05 21:13:01.095178,  1]  
> ../source3/auth/user_krb5.c:164(get_user_from_kerberos_info)
> Username DOMAINwusername is invalid on this system
>
> [2015/04/05 21:13:01.095200,  1]  
> ../source3/auth/auth_generic.c:99(auth3_generate_session_info_pac)
> Failed to map kerberos principal to system user (NT_STATUS_LOGON_FAILURE)
>
> which, on one hand, is right - such UNIX user does not exist on the  
> file server. If I try to access file server as user registered both  
> in AD domain and file server's local passwd/shadow, I succed.
>
> Does it mean that I have to have all intended users to be registered  
> as local UNIX users on file server, and, if I plan to manage share  
> permissions using domain groups, I have to make "mirror" groups  
> locally as well?
quotation form another Rowland's e-mail:
Are your users & groups uidNumber & gidNumber attributes inside the  
'10000=99999' range ?

Does this question relates to the UIDs/GIDs on Samba AD DC (for domain  
users/groups) or local UNIX accounts (on file server, for example)?


Janis

I am sorry for many P.S.
>> When domain user tries to access file server (samba4, member of AD
domain)
>> server logs such error:
>>
>> 2015/04/05 21:13:01.095178,  1]  
>> ../source3/auth/user_krb5.c:164(get_user_from_kerberos_info)
>> Username DOMAINwusername is invalid on this system
>>
>> [2015/04/05 21:13:01.095200,  1]  
>> ../source3/auth/auth_generic.c:99(auth3_generate_session_info_pac)
>> Failed to map kerberos principal to system user
(NT_STATUS_LOGON_FAILURE)
>>
>> which, on one hand, is right - such UNIX user does not exist on the  
>> file server. If I try to access file server as user registered both  
>> in AD domain and file server's local passwd/shadow, I succed.
>>
>> Does it mean that I have to have all intended users to be  
>> registered as local UNIX users on file server, and, if I plan to  
>> manage share permissions using domain groups, I have to make  
>> "mirror" groups locally as well?
>
> quotation from another Rowland's e-mail:
> Are your users & groups uidNumber & gidNumber attributes inside the
> '10000=99999' range ?
>
> Does this question relates to the UIDs/GIDs on Samba AD DC (for  
> domain users/groups) or local UNIX accounts (on file server, for  
> example)?
getent group lists only local groups;
getent passwd shows list of local users, freezes for a while and exits;
id user shows user info if it exists locally.

Janis

On 05/04/15 19:26, jd at ionica.lv wrote:
> Hi!
>
> Wheh domain user tries to access file server (samba4, member of AD 
> domain)
> server logs such error:
>
> 2015/04/05 21:13:01.095178,  1] 
> ../source3/auth/user_krb5.c:164(get_user_from_kerberos_info)
> Username DOMAINwusername is invalid on this system
>
> [2015/04/05 21:13:01.095200,  1] 
> ../source3/auth/auth_generic.c:99(auth3_generate_session_info_pac)
> Failed to map kerberos principal to system user (NT_STATUS_LOGON_FAILURE)
>
> which, on one hand, is right - such UNIX user does not exist on the 
> file server. If I try to access file server as user registered both in 
> AD domain and file server's local passwd/shadow, I succed.
>
> Does it mean that I have to have all intended users to be registered 
> as local UNIX users on file server, and, if I plan to manage share 
> permissions using domain groups, I have to make "mirror" groups 
> locally as well?
>
> Janis
>
No, you can have local Unix users & groups and AD domain users & groups,
but the two cannot mix i.e. if user 'joe' is in /etc/passwd, you cannot 
have a user 'joe' in AD. This applies when you correctly set up smb.conf
on the file server and join it to the domain.

What you have to do to get AD users known to Unix, is:

Correctly set up smb.conf
Join the machine to the domain
Ensure that the users & groups have the required uidNumbers & gidNumber
Ensure that kerberos, resolv.conf and nsswitch.conf are correctly set up.

Or to put it another way, you do not add Unix users to AD, you extend AD 
users to become Unix users.

If unsure what to do, see the samba wiki member server page:

https://wiki.samba.org/index.php/Setup_a_Samba_AD_Member_Server

Rowland

On 05/04/15 19:37, jd at ionica.lv wrote:
> Hi!
>
>> When domain user tries to access file server (samba4, member of AD 
>> domain)
>> server logs such error:
>>
>> 2015/04/05 21:13:01.095178,  1] 
>> ../source3/auth/user_krb5.c:164(get_user_from_kerberos_info)
>> Username DOMAINwusername is invalid on this system
>>
>> [2015/04/05 21:13:01.095200,  1] 
>> ../source3/auth/auth_generic.c:99(auth3_generate_session_info_pac)
>> Failed to map kerberos principal to system user 
>> (NT_STATUS_LOGON_FAILURE)
>>
>> which, on one hand, is right - such UNIX user does not exist on the 
>> file server. If I try to access file server as user registered both 
>> in AD domain and file server's local passwd/shadow, I succed.
>>
>> Does it mean that I have to have all intended users to be registered 
>> as local UNIX users on file server, and, if I plan to manage share 
>> permissions using domain groups, I have to make "mirror"
groups
>> locally as well?
>
> quotation form another Rowland's e-mail:
> Are your users & groups uidNumber & gidNumber attributes inside the
> '10000=99999' range ?
>
> Does this question relates to the UIDs/GIDs on Samba AD DC (for domain 
> users/groups) or local UNIX accounts (on file server, for example)?
>
>
> Janis
>
If you are using AD for authentication, you can ignore local Unix 
accounts, all your users should be in AD apart from at least one local 
AD user (which can't be in AD) just in case something catastrophic happens.

Just use AD users and extend them to be Unix users and set up Linux to 
use them.

Rowland

Greetings, jd at ionica.lv!
>> When domain user tries to access file server (samba4, member of AD
domain)
>> server logs such error:
>>
>> 2015/04/05 21:13:01.095178,  1]  
>> ../source3/auth/user_krb5.c:164(get_user_from_kerberos_info)
>> Username DOMAINwusername is invalid on this system
>>
>> [2015/04/05 21:13:01.095200,  1]  
>> ../source3/auth/auth_generic.c:99(auth3_generate_session_info_pac)
>> Failed to map kerberos principal to system user
(NT_STATUS_LOGON_FAILURE)
>>
>> which, on one hand, is right - such UNIX user does not exist on the  
>> file server. If I try to access file server as user registered both  
>> in AD domain and file server's local passwd/shadow, I succed.
>>
>> Does it mean that I have to have all intended users to be registered  
>> as local UNIX users on file server, and, if I plan to manage share  
>> permissions using domain groups, I have to make "mirror"
groups
>> locally as well?
> quotation form another Rowland's e-mail:
> Are your users & groups uidNumber & gidNumber attributes inside the
> '10000=99999' range ?
> Does this question relates to the UIDs/GIDs on Samba AD DC (for domain  
> users/groups) or local UNIX accounts (on file server, for example)?
It is related to both, assuming you are using idmap backend ad or similar.
Please refer to previous thread on the same subject (and my very recent email
explaining the judgmental diagnostic).


-- 
With best regards,
Andrey Repin
Sunday, April 5, 2015 22:22:18

Sorry for my terrible english...