Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Active Directory Authentication

    Scheduled Pinned Locked Moved General pfSense Questions
    8 Posts 4 Posters 1.0k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • A
      andrewhancock91
      last edited by

      So I know this has been covered a few times both on here and reddit but I'm still very much struggling to get AD authentication working in pfSense with the primary goal of having my openvpn road warriors connect and be able to use their AD credentials.

      What I would really like to do is have a group called "vpnusers" and only people in that group can authenticate, the trouble is that in my testing the users that can authenticate seems pretty random. It works great with all the users in a single OU but without redesigning my AD layout that isn't going to work in our production environment. Here's my current configuration and with any luck I just need to check a box or something to get this working!
      0_1532372886567_2018-07-23 14_03_33-.jpg
      0_1532372897546_2018-07-23 14_03_52-rt-wag02.wag.watermarkauto.com - System_ User Manager_ Authentication Servers_ E.jpg

      To give a little background, I have active directory setup for our company which is spread out across 8 different locations and each location has at minimum 4 departments and a couple sites have up to 8. The way my AD is laid out is each location has an OU, inside of that each department has an OU, and in a couple instances there is another OU past that.

      Story for the novel and thanks in advance!

      1 Reply Last reply Reply Quote 0
      • stephenw10S
        stephenw10 Netgate Administrator
        last edited by

        When you test from Diag > Authentication does it respond as expected?

        Does it return the correct user groups?

        Steve

        1 Reply Last reply Reply Quote 0
        • A
          andrewhancock91
          last edited by

          Its extremely hit or miss when testing from the Diag > Authentication screen or trying to log in to the console, by default pfSense seems to recognize any correct login from the specified authentication containers and if it matches a group created in pfSense like "vpnusers" it will say that the user is part of that group. But its not recognizing all the valid logins and I think its because pfSense is having trouble dealing with my multiple layers of OU's. I have both my Base DN and Authentication Container set to the root of my domain since the users authenticating are from more than one OU.

          Say I have an OU called "test1" that has several users like test11, test12, etc... all of which are members of the vpnusers group and they authenticate just fine. And I have another OU called "test2" with users test21, test22, etc... which are members of the vpnusers group as well but they fail the authentication test.

          I've played with this some more and if I specify an OU as the authentication container it works just fine, to me that verifies my hypothesis that pfSense can't handle the multiple layers of OU's.

          1 Reply Last reply Reply Quote 0
          • stephenw10S
            stephenw10 Netgate Administrator
            last edited by

            In which test2 is a sub-group of test1?

            Not sure I've ever tested that. Someone will have though...

            Steve

            1 Reply Last reply Reply Quote 0
            • M
              moikerz
              last edited by

              Port 389 is for unencrypted communication. But you have selected a CA? Encrypted communcation is port 696 (I think .. or 698?)

              Consider testing your LDAP communication by using "Softerra LDAP Browser" to make sure things are even accessible before plugging it into pfSense.

              M 1 Reply Last reply Reply Quote 0
              • M
                Mats @moikerz
                last edited by

                @moikerz : 636 for secured LDAP

                1 Reply Last reply Reply Quote 0
                • stephenw10S
                  stephenw10 Netgate Administrator
                  last edited by

                  The selected CA selection is only used if the transport is set to SSL or STARTTLS. So it's doing nothing there.
                  If it was needed I wouldn't expect any queries to work.

                  Steve

                  1 Reply Last reply Reply Quote 0
                  • A
                    andrewhancock91
                    last edited by

                    stephenw10 - I was just saying the same thing about SSL and STARTTLS then realized you had already clarified that!

                    In that example I gave above about the "test1" and test2" groups they were sitting side by side in the root domain which is why I don't at all understand why one works and one doesn't when my authentication container is the root domain itself. If it see's one OU it should see both right? Unless there's a way to make pfSense do a more detailed query when someone tries to log in I've about decided that this won't work.

                    One thing I have not tried yet because it seems kind of messy to deal with later on down the road is listing each individual OU in the authentication container field. This would be easy to do since it lets you select OU's with checkboxes but if for some reason I ran into a scenario where pfSense couldn't talk to AD and I couldn't pull up that list of checkboxes it would be hell to sift through all that data in that tiny field if an OU got deleted or something screwing the whole thing up. Hopefully that makes sense....

                    Thanks for the responses everyone!

                    1 Reply Last reply Reply Quote 0
                    • First post
                      Last post
                    Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.