Dear, I've been noticing that constantly, some user accounts has been repeatedly blocked. We use DC Samba 4.4.5. Here we have a blocking policy, if the wrong password is entered more than 5 times. But most users say they do not screwed up the password. They perform the log at the beginning of working hours. After a while, they block the session and when they try to log on again, the message of blocked account. The same thing happened with two users who work with me. And today I experienced the problem, rebooted my desktop when I perform logon, I received the message that the account was blocked. We perform other test. We managed to block an account with only 3 attempts to wrong password. Someone can tell me where I can check the Samba logs the account lockout reason? We performed a search on all machines and servers, the search for malware, but nothing was found. Thank you!
Windows has some "features" which can create a lot of fake invalid logon attempts. Windows remembers userids and passwords until logout, and whenever you want to access a protected share, it automatically first tries with stored passwords, before showing a password prompt. If users are using local accounts (for example on their personal notebooks), and have different username or password on the server, Windows will always first try to log in to the server with the local credentials. Also Windows remembers all shares that you ever used (unless you connect always with "net use share /user:xxx * /persistent:no", or you remove them with "net use share /delete"), and Windows tries to access all previously known shares many times, for example each time you open Explorer. If you revoke a user the right to access a share, which they previously used, and they do not specifically disconnect from it, Windows will keep trying many times per day to access it. Maybe some users once clicked on "remember password", and later changed the password on the server. Now some of their devices (maybe a smartphone) silently keeps trying with the old password.
Ricardo, I am very sure this is a bug that has a fix in the 4.5rc version of Samba. I am not having any luck finding the bug page for this though though. You can increase the log levels to 4 (I think) or greater to see what is happening. I set my log level to 10 when I investigated this, but that generates a huge amount of info to shift through.>From what I understand, after attempting to authenticate on a Windowsworkstation the workstation sends a authentication request to the Samba server. Windows then expects a certain reply from the Samba server. If Windows does not see the reply it wants, then the workstation sends the request again. If there was a bad password entered during authentication request, then Samba would see multiple bad password attempts coming from the workstation and would lock the account out after it reaches the lockout threshold. I wanted a lockout threshold of 3 on my systems, so I ended up setting this to 6 since it seems to increase the bad password count by 2 on average for each bad password attempt on my systems. I have seen it increase the bad password count by up to 4 for a single bad password attempt though. Thanks, -James Crouch On Fri, Aug 19, 2016 at 12:21 PM, Ricardo Pardim Claus via samba < samba at lists.samba.org> wrote:> > > Dear, > I've been noticing that constantly, some user accounts has been repeatedly > blocked. > We use DC Samba 4.4.5. > > Here we have a blocking policy, if the wrong password is entered more than > 5 times. But most users say they do not screwed up the password. They > perform the log at the beginning of working hours. After a while, they > block the session and when they try to log on again, the message of blocked > account. > > The same thing happened with two users who work with me. And today I > experienced the problem, rebooted my desktop when I perform logon, I > received the message that the account was blocked. > We perform other test. We managed to block an account with only 3 attempts > to wrong password. > > Someone can tell me where I can check the Samba logs the account lockout > reason? > > We performed a search on all machines and servers, the search for malware, > but nothing was found. > > Thank you! > > -- > To unsubscribe from this list go to the following URL and read the > instructions: https://lists.samba.org/mailman/options/samba >
> Windows has some "features" which can create a lot of fake invalid logon> attempts.> Windows remembers userids and passwords until logout, and whenever you > want to access a protected share, it automatically first tries with > stored passwords, before showing a password prompt.> If users are using local accounts (for example on their personal > notebooks), and have different username or password on the server, > Windows will always first try to log in to the server with the local > credentials.> Also Windows remembers all shares that you ever used (unless you connect > always with "net use share /user:xxx * /persistent:no", or you remove >them with "net use share /delete"), and Windows tries to access all > previously known shares many times, for example each time you open Explorer.> If you revoke a user the right to access a share, which they previously > used, and they do not specifically disconnect from it, Windows will keep > trying many times per day to access it.> Maybe some users once clicked on "remember password", and later changed > the password on the server. Now some of their devices (maybe a > smartphone) silently keeps trying with the old password.Dear Klaus I appreciate the contribution. Here the company carried out a work to migrate the Windows Server DC for Samba 4. GPO settings are the same as we used in Windows Server. The shared network drive mapping is set by a GPO, which used the "/delete /yes and persistent:no". The doubts are generated precisely because it did not happen with the DC MS. The authentication credentials in AD are used only on desktops. In other devices (tablet / smartphone) do not use credentials. I keep looking for a solution to this issue.
Here are the bug report pages for the issues I was having that sounds similar to your issue. https://bugzilla.samba.org/show_bug.cgi?id=11029 https://bugzilla.samba.org/show_bug.cgi?id=11539 -James Crouch On Fri, Aug 19, 2016 at 1:45 PM, Ricardo Pardim Claus via samba < samba at lists.samba.org> wrote:> > > > > Windows has some "features" which can create a lot of fake invalid logon > > > attempts. > > > Windows remembers userids and passwords until logout, and whenever you > > want to access a protected share, it automatically first tries with > > stored passwords, before showing a password prompt. > > > If users are using local accounts (for example on their personal > > notebooks), and have different username or password on the server, > > Windows will always first try to log in to the server with the local > > credentials. > > > Also Windows remembers all shares that you ever used (unless you connect > > always with "net use share /user:xxx * /persistent:no", or you remove > >them with "net use share /delete"), and Windows tries to access all > > previously known shares many times, for example each time you open > Explorer. > > > If you revoke a user the right to access a share, which they previously > > used, and they do not specifically disconnect from it, Windows will keep > > trying many times per day to access it. > > > Maybe some users once clicked on "remember password", and later changed > > the password on the server. Now some of their devices (maybe a > > smartphone) silently keeps trying with the old password. > > > Dear Klaus > I appreciate the contribution. > > Here the company carried out a work to migrate the Windows Server DC for > Samba 4. GPO settings are the same as we used in Windows Server. > The shared network drive mapping is set by a GPO, which used the "/delete > /yes and persistent:no". > The doubts are generated precisely because it did not happen with the DC > MS. > The authentication credentials in AD are used only on desktops. In other > devices (tablet / smartphone) do not use credentials. > I keep looking for a solution to this issue. > > -- > To unsubscribe from this list go to the following URL and read the > instructions: https://lists.samba.org/mailman/options/samba >
Dear James, Thanks for the input. Even increasing from 5 to 10, the amount of times to miss the password and lock the account (after changing, I wheeled a gpupdate / force), if you miss 3 times the account is locked. I changed smb.conf log level to 9. I tried to unlock the account using the samba-tool command line, but without success, because I can only unlock using the RSAT. I get these messages: # Samba-user tool enable erico INFO: Current debug levels: all: 9 tdb: 9 printdrivers: 9 lanman: 9 smb: 9 rpc_parse: 9 rpc_srv: 9 rpc_cli: 9 passdb: 9 sam: 9 auth: 9 winbind: 9 vfs: 9 idmap: 9 share: 9 acls: 9 locking: 9 msdfs: 9 DMAPI: 9 Registry: 9 Scavenger: 9 dns: 9 ldb: 9 tevent: 9 Processing section "[netlogon]" Processing section "[sysvol]" pm_process () returned Yes Module 'tombstone_reanimate' is disabled. Skip registration.ldb_wrap open of secrets.ldb lpcfg_servicenumber: could not find ldb schema_fsmo_init: we are master [yes] updates allowed [in] schema_fsmo_init: we are master [yes] updates allowed [in] Enabled user 'erico' In "tail -f /var/log/samba/%m.log" I see these lines: [2016/08/19 15:13:27.681166, 4] ../source4/dsdb/samdb/ldb_modules/repl_meta_data.c:5397(replmd_extended_replicated_objects) linked_attributes_count=0 [2016/08/19 15:13:27.681922, 6] ../source4/dsdb/samdb/ldb_modules/repl_meta_data.c:759(replmd_replPropertyMetaDataCtr1_sort_and_verify) Sorting rpmd with attid exception 3 rDN=CN DN=CN=Erico Joao Santos Velter,OU=TI-INFRA,OU=domain,DC=domain,DC=local [2016/08/19 15:13:27.682003, 4] ../source4/dsdb/samdb/ldb_modules/repl_meta_data.c:4694(replmd_replicated_apply_merge) [2016/08/19 15:13:27.683095, 4] ../source4/dsdb/samdb/ldb_modules/repl_meta_data.c:4696(replmd_replicated_apply_merge) DRS replication modify message: dn: CN=Erico Joao Santos Velter,OU=TI-INFRA,OU=domain,DC=domain,DC=local changetype: modify replace: whenChanged whenChanged: 20160819181321.0Z - replace: uSNChanged uSNChanged: 14351 - replace: replPropertyMetaData replPropertyMetaData:: AQAAAAAAAAAeAAAAAAAAAAAAAAABAAAAO+eADAMAAAA0cRFe3a15QqY Pt3C2QPfI/zQAAAAAAAAbEAAAAAAAAAQAAAABAAAAO+eADAMAAAA0cRFe3a15QqYPt3C2QPfI/zQA AAAAAAAbEAAAAAAAACoAAAABAAAAO+eADAMAAAA0cRFe3a15QqYPt3C2QPfI/zQAAAAAAAAbEAAAA AAAAAEAAgABAAAAO+eADAMAAAA0cRFe3a15QqYPt3C2QPfI/zQAAAAAAAAbEAAAAAAAAAIAAgABAA AAO+eADAMAAAA0cRFe3a15QqYPt3C2QPfI/zQAAAAAAAAbEAAAAAAAAA0AAgABAAAAO+eADAMAAAA 0cRFe3a15QqYPt3C2QPfI/zQAAAAAAAAbEAAAAAAAABkBAgACAAAADZiEDAMAAAA0cRFe3a15QqYP t3C2QPfIBmIAAAAAAAAbEAAAAAAAAAEACQARAAAAUpjCDQMAAADj+0WJUrcbT71MPVMCZ7NQLSIAA AAAAAAtIgAAAAAAAAgACQAFAAAAv2WpDQMAAABGCTrnfBiVS4Sau+xkyjfDtVIBAAAAAAAbEAAAAA AAABAACQABAAAAO+eADAMAAAA0cRFe3a15QqYPt3C2QPfIADUAAAAAAAAbEAAAAAAAABkACQABAAA AO+eADAMAAAA0cRFe3a15QqYPt3C2QPfIADUAAAAAAAAbEAAAAAAAADcACQAQAAAAt2WpDQMAAABG CTrnfBiVS4Sau+xkyjfDs1IBAAAAAAAbEAAAAAAAAEAACQABAAAAO+eADAMAAAA0cRFe3a15QqYPt 3C2QPfIADUAAAAAAAAbEAAAAAAAAFoACQAQAAAAt2WpDQMAAABGCTrnfBiVS4Sau+xkyjfDs1IBAA AAAAAbEAAAAAAAAF4ACQAQAAAAt2WpDQMAAABGCTrnfBiVS4Sau+xkyjfDs1IBAAAAAAAbEAAAAAA AAGAACQAVAAAAt2WpDQMAAABGCTrnfBiVS4Sau+xkyjfDs1IBAAAAAAAbEAAAAAAAAGIACQAEAAAA 5TmEDQMAAADGBIYQJPnHTpP0rJHpn8MYrrwAAAAAAAAbEAAAAAAAAH0ACQAPAAAAt2WpDQMAAABGC TrnfBiVS4Sau+xkyjfDtFIBAAAAAAAbEAAAAAAAAJIACQABAAAAO+eADAMAAAA0cRFe3a15QqYPt3 C2QPfI/zQAAAAAAAAbEAAAAAAAAJYACQABAAAADZiEDAMAAAA0cRFe3a15QqYPt3C2QPfIBmIAAAA AAAAbEAAAAAAAAJ8ACQABAAAAO+eADAMAAAA0cRFe3a15QqYPt3C2QPfIADUAAAAAAAAbEAAAAAAA AKAACQAQAAAAt2WpDQMAAABGCTrnfBiVS4Sau+xkyjfDs1IBAAAAAAAbEAAAAAAAAN0ACQABAAAAO +eADAMAAAA0cRFe3a15QqYPt3C2QPfI/zQAAAAAAAAbEAAAAAAAAC4BCQABAAAAO+eADAMAAAA0cR Fe3a15QqYPt3C2QPfI/zQAAAAAAAAbEAAAAAAAAJACCQABAAAAO+eADAMAAAA0cRFe3a15QqYPt3C 2QPfI/zQAAAAAAAAbEAAAAAAAAJYCCQAjAAAAQd3HDQMAAADUBnA1JNVVRYN4On+wEF1BuSMAAAAA AAAPOAAAAAAAAA4DCQABAAAAO+eADAMAAAA0cRFe3a15QqYPt3C2QPfI/zQAAAAAAAAbEAAAAAAAA KAGCQAXAAAA9wvFDQMAAADj+0WJUrcbT71MPVMCZ7NQPiwAAAAAAAA+LAAAAAAAAKsHCQABAAAAv2 WpDQMAAABGCTrnfBiVS4Sau+xkyjfDtVIBAAAAAAAbEAAAAAAAAAMAAAANAAAApnSyDQMAAABGCTr nfBiVS4Sau+xkyjfDkLgBAAAAAABxEwAAAAAAAA== - replace: lockoutTime lockoutTime: 131161040016926080 - [2016/08/19 15:13:27.687552, 4] ../source4/dsdb/samdb/ldb_modules/repl_meta_data.c:5231(replmd_replicated_uptodate_modify) DRS replication uptodate modify message: dn: DC=domain,DC=local changetype: modify replace: replUpToDateVector replUpToDateVector:: AgAAAAAAAAALAAAAAAAAAMYEhhAk+cdOk/SskemfwxjtXgIAAAAAAPW0l g0DAAAAl8bFE0zNXEGg22QMX6cWu9IvAAAAAAAAAIA+1d6xnQHUBnA1JNVVRYN4On+wEF1BuSMAAA AAAAAAgD7V3rGdAQ4crjuNcRJNp8XYZYxANVMxEwAAAAAAAACAPtXesZ0BNHERXt2teUKmD7dwtkD 3yAMzBwAAAAAABUiADQMAAAB5CTJ76gkgQZ/R3EKh722VgBMAAAAAAAAAgD7V3rGdASU0K4OwPo5J hZeJgfvJkr/vEgAAAAAAAACAPtXesZ0BLNuomXXda0+AaGlWssQYqBsTAAAAAAAAAIA+1d6xnQEZJ DHD3GZdSJo5+MrbBGDCorgBAAAAAABl7p8NAwAAAMT1D+Gifk5LjnVt/upuUAYGEwAAAAAAAACAPt XesZ0BRgk653wYlUuEmrvsZMo3wyAxAwAAAAAA9Jy/DQMAAAA= - replace: repsFrom repsFrom:: AQAAAAAAAAAPAQAAAAAAAEfdxw0DAAAAR93HDQMAAAAAAAAA0AAAAD8AAAB0AAAAERE RERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERER ERERERERERERERERERERERERERERERERAAAAALkjAAAAAAAAAAAAAAAAAAC5IwAAAAAAAOwZCRo0s CtDqb1rc6O7bG3UBnA1JNVVRYN4On+wEF1BAAAAAAAAAAAAAAAAAAAAADsAAAAxYTA5MTllYy1iMD M0LTQzMmItYTliZC02YjczYTNiYjZjNmQuX21zZGNzLmxvamFjb3JyLmxvY2FsAA== - [2016/08/19 15:13:27.694897, 2] ../source4/dsdb/repl/replicated_objects.c:1008(dsdb_replicated_objects_commit) Replicated 1 objects (0 linked attributes) for DC=domain,DC=local [2016/08/19 15:13:27.816480, 6] ../librpc/rpc/dcerpc_util.c:173(dcerpc_pull_auth_trailer) ../librpc/rpc/dcerpc_util.c:173: auth_pad_length 12 [2016/08/19 15:13:27.816608, 4] ../source4/dsdb/repl/drepl_out_helpers.c:918(dreplsrv_update_refs_done) UpdateRefs OK for f192ce0f-92cf-4511-b1bb-71b0fbc2f39c._msdcs.domain.local DC=domain,DC=local [2016/08/19 15:13:27.816632, 4] ../source4/dsdb/repl/drepl_out_pull.c:178(dreplsrv_pending_op_callback) dreplsrv_op_pull_source(WERR_OK) for DC=domain,DC=local [2016/08/19 15:13:30.360979, 4] ../source4/dsdb/repl/drepl_notify.c:463(dreplsrv_notify_schedule) dreplsrv_notify_schedule(5) scheduled for: Fri Aug 19 15:13:35 2016 BRT [2016/08/19 15:13:32.271240, 5] ../source4/libcli/dgram/dgramsocket.c:65(dgm_socket_recv) Received dgram packet of length 201 from 172.16.16.137:138 [2016/08/19 15:13:32.271406, 4] ../source4/nbt_server/dgram/browse.c:70(nbtd_mailslot_browse_handler) Browse HostAnnouncement (Op 1) on 'domain<1d>' '\MAILSLOT\BROWSE' from 172.16.16.137:138 [2016/08/19 15:13:32.271453, 5] ../source4/libcli/dgram/dgramsocket.c:65(dgm_socket_recv) Received dgram packet of length 201 from 172.16.16.137:138 [2016/08/19 15:13:32.271484, 4] ../source4/nbt_server/dgram/browse.c:70(nbtd_mailslot_browse_handler) Browse HostAnnouncement (Op 1) on 'domain<1d>' '\MAILSLOT\BROWSE' from 172.16.16.137:138 [2016/08/19 15:13:35.368264, 4] ../source4/dsdb/repl/drepl_notify.c:463(dreplsrv_notify_schedule) dreplsrv_notify_schedule(5) scheduled for: Fri Aug 19 15:13:40 2016 BRT ________________________________> De: James Crouch > Ricardo,> I am very sure this is a bug that has a fix in the 4.5rc version of Samba. I am not having any luck finding the bug page for this though though.> You can increase the log levels to 4 (I think) or greater to see what is happening. I set my log level to 10 when I investigated this, but that generates a huge amount of info to shift > through.> From what I understand, after attempting to authenticate on a Windows workstation the workstation sends a authentication request to the Samba server. Windows then expects a certain reply > from the Samba server. If Windows does not see the reply it wants, then the workstation sends the request again. If there was a bad password entered during authentication request, then Samba would see multiple bad password attempts coming from the workstation and would lock the account out after it reaches the lockout threshold.>I wanted a lockout threshold of 3 on my systems, so I ended up setting this to 6 since it seems to increase the bad password count by 2 on average for each bad password attempt on my >systems. I have seen it increase the bad password count by up to 4 for a single bad password attempt though. >Thanks, >-James Crouch