francis picabia
2016-Aug-08 14:48 UTC
[Samba] why does add_local_groups come up in only one system's logs?
On Mon, Aug 8, 2016 at 10:54 AM, Rowland Penny <rpenny at samba.org> wrote:> On Mon, 8 Aug 2016 10:24:03 -0300 > francis picabia <fpicabia at gmail.com> wrote: > > > I have a couple of Debian 8.5 systems set up in similar manner. > > Samba is version 4.2.10-Debian > > > > Here is the essential config... > > > > # testparm /etc/samba/smb.conf > > Load smb config files from /etc/samba/smb.conf > > Processing section "[homes]" > > Loaded services file OK. > > Server role: ROLE_DOMAIN_MEMBER > > > > Press enter to see a dump of your service definitions > > > > # Global parameters > > [global] > > workgroup = MYDOM > > realm = AD.MYDOM.CA > > server string = debian2 Server > > security = ADS > > log file = /var/log/samba/%m.log > > max log size = 50 > > unix extensions = No > > load printers = No > > printcap name = /dev/null > > disable spoolss = Yes > > dns proxy = No > > winbind enum users = Yes > > winbind enum groups = Yes > > winbind use default domain = Yes > > idmap config * : range = 1000-1999999 > > idmap config * : backend = tdb > > nt acl support = No > > printing = bsd > > > > > > [homes] > > comment = Home Directories > > path = %H > > valid users = %U at mydom > > read only = No > > create mask = 0700 > > directory mask = 0700 > > browseable = No > > wide links = Yes > > > > /etc/pam.d/samba, /etc/nsswitch.conf and /etc/krb5.conf are the same > > configuration on both systems. The first one allows a connection > > to the homes. Here is a tail on the log file: > > > > [2016/08/08 09:42:49.956619, 3] > > ../source3/auth/auth.c:178(auth_check_ntlm_password) > > check_ntlm_password: Checking password for unmapped user > > [MYDOM]\[username]@[DEBIAN1] with the new password interface > > [2016/08/08 09:42:49.956656, 3] > > ../source3/auth/auth.c:181(auth_check_ntlm_password) > > check_ntlm_password: mapped user is: [MYDOM]\[username]@[DEBIAN1] > > [2016/08/08 09:42:49.961548, 3] > > ../source3/auth/auth.c:249(auth_check_ntlm_password) > > check_ntlm_password: winbind authentication for user [username] > > succeeded [2016/08/08 09:42:49.961610, 2] > > ../source3/auth/auth.c:305(auth_check_ntlm_password) > > check_ntlm_password: authentication for user [username] -> > > [username] -> [username] succeeded > > [2016/08/08 09:42:49.961671, 3] > > ../auth/ntlmssp/ntlmssp_sign.c:509(ntlmssp_sign_reset) > > NTLMSSP Sign/Seal - Initialising with flags: > > [2016/08/08 09:42:49.961699, 3] > > ../auth/ntlmssp/ntlmssp_util.c:69(debug_ntlmssp_flags) > > Got NTLMSSP neg_flags=0x62088215 > > [2016/08/08 09:42:49.961748, 3] > > ../auth/ntlmssp/ntlmssp_sign.c:509(ntlmssp_sign_reset) > > NTLMSSP Sign/Seal - Initialising with flags: > > [2016/08/08 09:42:49.961772, 3] > > ../auth/ntlmssp/ntlmssp_util.c:69(debug_ntlmssp_flags) > > Got NTLMSSP neg_flags=0x62088215 > > [2016/08/08 09:42:50.271337, 3] > > ../source3/param/loadparm.c:1427(lp_add_home) > > adding home's share [username] for user 'username' at '%H' > > > > The second server fails with the add_local_groups and getpwuid: > > > > [2016/08/08 09:53:55.146840, 3] > > ../source3/auth/auth.c:178(auth_check_ntlm_password) > > check_ntlm_password: Checking password for unmapped user > > [MYDOM]\[username]@[DEBIAN2] with the new password interface > > [2016/08/08 09:53:55.146867, 3] > > ../source3/auth/auth.c:181(auth_check_ntlm_password) > > check_ntlm_password: mapped user is: [MYDOM]\[username]@[DEBIAN2] > > [2016/08/08 09:53:55.150852, 3] > > ../source3/auth/auth.c:249(auth_check_ntlm_password) > > check_ntlm_password: winbind authentication for user [username] > > succeeded [2016/08/08 09:53:55.150902, 2] > > ../source3/auth/auth.c:305(auth_check_ntlm_password) > > check_ntlm_password: authentication for user [username] -> > > [username] -> [username] succeeded > > [2016/08/08 09:53:55.150960, 3] > > ../auth/ntlmssp/ntlmssp_sign.c:509(ntlmssp_sign_reset) > > NTLMSSP Sign/Seal - Initialising with flags: > > [2016/08/08 09:53:55.150978, 3] > > ../auth/ntlmssp/ntlmssp_util.c:69(debug_ntlmssp_flags) > > Got NTLMSSP neg_flags=0x62088215 > > [2016/08/08 09:53:55.151024, 3] > > ../auth/ntlmssp/ntlmssp_sign.c:509(ntlmssp_sign_reset) > > NTLMSSP Sign/Seal - Initialising with flags: > > [2016/08/08 09:53:55.151036, 3] > > ../auth/ntlmssp/ntlmssp_util.c:69(debug_ntlmssp_flags) > > Got NTLMSSP neg_flags=0x62088215 > > [2016/08/08 09:53:55.151321, 1] > > ../source3/auth/token_util.c:430(add_local_groups) > > SID S-1-5-21-82194667-1315141139-1877560073-12331 -> > > getpwuid(16777216) failed > > [2016/08/08 09:53:55.151348, 3] > > ../source3/auth/token_util.c:316(create_local_nt_token_from_info3) > > Failed to finalize nt token > > > > > > I am so far unable to find why the getpwuid for add_local_groups > > matters, or why only one system even mentions it in the logfile > > trace. The default group ID is listed in /etc/group for the user and > > the home directory with ls -ld looks fine with 700 chmod > > for the home directory in both servers. > > Are you using sssd ? > If not, where are you storing the users & groups ? > >I've never used sssd anywhere before nor here. We're just trying to make this work as it has before with Samba 3.x and security=ads with Active Directory on MS Windows. We have /etc/passwd and /etc/group on each system. They are not identical. If I run: 'net ads group -U username | sort' on each system and compare, they show identical groups coming back from AD. The Group ID on Linux is in the 500 range on the system which works OK, and in the 1000 range on the system which does not work. Same AD user is tested with both systems. We also use winbind on ssh authentication and this works fine on both systems.
Rowland Penny
2016-Aug-08 15:43 UTC
[Samba] why does add_local_groups come up in only one system's logs?
On Mon, 8 Aug 2016 11:48:42 -0300 francis picabia <fpicabia at gmail.com> wrote:> On Mon, Aug 8, 2016 at 10:54 AM, Rowland Penny <rpenny at samba.org> > wrote: > > > On Mon, 8 Aug 2016 10:24:03 -0300 > > francis picabia <fpicabia at gmail.com> wrote: > > > > > I have a couple of Debian 8.5 systems set up in similar manner. > > > Samba is version 4.2.10-Debian > > > > > > Here is the essential config... > > > > > > # testparm /etc/samba/smb.conf > > > Load smb config files from /etc/samba/smb.conf > > > Processing section "[homes]" > > > Loaded services file OK. > > > Server role: ROLE_DOMAIN_MEMBER > > > > > > Press enter to see a dump of your service definitions > > > > > > # Global parameters > > > [global] > > > workgroup = MYDOM > > > realm = AD.MYDOM.CA > > > server string = debian2 Server > > > security = ADS > > > log file = /var/log/samba/%m.log > > > max log size = 50 > > > unix extensions = No > > > load printers = No > > > printcap name = /dev/null > > > disable spoolss = Yes > > > dns proxy = No > > > winbind enum users = Yes > > > winbind enum groups = Yes > > > winbind use default domain = Yes > > > idmap config * : range = 1000-1999999 > > > idmap config * : backend = tdb > > > nt acl support = No > > > printing = bsd > > > > > > > > > [homes] > > > comment = Home Directories > > > path = %H > > > valid users = %U at mydom > > > read only = No > > > create mask = 0700 > > > directory mask = 0700 > > > browseable = No > > > wide links = Yes > > > > > > /etc/pam.d/samba, /etc/nsswitch.conf and /etc/krb5.conf are the > > > same configuration on both systems. The first one allows a > > > connection to the homes. Here is a tail on the log file: > > > > > > [2016/08/08 09:42:49.956619, 3] > > > ../source3/auth/auth.c:178(auth_check_ntlm_password) > > > check_ntlm_password: Checking password for unmapped user > > > [MYDOM]\[username]@[DEBIAN1] with the new password interface > > > [2016/08/08 09:42:49.956656, 3] > > > ../source3/auth/auth.c:181(auth_check_ntlm_password) > > > check_ntlm_password: mapped user is: > > > [MYDOM]\[username]@[DEBIAN1] [2016/08/08 09:42:49.961548, 3] > > > ../source3/auth/auth.c:249(auth_check_ntlm_password) > > > check_ntlm_password: winbind authentication for user [username] > > > succeeded [2016/08/08 09:42:49.961610, 2] > > > ../source3/auth/auth.c:305(auth_check_ntlm_password) > > > check_ntlm_password: authentication for user [username] -> > > > [username] -> [username] succeeded > > > [2016/08/08 09:42:49.961671, 3] > > > ../auth/ntlmssp/ntlmssp_sign.c:509(ntlmssp_sign_reset) > > > NTLMSSP Sign/Seal - Initialising with flags: > > > [2016/08/08 09:42:49.961699, 3] > > > ../auth/ntlmssp/ntlmssp_util.c:69(debug_ntlmssp_flags) > > > Got NTLMSSP neg_flags=0x62088215 > > > [2016/08/08 09:42:49.961748, 3] > > > ../auth/ntlmssp/ntlmssp_sign.c:509(ntlmssp_sign_reset) > > > NTLMSSP Sign/Seal - Initialising with flags: > > > [2016/08/08 09:42:49.961772, 3] > > > ../auth/ntlmssp/ntlmssp_util.c:69(debug_ntlmssp_flags) > > > Got NTLMSSP neg_flags=0x62088215 > > > [2016/08/08 09:42:50.271337, 3] > > > ../source3/param/loadparm.c:1427(lp_add_home) > > > adding home's share [username] for user 'username' at '%H' > > > > > > The second server fails with the add_local_groups and getpwuid: > > > > > > [2016/08/08 09:53:55.146840, 3] > > > ../source3/auth/auth.c:178(auth_check_ntlm_password) > > > check_ntlm_password: Checking password for unmapped user > > > [MYDOM]\[username]@[DEBIAN2] with the new password interface > > > [2016/08/08 09:53:55.146867, 3] > > > ../source3/auth/auth.c:181(auth_check_ntlm_password) > > > check_ntlm_password: mapped user is: > > > [MYDOM]\[username]@[DEBIAN2] [2016/08/08 09:53:55.150852, 3] > > > ../source3/auth/auth.c:249(auth_check_ntlm_password) > > > check_ntlm_password: winbind authentication for user [username] > > > succeeded [2016/08/08 09:53:55.150902, 2] > > > ../source3/auth/auth.c:305(auth_check_ntlm_password) > > > check_ntlm_password: authentication for user [username] -> > > > [username] -> [username] succeeded > > > [2016/08/08 09:53:55.150960, 3] > > > ../auth/ntlmssp/ntlmssp_sign.c:509(ntlmssp_sign_reset) > > > NTLMSSP Sign/Seal - Initialising with flags: > > > [2016/08/08 09:53:55.150978, 3] > > > ../auth/ntlmssp/ntlmssp_util.c:69(debug_ntlmssp_flags) > > > Got NTLMSSP neg_flags=0x62088215 > > > [2016/08/08 09:53:55.151024, 3] > > > ../auth/ntlmssp/ntlmssp_sign.c:509(ntlmssp_sign_reset) > > > NTLMSSP Sign/Seal - Initialising with flags: > > > [2016/08/08 09:53:55.151036, 3] > > > ../auth/ntlmssp/ntlmssp_util.c:69(debug_ntlmssp_flags) > > > Got NTLMSSP neg_flags=0x62088215 > > > [2016/08/08 09:53:55.151321, 1] > > > ../source3/auth/token_util.c:430(add_local_groups) > > > SID S-1-5-21-82194667-1315141139-1877560073-12331 -> > > > getpwuid(16777216) failed > > > [2016/08/08 09:53:55.151348, 3] > > > ../source3/auth/token_util.c:316(create_local_nt_token_from_info3) > > > Failed to finalize nt token > > > > > > > > > I am so far unable to find why the getpwuid for add_local_groups > > > matters, or why only one system even mentions it in the logfile > > > trace. The default group ID is listed in /etc/group for the user > > > and the home directory with ls -ld looks fine with 700 chmod > > > for the home directory in both servers. > > > > Are you using sssd ? > > If not, where are you storing the users & groups ? > > > > > I've never used sssd anywhere before nor here. We're just trying to > make this work > as it has before with Samba 3.x and security=ads with Active > Directory on MS Windows. > > We have /etc/passwd and /etc/group on each system. They are not > identical. > > If I run: 'net ads group -U username | sort' on each system and > compare, they > show identical groups coming back from AD. > > The Group ID on Linux is in the 500 range on the system which works > OK, and in the 1000 range on the system which does not work. Same AD > user is tested with both systems. > > We also use winbind on ssh authentication and this works fine on both > systems.The way you have Samba setup, ALL your AD users & groups are getting mixed up i.e. normal users & groups and the well known SIDs The '*' domain is usually only used for the well known SIDs, I would normally expect to see another few lines, similar to these: idmap config MYDOM : backend = rid idmap config MYDOM : range = 10000-999999 This is where your users should be mapped to Unix ids, I also wouldn't have started the '*' range at 1000, this means you cannot have any normal local Unix users. By using '1000', you will only be able to log into the Samba machine as the 'root' user if you have network problems and the AD domain isn't contactable. Can I suggest you go and read this wiki page: https://wiki.samba.org/index.php/Setup_Samba_as_an_AD_Domain_Member Rowland
francis picabia
2016-Aug-08 18:27 UTC
[Samba] why does add_local_groups come up in only one system's logs?
On Mon, Aug 8, 2016 at 12:43 PM, Rowland Penny <rpenny at samba.org> wrote:> On Mon, 8 Aug 2016 11:48:42 -0300 > francis picabia <fpicabia at gmail.com> wrote: > > > On Mon, Aug 8, 2016 at 10:54 AM, Rowland Penny <rpenny at samba.org> > > wrote: > > > > > On Mon, 8 Aug 2016 10:24:03 -0300 > > > francis picabia <fpicabia at gmail.com> wrote: > > > > > > > I have a couple of Debian 8.5 systems set up in similar manner. > > > > Samba is version 4.2.10-Debian > > > > > > > > Here is the essential config... > > > > > > > > # testparm /etc/samba/smb.conf > > > > Load smb config files from /etc/samba/smb.conf > > > > Processing section "[homes]" > > > > Loaded services file OK. > > > > Server role: ROLE_DOMAIN_MEMBER > > > > > > > > Press enter to see a dump of your service definitions > > > > > > > > # Global parameters > > > > [global] > > > > workgroup = MYDOM > > > > realm = AD.MYDOM.CA > > > > server string = debian2 Server > > > > security = ADS > > > > log file = /var/log/samba/%m.log > > > > max log size = 50 > > > > unix extensions = No > > > > load printers = No > > > > printcap name = /dev/null > > > > disable spoolss = Yes > > > > dns proxy = No > > > > winbind enum users = Yes > > > > winbind enum groups = Yes > > > > winbind use default domain = Yes > > > > idmap config * : range = 1000-1999999 > > > > idmap config * : backend = tdb > > > > nt acl support = No > > > > printing = bsd > > > > > > > > > > > > [homes] > > > > comment = Home Directories > > > > path = %H > > > > valid users = %U at mydom > > > > read only = No > > > > create mask = 0700 > > > > directory mask = 0700 > > > > browseable = No > > > > wide links = Yes > > > > > > > > /etc/pam.d/samba, /etc/nsswitch.conf and /etc/krb5.conf are the > > > > same configuration on both systems. The first one allows a > > > > connection to the homes. Here is a tail on the log file: > > > > > > > > [2016/08/08 09:42:49.956619, 3] > > > > ../source3/auth/auth.c:178(auth_check_ntlm_password) > > > > check_ntlm_password: Checking password for unmapped user > > > > [MYDOM]\[username]@[DEBIAN1] with the new password interface > > > > [2016/08/08 09:42:49.956656, 3] > > > > ../source3/auth/auth.c:181(auth_check_ntlm_password) > > > > check_ntlm_password: mapped user is: > > > > [MYDOM]\[username]@[DEBIAN1] [2016/08/08 09:42:49.961548, 3] > > > > ../source3/auth/auth.c:249(auth_check_ntlm_password) > > > > check_ntlm_password: winbind authentication for user [username] > > > > succeeded [2016/08/08 09:42:49.961610, 2] > > > > ../source3/auth/auth.c:305(auth_check_ntlm_password) > > > > check_ntlm_password: authentication for user [username] -> > > > > [username] -> [username] succeeded > > > > [2016/08/08 09:42:49.961671, 3] > > > > ../auth/ntlmssp/ntlmssp_sign.c:509(ntlmssp_sign_reset) > > > > NTLMSSP Sign/Seal - Initialising with flags: > > > > [2016/08/08 09:42:49.961699, 3] > > > > ../auth/ntlmssp/ntlmssp_util.c:69(debug_ntlmssp_flags) > > > > Got NTLMSSP neg_flags=0x62088215 > > > > [2016/08/08 09:42:49.961748, 3] > > > > ../auth/ntlmssp/ntlmssp_sign.c:509(ntlmssp_sign_reset) > > > > NTLMSSP Sign/Seal - Initialising with flags: > > > > [2016/08/08 09:42:49.961772, 3] > > > > ../auth/ntlmssp/ntlmssp_util.c:69(debug_ntlmssp_flags) > > > > Got NTLMSSP neg_flags=0x62088215 > > > > [2016/08/08 09:42:50.271337, 3] > > > > ../source3/param/loadparm.c:1427(lp_add_home) > > > > adding home's share [username] for user 'username' at '%H' > > > > > > > > The second server fails with the add_local_groups and getpwuid: > > > > > > > > [2016/08/08 09:53:55.146840, 3] > > > > ../source3/auth/auth.c:178(auth_check_ntlm_password) > > > > check_ntlm_password: Checking password for unmapped user > > > > [MYDOM]\[username]@[DEBIAN2] with the new password interface > > > > [2016/08/08 09:53:55.146867, 3] > > > > ../source3/auth/auth.c:181(auth_check_ntlm_password) > > > > check_ntlm_password: mapped user is: > > > > [MYDOM]\[username]@[DEBIAN2] [2016/08/08 09:53:55.150852, 3] > > > > ../source3/auth/auth.c:249(auth_check_ntlm_password) > > > > check_ntlm_password: winbind authentication for user [username] > > > > succeeded [2016/08/08 09:53:55.150902, 2] > > > > ../source3/auth/auth.c:305(auth_check_ntlm_password) > > > > check_ntlm_password: authentication for user [username] -> > > > > [username] -> [username] succeeded > > > > [2016/08/08 09:53:55.150960, 3] > > > > ../auth/ntlmssp/ntlmssp_sign.c:509(ntlmssp_sign_reset) > > > > NTLMSSP Sign/Seal - Initialising with flags: > > > > [2016/08/08 09:53:55.150978, 3] > > > > ../auth/ntlmssp/ntlmssp_util.c:69(debug_ntlmssp_flags) > > > > Got NTLMSSP neg_flags=0x62088215 > > > > [2016/08/08 09:53:55.151024, 3] > > > > ../auth/ntlmssp/ntlmssp_sign.c:509(ntlmssp_sign_reset) > > > > NTLMSSP Sign/Seal - Initialising with flags: > > > > [2016/08/08 09:53:55.151036, 3] > > > > ../auth/ntlmssp/ntlmssp_util.c:69(debug_ntlmssp_flags) > > > > Got NTLMSSP neg_flags=0x62088215 > > > > [2016/08/08 09:53:55.151321, 1] > > > > ../source3/auth/token_util.c:430(add_local_groups) > > > > SID S-1-5-21-82194667-1315141139-1877560073-12331 -> > > > > getpwuid(16777216) failed > > > > [2016/08/08 09:53:55.151348, 3] > > > > ../source3/auth/token_util.c:316(create_local_nt_token_from_info3) > > > > Failed to finalize nt token > > > > > > > > > > > > I am so far unable to find why the getpwuid for add_local_groups > > > > matters, or why only one system even mentions it in the logfile > > > > trace. The default group ID is listed in /etc/group for the user > > > > and the home directory with ls -ld looks fine with 700 chmod > > > > for the home directory in both servers. > > > > > > Are you using sssd ? > > > If not, where are you storing the users & groups ? > > > > > > > > I've never used sssd anywhere before nor here. We're just trying to > > make this work > > as it has before with Samba 3.x and security=ads with Active > > Directory on MS Windows. > > > > We have /etc/passwd and /etc/group on each system. They are not > > identical. > > > > If I run: 'net ads group -U username | sort' on each system and > > compare, they > > show identical groups coming back from AD. > > > > The Group ID on Linux is in the 500 range on the system which works > > OK, and in the 1000 range on the system which does not work. Same AD > > user is tested with both systems. > > > > We also use winbind on ssh authentication and this works fine on both > > systems. > > > The way you have Samba setup, ALL your AD users & groups are getting > mixed up i.e. normal users & groups and the well known SIDs > > The '*' domain is usually only used for the well known SIDs, I would > normally expect to see another few lines, similar to these: > > idmap config MYDOM : backend = rid > idmap config MYDOM : range = 10000-999999 > > This is where your users should be mapped to Unix ids, I also wouldn't > have started the '*' range at 1000, this means you cannot have any > normal local Unix users. By using '1000', you will only be able to log > into the Samba machine as the 'root' user if you have network problems > and the AD domain isn't contactable. > > Can I suggest you go and read this wiki page: > > https://wiki.samba.org/index.php/Setup_Samba_as_an_AD_Domain_Member > <https://lists.samba.org/mailman/options/samba> >OK, that was my bad for copy/pasting some config lines I found with a report of "this works!" on a bug report (only the second login connects bug). I've included the domain and fixed the range so it won't overlap with Unix IDs. # grep idmap /etc/samba/smb.conf idmap config MYDOM : backend = rid idmap config MYDOM : range = 70000-99999999 I eliminated the "valid users =" line from the homes section. On Debian, there are a couple of difference services. I read that with 4.2, it can run its own winbind service. So I wondered if that can make a difference. If I stop winbind, and restart samba... # /etc/init.d/samba restart [ ok ] Restarting nmbd (via systemctl): nmbd.service. [ ok ] Restarting smbd (via systemctl): smbd.service. [ ok ] Restarting samba-ad-dc (via systemctl): samba-ad-dc.service. # ps auxww | grep winbind root 19867 0.0 0.0 12764 948 pts/0 S+ 14:13 0:00 grep winbind Then I can connect with smbclient to the system where I never could before. That would be fine except that ssh requires winbind. If I stop /etc/init.d/samba and launch nmbd, smbd and winbind as services on their own, then ssh login with AD credentials works, but I cannot connect with smbclient. The other system running with winbind allows both smbclient and ssh connections. On the problem system: Winbind on, and smbclient fails. Winbind off, and smbclient connects. It doesn't matter if winbind is in /etc/nsswitch.conf The good working system does not have winbind in the nsswitch.conf Both systems have the same packages containing winbind in the name. The error from smbclient is only: session setup failed: NT_STATUS_UNSUCCESSFUL tail on the logfile for this client: [2016/08/08 14:47:46.385401, 3] ../source3/auth/auth.c:249(auth_check_ntlm_password) check_ntlm_password: winbind authentication for user [theusername] succeeded [2016/08/08 14:47:46.385452, 2] ../source3/auth/auth.c:305(auth_check_ntlm_password) check_ntlm_password: authentication for user [theusername] -> [theusername] -> [theusername] succeeded [2016/08/08 14:47:46.385511, 3] ../auth/ntlmssp/ntlmssp_sign.c:509(ntlmssp_sign_reset) NTLMSSP Sign/Seal - Initialising with flags: [2016/08/08 14:47:46.385530, 3] ../auth/ntlmssp/ntlmssp_util.c:69(debug_ntlmssp_flags) Got NTLMSSP neg_flags=0x62088215 [2016/08/08 14:47:46.385577, 3] ../auth/ntlmssp/ntlmssp_sign.c:509(ntlmssp_sign_reset) NTLMSSP Sign/Seal - Initialising with flags: [2016/08/08 14:47:46.385587, 3] ../auth/ntlmssp/ntlmssp_util.c:69(debug_ntlmssp_flags) Got NTLMSSP neg_flags=0x62088215 [2016/08/08 14:47:46.385860, 1] ../source3/auth/token_util.c:430(add_local_groups) SID S-1-5-21-82194667-1315141139-1877560073-12331 -> getpwuid(16777216) failed [2016/08/08 14:47:46.385893, 3] ../source3/auth/token_util.c:316(create_local_nt_token_from_info3) Failed to finalize nt token Both systems can do wbinfo -u or -g (as long as winbind service is running) I'm not finding anything useful which will trace what is going wrong.
Reasonably Related Threads
- why does add_local_groups come up in only one system's logs?
- why does add_local_groups come up in only one system's logs?
- why does add_local_groups come up in only one system's logs?
- why does add_local_groups come up in only one system's logs?
- why does add_local_groups come up in only one system's logs?