FOG/Apache PKI/Certificate Authentication
-
@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
$FOGUseris 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 invalidatePwfunction 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?
-
@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’
-
@ty900000 Well that’s where I wonder if you want to tweak the login form. I know this is hacking FOG a bit more than you wanted. But set the field on the login page to read only and then pipe in a random password. As I’m suspecting FOG or apache is caching what the user keys into the login page for subsequent logins during the session. Probably by setting a session level value with the user ID and password. But I’m only guessing here. But that would explain why setting something on the login page would be persistent and you keying in something in the plugin code is being rejected.
-
@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!!
-
@ty900000 Yes, on line 275ff.
-
@ty900000 For that answer I’ll have to see if I can reverse engineer it. I don’t think it was the class but just a php page. I can see the processlogin acting upon the form.
-
@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.
