Whats this? a Sonus article? Damn straight it is!
So I was recently doing a deployment for a larger organisation. One of my first deployments using a Sonus SBC to do LDAP routing instead of an AudioCodes and I ran into some interesting issues
For those that arent aware, Sonus SBC’s do AD lookups a bit differently from AudioCodes units, They will actually query AD and store all the users with the “msRTCSIP-Line” attribute locally. before calls come in, whereas AudioCodes units will cache on a call by call basis.
Anyway, I had received my LDAP accounts from the customer and I could connect to the AD controllers, the SBC was happy it could see them and even reported it was caching correctly. Yet LDAP routing would fail.
A quick look at the cache showed it was too small and switching to “online” routing didnt work either so I enabled AD Logging by going to Settings > Logging Configuration > Subsystems clicking on Apply Log Profile and enabling the Authentication subsystem
After enabling AD logging and rummaging though LX logs I could see the unit correctly connecting to AD, But when it went to obtain the cache, I saw that it was only retrieving 1 result, none of which were cachable
xx.xx.xx.xx:52500 <==> <135>[2017-07-19 16:40:03,307] 5075 0004 com.sonus.sbc.ads DEBUG (ActiveDirectory.cpp:545) – threadID (0x40ebc520): Search complete, result: 10 (Referral)
xx.xx.xx.xx:52500 <==> <135>[2017-07-19 16:40:03,307] 5076 0003 com.sonus.sbc.ads DEBUG (ActiveDirectoryCache.cpp:414) – threadID (0x40ebc520): Page 1 :: Number of entries received for DC#1 (xx.xx.xx.xx) : 1.
xx.xx.xx.xx:52500 <==> <135>[2017-07-19 16:40:03,307] 5077 0002 com.sonus.sbc.ads DEBUG (ActiveDirectoryCache.cpp:444) – threadID (0x40ebc520): Number of entries received from DC#1 (xx.xx.xx.xx) : 1, actually cachable records : 0, total entries cached from previos DCs : 0.
Some testing with ldap tools and headbanging later, I find that the LDAP credentials work fine and everything is hunkydory
In a moment of desperation, I read the publicly available documentation over here (Yes AudioCodes, that’s a jab at you)
Turns out, the Sonus doesnt support LDAP referrals
AD lookups for call routing are executed the same regardless of the AD TLS configuration. DCs do not support referral chasing for call route lookups, therefore you must individually configure each DC that you wish to search for AD call routing queries.
What did the log files say again?
xx.xx.xx.xx:52500 <==> <135>[2017-07-19 16:40:03,307] 5075 0004 com.sonus.sbc.ads DEBUG (ActiveDirectory.cpp:545) – threadID (0x40ebc520): Search complete, result: 10 (Referral)
xx.xx.xx.xx:52500 <==> <135>[2017-07-19 16:40:03,307] 5076 0003 com.sonus.sbc.ads DEBUG (ActiveDirectoryCache.cpp:414) – threadID (0x40ebc520): Page 1 :: Number of entries received for DC#1 (xx.xx.xx.xx) : 1.
xx.xx.xx.xx:52500 <==> <135>[2017-07-19 16:40:03,307] 5077 0002 com.sonus.sbc.ads DEBUG (ActiveDirectoryCache.cpp:444) – threadID (0x40ebc520): Number of entries received from DC#1 (xx.xx.xx.xx) : 1, actually cachable records : 0, total entries cached from previos DCs : 0.
I had 2 AD controllers configured, 1 as primary and 1 as backup. this customer has 12 domain controllers and it appears the primary domain controller was referring me to the backup
So I changed the backup domain controller to a primary with a priority of 2, and LDAP queries started working
Documentation saves the day once again.
I hope someone else finds this useful
Just because you switched the quer priority of DomainControllers in the Sonus AD config, we still dont know why did a completely hwalthY DC not know the answer you asked for, and had to refer to another DC. Are both DCs in the same domain first of all? Was that a multi-domain forest AD, or what is the difference between the DC you called primary and the DC you called backup? Any chance one of them has Global catalog role and the other hasnt? More info please! 🙂
Further investigation showed this was a root domain “domain.local” and the second dc was the user domain “Customer.domain.local”
The difference with a “Backup” controller is the Sonus wont query it unless the primary is down, by adding both I’ve ensured I get the appropriate details.
Thanks! So yet another bloody multi-domain hierarchy, the scenario just as I expected 😉
Regarding the backup server not used as long as the primary keeps responding (no matter if the answer is just a plain “I-DUNNO”): thanks for that, so I can make a note to my evergrowing Knowledgebase: Sonus LDAP query works exactly like DNS name resolution and handling the negative type of answer vs. no answer 🙂
Thanks again!
Totally just fixed my problem man. I NEVER would have figured this out.
Thank you.
You’re welcome mate, I know I’ve run into countless issues where I found a fix in a blogpost, so I do my damndest to make sure I document every “weird” issue I come across in the hopes it helps someone else.
Hopefully I saved you a couple of hours of frustration.