Posts made by ty900000

@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.

@Sebastian-Roth

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!!

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!

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!

@george1421 said in FOG/Apache PKI/Certificate Authentication:

@ty900000 But set the field on the login page to read only and then pipe in a random password.

Okay, I will try that. Stupid question from me, where is the code that creates the page that does the username and password read?

Is it somewhere in here? https://github.com/FOGProject/fogproject/blob/dev-branch/packages/web/lib/pages/processlogin.class.php

Thanks again!!

@george1421 said in FOG/Apache PKI/Certificate Authentication:

@ty900000 Well on line 104 we are getting the text from the form. Its only used in 4 spots and one is used to check if we can bind to ad with the user id and password combo. I guess I don’t see a reason why you can’t just set it to a static (or random) value.

Without thinking about this at all, I wonder if you seeded the value on the login prompt, just type in a random password on the login form, because apache may be caching that value. During your testing will it accept any password you enter since you are not using that value for qualification of the account?

Yes, I did try manually setting line 104 to something like “testing” and FOG would not let me log in no matter what I type in the password box, even if it was the local built-in fog user/password.

If I leave line 104 alone and type in random stuff in the password box on the login page, it will pass along whatever I type in the password box. But, that means the password of the temporary user could be something really simple like ‘a’

@george1421 In my previous post I mentioned generating a random password for the login user, rather than manually typing in a password in the box at the login page. I can’t seem to figure that out. I know you said you were an originator of the LDAP plugin. Could you offer any tips on how I can change this? https://github.com/FOGProject/fogproject/blob/dev-branch/packages/web/lib/plugins/ldap/hooks/ldappluginhook.hook.php#L133

If I change the $pass variable, which is defined at line 104, in any way, the login fails. Thank you, sir!

@Sebastian-Roth said in FOG/Apache PKI/Certificate Authentication:

As mentioned using a special service account to bind to LDAP/AD is good practice and I don’t advice you to allow anonymous LDAP searches!

Right! Yeah, I would never enable anonymous LDAP searching. I’ll stick with the hardcoded bind user and set it up on a password change schedule.

For that you need to start looking at the core code.

Okay, cool. I’ve been tracking down the myriad bugs I have managed to introduce for today, so I can take a look at that code tonight and tomorrow.

Sorry I can’t give a an easy solution to this just now. Don’t have enough time.

No worries! I know you guys are busy with updating the core FOG functionality. I’ll keep at it and see what I can find.

@george1421 @Sebastian-Roth

Right, I am currently using the bindDN user to search through LDAP and commented out the rebind since there is no user/password defined with PKI certificates. I was just wondering if there was another way to search LDAP without explicitly defining a user and password. I know anonymous LDAP browsing is a thing, but that’s a huge security risk and should never be enabled in production.

@Sebastian-Roth

Still no luck with the iPXE over HTTPS… That’s something I’ll look at later. I don’t want to get too off track and overwhelmed with taking on too many things at one time.

However, I did manage to get FOG to pass through the certificate and its information. FOG prompts for a certificate, pulls the (Microsoft) UPN, and creates the temporary user with the UPN.

I have been wracking my brain all day about ways to bind to LDAP and since I’m not an expert on LDAP; I don’t know if there is a way to check LDAP without a username and password. What brought this on is: I found out the LDAP plugin does not need a bind user and password to successfully log in, it can use the entered username and password. But if a bind user is defined, it will rebind with the username and password entered on the login page. Since the certificate does not have a password, it can’t technically bind to LDAP to search through group memberships? I’m not entirely sure how other companies search through LDAP for group membership with PKI authentication.

For now, since I have to define a bind user and password, I disabled the rebind. It does work, but it’s not perfect.

Once I select a viable certificate, I still get directed to the login page. I have to enter random gibberish in the username and password boxes so it will create the temporary user with the password that was entered. I have tried in vain to change the password passthrough and generate a random password. I have a function to generate an ‘n’ length string. But when I replace the $pass variable from what what originally defined to the returned variable from the password function, FOG will not log the user in. I tried several things to replace $pass. I set it manually to something like ‘testing’ and it still wouldn’t work and then I changed the actual variable call in line 133 to a string, still no luck. https://github.com/FOGProject/fogproject/blob/dev-branch/packages/web/lib/plugins/ldap/hooks/ldappluginhook.hook.php#L133

I can’t seem to figure out how to decouple it and change it…

Also, I’d like to figure out how to completely skip the login page if a valid certificate is presented. Since the LDAP plugin needs a password to create the temporary user, I was hoping to use the randomly generated password to bypass the login page password box.

I know it’s a lot in this post and I’m sure it’s not very clear. Let me know if I’m not being clear and I can attempt to explain better.

I appreciate the assistance! Thanks again for the help and guidance. I’d never be able to figure it out with the tips and pointers of where to start digging.

@Sebastian-Roth

Yes, sir! I fully understand. I really do appreciate all the assistance. I’ll keep posting stuff as I figure it out or come up against road blocks.

I do have one other issue I can’t seem to figure out. Ever since I told FOG to use HTTPS, iPXE doesn’t seem particularly happy. I figured out a way to exclude the ipxe directory from the RewriteEngine so I am able to image machines and the rest of the FOG webpages do automatically redirect to HTTPS. I know that when you do an installfog.sh -S, iPXE should be happy with the CA certs. I’m not sure since I am not using FOG’s self-signed certificate, if that is causing the issue? I did get a different error when I redirect all pages to HTTPS. http://ipxe.org/err/410de3 I can see that means it doesn’t like the certificates, but I’m not sure where to begin to fix it…

Thanks again!

@Sebastian-Roth said in FOG/Apache PKI/Certificate Authentication:

That sounds kinda strange. What command did you use?

I just used sudo systemctl restart httpd. The configuration files were read just fine, the page just never prompted for a certificate. I did private browsing in IE just to make sure, but no good. I shut FOG off last night and it happened to work this morning when it booted.

Well done! Now that you’ve done the easy part you/we need to start looking at the PHP code. You want to start looking at this here: https://github.com/FOGProject/fogproject/blob/dev-branch/packages/web/lib/plugins/ldap/hooks/ldappluginhook.hook.php#L101

Okay, cool. Yeah, I’ll read over it tonight and see what I can figure out tomorrow. Just a heads up, I’m not a programmer - I’m just an IT guy/sysadmin. I do have some programming background (BS in Comp Sci from 6 years ago), but my forte is definitely not programming (especially C-like languages). I’ll probably be able to eventually figure this out, but it’ll take me a while. So, any assistance would be much appreciated.

Thanks again for the help!!

@Sebastian-Roth said in FOG/Apache PKI/Certificate Authentication:

Be aware that you cannot use the current fog-client as it is using your own CA.

Apologies for the double post - I didn’t see you had posted until after I refreshed the page. I don’t plan on using the FOG-Client right now, so I am not too worried about that.

I did manage to get the FOG site to prompt me for a certificate. From that website you sent, I added to fog.conf:

SSLVerifyClient require
SSLVerifyDepth 1
SSLOptions +StdEnvVars

I also then added the following line to that file

SSLCACertificateFile </full/path/to/CA/cert.pem>

I had to reboot FOG complete, restarting httpd didn’t seem to work too well. It did prompt me for a certificate (which needs Client Authentication at a minimum). When I selected the cert, it did move me along to the normal login page, which I would expect since it’s not doing anything with the cert yet. Now, I am just not sure what to do with the information I can glean from the certificate?

Thanks again for the assistance!!

@Sebastian-Roth said in FOG/Apache PKI/Certificate Authentication:

Not sure if you are aware of the installing having a command line switch forcing it to setup FOG with HTTPS?! Run ./installfog.sh --force-https and it should generate the right Apache config for you as well as compile iPXE binaries with the CA cert to trust included.

Haha! Yes, I did see FOG supports generating its own certificates. I had to modify the functions.sh script to stop doing that. I wanted to use my own Windows CA and its template so the FOG certificate would be trusted by other clients on the domain automatically - no self-signed certs.

The last command will ask you for certificate details like country code and most importantly Common Name (CN) and Email Address.

I did create a certificate with the CN as the FQDN of the FOG server before I passed it on to the CA for approval and issuing. It does not have an email though, since it is a server and not a user. If what you say about PHP using the CN is feasible, my certificate should be good to go. I can always request a new certificate with different fields, if it comes to that.

I’ll take a look at that website, too. Thanks for sending that over. I’ll see if I can incorporate that to at least prompt for a certificate. Would that be a good idea, you think?

Thanks again for the assistance!

I did manage to get the FOG and the CA certificate installed and functional. It took a little rewriting of the functions.sh. This made HTTPS work properly, too.

However (and I figured this would happen), iPXE does not work. When it attempts to use the HTTPS site, it throws an error (http://ipxe.org/err/3e1161). Says DNS isn’t happy. That does not appear to be accurate. When I hop in the iPXE shell, and do a ‘show dns’ it returns the correct DNS server. And when I ping, by name, the FOG server, it succeeds. So, I’m not sure why iPXE is complaining about that. I did figure out that if I disable the HTTPS rewrite on Apache and change the iPXE chain to use the normal HTTP site, iPXE does begin to work. This, of course, allows browsing to the normal HTTP FOG site - not super great. Deploying an image works, too.

Don’t know if any of this helps out.

@george1421 said in FOG/Apache PKI/Certificate Authentication:

The issue is that FOG needs a named user in its local database for authentication.

Hmmm… okay. I wonder if it would it be possible to pull the alternate name from the certificate offered to be temporarily added to the FOG database. And then if that alternate name is part of an LDAP group, that user would be allowed to log into FOG. I don’t know, just throwing some stuff out there. I know this isn’t functionality that very many people are looking for, if any. Either way, I truly appreciate the assistance and support.

@Sebastian-Roth Yes, sir. I’d like to give it a shot. And I did read over that link - thanks for providing it!

I generated a certificate using a request file on my FOG server just this evening. I got the certificate how I’d like it, with all the necessary alternate names and all that, and got it issued from my Windows CA using a template I created for *Nix-based devices. I copied the cer (PEM) certificate over to the FOG server for use. I also have the key from when I created the CSR (I am assuming that is the key file needed for the actual PEM certificate. If not, please forgive my ignorance).

I went ahead a little and tried to put the PEM and key in the right locations - /var/www/html/fog/managment/other/ssl and /opt/fog/snapins/ssl directories. I think those are right? When I run the installfog.sh script with -S to force HTTPS, I notice the script automatically recreates the keys and PEM for both the FOG self-signed cert and the CA cert and deletes the stuff I put in there and then Apache freaks out.

I Googled for FOG with SSL and only really got this forum post: https://forums.fogproject.org/topic/12095/web-interface-ssl/

Doesn’t look like it got very far for external CA certs, though.

Thanks very much for the assistance! I really appreciate it!

Hey all, just a quick question (I hope). Would it be possible to log into FOG using PKI certificates, rather than the local database or LDAP? Is that an Apache thing, I think? Has anyone done anything like this?

Thanks!

@Daniel-Miller said in LDAP Bind during Login:

Now, if you happen to know what the DN suffix will be, an alternative to the search and bind method would be a direct bind where the required static information is added to the username to create the DN that is proffered to LDAP for the bind request.

Right, this is something like I was thinking about, especially on a domain-joined machine. I suppose I didn’t phrase it properly or concisely - that’s my bad.

No particular reason for this functionality; just didn’t know if it would be something worth adding in or how difficult it would be to code into the plugin. No worries!

Thanks for the quick reply!