Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

LDAP connection with SMGR 1

Status
Not open for further replies.

Mohamed-IT

IS-IT--Management
Mar 10, 2020
44
IQ
Hi Guys,

I have LDAP Connected to SMGR and all users appeared on SMGR normally, but I have few SIP phones doesn't display any contacts so I install AADS to solve this issue, the question is do I have to connect "AADS to LDAP" or "AADS to SMGR" and what is the needed configurations.
 
When You install AADS - You can configure LDAP do You do this or skip?
 
Hi OlegPowerC,

Thanks for your replay, I skip that, but i can return to that option by run "app configuration" command. But some configuration options not clear to me and get below Error
1_kncare.png
 
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 :)
 
Dear kyle555,

Thanks a lot for the informative information and great explanation, really appreciated.
 
Hi kyle555

Please your help

As you said I create a user in AD and add it to SMGR also I tried to use it in AADS but I get an issue which I can't do "User Synchronization" on AADS.
PLease find below snapshots

1. the SMGR is synch with AD normally
p1_fs54at.png


2. the connection from AADS to AD is ok
2_be6xe7.png


3. the issue is I cant see SMGR or AD users on AADS and when I try to do force LDAP sync i get below error
1_ozwcu3.png


4. below snapshot show the user info on SMGR
3_emdwaz.png
 
If you have a vanilla AD brand new for DC=lab,DC=COM

You'll have a Users folder in there. And in that folder you make groups like AADSUsers and AADSAdmins

So, your base context DN might be CN=Users,DC=lab,dc=com and for AADSAdmins, you'd point to CN=AADSAdmins,CN=Users,DC=lab,DC=com and for users, DC=AADSUsers,CN=Users, bla bla bla

You have a successful LDAP test, but you havent mapped roles of people in LDAP to a role in AADS - specifically, users
 
Hi Kyle555

Many thanks for your quick reply,
please be informed that i don't have access to LDAP server because its related to customer so i have to ask customer for below:

1. what is the LDAP server used "windows server 20xx"
2. create a 2 groups in users folder like "AADSUsers & AADSadmin"
3. "your base context DN might be CN=Users,DC=lab,dc=com and for AADSAdmins, you'd point to CN=AADSAdmins,CN=Users,DC=lab,DC=com and for users, DC=AADSUsers,CN=Users, bla bla bla" do you mean this setting should be on LDAP server or on my AADS?
4. please advice how can I map roles of people in LDAP to role in AADS so i can share the steps with customer to do it.

** do I need to create a user in LDAP and sync it with SMGR then use the same user in AADS??
 
The install guide will help and show you what to fill in the fields given an example similar to what I showed you.
 
Hi kyle555

thanks a lot for your help, will try to follow installation guide and see the results.
 
Didn't have time to answer yesterday.

When you're logged in and type a name to search, AADS uses the Bind DN as the account it logs into LDAP with to make the search.

That has nothing to do with getting users authenticated.

AADS supports many different roles - only the Users are the ones that use IX Workplace. Service Admin, Auditor, etc are roles that are for specific tasks. So, if you want someone to be able to restart AADS but not make config changes, you'd make them a Service Admin.

So, those role fields are groups or folders in LDAP. So, if mohamed@lab.com with DN=mohamed,CN=users,dc=lab,dc=com logs in to IX Workplace and the user role = CN=users,dc=lab,dc=com, then you'll be allowed to login and AADS will try to match your userPrincipalName to a SMGRLogin name in the attribute mappings and associate your LDAP account with your Avaya account.

Now, lets say you have a group CN=AADSAdmins,CN=users,dc=lab,dc=com and mohamed is a member of that group and if I did a ldap search for members of CN=AADSAdmins,CN=users,dc=lab,dc=com and you showed up, then if you went to in your browser and logged in as mohamed, you'd be allowed to login as an admin.
 
Hi Kyle555,

Many thanks for your great explanation and support, really appropriated.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top