Open arthepsy opened 4 years ago
Thanks. I will take a look. For something like the csd wrapper, should I put that in the openconnect args?
Yes, that's correct.
Getting
Traceback (most recent call last):
File "./gp-okta.py", line 964, in <module>
sys.exit(main())
File "./gp-okta.py", line 886, in main
_, userauthcookie, gateways = paloalto_getconfig(conf, s, saml_username, prelogin_cookie)
File "./gp-okta.py", line 745, in paloalto_getconfig
conf.add_cert(cert)
File "./gp-okta.py", line 228, in add_cert
self.certs_fh.write(cert)
File "/usr/lib/python3.8/tempfile.py", line 474, in func_wrapper
return func(*args, **kwargs)
After an SMS or an interactive TOTP. I put my gateway in the same as before. gateway = gw.xyz.com
Also, I tried doing the initial TOTP secret for okta and it doesn't seem to work. I'm guessing it's the f=xxxxxxxxxxxxxxxxxxxx argument in the QR code.
Manjaro + Openconnect 8.05, python 3.8.2, no unbound
This worked with the previous version.
What is the actual exception you got? It should be right after the traceback.
@gunslingerfry error doesn't seem to be related to config or anything You described. seems like a general issue. It fails when trying to write certificate to temporary file or file You specified in configuration. But, yes, I would need to see a full error message.
Whoops. Not sure how I missed that.
TypeError: a bytes-like object is required, not 'str'
@gunslingerfry could You try latest-commit and see if that works? If not, please, provide a full error.
Thanks for merging my changes and improving it even further! Wonderful that we are now reducing the variety of forks!
I am just trying to use your new, consolidated version and to abandon my own.
I saw that in commit 9eea095bda5d5def53290b445e3ab30b9abd32ca you reworked the certificate parts.
Now we have a vpn_cli_cert
and a okta_cli_cert
.
From reading the code I see that you use the okta_cli_cert
in all of the python parts and vpn_cli_cert
(only) for the final openconnect call.
This is confusing.
The python part is connecting to the vpn_url (portal & Gateway) and also to the okta_url (3rd Party service).
Especially in my case only vpn_url
is really using and checking client certificates, okta does not know anything about our CA, But I now need to set okta_cli_cert
to present my certificate to the gateway?
Is Okta really checking anyones client certificates? Is that a feature? At least for me they never asked for any client certificates.
If you would like to keep the newliy introduced separation I would suggest to rename
vpn_cli_cert
and a okta_cli_cert
to
vpn_cli_cert
-> openconnect_cli_cert
okta_cli_cert
-> ??? (maybe gp-okta_cli_cert?)
Maybe you have some idea?
At least having to set okta_cli_cert
to present it to vpn_url
seems not intuitive?
One more, sorry ...
That here:
is not working for me. for some reason it is no separate command? My openconnect complains that it does not know anything about a "-f"
Commenting out the two lines makes openconnect start & connect! Can you please rework the deletion?
It seems to be needed now as the file is not automagically deleted anymore: and was introduced in commit 9eea095bda5d5def53290b445e3ab30b9abd32ca
Just to document:
What I needed to do to make your merged version work for me is:
move my openconnect_certs = xxx
option to certs = xxx
in my conf
set my former client_cert = yyy
option as both vpn_cli_cert = yyy
and okta_cli_cert = yyy
in my conf (removing my old client_cert = yyy
) [see my comment above]
add a new option gateway_url = zzz
basically duplicating my old, existing gateway = zzz
option, so now I have
gateway = vpn-someplace.company.com
gateway_url = https://vpn-someplace.company.com
comment out lines 927 and 928 [see comment above]
Thanks for merging my changes and improving it even further! Wonderful that we are now reducing the variety of forks!
I am just trying to use your new, consolidated version and to abandon my own.
Yes, I want to merge everything, improve it, get You guys test it, and release 1.00, so it can be referenced.
I saw that in commit 9eea095 you reworked the certificate parts.
Now we have a
vpn_cli_cert
and aokta_cli_cert
.From reading the code I see that you use the
okta_cli_cert
in all of the python parts andvpn_cli_cert
(only) for the final openconnect call.This is confusing.
I was going with comment from https://github.com/aclindsa/pan-globalprotect-okta/pull/1#issuecomment-499841729 ... and trying to make it future-proof.
So, basically, we have a client certificate for connecting to OKTA (python requests). And other client certificate to which authenticate portal/gateway with (which is passed in command-line to openconnect). They are two different certificates, right?
The python part is connecting to the vpn_url (portal & Gateway) and also to the okta_url (3rd Party service).
Especially in my case only
vpn_url
is really using and checking client certificates, okta does not know anything about our CA, But I now need to setokta_cli_cert
to present my certificate to the gateway?Is Okta really checking anyones client certificates? Is that a feature? At least for me they never asked for any client certificates.
I see the issue now. We have 5 different connections: 1) to OKTA in Python script 2) to PORTAL in Python script 3) to GATEWAY in Python script 4) to PORTAL in command-line 5) to GATEWAY in command-line
If you would like to keep the newliy introduced separation I would suggest to rename
vpn_cli_cert
and aokta_cli_cert
tovpn_cli_cert
->openconnect_cli_cert
okta_cli_cert
-> ??? (maybe gp-okta_cli_cert?) Maybe you have some idea?At least having to set
okta_cli_cert
to present it tovpn_url
seems not intuitive?
I was going with same naming scheme as _url.
So okta_url
will be provided okta_cli_cert
and vpn_url
withh be provided vpn_cli_cert
. Doesn't that seem sane?
Only thing seem to fix code, where to use each certificate. Currently it wrongly uses okta_cli_cert
for communication with portal/gateway in Python script.
Do You agree?
One more, sorry ...
That here:
is not working for me. for some reason it is no separate command? My openconnect complains that it does not know anything about a "-f"
Good point. Didn't test this part. Will check and issue fix.
Commenting out the two lines makes openconnect start & connect! Can you please rework the deletion?
It seems to be needed now as the file is not automagically deleted anymore: and was introduced in commit 9eea095
File is not deleted, because it is passed as command-line option (-cafile
) to openconnect
. How otherwise openconnect
would use it, if it was deleted? Maybe if it's piping (printf ... | ./openconnect
), then while pipe is open, all would be good. But if somebody wants to not use execute
flag, and executes manually? File is gone. Therefore it mustn't be deleted. Don't You agree?
Unfortunately our VPN doesn't have client certificates and I can only go by pull request comments and sane ideas, but not able to test. Do You have client certificate VPN You can test with?
- add a new option
gateway_url = zzz
basically duplicating my old, existinggateway = zzz
option, so now I havegateway = vpn-someplace.company.com gateway_url = https://vpn-someplace.company.com
I don't even get this worked for You before. I commented my issues in pull request. Gateway is named and can be passed (I will rework it to be in such way) either in command-line as authgroup
or in execution. But never as URL.
How did You execute it before and how did it work? If it connected directly to gateway (_url), fine, but then, when it passed in pipe, e.g., printf cookie|gateway_url
... that shouldn't have worked. Baffles me.
Edit: Ok, got it. You authenticated against gateway and therefore, passing anything after cookie
is just ignored, be it gateway or any other garbage.
@arthepsy missed your reply. I'll try to check this today.
@coldcoff do You know what certificates are returned in "getconfig" request, where responding SAML could contain //root-ca/cert
? I'm assuming it's only for gateways, but want to make sure.
Looks like you've got 'command' instead of the actual command at line 955.
File "./gp-okta.py", line 992, in <module>
sys.exit(main())
File "./gp-okta.py", line 955, in main
p = subprocess.Popen(['command', '-v', openconnect_bin], stdin=subprocess.PIPE, stdout=fnull, stderr=subprocess.STDOUT)
File "/usr/lib/python3.8/subprocess.py", line 854, in __init__
self._execute_child(args, executable, preexec_fn, close_fds,
File "/usr/lib/python3.8/subprocess.py", line 1702, in _execute_child
raise child_exception_type(errno_num, err_msg, err_filename)
FileNotFoundError: [Errno 2] No such file or directory: 'command'```
Looks like you've got 'command' instead of the actual command at line 955.
File "./gp-okta.py", line 992, in <module> sys.exit(main()) File "./gp-okta.py", line 955, in main p = subprocess.Popen(['command', '-v', openconnect_bin], stdin=subprocess.PIPE, stdout=fnull, stderr=subprocess.STDOUT) File "/usr/lib/python3.8/subprocess.py", line 854, in __init__ self._execute_child(args, executable, preexec_fn, close_fds, File "/usr/lib/python3.8/subprocess.py", line 1702, in _execute_child raise child_exception_type(errno_num, err_msg, err_filename) FileNotFoundError: [Errno 2] No such file or directory: 'command'```
Wow. You don't have command
utility? Which OS and shell You're using, @gunslingerfry ? Can You test that in the shell:
command -v openconnect
I do have command it looks like. (Sorry, I've never used that utility before)
$ command -v openconnect
/usr/bin/openconnect
I'm slightly above the python experience level of 'knows what python is' but I tried os.system('command -v openconnect')
and it works fine but subprocess.Popen doesn't.
@gunslingerfry seems interesting. Would like to reproduce such error. Can You share what is the shell, where You execute that script? Never seen such issue.
Anyhow, I will removed that part and re-worked it in a different way. Please, re-check.
@coldcoff @gunslingerfry @cardonator I've made another several rounds of improvements. Would be nice if You could check it out and give feedback. Trying to release 1.00 ;)
To https://github.com/arthepsy/pan-globalprotect-okta/issues/21#issuecomment-633650409
They are two different certificates, right?
Yes. at least they could be. Or only one service uses certificates.
Do You agree?
Yes.
To https://github.com/arthepsy/pan-globalprotect-okta/issues/21#issuecomment-633651647
File is not deleted, because it is passed as command-line option (-cafile) to openconnect. How otherwise openconnect would use it, if it was deleted?
In the previous code the temp file existed as long as the python object holding/referencing it existed (which is basically the runtime of gp-okta.py
.) (see: https://docs.python.org/2/library/tempfile.html)
So it elegantly was also still there when python is calling the subcommand to start openconnect, because at that time the python script and the temp file object are still "alive".
You are right, this won't work in the execute = 0
case, this was an oversight. I did not realize, because I have a concrete file name (~/etc/openconnect/openconnect.certs
) in my gp-okta.conf
.
Do You have client certificate VPN You can test with?
Yes. Happy to test for you anytime!
To https://github.com/arthepsy/pan-globalprotect-okta/issues/21#issuecomment-633680982
You know what certificates are returned in "getconfig" request, where responding SAML could contain //root-ca/cert? I'm assuming it's only for gateways, but want to make sure.
For me it's the certs that both, portal and gateway use. In fact no new content compared to what is already in vpn_url_cert
. Our companies root ca and the digicert chain. I assume this is for the gateways, yes. But as portal & gateway is basically two modes of the same "product" probably there won't be differences. But (chicken & egg ...) you need to connect to the portal to issue the getconfig request :-)
https://github.com/arthepsy/pan-globalprotect-okta/issues/21#issuecomment-633711325
command
is a bash builtin to ensure that you call real "commands", no functions or aliases or such (see: help command
). So when you use pythons subprocess.Popen
then you don't need command
, because that's what the Popen does.
It would work with subprocess.Popen(..., shell=True, ...)
though, when you enforce the command to be executed in a shell. Best is to remove the command
here and not assume anything about a users shell. If a user really needs a special prefix he can tune his openconnect_cmd
.
https://github.com/arthepsy/pan-globalprotect-okta/issues/21#issuecomment-633775197
@coldcoff... I've made another several rounds of improvements. Would be nice if You could check it out and give feedback. Trying to release 1.00 ;)
Will do.
File is not deleted, because it is passed as command-line option (-cafile) to openconnect. How otherwise openconnect would use it, if it was deleted?
In the previous code the temp file existed as long as the python object holding/referencing it existed (which is basically the runtime of
gp-okta.py
.) (see: https://docs.python.org/2/library/tempfile.html) So it elegantly was also still there when python is calling the subcommand to start openconnect, because at that time the python script and the temp file object are still "alive". You are right, this won't work in theexecute = 0
case, this was an oversight. I did not realize, because I have a concrete file name (~/etc/openconnect/openconnect.certs
) in mygp-okta.conf
.
I reworked it to delete it automatically if execute=1
, otherwise file is not deleted and rm -f
command is outputted.
@coldcoff... I've made another several rounds of improvements. Would be nice if You could check it out and give feedback. Trying to release 1.00 ;)
Will do.
Would be awesome!
xxx_cli_cert
-> could we probably rename that to xxx_client_cert
?
At least I always understand "cli" as "commandline", not "client" in my abbreviation 1st level cache.
gateway = vpn-someplace.company.com
gateway_url = https://vpn-someplace.company.com
I understand that for you thi rule does not apply, but could you probably add a shortcut that gateway_url
can be automatically constructed from gateway
if unset?
Note: I am still able to connect after all of your recent changes yesterday and today, using the current HEAD.
gateway = vpn-someplace.company.com gateway_url = https://vpn-someplace.company.com
I understand that for you thi rule does not apply, but could you probably add a shortcut that
gateway_url
can be automatically constructed fromgateway
if unset?
That would not make sense. How would that work? For example, my gateway is named "FRANKFURT". What domain should I add? For others, also, that is only a name, not URL and in most cases, not even related to URL.
gateway
is Gateway name (see openconnect --authgroup
option). gateway_url
is URL to direct connect to gateway.
By the way, in Your case, when You use gateway_url
, You don't need gateway
. That is the reason it worked for You before (where pull request wrongly reworked gateway only for that case).
xxx_cli_cert
-> could we probably rename that toxxx_client_cert
?At least I always understand "cli" as "commandline", not "client" in my abbreviation 1st level cache.
Heh, good note. Now when You mention it, I also have seen "cli' as "command-line", but in server/client context, usually I see "srv" and "cli. Anyway, I wanted to make config name in same lines as in _url_
, i.e., 3-letter. Anyhow, it's documented in .conf
, so it wouldn't make any confusion.
Note: I am still able to connect after all of your recent changes yesterday and today, using the current HEAD.
Does it work with certificate authentication and verification? If so, then all seems great and pretty much ready for release.
I was able to test 1) direct gateway config 2) simple portal config 3) second auth dance 4) cert verification. I am not able to test client certificates.
I corrupted my vpn_url_cert
(copied okta_url_cert
over it) to force a failure.
Bad: The connection is still established.
The get_verify
just returns True for the prelogin request.
Please consider the following patch:
diff --git a/gp-okta.py b/gp-okta.py
index 4eb2467..a107fa1 100755
--- a/gp-okta.py
+++ b/gp-okta.py
@@ -260,8 +260,11 @@ class Conf(object):
return self._store['okta_url_cert']
if name == 'portal' and 'vpn_url_cert' in self._store:
return self._store['vpn_url_cert']
- if name == 'gateway' and self._ocerts:
- return self.certs
+ if name == 'gateway':
+ if self._ocerts:
+ return self.certs
+ elif 'vpn_url_cert' in self._store:
+ return self._store['vpn_url_cert']
return default_verify
def get_line(self, name):
otherwise a malicious gateway can inject arbitrary self._ocerts
via a faked getconfig response.
Now it fails, as expected:
requests.exceptions.ConnectionError: HTTPSConnectionPool(host='vpn-someplace.company.com', port=443): Max retries exceeded with url: /ssl-vpn/prelogin.esp (Caused by SSLError(SSLError("bad handshake: Error([('SSL routines', 'ssl3_get_server_certificate', 'certificate verify failed')],)",),))
I corrupted my
vpn_url_cert
(copiedokta_url_cert
over it) to force a failure.Bad: The connection is still established. The
get_verify
just returns True for the prelogin request.Please consider the following patch:
diff --git a/gp-okta.py b/gp-okta.py index 4eb2467..a107fa1 100755 --- a/gp-okta.py +++ b/gp-okta.py @@ -260,8 +260,11 @@ class Conf(object): return self._store['okta_url_cert'] if name == 'portal' and 'vpn_url_cert' in self._store: return self._store['vpn_url_cert'] - if name == 'gateway' and self._ocerts: - return self.certs + if name == 'gateway': + if self._ocerts: + return self.certs + elif 'vpn_url_cert' in self._store: + return self._store['vpn_url_cert'] return default_verify def get_line(self, name):
otherwise a malicious gateway can inject arbitrary
self._ocerts
via a faked getconfig response.Now it fails, as expected:
requests.exceptions.ConnectionError: HTTPSConnectionPool(host='vpn-someplace.company.com', port=443): Max retries exceeded with url: /ssl-vpn/prelogin.esp (Caused by SSLError(SSLError("bad handshake: Error([('SSL routines', 'ssl3_get_server_certificate', 'certificate verify failed')],)",),))
I don't understand Your description in context with patch. If You changed vpn_url_cert
, then it is verified in line before:
if name == 'portal' and 'vpn_url_cert' in self._store:
return self._store['vpn_url_cert']
Wait, do You expect vpn_url_cert
to be verified, when You use gateway_url
? It won't. It's written in configuration description. vpn_url_cert
is verified only for vpn_url
. If You want to verify gateway_url
, then create any *_cert
, e.g., my_super_gateway_cert=...
and it will be verified.
When You use gateway_url
, then vpn_url_cert
is ignored at all.
My first (and only) contact is the gateway (due to my config)!
[INFO] load conf [INFO] prelogin request [gateway_url] [INFO] okta saml request [okta_url] [INFO] okta auth request [okta_url] [INFO] sessionToken: XXX [INFO] okta redirect request 1 [okta_url] [INFO] stateToken: YYY [INFO] okta auth request [okta_url] [INFO] mfa fido challenge request [okta_url]
!!! Touch the flashing U2F device to authenticate... !!!
@coldcoff check my comments before. You need other _cert
defined and it will work.
OK, understood.
Well, I can't test really as I wanted - because the returned self.certs will contain the union of all certs, so it will not look for my corrupted my_super_gateway_cert
alone.
But indeed, if I explicitely delete vpn_url_cert
then it fails.
Ship it :-) If I advertise here locally, you will soon get ~ 20-30 users.
I'll need to write up some "How-to-Update" document for them (for the gp-okta.conf
)
@lvml - could you please test as well and give your opinion?
Ship it :-) If I advertise here locally, you will soon get ~ 20-30 users. I'll need to write up some "How-to-Update" document for them (for the
gp-okta.conf
)
Yay, would be great. Also, not keeping different forks. I'll test one feature (gpg) in Your pull request and then ship it.
Just wanted to let you know that the latest version doesn't work with my portal at all now :)
Just wanted to let you know that the latest version doesn't work with my portal at all now :)
Oh, come on :) What's the issue? Can't imagine. Please, provide a error message and description.
Haha! I was trying to figure out what's going on but this one keeps stumping me.
Basically, every time I try to connect I'm getting that 512 error again.
[INFO] gateway: https://gatewayurl
[INFO] saml-username: corp\myusername
[INFO] prelogin-cookie: <prelogin cookie>
POST https://gatewayurl/global-protect/prelogin.esp?tmp=tmp&clientVer=4100&clientos=Linux
Connected to <gatewayIP>
SSL negotiation with gatewayurl
Connected to HTTPS on gatewayurl
SAML login is required via POST to this URL:
<html>
<body>
<form id="myform" method="POST" action="https://oktadomain/app/panw_globalprotect/oktatoken/sso/saml">
<input type="hidden" name="SAMLRequest" value="<samltoken>" />
<input type="hidden" name="RelayState" value="<relaytoken>" />
</form>
<script>
document.getElementById('myform').submit();
</script>
</body>
</html>
Enter login credentials
POST https://gatewayurl/global-protect/getconfig.esp
Got HTTP response: HTTP/1.1 512 Custom error
Unexpected 512 result from server
SAML login is required via POST to this URL:
<html>
<body>
<form id="myform" method="POST" action="https://oktadomain/app/panw_globalprotect/oktatoken/sso/saml">
<input type="hidden" name="SAMLRequest" value="<samltoken>" />
<input type="hidden" name="RelayState" value="<relaytoken>" />
</form>
<script>
document.getElementById('myform').submit();
</script>
</body>
</html>
Enter login credentials
Username: portal-userauthcookie:
fgets (stdin): Inappropriate ioctl for device
For reference, if I switch back to coldcoff's master PR, I am able to connect without issue. I am also able to connect on the merge commit from #19. Something since then has broken my ability to connect.
@cardonator where is this error from? Seems packed from multiple sources. Doesn't look like either Python script or openconnect output. Could You reformat it a bit? What's the command-line and printf pipe contents?
Your description seems that it's somehow providing wrong cookie to portal or gateway (don't know Your config) for some reason. Can't think of reason, though. What's your config, i.e., are You connecting to portal, gateway, doing another dance, etc? Is another_dance
or gateway_url
configured?
@arthepsy Alright. I tested with the current head (b637ea902832e4d6d3b6f610456188207a832081) with SMS, push, and TOTP entry and all work perfectly. THANKS!!!
The vpnc script is failing to set a route of some sort, the ip command returns Error: ipv4: Invalid values in header for route get request.
then dumps the help for ip route. It doesn't seem to fail to connect or split and it has been like this since I started using this project.
@gunslingerfry awesome! I was thinking it should be pretty much perfect now.
Regarding vpnc
script, that's a thing You should figure out, if interested. Don't recall such issues.
@cardonator where is this error from? Seems packed from multiple sources. Doesn't look like either Python script or openconnect output. Could You reformat it a bit? What's the command-line and printf pipe contents?
This is literally every message that is printed out after finishing the Okta handshake. I can set execute to 0 to see what command it constructed. It might be helpful to note that I was also always getting this error on this repo without coldcoff changes prior to merge, so this is the same behavior I had over a week ago.
Your description seems that it's somehow providing wrong cookie to portal or gateway (don't know Your config) for some reason. Can't think of reason, though. What's your config, i.e., are You connecting to portal, gateway, doing another dance, etc? Is
another_dance
orgateway_url
configured?
my config looks like this:
debug = 0
vpn_url = https://gatewayurl/
#vpn_url_cert = vpn_url.cert
okta_url = https://digicert.okta.com
#okta_url_cert = okta_url.cert
username = myusername
password = mypassword
#client_cert = path-to-myusers-client-cert-as-unencrypted-pem-file.pem
mfa_order = push
#sms.okta = 0
#totp.okta = ABCDEFGHIJKLMNOP
#totp.google = ABCDEFGHIJKLMNOP
#totp.symantec = ABCDEFGHIJKLMNOP
gateway = gatewayname # optional hardcoded gateway
openconnect_cmd = "sudo openconnect"
#openconnect_certs = path-to-a-writeable-filename-in-which-the-script-will-collect-all-involved-server-certs-if-not-set-a-temp-file-is-used-instead
openconnect_args = "--csd-wrapper=hipreport.sh" # optional arguments to openconnect
execute = 1 # execute openconnect command
another_dance = 0 # second round of authentication required
bug.nl = 0 # newline work-around for openconnect
bug.username = 0 # username work-around for openconnect
To clarify, this exact config works on coldcoff-master but not on actual master.
I am vaguely remembering something, though. I did have an issue at one point where the settings were making the cookie get passed as portal:portal-userauthcookie
but my portal wanted gateway:prelogin-cookie
instead. That went away on the coldcoff branch at some point, though. (I just tried forcing it both ways and it had no effect)
Ok, I'm wrong, it's not the vpnc script, I think openconnect is doing this. I'll check in at the openconnect repo to see if that's been reported.
I am getting this after shutting down though. Logout successful
is what I'm used to seeing.
Invalid user name
Logout failed.
Ok, I'm wrong, it's not the vpnc script, I think openconnect is doing this. I'll check in at the openconnect repo to see if that's been reported. I am getting this after shutting down though.
Logout successful
is what I'm used to seeing.Invalid user name Logout failed.
I would suggest creating simple vpnc
scripts and figuring it out. Example:
#!/bin/sh
env
@cardonator I commited Python3 fixes and new feature (to support newer openconnect version). Is everything working as expected now? P.S. Please check modified
.conf
.