This is a follow on to the overall topic in the thread above, but aimed at clarifying some information regarding the auth process. Great job on this - it is awesome integration.I am running FreePBX Distro 10.13.66-5 and have User Manager module 13.0.21. I have a few questions …
When a UCP user logs in to the UCP site, the authentication is passed through to AD at that time for authorization, not something stored locally in FreePBX correct?
Is the re-population of AD usernames in FreePBX based on any kind of a recurring schedule or is it only performed when the Submit button is selected? I have created a new user (30 minutes ago) in AD and selected the Submit button, but the new user is not showing up in FreePBX. I have a status of Green Connected on the “Authentication Settings” page both before and after selecting Submit. I can also see that the traffic is getting to the AD server when the submit button is selected.
What is the function/intention/format of the “Extension Link Attribute” in the “Authentication Settings” page? I have tried listing a number of AD user attributes and varying extension values (XXX, My Name ) in AD but cant seem to get anything to automatically link an AD user to an extension in User Manager if that is what it is supposed to do.
Is it possible (currently or on the roadmap) to filter the user accounts brought in by the AD connector other than by specifying the base DN?
Is the format for specifying more than one AD server source in the Authentication Settings>Host field supported?
I have changed the BaseDN around a few times trying to figure out what the qualification is for pulling user accounts from AD into FreePBX, but despite the changes it is only pulling real user accounts. I have a slew of service accounts as well that are included in the BaseDN of dc=domain,dc=local. The real user accounts are no different than the service accounts except they lack email addresses.What are the qualifications for the connector to determine if it is a qualifying user account to bring back?
I am happy to do any testing to further isolate/validate any of the AD integration. Any of this that needs to be submitted as a bug report I am happy to do also. With the limited amount of documentation there is around this capability I just didn’t want to jump the gun.
Yes. Real time authentication. There is no other way to do it.
Only when submit button is clicked. For now. By stable release it will be settable.
Works for me.
On our test server we have an attribute called “ipphone”, we have set the “Extension Link Attribute” to “iphone”. When the sync happens if “ipphone” is set to a valid extension (that is not previously assigned) it will be set to that user automatically.
You’d have to give examples of a filter you’d like to provide.
I don’t know what it would look like or how that would even function
Thanks for the answers Andrew. My (wrong )assumption for the extension link attribute was that it would pair up an AD user account to an existing extension, not create a new extension for them. So in an attempt to give that a go, I think I stumbled on an underlying issue that is preventing me from moving forward - my AD user list is cached somehow.
When I change the Authentication source back to “FreePBX internal Directory” authentication type it gives me back the previously defined users created when I used the quick create in extensions module, but when I switch the authentication source back to use Windows AD, it has all the information already saved and on submit says saved with a status of “Connected”. I then changed the server address to a bogus one and hit submit and it still said saved and shows a status of “Connected”. It still shows the same number of accounts I had yesterday when it was first successful in retrieving the users from AD (missing the new account I created yesterday afternoon).
Since the code snippet you shared shows that there is a cache (ucache), is there any way to clear that value and force it to grab all the AD values again? I also tried rebooting the FreePBX server but that didn’t make any difference for me.
Thanks for all your help and the information you shared thus far. I think you all have done a great job with this platform and service,
Has any thought been put into expanding the search to allow for child containers? For example, some Active Directory models use OU to organize users so using a singular base dn fails. There might be a generic “Users” container with two child OUs of “Power Users” and “Normal Users”. Specifying the Users container as the base DSN will leave out anyone in Power or Normal users.
A means to allow this would be to add a checkbox to the settings page with something along the lines of “Search child containers” which would cause the internal query to include child objects. For PHP, its a matter of adding ldap_set_option($connect, LDAP_OPT_REFERRALS, 0); after the connect and before the bind.
Also, for those that want to use an AD attribute, I’d suggest using the “drink” attribute. It isn’t used anywhere else and is frequently used by places to store extra info without having to extend your schema. I’d avoid using the ExtensionAttributes because they’re actually added via Microsoft Exchange and if you disable the mailbox associated with that user, it’ll null out those values. To use the drink attribute, you first have to enable it:
Click Start / Run and type mmc and press Enter.
In the MMC, click File / Add/Remove Snap-in / Add, choose Active
Directory Schema Snap-in. Click OK.
Expand the Classes container, locate the user class, right-click and
Click the Attributes tab, click the Add button.
In the list of attributes, choose the drink attribute and click OK.
Click OK to close the Properties window and save the changes.
Close the Active Directory Schema MMC.
Wait at least 5 minutes for the schema cache to get updated.
From there, you can use AD User and Computers or Powershell to add the extensions. For AD Users and Computers, make sure Advanced Features is enabled under the View menu, then browse a user’s properties. Click the Attribute Editor tab and scroll to drink. Enter in your extension without any quotes or other info. If you add multiple extensions to the attribute, only the first one counts. (I’ve tried)
I’ve asked you both to come in here because you seem really excited about Active Directory (as were some of our Support staff).
Soo that said. If you have any more thoughts on the processes involved from what you’ve already provided or any features you’d like to see let me know.
Also note that it might be pretty buggy (removing a user from AD doesnt remove them from FreePBX [a bug!]), but I want to get these features working as it seems to be a key feature for many corporations. The fact that it’s free doesnt hurt either
It really helps me to focus on one topic also while we flush these issues out together instead of having to deal with multiple issues/threads.
Something I was thinking about in the future was when you add a new user to AD and have said “attribute” filled in when FreePBX syncs it can auto-add the extension and generate dialplan, perhaps even link into Endpoint Manager (commercial $75) and create all of your configs but looking for another attribute… just some thoughts.
Thanks for sharing your thoughts Andrew (and you too Nick). I really think that leveraging an existing information directory will go leaps and bounds for FreePBX in adoption (or lessen the opposition to consider it).
I think the idea you had about the sync process auto creating extensions (and all that goes along with it) based upon a user attribute is great, but might not be used as much as it could be. I create user accounts all the time but rarely add a new endpoint/extension when a new employee comes on-board. Most of the time the new user account is replacing someone that left and will occupy an already existing extension.
With regard to the capability of syncing with AD, I think the best implementations in software suites share some common features.I would consider them to be:
Sync configuration account validation - This already exists and is great.
Filterable results - I would love to be able to filter by AD group membership (on a primary group only - getting into nested group memberships is too complex). Usually AD is full of accounts (service accounts and otherwise) that may not need to be included for a phone extension. Using only an attribute as a qualifier is tricky to track down as it is a value inside applicable individual accounts. It is easy and accepted practice to list or view group membership.I realize the attribute is needed for the extension mapping, but the additional conditional filtering would be more straight forward in my opinion even if it is a dedicated attribute for extension use only.
Debugging - When things go wrong with disparate systems talking, being able to see both sides makes it easier to troubleshoot.
Sync process isolated from the account/extension association - It is most effective to have the association of the extension to AD account stored off separately rather than it dynamically being matched to an attribute when the Sync process runs. I don’t know how this works now in FreePBX. When I switch authentication sources back and forth to FreePBX internal directory or AD it seems to still have the corresponding information saved (switching from AD to FreePBX internal directory lists the user manager associations created when using the quick create extension option). To say this another way, I don’t know if the AD account to extension association is saved somewhere in the FreePBX database or if it is matching the attribute to the extension every time it syncs. My main concern with this comes out of stability and predictability. In some software solutions there is way to much power given to an connector that dynamically updates things.
As for the commercial aspect of this, I would say commercialize this whole feature. I and I suspect many organizations would gladly pay $75 for the ability to cut down on one more password users have to be aware of, remember, change, and otherwise manage.
If I were to make a punch list of things I’d like to see, this is what it’d look like (If some of it is repeat, my apologies, but let’s get it all grouped together in a single reply vs spread out among many):
Automatic sync, with user configurable period. (15 minutes, 1 hr, 1 day, 1 week, etc) Notification email if sync has failed.
The user properties in AD allow for 4 phone numbers, Home, Pager, Mobile, Fax. There are technically more, but these are what are presented by default. These don’t line up directly with freepbx, but I’d like to see the Home/Cell/Fax properties be pulled over. Pager is a holdover from a previous era, but for completeness sake if its to be synced as well, I think it would make sense to at least display “Pager” instead of “Work” when AD Auth is selected in freepbx. There’s an IP phone field in AD, but I’m not sure how widely used it is in the corporate environment. That might be a good suggested target for storing the default extension. Please don’t remove the extension auto-map ability though, its very handy to sync up a large number of users at once.
For the times where a user has a specified default extension that doesn’t exist in Asterisk, perhaps add a tool tip/warning to their line in the users list that warns that the extension doesn’t exist and add a link that would then auto-create the extension if the user so desires? Its not automatic so that if someone goofs when editing AD, they don’t create a false extension, but its also easy to create the extension if that’s the intent.
Having the option to remove users from freepbx when removed from AD needs to be there, but there needs to be some sort of trash bin on the freepbx side so that if a user gets moved in AD (on purpose or by accident) all of their settings aren’t trashed if the user gets moved back in AD. Perhaps a day, perhaps a week, perhaps its a manual button push to purge? If the greyed out suggestion from below is used, then just gray out the line as an inactive user and then have the button remove the user.
The lack of multiple dn’s to search for sync is a bit of a deal breaker for me. I either need to be able to search multiple base dn’s (which the php ldap library will do out of the box and with minimal code refactor on your end) or I need to be able to tell it a base dn and have it search all subtrees below that (which would take a bit of code refactor for you because you don’t always want to search subtrees and your connection setup is all in a singular function). This would be a bit of work, but to simplify the setup for end users, a wizard could be made that accepts an AD username and password, then displays the AD tree with checkboxes next to each OU so that a user could simply check which OUs to include when searching via the first sync method. That’d prevent a user from going and digging out what their DN’s are or even having to explain what they are to the less knowledgeable users.
I’d really like a way to filter users that will/won’t be synced, even after selecting the dsn: only include users that include a particular attribute or have membership in a group and/or exclude users that include a particular attribute or have membership in a group. Perhaps give us an advanced option to customize the ldap filter?
Switching authentication methods leaves the existing mappings in place, but hidden, so if an admin doesn’t unmap an extension from a user, they’re blocked unless they go back to the other authentication method and remove it. I imagine you’re planning to add other authentication methods later, but perhaps adding a column to the list that specifies the authentication method with which that particular user is associated. You could then show all users, but grey out the ones that aren’t associated with the active authentication method, that way an admin could edit/remove the other users without having to toggle back and forth.
I realize AD auth is just getting started and some of this is probably rather complicated, but I like what you’ve done so far. For the commercial side of things, I bought your system builder package for the set of modules, but I can definitely see where this would be a value add for places.
I agree Nick. I think those features would make the AD authentication a full-fledged toolkit in the job of interconnecting the two systems.
I think it is necessary to classify this process into the three elements as to not confuse the issue:
User account retrieval (initial synchronization/ new AD accounts and attribute to extension matching; happening on a schedule)
User authentication (a real-time process as needed)
Managing changes (attribute changes, account disabled, account deletion, etc…) to existing (extension mapped) accounts detected in the user account retrieval
I think the first part, user account retrieval, might almost be there if the capabilities Andrew posted in that screenshot can be ported (copied?) into FreePBX. It seems like the second part, user authentication, is fully functional (I haven’t seen any bugs with it). The third part (from where I sit) seems wide open right now as I don’t know if those requirements have been spec’d yet (apart from the bug Andrew mentioned about account deletions not working),
I am not trying to put too much assumption on how things are or should be done ( as I will be the first to admit I don’t know how they are intended to work), but I do think that this is headed in the right direction.
I see the ability to sign in via voicemail info has been added. I like it. If we take Brian’s suggestion above about breaking the AD sync into 3 components, I think it’d make the voicemail auth more useful if there was still the ability to sync AD info (Name, Phone, etc) even though the authentication is via voicemail.
I wanted to ask a question about the implications of choosing a specific authentication scheme (AD for this question but it would hold true for Asterisk VM as well). When the auth sceme was “FreePBX Internal Directory” I set an extension that mapped (linked to a default user) in the extensions module.This extension in particular is setup for receiving inbound faxes. I can set the fax preferences in user manager for that user (extension). When I switch to Windows AD scheme I lose visibility to that user in User Manager and thereby can no longer manage any settings. Despite this FreePBX internal directory user not being listed in User Manager and the extension no longer being linked to a default user in extensions module, the fax settings for that un-linked user are still honored (faxes are still emailed to the address that was listed in user manager for that FreePBX internal directory user).
I am glad that this continues to function in this manner (sending emails for received faxes) despite the ability to change settings for that missing user, but I wanted to know if that is operating as intended. If you choose a different authentication scheme are you then required to have every extension you want to manage settings for in User Manager mapped to an account in that auth scheme? Not that I have tested this, but I would imagine the same scenario would be true for the Asterisk Voicemail scheme if a pre-existing user in another scheme did not have voicemail established (as my dedicated fax extension currently does not).
Those User/Group Configuration options are very important.
AD integration is a major thing for me in a business environment. I always look for tools that integrate against it, it makes my life easier. And now with Samba 4 I can get a basic 2008R2 AD (which does everything I need) running on linux without the Microsoft expense.
From working with other AD integration tools, I’d say consider how ejabberd integrates with LDAP/AD for an idea of both what to do and not to do. The “official” module(s) are really good but fall just short of being completely flexible for all AD setups. They have created multiple modules for each part of LDAP/AD integration. One handles LDAP authentication. Another handles shared rosters (what and how users/groups show up in your XMPP client). And another handled vcard data (mapping AD attributes to vcard fields). The only really issue I have with what they offer is the mod_shared_roster_ldap module, which lacks the necessary filtering. Someone modified it (wish they would merge or adopt the changes) and offered a TON of flexibility (see HERE).
I think you could go down a similar path. The authentication part is pretty much there. From that you would expand by offering something like the “shared_roster” plugin which defined with users/groups to pull and let people really structure the LDAP query to only get what they want. And finally something like vcard, which defines a mapping of LDAP/AD attributes to FreePBX attributes.
I just upgraded to 13 on a new deployment that I have to get setup by the end of the month and this was one of the main reasons I took the jump instead of waiting and dealing with the transition after the fact. I wish I had more time to discuss this feature because I think it is a major plus to FreePBX and I would certainly pay for a well fleshed out LDAP/AD implementation (especially with GUI setup).
[quote=“tm1000, post:7, topic:31099, full:true”]
Also note that it might be pretty buggy (removing a user from AD doesnt remove them from FreePBX [a bug!]),[/quote]
Just to check with others, this bug still exists correct?
I sync’ed with an AD that mixed security accounts with regular user accounts (I didn’t do it, I’m just cleaning up the mess) and now I have a bunch of users and groups that I don’t need in FreePBX. Doesn’t seem like you can “delete” an account sync’ed from AD. I’ve removed the user/groups from the AD Base DN location specified and tried to resubmit from the authentication page but nothing changes. Any workaround for this right now?
PS: perhaps I don’t understand the Extension Link Attribute, but I don’t think it is working for me.
I define the extension link attribute as telephoneNumber (AD attribute). I create a user and provide an extension and name. I expected them to “link” based on this extension link attribute setting but they haven’t. Am I missing something?