[Samba] Opensolaris-ish joins but does not seem to be valid

Tue Oct 10 16:28:09 UTC 2017

----- Original Message -----
> From: "samba" <samba at lists.samba.org>
> To: "samba" <samba at lists.samba.org>
> Sent: Tuesday, October 10, 2017 10:19:29 AM
> Subject: Re: [Samba] Opensolaris-ish joins but does not seem to be valid

> On Tue, 10 Oct 2017 09:39:43 -0500 (CDT)
> Andrew Martin <amartin at xes-inc.com> wrote:
> 
>> ----- Original Message -----
>> > From: "samba" <samba at lists.samba.org>
>> > To: "samba" <samba at lists.samba.org>
>> > Sent: Tuesday, October 10, 2017 2:23:02 AM
>> > Subject: Re: [Samba] Opensolaris-ish joins but does not seem to be
>> > valid
>> 
>> > On Mon, 9 Oct 2017 18:04:45 -0500 (CDT)
>> > Mike Ray via samba <samba at lists.samba.org> wrote:
>> > 
>> >> We have a product that is similar to Opensolaris. It joins to the
>> >> domain (Samba version 4.7.0) without error and I can verify that a
>> >> computer object is created in the domain for it.
>> >> 
>> >> However, the command "getent passwd" which I would expect to
>> >> return a list of all domain users, only returns a list of local
>> >> users.
>> >> 
>> >> I am confident I do not have a misconfigured file because if I get
>> >> a kerberos ticket as the Administrator (i.e. kinit
>> >> -UAdministrator) and then issue "getent passwd", the list returns
>> >> as I would expect.
>> >> 
>> >> The host is populated with a keytab after joining to the domain and
>> >> it appears to have good entries:
>> >> "host/hostname.example.com at EXAMPLE.COM", etc. And when I do a
>> >> "klist" with no prior kinit, it says it says the default principal
>> >> is "host/hostname at EXAMPLE.COM" which is listed in the keytab.
>> >> 
>> >> Since I am on 4.7.0, I've also turned on the authentication
>> >> auditing and I can see the authentication attempt when I issue
>> >> "getent passwd". But instead of being host specific, it registers
>> >> the user as [NT AUTHORITY]\[ANONYMOUS LOGON].
>> >> 
>> >> There is an additional setup we have to run for this host, setting
>> >> up directory based mappings for idmap to resolve UIDs
>> >> (http://web.archive.org/web/20090416045554/http://docs.sun.com:80/app/docs/doc/820-2429/createidmappingstrategy?a=view).
>> >> That command registers as the host authority in the DC logs, i.e.
>> >> "[EXAMPLE]\[HOSTNAME$][SID]"; however, on the client side, the
>> >> process returns as "sasl/GSSAPI bind" error. As above, if I do a
>> >> kinit as Administrator beforehand, the command succeeds
>> >> successfully.
>> >> 
>> >> It seems like something is wrong with the computer account, but
>> >> it's not like I can set the computer accounts password and
>> >> manually trying kiniting as it. Any suggestions about what might
>> >> be wrong or how to further troubleshoot?
>> >> 
>> >> Mike Ray
>> >> 
>> > 
>> > Can you post your smb.conf
>> > 
>> > Rowland
>> > 
>> 
>> Rowland,
>> 
>> Here's the smb.conf for one of the DCs (I'm working with Mike on
>> this): [global]
>>         netbios name = DC3
>>         realm = EXAMPLE.COM
>>         workgroup = EXAMPLE
>>         server role = active directory domain controller
>>         allow dns updates = nonsecure
>>         dns forwarder = 192.168.0.2
>>         idmap_ldb:use rfc2307 = Yes
>>         printcap name = /dev/null
>>         load printers = no
>>         printing = bsd
>>         ntp signd socket directory = /var/run/samba/ntp_signd
>>         #acl:search = no
>>         ldap server require strong auth = no
>>         winbind sealed pipes = false
>>         client signing = off
>>         require strong key = false
>>         client ldap sasl wrapping = plain
>>         log level = 1 auth_audit:10
>> 
>> [netlogon]
>>         path = /var/lib/samba/sysvol/example.com/scripts
>>         read only = No
>> 
>> [sysvol]
>>         path = /var/lib/samba/sysvol
>>         read only = No
>> 
>> Thanks,
>> 
>> Andrew
> 
> Is this from the Opensolaris-ish machine ?
> 
> I expected to see a smb.conf file from a Unix domain member.
> 
> If it is from the machine where you are getting '[NT
> AUTHORITY]\[ANONYMOUS LOGON]', then can you try 'getent passwd
> username'. By default winbind doesn't enumerate users and groups.

Running "getent passwd username" does not return anything on the
client machine.

The smb.conf I sent is from the DC; the OpenSolaris-based machine 
is not using Samba but is using the Solaris CIFS Service instead:
http://docs.oracle.com/cd/E19120-01/open.solaris/820-2429/configuredomainmodetask/index.html

The Solaris CIFS service, aka smb/server, is joined to the domain
with "smbadm join -u Administrator example.com" and once joined you
can query AD users using "idmap show -cV user at example.com". By
default, idmapd uses "Ephemeral mapping", so AD users are represented
locally by a randomly-chosen, high-numbered uid rather than their
actual uid as stored in uidNumber or elsewhere in AD. This is
undesirable, so we have reconfigured idmap to use
"directory-based mapping" instead:
http://docs.oracle.com/cd/E22471_01/html/820-4167/configuration__services__identity_mapping.html
https://docs.oracle.com/cd/E19120-01/open.solaris/820-2429/configuredirbasedmapping/index.html

This allows us to set some properties in idmap to tell it which AD
attribute (CN) to query to find out how to map AD users to local users:
svccfg -s svc:/system/idmap setprop config/ad_unixgroup_attr=astring: cn
svccfg -s svc:/system/idmap setprop config/ad_unixuser_attr=astring: cn
svccfg -s svc:/system/idmap setprop config/directory_based_mapping=astring: name
svcadm refresh idmap

At this point smb/server and idmap should be able to look up AD users and
map them to a local user whose username is the same as the user's CN field
in AD. We then populate all of the AD users in the local nsswitch database
by running "ldapclient" and telling it which AD attributes to map to each
property in the nsswitch database:
https://docs.oracle.com/cd/E23824_01/html/821-1455/clientsetup-49.html

We have two problems, both of which I think may be related to the same
underlying issue of not being able to communicate with the Samba DC:
* idmap cannot query user's CN values for "directory-based mapping"
* ldapclient cannot query users to populate the nsswitch database

I think both of these are related to the "sasl/GSSAPI bind" error that
Mike mentioned; previously on Samba 4.0.6, this client was able to
make these queries successfully, but now on Samba 4.7.0 these queries
require that we manually kinit on the client before the GSSAPI 
authentication is allowed. Has something changed with how GSSAPI
authentication or host Kerberos tickets are issued? Can we still allow
the old behavior with a smb.conf config option?

Thanks,

Andrew