FOG/Apache PKI/Certificate Authentication
-
@ty900000 Yes from what Sebastian said is what I found. Its in
lib/pages/processlogin.class.phprelative to the fog root directory. I searched for “form-signin” that I found on the web page using the firefox developer tools. -
Okay, I managed to figure out how to generate a random string for the password in place of user input. (I could never decouple the password form and the LDAP plugin need for a password, so it just passes it through like it always has.) I also made the Username and Password not required, so they can be left blank. Now if I press the Login button, it just uses the LDAP query to authenticate certificate UPN user is in the specified admin group in AD.
I took a look at how to completely bypass the login page after selecting a certificate. I am a little stumped on how the Login button actually does the login. Is it this line that does the login? If so, how? https://github.com/FOGProject/fogproject/blob/dev-branch/packages/web/lib/pages/processlogin.class.php#L320
I’m not so good at working with HTML code, so I don’t really understand how things do the thing they are supposed to do, i.e. a button logging a user in.
Thanks for the assistance over the past week, everyone. I truly appreciate the help and guidance!
-
@ty900000 Well what makes it a bit confusing is there is a mixture of JS, HTML and PHP code intermixed. But me (ignorantly) reading it, I just looked at the HTML. The login button is an html “submit” button L366. It then submits the html form. The html form has a javascript action attached L329 to it. It calls a javascript procedure called formAction. I don’t see the procedure formAction in any of the code on that page, so that means the procedure is being brought in through an html include some place else. I’ll have to remote into the office to my fog server to find where that is. It will be in a .js file (probably).
Edit: well I was wrong (maybe), formAction is a variable that holds a pointer to the javascript functions that gets called. This level of indirection is a bit maddening.
Edit2: Ok I’m not as smart as I thought. I thought the action may have come in through the class style sheet for “form-signin” class, but no.
-
Not much luck today. I couldn’t really decipher what the login page is doing when the button is pressed. I was thinking that, after a certificate is selected, I could figure out how to change the login page to automatically “click” the button and that would automatically call the JavaScript code. But, I could never get that far.
That would also mean when a user clicked “Logout” and it redirected back to the login page, it would automatically log back in immediately. I was thinking of adding an actual logout page that was just a basic HTML page stating the user was logged out.
There are still a number of bugs, some of which I cannot for the life of me figure out what is wrong and Googling returns zero results. On a more positive note, I did manage to get LDAPS to work. I initially had problems with it binding the server for some reason - probably certificate stuff, I’m sure.
Don’t know if anyone can offer any more guidance on how to make the login page automatically “click” the login button?
Thanks again for the assistance everyone!
-
@ty900000 I will have a bit more time next week. Will see what I can do.
-
Yeah, that’s cool. I know y’all are busy - no rush or anything. The PKI authentication works as expected, so no worries. Just a few “nice to haves” are all that’s left.
I’ve mostly been working on documenting what I’ve done and making it more generic to add to the original FOG scripts. I’m not sure if this technically needs to be a plugin - it’s more like an extension of the LDAP plugin (which has to be setup before external certificates can be used). Just throwing that out there.
Thanks again for all the assistance!!
-
@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
