search for: ouruser

...from the hashed response or the plain-text password? What else am I doing wrong? Mar 7 09:20:53 olddsm wforce[17763]: WforceWebserver: HTTP Request "/" from 127.0.0.1:56416: Web Authentication failed curl -X POST -H "Content-Type: application/json" --data '{"login?:?ouruser?, "remote": "127.0.0.1", "pwhash?:?hashed-password?}? http://127.0.0.1:8084/?command=allow -u wforce:super {"status":"failure", "reason":"Unauthorized"} Mar 07 09:32:15 auth-worker(18933): Debug: Loading modules from directory: /usr...

...sponse or the plain-text password? What else am I doing wrong? > > Mar 7 09:20:53 olddsm wforce[17763]: WforceWebserver: HTTP Request "/" from 127.0.0.1:56416: Web Authentication failed > > curl -X POST -H "Content-Type: application/json" --data '{"login?:?ouruser?, "remote": "127.0.0.1", "pwhash?:?hashed-password?}? http://127.0.0.1:8084/?command=allow -u wforce:super > {"status":"failure", "reason":"Unauthorized"} > > > Mar 07 09:32:15 auth-worker(18933): Debug: Loading modules...

...yes auth_policy_check_after_auth = yes auth_policy_report_after_auth = yes And auth_debug=yes in /usr/local/etc/wforce.conf webserver("0.0.0.0:8084", "our_password") So when I run: curl -X POST -H "Content-Type: application/json" --data '{"login":"ouruser", "remote": "127.0.0.1", "pwhash":"our_password"}' http://127.0.0.1:8084/?command=allow -u wforce:our_passwordi {"msg": "", "r_attrs": {"defaultReturn": "1"}, "status": 0} What's the va...

...list for some time, so I have no > experience how (good) it actually works. > That was a thread I started. I got wforce to work. However the "reporting IP" in the logs always shows as 127.0.0.1, so I risk banning myself. Here's the log entry: Apr 12 10:06:12 auth: Debug: policy(ouruser,127.0.0.1,<OWoLzlWGDrh/AAAB>): Policy server request JSON: {"device_id":"","login":"ouruser","protocol":"imap","pwhash":"2a","remote":"127.0.0.1","success":false,"policy_reject&q...

...nt IP, you need to enable forwarding of > said data. With dovecot it's done by setting > > login_trusted_networks = your-upstream-host-or-net > > in backend config file. > OK I changed it and restarted wforce and dovecot. Still seeing this: Apr 12 14:38:55 auth: Debug: policy(ouruser,127.0.0.1,<6GFTnVmGcMN/AAAB>): Policy server request JSON: {"device_id":"","login":" ouruser","protocol":"imap","pwhash":"43","remote":"127.0.0.1","success":false,"policy_reject&...

...ot:auth): requirement "uid >= 1000" not met by user "nobody" Feb 27 08:31:12 ourserver auth[17875]: pam_unix(dovecot:auth): check pass; user unknown Feb 27 08:31:12 ourserver auth[17875]: pam_unix(dovecot:auth): authentication failure; logname= uid=0 euid=0 tty=dovecot ruser= ouruser at ourserver.ourdomain.edu rhost=80.78.70.1 Feb 27 08:31:33 ourserver auth[17875]: pam_unix(dovecot:auth): authentication failure; logname= uid=0 euid=0 tty=dovecot ruser=ouruser rhost=45.225.236.198 user=ouruser Feb 27 09:32:22 ourserver auth[32689]: pam_unix(dovecot:auth): check pass; user unkno...

On 28.3.2019 22.34, Robert Kudyba via dovecot wrote: >>>>> Set >>>>> >>>>> ssl_client_ca_file=/path/to/cacert.pem to validate the certificate? >>>> >>>> Can this be the Lets Encrypt cert that we already have? In other >>>> words we have: >>>> ssl_cert = </etc/pki/dovecot/certs/dovecot.pem

...'s done by setting > > > > > > login_trusted_networks = your-upstream-host-or-net > > > > > > in backend config file. > > > > OK I changed it and restarted wforce and dovecot. Still seeing this: > > Apr 12 14:38:55 auth: Debug: > policy(ouruser,127.0.0.1,<6GFTnVmGcMN/AAAB>): Policy server request JSON: > {"device_id":"","login":" > ouruser","protocol":"imap","pwhash":"43","remote":"127.0.0.1","success":false,"poli...

...e, so I have no > > experience how (good) it actually works. > > That was a thread I started. I got wforce to work. However the "reporting IP" in the logs always shows as 127.0.0.1, so I risk banning myself. Here's the log entry: > Apr 12 10:06:12 auth: Debug: policy(ouruser,127.0.0.1,<OWoLzlWGDrh/AAAB>): Policy server request JSON: {"device_id":"","login":"ouruser","protocol":"imap","pwhash":"2a","remote":"127.0.0.1","success":false,"policy_reject&q...

...rding of said data. With dovecot it's done by setting > > > > login_trusted_networks = your-upstream-host-or-net > > > > in backend config file. > > OK I changed it and restarted wforce and dovecot. Still seeing this: > Apr 12 14:38:55 auth: Debug: policy(ouruser,127.0.0.1,<6GFTnVmGcMN/AAAB>): Policy server request JSON: {"device_id":"","login":" ouruser","protocol":"imap","pwhash":"43","remote":"127.0.0.1","success":false,"policy_reject&...

...15.0.3.ELsmp. Configuration is as follow: # Global parameters [global] workgroup = OURWORKGROUP server string = Software Server interfaces = eth1 auth methods = guest, sam, winbind map to guest = Bad User null passwords = Yes guest account = ouruser passwd program = /usr/bin/passwd %u passwd chat = *New*UNIX*password* %n\n *ReType*new*UNIX*password* %n\n *passwd:*all*authentication*tokens*updated*successfully* username map = /etc/samba/smbusers log file = /var/log/samba/smbd.log max log size = 10240...

Hi all, I've got on AD DC using Samba 4.4.3 on Centos7 which accept Kerberos connections (kinit is working), which accept ldapsearch with credentials but which refuse ldapsearch with GSSAPI. The issue does not seem to be coming from the client as I discovered this issue writing a script to test all 22 DC, and all 21 others DC are working well from that client. The error: SASL/GSSAPI

On 11/04/2019 11:43, Marc Roos via dovecot wrote: > A. With the fail2ban solution > - you 'solve' that the current ip is not able to access you It is only a solution if there are subsequent attempts from the same address. I currently have several thousand addresses blocked due to dovecot login failures. My firewall is set to log these so I can see that few repeat, those

...onany "non-accessible" resource resulted in a message > > > notifying that noaccess was granted. > > > Since 4.18 the folder is simply completely invisible. I don? t > > > argueabout this being "correct" behaviour or not. It is just that > > > ourusers where just used to having the whole list and knowing > > > what is inthere (and eventually ask access to it to us or the > > > relevantdepartment that then forwards to us). > > > Is there a way to have that "old behaviour" back while still > > > usings...

...uth = yes > > And auth_debug=yes > > in /usr/local/etc/wforce.conf > webserver("0.0.0.0:8084 <http://0.0.0.0:8084>", "our_password") > So when I run: > curl -X POST -H "Content-Type: application/json" --data > '{"login":"ouruser", "remote": "127.0.0.1", "pwhash":"our_password"}' > http://127.0.0.1:8084/?command=allow -u wforce:our_passwordi > {"msg": "", "r_attrs": {"defaultReturn": "1"}, "status": 0} > &gt...

More information, making me more crazy: - ldapsearch without SASL is working from any host: ldapsearch -D 'CN=user-ldapmodify,OU=OurUsers,DC=ad,DC=domain,dc=tld' -w Passw0rd -x -ZZ -b 'dc=ad,DC=domain,dc=tld' -h dc106 sAMAccountName=administrator dn - ldapsearch with SASL is not working (Kerberos ticket existing following a working kinit) from any host but it works when launched from the non-working-server kinit -k -t a...

...mon with the following configuration: log file = /var/log/rsyncd.log pid file = /var/run/rsyncd.pid lock file = /var/run/rsync.lock socket options = SO_KEEPALIVE TCP_NODELAY IPTOS_LOWDELAY IPTOS_THROUGHPUT [data1] path = /data1 comment = data1 read only = false uid = ouruser gid = ourgrp hosts allow = 10.2.1.188 timeout = 300 and from source machine I'm pushing some data like: rsync -av --keep-dirlinks /data/hudson/ 10.2.2.74::data1 it works fine except for the --keep-dirlinks option which doesn't have any effect, so symlinks at the ta...

...;t perform test to make it work without that reverse DNS entry set up. 2016-06-07 17:50 GMT+02:00 mathias dufresne <infractory at gmail.com>: > More information, making me more crazy: > - ldapsearch without SASL is working from any host: > ldapsearch -D 'CN=user-ldapmodify,OU=OurUsers,DC=ad,DC=domain,dc=tld' -w > Passw0rd -x -ZZ -b 'dc=ad,DC=domain,dc=tld' -h dc106 > sAMAccountName=administrator dn > > - ldapsearch with SASL is not working (Kerberos ticket existing following > a working kinit) from any host but it works when launched from the > non...

We have dovecot-1:2.3.3-1.fc29.x86_64 running on Fedora 29. I'd like to test wforce, from https://github.com/PowerDNS/weakforced. I see instructions at the Authentication policy support page, https://wiki2.dovecot.org/Authentication/Policy I see the Required Minimum Configuration: auth_policy_server_url = http://example.com:4001/ auth_policy_hash_nonce = localized_random_string But when I