I'm trying to configure Freeradius to make a REST call to authenticate users in the inner tunnel.
Without the REST call, I have user bob in the users file and the entry
bob Cleartext-Password := "test"
This by itself works as expected when the test user tries to authenticate.
Now, I have configured the REST endpoint to return the json:
{
"Cleartext-Password": "test"
}
and I have changed the config in inner-tunnel:
authorize {
...
rest
# files
...
}
authenticate {
...
Auth-Type MS-CHAP {
mschap
}
Auth-Type rest {
rest
}
...
This fails, and the relavant logs are:
2020-09-22T16:14:30.698-04:00 (7) rest: Status : 200 (OK)
2020-09-22T16:14:30.698-04:00 (7) rest: Type : json (application/json)
2020-09-22T16:14:30.698-04:00 (7) rest: Parsing attribute "Cleartext-Password"
2020-09-22T16:14:30.698-04:00 (7) rest: EXPAND test
2020-09-22T16:14:30.698-04:00 (7) rest: --> test
2020-09-22T16:14:30.698-04:00 (7) rest: Cleartext-Password := "test"
2020-09-22T16:14:30.703-04:00 (7) [rest] = updated
2020-09-22T16:14:30.703-04:00 (7) [expiration] = noop
2020-09-22T16:14:30.703-04:00 (7) [logintime] = noop
2020-09-22T16:14:30.703-04:00 (7) [pap] = noop
2020-09-22T16:14:30.703-04:00 (7) } # authorize = updated
2020-09-22T16:14:30.703-04:00 (7) Found Auth-Type = mschap
2020-09-22T16:14:30.703-04:00 (7) # Executing group from file /etc/freeradius/sites-enabled/inner-tunnel
2020-09-22T16:14:30.703-04:00 (7) authenticate {
2020-09-22T16:14:30.703-04:00 (7) mschap: WARNING: No Cleartext-Password configured. Cannot create NT-Password
I'm sure what I'm missing here is quite simple, but I'm a radius noob and this is as far as I've managed to get by fiddling around.
Found the issue! Apparently the returned json needed a small tweak.
Instead of:
{
"Cleartext-Password": "test",
}
It should have been:
{
"control:Cleartext-Password": "test",
}
I found this buried in an answer to a related question (https://stackoverflow.com/a/57662829/2345647)
If anyone can point me to documentation that states this and maybe even explains why, I will upvote you so hard.
Related
I have a service A and B. I am running up keycloak service in the same container with service A.
So, configs for service A are the following:
[app]
PageSize = 10
JwtSecret = 233
PrefixUrl = http://127.0.0.1:8000
[sso]
Host = http://127.0.0.1:8080
AdminLogin = some_admin
AdminPassword = some_password
Realm = master
ClientID = my_client
ClientSecret = XXX
I set up a middleware that validates JWT (gotten by keycloak) in service A and it successfully works out.
I run service B in another container with this config:
[app]
PageSize = 10
JwtSecret = 233
PrefixUrl = http://127.0.0.1:8002
[sso]
Host = http://172.18.0.1:8080
AdminLogin = some_admin
AdminPassword = some_password
Realm = master
ClientID = my_client
ClientSecret = XXX
You have noticed that I couldn't use 127.0.0.1 in B's config because it cannot dial this address (because keycloak is running with A in the same container).
I use the same JWT in the request header for service B. After that it goes to keycloak and gets:
{
"code": "ERROR_AUTH_CHECK_TOKEN_FAIL",
"context": {
"code": 401,
"message": "401 Unauthorized: invalid_token: Token verification failed",
"type": "unknown"
}
}
Am I right that keycloak detects the proxing somehow and the error is thrown because of that?
Should I use separate clients for keycloak for both services? And if it is so, how do I verify JWT gotten from service A in the B service?
I solved my problem. Ticket that I got from A had the issuer host http://127.0.0.1:8080 and B sent a header with the host http://172.18.0.1:8080 that failed token validation. Briefly, these hosts must be the same
I've looked through the list of possible solutions, but I don't see this problem, here it is.
I had been using smtp for years for my crontab entry to provide status updates via email. Then it quit this week, and I was unable to fix it. Then I saw that it had become orphaned, and the suggestion was to move to msmtp. So I downloaded and installed it on my Ubuntu 18.10 system.
I'm trying to send email to my myaccount#gmail.com account.
It appears that I'm communicating properly with the gmail smtp server, as the debug below show. But it always gets a TLS Timeout.
I also don't understand why I have multiple EHLO entries. My system does not have a DNS domain name, so that I'm not sure what to put here; localhost seems to be working OK. Also, my Thunderbird emailer is working correctly with gmail.
Here's the debug output:
echo "Hello there" | msmtp --debug myaccount#gmail.com >/tmp/msmtpOut.txt
ignoring system configuration file /etc/msmtprc: No such file or directory
loaded user configuration file /home/myhome/.msmtprc
falling back to default account
using account default from /home/myhome/.msmtprc
host = smtp.gmail.com
port = 587
proxy host = (not set)
proxy port = 0
timeout = off
protocol = smtp
domain = localhost
auth = choose
user = myaccount
password = *
passwordeval = (not set)
ntlmdomain = (not set)
tls = on
tls_starttls = on
tls_trust_file = /etc/ssl/certs/ca-certificates.crt
tls_crl_file = (not set)
tls_fingerprint = (not set)
tls_key_file = (not set)
tls_cert_file = (not set)
tls_certcheck = on
tls_min_dh_prime_bits = (not set)
tls_priorities = (not set)
auto_from = off
maildomain = (not set)
from = myaccount#gmail.com
add_missing_from_header = on
dsn_notify = (not set)
dsn_return = (not set)
logfile = (not set)
syslog = (not set)
aliases = (not set)
reading recipients from the command line
<-- 220 smtp.gmail.com ESMTP 4sm116524ywc.22 - gsmtp
--> EHLO localhost
<-- 250-smtp.gmail.com at your service, [71.56.87.81]
<-- 250-SIZE 35882577
<-- 250-8BITMIME
<-- 250-STARTTLS
<-- 250-ENHANCEDSTATUSCODES
<-- 250-PIPELINING
<-- 250-CHUNKING
<-- 250 SMTPUTF8
--> STARTTLS
<-- 220 2.0.0 Ready to start TLS
TLS certificate information:
Owner:
Common Name: smtp.gmail.com
Organization: Google LLC
Locality: Mountain View
State or Province: California
Country: US
Issuer:
Common Name: Google Internet Authority G3
Organization: Google Trust Services
Country: US
Validity:
Activation time: Tue 21 May 2019 04:48:45 PM EDT
Expiration time: Tue 13 Aug 2019 04:32:00 PM EDT
Fingerprints:
SHA256: C7:78:B6:D6:4E:3E:2B:2F:08:6D:A4:84:E6:1D:87:8E:A1:DF:54:D2:AB:79:AC:A6:BB:50:E5:5D:EC:B4:20:4C
SHA1 (deprecated): 39:C5:E5:40:64:37:17:25:17:7F:E8:BA:20:F4:70:F4:FE:22:70:22
--> EHLO localhost
msmtp: cannot read from TLS connection: the operation timed out
msmtp: could not send mail (account default from /home/myhome/.msmtprc)
Build msmtp using --with-tls=openssl to solve the problem.
As regards as the EHLO command sent twice the RFC3207 states:
The server MUST discard any knowledge
obtained from the client, such as the argument to the EHLO command,
which was not obtained from the TLS negotiation itself. The client
MUST discard any knowledge obtained from the server, such as the list
of SMTP service extensions, which was not obtained from the TLS
negotiation itself. The client SHOULD send an EHLO command as the
first command after a successful TLS negotiation.
So that is the normal behaviour.
I have configured a freeradius proxy (3.0.16) on Ubuntu (4.15.0-47-generic). It receives the radius accounting packets from another radius server running on Ubuntu and writes those to another radius server on running on Fortigate.
Radius Server ---> Proxy Radius Server ---> Fortigate Radius Server
I have configured copy-acct-to-home-server to include the Realm in proxy.conf
proxy.conf ( Realm definition )
home_server myFortigate {
type = acct
ipaddr = <IP address of Fortigate Interface Running Radius>
port = 1813
secret = superSecret
}
home_server_pool myFortigatePool {
type = fail-over
home_server = myFortigate
}
realm myFortigateRealm {
acct_pool = myFortigatePool
nostrip
}
copy-acct-to-home-server entry
preacct {
preprocess
update control {
Proxy-To-Realm := myFortigateRealm
}
suffix
}
After I run the freeradius -X, I also run tcpdump from a new session
tcpdump -ni eth01 port 1812 or port 1813
and get the following log
15:03:40.225570 IP RADIUS_PROXY_IP.56813 > FORTIGATE_INTERFACE_IP.1813: RADIUS, Accounting-Request (4), id: 0x31 length: 371
15:03:40.236155 IP FORTIGATE_INTERFACE_IP.1813 > RADIUS_PROXY_IP.56813: RADIUS, Accounting-Response (5), id: 0x31 length: 27
Which basically shows it is sending the account request to fortigate radius server and receiving the accounting response.
But strangely freeradius -X debug output shows a request time out for the same radius server on Fortigate and it ultimately tags the server as zombie
Starting proxy to home server FORTIGATE_INTERFACE_IP port 1813
(14) Proxying request to home server FORTIGATE_INTERFACE_IP port 1813 timeout 30.000000
Waking up in 0.3 seconds.
(14) Expecting proxy response no later than 29.667200 seconds from now
Waking up in 3.5 seconds.
and Finally it gives up
25) accounting {
(25) [ok] = ok
(25) } # accounting = ok
(25) ERROR: Failed to find live home server: Cancelling proxy
(25) WARNING: No home server selected
(25) Clearing existing &reply: attributes
(25) Found Post-Proxy-Type Fail-Accounting
(25) Post-Proxy-Type sub-section not found. Ignoring.
So the situation is the Radius proxy is sending accounting packets to Fortigate Radius server (could be seen in both freeradius and fortigate logs)
tcpdump shows that Radius proxy is receiving accounting response from the fortigate, but for some reason freeradius process doesn't recognize (or can not read) accounting response. It may be some interoperability issue or I have missed to set some flag. Requesting help from the experts to isolate and rectify the issue.
how can I configure FreeRADIUS to proxy the PAP request inside an EAP-PEAP-GTC tunnel? . I want to proxy the PAP request to another RADIUS server which understands only PAP. How could I configire freeradius for this.
Configure your proxy realm in proxy.conf
Call the eap module in the authorize section of the inner tunnel, and if the EAP module creates the User-Password attribute during the round, proxy the request.
authorize {
eap
if (&User-Password) {
update control {
Proxy-To-Realm := <realm>
}
}
}
I'm trying to login to Roundcube only the program won't let me.
I can login to the said account from the shell and mail is setup and working correctly on my server for user 'admin'. It's RC that is the problem. If I check my logs:
/usr/local/www/roundcube/logs/errors
they show:
[21-Sep-2013 17:19:02 +0100]: IMAP Error: Login failed for admin from ip.ip.ip.ip. Could not connect to ip.ip.ip.ip:143:
Connection refused in /usr/local/www/roundcube/program/lib/Roundcube/rcube_imap.php on line 184
(POST /roundcube/?_task=login&_action=login)
which doesn't give me many clues really, just leads me to:
public function connect($host, $user, $pass, $port=143, $use_ssl=null) {}
from
rcube_imap.php
Stuff I've tried, editing:
/usr/local/www/roundcube/config/main.inc.php
with:
// IMAP AUTH type (DIGEST-MD5, CRAM-MD5, LOGIN, PLAIN or null to use
// best server supported one)
//$rcmail_config['imap_auth_type'] = LOGIN;
$rcmail_config['imap_auth_type'] = null;
// Log IMAP conversation to <log_dir>/imap or to syslog
$rcmail_config['imap_debug'] = /var/log/imap;
With a failed login attempt
/var/log/imap
doesn't even get written to, leaving me no clues. I'm using dovecot and Sendmail on a FreeBSD box with full root access. It's not an incorrect username password combination for sure.
Several Googles on the string 'Roundcube: Connection to storage server failed' are fruitless.
EDIT:
I needed an entry in
/etc/rc.conf
dovecot_enable="YES"
Schoolboy error.
I had the same problem with a letsencrypt certificate and resolve it by disabling peer authentication:
$config['imap_conn_options'] = array(
'ssl' => array('verify_peer' => true, 'verfify_peer_name' => false),
'tls' => array('verify_peer' => true, 'verfify_peer_name' => false),
);
Afterwards you can set the connection string like this (starttls):
$config['default_host'] = 'tls://your-host.tld';
$config['default_port'] = '143';
$config['smtp_server'] = 'tls://your-host.tld';
$config['smtp_port'] = '25';
Or like this (ssl approach):
$config['default_host'] = 'ssl://your-host.tld';
$config['default_port'] = '993';
$config['smtp_server'] = 'ssl://your-host.tld';
$config['smtp_port'] = '587';
Make sure you use the fully qualified hostname of the certificate in the connection string (like your-host.tld) and not an internal hostname (like localhost).
Hope that helps someone else.
Change the maildir to whatever your system uses.
Change Dovecot mail_location setting to
mail_location = maildir:~/Mail
Change Postfix home_mailbox setting to
home_mailbox = Mail/
Restart services and away you go
Taken from this fedoraforum post
If you run fail2ban, then dovecot might get banned following failed Roundcube login attempts. This has happened to me twice already...
First, check if this is indeed the case:
sudo fail2ban-client status dovecot
If you get an output similar to this:
Status for the jail: dovecot
|- Filter
| |- Currently failed: 1
| |- Total failed: 8
| `- File list: /var/log/mail.log
`- Actions
|- Currently banned: 1
|- Total banned: 2
`- Banned IP list: X.X.X.X
i.e. the Currently banned number is higher than 0, then fail2ban was a bit overeager and you have to "unban" dovecot.
Run the fail2ban client in interactive mode:
sudo fail2ban-client -i
and at the fail2ban> prompt enter the following:
set dovecot unbanip X.X.X.X
where X.X.X.X is the IP address of your Dovecot server.
Exit from the interactive client and run sudo fail2ban-client status dovecot again. The Currently banned: field now should have a value of 0. What's more important, RoundCube should work again :-)
The issue is in your mail server.
Check your ports in your mail server and reset it (if necessary):
Port 25 (and 587) must be open for SMTP
Port 143 (and 993) must be open for IMAP
Port 110 must be open for POP3
Also open those ports in your firewall settings.
sudo dovecot should solve the problem.
If not restart dovecot
sudo service dovecot restart