SIP hard phones don't use AADS.
You'll notice that all the ACS related settings for AADS in 46xx reference Vantage and IX Workplace devices
Code:
################### AVAYA AURA DEVICE SERVICES (AADS) CONTACTS SERVICES ################
##
## ACSENABLED specifies whether to use contacts from Avaya Aura Device Services (AADS) or not.
If you want the IXW softclient to search your LDAP via AADS, you need to link the accounts on LDAP and SMGR.
What I mean to say by that is you need SMGRLoginName - the login name on the Identity tab of SMGR to match some attribute on LDAP - like userPrincipalName for Active Directory. You probably created that association between AD and SMGR when you imported your users to SMGR via LDAP sync which is great and helps keep data in sync, but isn't absolutely necessary.
What is absolutely necessary is that AADS understand that asociation. So you have a value - like userPrincipalName that on the LDAP Server Configuration page matches UID Attribute ID. That means it's the thing you log in to AADS with.
Then, on the Attribute Mappings, you have SMGRLoginName that must map to something - userPrincipalName is best if you're on AD. That means Mohamed-IT@tek-tips.com on AD can login to AADS and when he does, he will be associated with the SMGR user with login name Mohamed-IT@tek-tips.com (which you probably already have because you sync'd AD to SMGR). Now when you login to AADS, the AADS server knows it's the same Mohamed on AD as SMGR.
You also need to map BusinessPhone maps to something. That's something on AD that equals your extension. Use pager if you want or telephoneNumber or whatever else. It sometimes helps in enterprise deployments where companies have all sorts of crazy stuff in the "telephoneNumber" field to use something different like ipPhone or pager.
Now, let's say you picked pager. You didn't have to sync AD to SMGR. You could have gone and created Mohamed-IT@tek-tips.com on SMGR with SIP extension 101. And then you could have gone in AD and created the same user with pager number 101. Your AADS sync and mapping would still work - there does exist a user, Mohamed-IT@tek-tips.com on AD that AADS passed authentication through and proved your identity, and that user, with pager 101 is equal to the Avaya UC user with extension 101 and it will work.
AADS has 2 functions - auto-configuration and contacts. Auto-configuration works strictly by logging in correctly and depending what configurations you have in AADS for different groups - If in LDAP Group AADSUsersEast, use config with SET SIP_CONTROLLER_LIST eastsm.company.com etc.
The other function is the contacts service. SMGR isn't exposed as an LDAP source you can search through. AADS enables that while also consolidating that information with the other LDAP source.
So, AADS syncs with SM's nosql cassandra database for PPM, and with SMGR via DRS for all the SMGR users, and the LDAP stuff, and smashes it all into one super directory and exposes that over HTTPS to Aura clients. If you had a mobilePhone number in AD, then someone searching you would see that and be able to click to call that even if there was no reference to it in SMGR.
You must make auto-configuration work first - it only requires AADS to talk to AD. Then you make the contact service work by making the attributes between AD and SMGR align.
This is to say you can enter the autoconfig URL
in IXW and be prompted for a user/pass. It doesn't matter if the attribute mappings are all wrong as long as UID Role Attribute = userPrincipalName and you give a proper login. If you do, you'll get the dynamic configuration for your endpoint. You can just as easily test that by entering that URL in a browser - private tab is best if you have a session in your mail browser on the AADS admin interface - and on the private tab it'll prompt for basic authentication and you'll see something like a 46xxsettings file but that is especially for you.
You can test that even further and in the AADS Dynamic Configuration you're using, in the Group tab there's COMM_ADDR_HANDLE_TYPE (probably Avaya SIP) and COMM_ADDR_HANDLE_LENGTH - make that your extension length. If you also make SIPSSO set to 0, then when you check your dynamic configuration in the web, you'll set SET SIPEXTENSION 101 and SET SIPSHA1 fiurgiweioghweiohgiowhegohwrh. That's AADS passing you your SIP extension and a hash of your password for your client to automatically use it so you are able to login to "everything" with just your Windows name and password.
Words of warning about AADS: don't be afraid to reinstall the OVA from scratch. Sometimes the configs get stuck. Especially if you were looking around in a doc and left the blue config terminal menu timeout, I've always reinstalled when that happens because it's like things get stuck.
Good luck
