wbinfo -i output domain realm vs. ntdomain before login

[Heiner Lesaar]

Adding to my message from yesterday. The output from "wbinfo --group-info"
is also broken but unfortunately doesn´t even get corrected after the first
login of the user.

Please see below for explanation. All this on sernet-samba 4.7.4 (but also
same behaviour if tested on samba.org source-build)

## New created user that never logged in to Samba:
## (see how it returns "full domain" in result, which is "wrong" - expected
is NTDOMAIN name)

 root ~    $ wbinfo -i newuser11 at domain.intern

DOMAIN.INTERN+newuser11:*:43555590:43554944::/home/DOMAIN.INTERN/newuser11:/bin/false

## Same is true for result in group info, user is listed with wrong domain
info:

 root ~    $ wbinfo --group-info DOMAIN+newgroup

NTDOMAIN+newgroup:x:43555589:DOMAIN.INTERN+newuser11

## Logging in user once seems to fix this, at least for user info:

 root ~    $ smbclient \\\\127.0.0.1\\snfs1 -U newuser11 at domain.intern

WARNING: The "auth methods" option is deprecated
Enter newuser11 at domain.intern's password:
tree connect failed: NT_STATUS_BAD_NETWORK_NAME


## See how now NTDOMAIN is shown as result, problem is that results are
"inconsistent" before and after first login.

root ~    $ wbinfo -i newuser11 at domain.intern

NTDOMAIN+newuser11:*:43555590:43554944::/home/NTDOMAIN/newuser11:/bin/false


 ## Even more problematic is that --group-info still has the wrong syntax
in its listing:

 root ~  exitcode 1   $ wbinfo --group-info NTDOMAIN+newgroup

NTDOMAIN+newgroup:x:43555589:DOMAIN.INTERN+newuser11






2018-04-18 18:31 GMT+02:00 Heiner Lesaar <heiner.lesaar at googlemail.com>:

> Dear all,
>
> I have posted on samba at lists before and got a hint towards a change of
> winbind behaviour since samba 4.7 from a kind subscriber, but unfortunately
> the hint towards a change in group membership calculation does not really
> (seem to) relate to my question.
>
> I would like to be able to get a consistent result when running wbinfo -i
> so that it does not differ between user creation and after first login.
>
> For reference, please see my original request below and thanks a lot for
> your help and suggestions!
>
> Heiner
>
>
> On CentOs7 based linux w. different versions of Samba (4.6.x from CentOS
> repos, but also Sernet-Samba-4.7.4 and also compiled from source), "wbinfo
> -i user at domain.tld" returns different results before the first successful
> authentication of the user.
>
> Server joined as member to Active Directory, idmapping via tdb2 and rid or
> ad - does not seem to make a difference.
>
> On first attempt, the result returns "DOMAIN-REALM+Username", but after 1st
> login it switches to "NTDOMAIN+Username" (which is also the correct
> output).
> The tdb files also show the "wrong" info until the login is done (according
> to tdbdump comparison). It does not matter if the login happens on a client
> or like in my example "locally" via smbclient.
>
>
> See command output examples:
>
> #########
> 1st execution after user creation in AD:
>
> # $ wbinfo -i newuser at test.intern
>
> # TEST.INTERN+newuser:*:16777239:16777216::/home/TEST.
> INTERN/newuser:/bin/false
>
> Authentication (e.g. here via smbclient):
>
> # $ smbclient \\\\127.0.0.1\\sharename -U newuser at test.intern
>
> Execution after 1st login:
>
> # $ wbinfo -i newuser at test.intern
>
> # TEST+newuser:*:16777239:16777216::/home/TEST/newuser:/bin/false
>
> #########
>
> We use the command output to create database entries in a in-house
> developed database / application to centrally manage client logins from
> various operating systems.
>
> My questions are:
>
> 1) Is this expected behaviour or is it influenced by some smb.conf or
> krb5.conf option that we are not aware of?
>
> 2) Is there a way to query the domain "prefix" of a user which will not
> change depending on the fact if the user has ever tried to login to the
> server or not?
> Does it maybe depend on some command line option?
>
> FYI: getent passwd shows the same behaviour.
>
>
>
> Thank you very much for your help and assistance!
>