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.