FOG/Apache PKI/Certificate Authentication
-
@ty900000 I’ve had a bit of time last night. Though not as much to really get to a final conclusion. As far as I see there is no chance you can allow for an “automatic login using client certificate” without altering the FOG core code. In processlogin.class.php on line 246 there is a check for a so called POST variable. This is only being set when the login form is sent off via a POST request and would not be triggered by a simple page load (GET request) with client certificate.
I will play with this and think about it a little more. I’d hope we can get this to a stage where other people can use it too. I’d think that it’s not a great idea to directly modify the LDAP plugin code and add PKI auth because many people use LDAP without PKI.
-
@Sebastian-Roth said in FOG/Apache PKI/Certificate Authentication:
I’d think that it’s not a great idea to directly modify the LDAP plugin code and add PKI auth because many people use LDAP without PKI.
Right, I agree. As for the LDAP plugin-specific code, there is only one line I have modified. That is line 444 in https://github.com/FOGProject/fogproject/blob/master/packages/web/lib/plugins/ldap/class/ldap.class.php#L444. I have commented it out so it will not attempt to rebind if there is a bind user defined in the LDAP configuration. The rest of it is core FOG code modification, but I have added checks to everything to see if a certificate is being passed through. If it isn’t, then the login page and login process will act as normal. (This depends on how strict SSLVerifyClient is set - require = must have cert at all times; optional = can have cert, but if not it will still allow local or LDAP login. Require breaks a few other things too that I can’t figure out how to fix, so I am not certain how viable the require setting really is.)
The only thing I have not done any checks against is the requirement of the username and password boxes on the login page. In the original FOG code, they are marked as required in the HTML section. I just removed ‘required’ since the login call, local or LDAP, won’t work without a username and password regardless.
Either way, the automatic login is just a nice to have. Not necessary if it’s too difficult to work in without rewriting the login page and mechanism. Same for the logout page. It doesn’t technically need a logout page (that says something like “you’re logged out of the system” and the user has to actually go back to the login URL rather than be redirected back to the login URL automatically), it would just be a nice to have. Not necessary at all.
Thanks for the update! Let me know if you’d like the code modifications I’ve made to see if they could be worked in, if they need revamping, or if it’s not viable in the general sense.
-
@ty900000 Yes, it’d be great if you share your changes with us. Though we probably won’t add this feature to the soon to come 1.5.8 release (only bug fixing) but to FOG 1.6…
-
@Sebastian-Roth said in FOG/Apache PKI/Certificate Authentication:
@ty900000 Yes, it’d be great if you share your changes with us. Though we probably won’t add this feature to the soon to come 1.5.8 release (only bug fixing) but to FOG 1.6…
Right, sounds good. Do you all have a preferred method as to where I can send stuff?
Thanks again everyone!
-
@ty900000 Usually opening a pull request on github is the best way. But in this case I am not exactly sure if it is. Do you have an account with github.com yet? Do you know how to fork our project and send a pull request?
-
I think I managed to do it properly. Let me know if I need to change anything. Thanks!
-
Looks like everything is happy on Github. I see Mr. Tom Elliott has take a quick look at it already.
While that is being looked over and decided on what updates I need to make, I wanted to reach out and see if anyone could help me with the iPXE issue I am still having. If I try to boot iPXE over HTTPS, I get this error http://ipxe.org/err/1c0de8. I don’t know if iPXE technically needs HTTPS? Does that mean the imaging process is unencrypted?
Thanks to everyone for the assistance! I really appreciate all the hard work!
-
@ty900000 Tom Elliott is FOG’s senior developer.
I just send a few more comments.About the iPXE issue. I think what you are running into is described here as well: https://forums.fogproject.org/topic/12768/not-able-to-tftp-boot-invalid-argument-error
Probably best if we use this forum thread to discuss this iPXE issue to keep things sorted. Read through the whole thread and also check out my posts in the iPXE forums and on the developers mailing list. Unfortunately they haven’t been very active over the last months/year and we’d probably need to fix this ourselves and send in a pull request. Last year I have spent some ours to try and fix this but it’s just over my head and time budged right now.
-
Yes! I’ve seen Mr. Elliott around everywhere on these forums offering his wisdom for years.
I read over that forum post about iPXE and it does seem like you did run into a specific issue and then iPXE (the organization) got busy or disappeared. I have an idea after reading over some iPXE documentation, but I have a question first. When I run buildipxe.sh and it makes the new files and then copies them to the right directories, do I have to restart any services for that to take effect?
The reason I ask is because I modified buildipxe.sh and completely removed the BUILDOPTS from all four make calls (BIOS and EFI, regular and 10secdelay). So, the iPXE that gets created should not have custom certificates loaded into it, right? If that’s true, I am seeing some weird behavior. Even when I reboot the FOG server, attempt to iPXE boot, it fails and I hop into the iPXE shell, I run a certstat and it still displays my custom CA certificates as being [PERMANENT]. That shouldn’t be happening?
-
@ty900000 said:
When I run buildipxe.sh and it makes the new files and then copies them to the right directories, do I have to restart any services for that to take effect?
No restart needed but you need to manually copy the binaries from
fogproject-source/packages/tftp/to/tftpboot/directory! -
Gotcha. Yeah, I feel foolish. I apologize!
I had an idea based off this webpage: http://ipxe.org/crypto#embedded_certificates. I noticed in the client certificate section when making ipxe you can add in a client certificate and its private key. I attempted to do this in various ways, but never got it to work. It did load the client certificate and the chain of CAs, but I still got the same error (http://ipxe.org/err/1c0de8). I saw you previously attempted to comment out the offending lines and then got a “cert too big” error.
The weird thing is I could use the certstore command and the HTTP address of my OCSP server and pull in a random certificate (just to verify) and the command did connect and pull in the certificate. So, there is definitely something strange with iPXE, HTTPS, and connecting to itself.
That was the only idea I really had, unfortunately. I don’t know where to go next or if it should just be counted as a loss.
-
@ty900000 said in FOG/Apache PKI/Certificate Authentication:
That was the only idea I really had, unfortunately. I don’t know where to go next or if it should just be counted as a loss.
Good question. I would think that someone with a little bit of C programing skills and a fair amount of time could work this out for sure. I just lack the time to work on this. Do you know anyone who’d be keen? I can post all the details I know and give hints when needed.
-
@Sebastian-Roth said in FOG/Apache PKI/Certificate Authentication:
Do you know anyone who’d be keen?
No, unfortunately I don’t know anyone who is a C programmer. Most of the people I work with are .NET programmers… But, I can ask around to see if there are any other people on different teams who work with C.
I know you guys are super busy and this isn’t super important, so no worries!
-
Yes, sir! My apologies for not doing this sooner.
https://forums.fogproject.org/topic/14116/development-fog-not-capturing-image-partclone-update