Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
[Samba] User accounts being blocked
1,514 views
Skip to first unread message
Ricardo Pardim Claus via samba
Aug 19, 2016, 1:30:03 PM8/19/16
to
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
Klaus Hartnegg via samba
Aug 19, 2016, 2:10:02 PM8/19/16
to
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.
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.
James Crouch via samba
Aug 19, 2016, 2:10:03 PM8/19/16
to
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
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
Ricardo Pardim Claus via samba
Aug 19, 2016, 2:50:02 PM8/19/16
to
> 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.
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.
Ricardo Pardim Claus via samba
Aug 19, 2016, 3:10:02 PM8/19/16
to
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
> 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
James Crouch via samba
Aug 19, 2016, 3:20:03 PM8/19/16
to
Are you using the "samba-tool domain passwordsettings" command to set the
lockout policy, or are you using group policy?
-James Crouch
On Aug 19, 2016 2:03 PM, "Ricardo Pardim Claus" <ricard...@yahoo.com.br>
wrote:
lockout policy, or are you using group policy?
-James Crouch
On Aug 19, 2016 2:03 PM, "Ricardo Pardim Claus" <ricard...@yahoo.com.br>
wrote:
Ricardo Pardim Claus via samba
Aug 19, 2016, 3:30:02 PM8/19/16
to
James,
I configured the account lockout policies by RSAT, GPEDIT.MSC.
By GPEDIT.MSC I set the value = 10 attempts.
Through the samba-tool, I used this command:
# samba-tool domain passwordsettings set --account-lockout-threshold=11
INFO: Current debug levels:
...
pm_process() returned Yes
Module 'tombstone_reanimate' is disabled. Skip registration.lpcfg_servicenumber: couldn't find ldb
schema_fsmo_init: we are master[yes] updates allowed[no]
schema_fsmo_init: we are master[yes] updates allowed[no]
Sorting rpmd with attid exception 1376281 rDN=DC DN=DC=domain,DC=local
Account lockout threshold changed!
All changes applied successfully!
All desktops are Windows 10.
________________________________
De: James Crouch
Are you using the "samba-tool domain passwordsettings" command to set the lockout policy, or are you using group policy?
-James Crouch
James Crouch via samba
Aug 19, 2016, 3:40:02 PM8/19/16
to
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
similar to your issue.
https://bugzilla.samba.org/show_bug.cgi?id=11029
https://bugzilla.samba.org/show_bug.cgi?id=11539
-James Crouch
James Crouch via samba
Aug 19, 2016, 3:50:04 PM8/19/16
to
I am fairly sure Samba will ignore GP password policies, but if you set the
policies with the samba tool command, then it should adhere to it, unless
you are running across the bug I mentioned. You would see multiple
badPwdCount increases for one bad password in the logs if you are
experiencing that bug.
-James Crouch
On Aug 19, 2016 2:26 PM, "Ricardo Pardim Claus" <ricard...@yahoo.com.br>
wrote:
>
>
policies with the samba tool command, then it should adhere to it, unless
you are running across the bug I mentioned. You would see multiple
badPwdCount increases for one bad password in the logs if you are
experiencing that bug.
-James Crouch
On Aug 19, 2016 2:26 PM, "Ricardo Pardim Claus" <ricard...@yahoo.com.br>
wrote:
>
>
Andrew Bartlett via samba
Aug 26, 2016, 4:40:02 PM8/26/16
to
On Fri, 2016-08-19 at 14:39 -0500, James Crouch via samba wrote:
> I am fairly sure Samba will ignore GP password policies, but if you
> set the
> policies with the samba tool command, then it should adhere to it,
> unless
> you are running across the bug I mentioned. You would see multiple
> badPwdCount increases for one bad password in the logs if you are
> experiencing that bug.
> -James Crouch
This describes the situation correctly.
> I am fairly sure Samba will ignore GP password policies, but if you
> set the
> policies with the samba tool command, then it should adhere to it,
> unless
> you are running across the bug I mentioned. You would see multiple
> badPwdCount increases for one bad password in the logs if you are
> experiencing that bug.
> -James Crouch
We do wish we could honour the group policy files, but sadly the
patches have not been re-worked to a point where we can include them
(it is not a trivial task, even with the base of work from some GSoC
students).
I am glad to say we finally fixed the double-counting issue with 4.5.
Sorry,
Andrew Bartlett
--
Andrew Bartlett http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
Samba Developer, Catalyst IT http://catalyst.net.nz/services/samba
0 new messages