Andrew Martin
2017-Oct-10 16:28 UTC
[Samba] Opensolaris-ish joins but does not seem to be valid
----- 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
Rowland Penny
2017-Oct-10 17:02 UTC
[Samba] Opensolaris-ish joins but does not seem to be valid
On Tue, 10 Oct 2017 11:28:09 -0500 (CDT) Andrew Martin <amartin at xes-inc.com> wrote:> > > > 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.Then you have a problem, your users and groups seem to be unknown to the underlying OS.> 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 >If you provisioned the Samba AD DC with --use-rfc2307, then I think you should have gone with the IDMU mapping, what we call around here 'RFC2307'. By using this, you will doing something very similar to using the winbind 'ad' backend and will be able to use RSAT on a WIN 7 or 8.1 to admin it.> > 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.htmlIf Opensolaris is like Linux, you will not need local users, as your windows users can be made to be Unix users as well.> > > 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?There have been a lot of changes between 4.0.6 and 4.7.0, to many to mention, have a look here: https://wiki.samba.org/index.php/Samba_Features_added/changed_%28by_release%29 If this was Samba running on Opensolaris, I could talk you through setting up very easily, but I don't have an Opensolaris machine and have never used it, so I can only advise you on what I would try. Rowland
Andrew Martin
2017-Oct-10 20:19 UTC
[Samba] Opensolaris-ish joins but does not seem to be valid
----- Original Message -----> From: "samba" <samba at lists.samba.org> > To: "samba" <samba at lists.samba.org> > Sent: Tuesday, October 10, 2017 12:02:11 PM > Subject: Re: [Samba] Opensolaris-ish joins but does not seem to be valid> On Tue, 10 Oct 2017 11:28:09 -0500 (CDT) > Andrew Martin <amartin at xes-inc.com> wrote: > > >> > >> > 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. > > Then you have a problem, your users and groups seem to be unknown to > the underlying OS. > >> 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 >> > > If you provisioned the Samba AD DC with --use-rfc2307, then I think you > should have gone with the IDMU mapping, what we call around here > 'RFC2307'. By using this, you will doing something very similar to > using the winbind 'ad' backend and will be able to use RSAT on a WIN 7 > or 8.1 to admin it. >It has been awhile, but the last time I looked into IDMU mode I thought Samba didn't support it. I thought Windows AD required a separate installer to be run to add IDMU mode and then some extra fields in AD needed to be created and proactively synced on a regular basis (e.g. syncing from the normal userPassword field to unixUserPassword). Are there any guides or information on how to setup IDMU mode on a Samba DC? At least on Solaris, it sounds like IDMU is not 100% identical to RFC2307: http://docs.oracle.com/cd/E22471_01/html/820-4167/configuration__services__identity_mapping.html> IDMU adds a "UNIX Attributes" panel to the Active Directory Users and > Computers user interface that lets the administrator specify a number > of UNIX-related parameters: UID, GID, login shell, home directory, and > similar for groups. These parameters are made available through AD > through a schema similar to (but not the same as) RFC2307, and through > the NIS service.Thanks, Andrew
Mike Ray
2017-Oct-11 22:56 UTC
[Samba] Opensolaris-ish joins but does not seem to be valid
----- On Oct 10, 2017, at 12:02 PM, samba samba at lists.samba.org wrote:> On Tue, 10 Oct 2017 11:28:09 -0500 (CDT) > Andrew Martin <amartin at xes-inc.com> wrote: > >Rowland- I've been poking at this more and think the root of the problem is a Kerberos problem. After joining this machine to the domain, it goes through a process that it calls "AD/Kerberos Setup". Comparing to the working counterpart on the old domain, this process appears to set the domain name, a DN search base (sets to Schema) and then lists the GC servers. What follows is a tcpdump of port 88 during that "AD/Kerberos Setup": No. Time Source Destination Protocol Length Info 1 0.000000 192.168.0.115 192.168.6.6 KRB5 241 AS-REQ Frame 1: 241 bytes on wire (1928 bits), 241 bytes captured (1928 bits) User Datagram Protocol, Src Port: 55231 (55231), Dst Port: kerberos (88) Kerberos AS-REQ Pvno: 5 MSG Type: AS-REQ (10) KDC_REQ_BODY Padding: 0 KDCOptions: 00000010 (Renewable OK) Client Name (Service and Host): root/host.example.com Name-type: Service and Host (3) Name: root Name: host.example.com Realm: EXAMPLE.COM Server Name (Principal): krbtgt/EXAMPLE.COM Name-type: Principal (1) Name: krbtgt Name: EXAMPLE.COM from: 2017-10-11 22:30:52 (UTC) till: 2017-10-12 08:30:52 (UTC) Nonce: 1507761052 Encryption Types: aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 des3-cbc-sha1 rc4-hmac rc4-hmac-exp des-cbc-md5 des-cbc-crc HostAddresses: 192.168.0.115 No. Time Source Destination Protocol Length Info 2 0.002177 192.168.6.6 192.168.0.115 KRB5 303 KRB Error: KRB5KDC_ERR_PREAUTH_REQUIRED Frame 2: 303 bytes on wire (2424 bits), 303 bytes captured (2424 bits) User Datagram Protocol, Src Port: kerberos (88), Dst Port: 55231 (55231) Kerberos KRB-ERROR Pvno: 5 MSG Type: KRB-ERROR (30) stime: 2017-10-11 22:30:57 (UTC) susec: 26559 error_code: KRB5KDC_ERR_PREAUTH_REQUIRED (25) Client Realm: EXAMPLE.COM Client Name (Service and Host): root/host.example.com Name-type: Service and Host (3) Name: root Name: host.example.com Realm: EXAMPLE.COM Server Name (Principal): krbtgt/EXAMPLE.COM Name-type: Principal (1) Name: krbtgt Name: EXAMPLE.COM e-text: Need to use PA-ENC-TIMESTAMP/PA-PK-AS-REQ e-data padata: PA-ENC-TIMESTAMP PA-DASS PA-PK-AS-REP PA-ENCTYPE-INFO PA-ENCTYPE-INFO2 Type: PA-ENC-TIMESTAMP (2) Value: <MISSING> Type: PA-DASS (16) Value: <MISSING> Type: PA-PK-AS-REP (15) Value: <MISSING> Type: PA-ENCTYPE-INFO (11) Value: 30073005a003020117 rc4-hmac Encryption type: rc4-hmac (23) Type: PA-ENCTYPE-INFO2 (19) Value: 30073005a003020117 rc4-hmac Encryption type: rc4-hmac (23) No. Time Source Destination Protocol Length Info 3 0.003199 192.168.0.115 192.168.6.6 KRB5 321 AS-REQ Frame 3: 321 bytes on wire (2568 bits), 321 bytes captured (2568 bits) User Datagram Protocol, Src Port: 60405 (60405), Dst Port: kerberos (88) Kerberos AS-REQ Pvno: 5 MSG Type: AS-REQ (10) padata: PA-ENC-TIMESTAMP Type: PA-ENC-TIMESTAMP (2) Value: 303da003020117a23604341f02bfb4cefe9338f229dd3b57... rc4-hmac Encryption type: rc4-hmac (23) enc PA_ENC_TIMESTAMP: 1f02bfb4cefe9338f229dd3b578ab9b6e6b65709a5c50761... KDC_REQ_BODY Padding: 0 KDCOptions: 00000010 (Renewable OK) Client Name (Service and Host): root/host.example.com Name-type: Service and Host (3) Name: root Name: host.example.com Realm: EXAMPLE.COM Server Name (Principal): krbtgt/EXAMPLE.COM Name-type: Principal (1) Name: krbtgt Name: EXAMPLE.COM from: 2017-10-11 22:30:52 (UTC) till: 2017-10-12 08:30:52 (UTC) Nonce: 1507761052 Encryption Types: aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 des3-cbc-sha1 rc4-hmac rc4-hmac-exp des-cbc-md5 des-cbc-crc HostAddresses: 192.168.0.115 No. Time Source Destination Protocol Length Info 4 0.014971 192.168.6.6 192.168.0.115 KRB5 1381 AS-REP Frame 4: 1381 bytes on wire (11048 bits), 1381 bytes captured (11048 bits) User Datagram Protocol, Src Port: kerberos (88), Dst Port: 60405 (60405) Kerberos AS-REP Pvno: 5 MSG Type: AS-REP (11) Client Realm: EXAMPLE.COM Client Name (Service and Host): root/host.example.com Name-type: Service and Host (3) Name: root Name: host.example.com Ticket Tkt-vno: 5 Realm: EXAMPLE.COM Server Name (Principal): krbtgt/EXAMPLE.COM Name-type: Principal (1) Name: krbtgt Name: EXAMPLE.COM enc-part rc4-hmac enc-part rc4-hmac No. Time Source Destination Protocol Length Info 5 0.015978 192.168.0.115 192.168.6.6 KRB5 1438 TGS-REQ Frame 5: 1438 bytes on wire (11504 bits), 1438 bytes captured (11504 bits) User Datagram Protocol, Src Port: 64049 (64049), Dst Port: kerberos (88) Kerberos TGS-REQ Pvno: 5 MSG Type: TGS-REQ (12) padata: PA-TGS-REQ Type: PA-TGS-REQ (1) Value: 6e8204c4308204c0a003020105a10302010ea20703050000... AP-REQ Pvno: 5 MSG Type: AP-REQ (14) Padding: 0 APOptions: 00000000 Ticket Tkt-vno: 5 Realm: EXAMPLE.COM Server Name (Principal): krbtgt/EXAMPLE.COM Name-type: Principal (1) Name: krbtgt Name: EXAMPLE.COM enc-part rc4-hmac Authenticator rc4-hmac KDC_REQ_BODY Padding: 0 KDCOptions: 00010000 (Canonicalize) Realm: EXAMPLE.COM Server Name (Service and Host): ldap/dc9.example.com Name-type: Service and Host (3) Name: ldap Name: dc9.example.com till: 2017-10-12 08:30:52 (UTC) Nonce: 1507761057 Encryption Types: aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 des3-cbc-sha1 rc4-hmac rc4-hmac-exp des-cbc-md5 des-cbc-crc HostAddresses: 192.168.0.115 No. Time Source Destination Protocol Length Info 6 0.018414 192.168.6.6 192.168.0.115 KRB5 148 KRB Error: KRB5KDC_ERR_C_PRINCIPAL_UNKNOWN Frame 6: 148 bytes on wire (1184 bits), 148 bytes captured (1184 bits) User Datagram Protocol, Src Port: kerberos (88), Dst Port: 64049 (64049) Kerberos KRB-ERROR Pvno: 5 MSG Type: KRB-ERROR (30) ctime: 2017-10-11 22:30:57 (UTC) cusec: 234 stime: 2017-10-11 22:30:57 (UTC) susec: 42801 error_code: KRB5KDC_ERR_C_PRINCIPAL_UNKNOWN (6) Realm: <unspecified realm> Server Name (Unknown): Name-type: Unknown (0) As you can see, the machine makes an AS-REQ to the DC, which returns an AS-REP indicating everything is OK. Then to get the ticket-granting ticket (TGT), the machine makes a TGS-REQ to the same DC. However, instead of receiving the TGS-REP, the machine receives an error from the DC stating that the principal could not be found. How is that happening? Isn't the principal just "root/host.example.com"? I can verify that the "servicePrincipalName" attribute for that computer object has "root/host.example.com" listed. Isn't the TGS-REQ authenticated by the ticket response (AS-REP)? What could make the ticket included in the AS-REP instantly invalid? Any insights would be appreciated. Thanks,