FOG/Apache PKI/Certificate Authentication
-
@ty900000 said in FOG/Apache PKI/Certificate Authentication:
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
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.@george1421 Thanks heaps for your comment on this. Neither have I been involved in developing the LDAP plugin nor have I used it myself yet. I wasn’t aware of the point that a user account is needed. From what you said I would think PKI authentication would need to be added as a plugin just as well. Probably the LDAP plugin is a good start.
There is some good information on how to grab the client certificate information within PHP (and also what is needed on the Apache side again): https://cweiske.de/tagebuch/ssl-client-certificates.htm
Now to start off you’d generate at least one client certificate:
sudo -i cd /opt/fog/snapins/ssl openssl genrsa -out user1.key 4096 openssl req -new -sha512 -key user1.key -out user1.csr
The last command will ask you for certificate details like country code and most importantly
Common Name
(CN) andEmail Address
. Those two could be important later on in the PHP code.Next step: Sign the certificate request using the FOG server CA.
openssl x509 -req -in user1.csr -CA ./CA/.fogCA.pem -CAkey ./CA/.fogCA.key -CAcreateserial -out user1.crt -days 3650
You end up with a PEM certificate in
user1.crt
that should be importable in Firefox and other browsers. -
@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) andEmail 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!
-
@ty900000 said in FOG/Apache PKI/Certificate Authentication:
I had to modify the functions.sh script to stop doing that.
When you first said something about modifying functions.sh I was thinking if you really mean you use your own CA. Wasn’t sure though. Good to know! Be aware that you cannot use the current fog-client as it is using your own CA. I will be working on this but it’s a long way down the road to fully change this. If you are still keen to make it work you can compile your personal fog-client installer binary and use that instead till we have a solution ready for everyone. Let me know if you want to use the fog-client.
I’ll see if I can incorporate that to at least prompt for a certificate.
That shouldn’t be hard to do at all. Though grabbing and using the cert information in PHP to allow access to the web UI is still a fair work away.
-
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:
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.
-
@ty900000 said in FOG/Apache PKI/Certificate Authentication:
I had to reboot FOG complete, restarting httpd didn’t seem to work too well.
That sounds kinda strange. What command did you use?
I don’t plan on using the FOG-Client right now, so I am not too worried about that.
All fine then for now.
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?
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
-
@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!!
-
@ty900000 I am sure we (as in the whole community) can work this out together. The more effort you put in the sooner it’ll happen. I can’t put in much time as I need to focus on the next FOG release, means bug fixing instead of adding features. Though I’ll still try to give hints as much as I can.
-
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!
-
@ty900000 While you are right the http://ipxe.org/err/410de3 error is a bit strange but I’d still suspect this to be a certificate issue. FOG does a couple of things behind the scenes with the
-S
switch installed. But if you want to use your custom CA (which is perfectly fine by the way and I’d love that we’d already have the installer up to the point where we let people decide but you know too many other issues around) you can still do the iPXE compilation sort of “manually”.cd /path/to/fogproject-code/utils/FOGiPXE/ ./buildipxe.sh /path/to/your/own/CA/cert.pem
See if it runs through (take a few minutes) or if it stops with errors. If there are no errors you can just copy the new binaries over.
rsync -av /path/to/fogproject-code/packages/tftp/ /tftpboot/
Make sure you use the trailing slashes exactly as seen above!
-
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.
-
@ty900000 said:
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.
Good point! Take it one step at a time!
I’m not entirely sure how other companies search through LDAP for group membership with PKI authentication.
Usually this is done using what I’d call a service account. It’s setup in AD/LDAP and the username/password stored/hardcoded in the software that wants to query AD/LDAP.
Will answer more when I get more time.
-
@Sebastian-Roth If OP looked at the ldap plugin there is an account called a bind dn. That account is a basic level account that has read-only access to AD (LDAP). That bind account is used to search AD for a valid user, then it rebinds to AD as that user to test to see if the user’s password is valid. If its valid then using the user’s credentials it looks at the admin group and the mobile group to see if the user is a member of that group. I think that framework would be a good starting point for your pki plugin. At least someone can see how the program flow goes.
-
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.
-
@ty900000 My experience is anonymous ldap browsing is disabled in AD. As you said its a big security hole if left on. If on it would give hackers a way to enumerate the number and names of user accounts.
-
@ty900000 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!
Once I select a viable certificate, I still get directed to the login page.
For that you need to start looking at the core code. This is where it decides wheather the user is logged in and directed to the dashboard or not. The variable
$FOGUser
is being defined and initialized in class FOGBase. Now this again is being set as a global variable from the session. And the real magic then happens invalidatePw
function in class User.Sorry I can’t give a an easy solution to this just now. Don’t have enough time. But those pieces of code should give you all you need to figure it out - I hope.
-
@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 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!
-
@ty900000 This is the bit of code the developers added. But I wonder if you set $pass to a static text like “hello” and then when it writes that to that temp user it would write hello to that account. But I suspect there is a bit of caching of $pass going on at a session level.
-
@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?