I have set up DDI numbers for my organization to receive inbound and outbound calls through MS Teams using a telephone number. I bought this from a telecom provider.
First I opened active directory and added the telephone number to the Telephone Number field and Added name "Team" to the pager section.
Then, wait couple of hours to sync the system.
I opened PowerShell and logged in to teams via PowerShell.
Then I entered below commands;
Set-CsUser -Identity '<EMAIL_ADDRESS>' -EnterpriseVoiceEnabled $true -HostedVoiceMail $true -OnPremLineURI 'tel:+6XXXXXXXXX'
Grant-CsTenantDialPlan -PolicyName <POLICY_NAME> -Identity '<EMAIL_ADDRESS>'
Grant-CsTeamsCallingPolicy -PolicyName AllowCalling -Identity '<EMAIL_ADDRESS>'
Grant-CsOnlineVoiceRoutingPolicy -PolicyName '<POLICY_NAME_2>' -Identity '<EMAIL_ADDRESS>'
I waited another 3,4 hours to sync and update group policies on devices using gpupdate
Now I can take call to outside using dial pad. But I am not receiving any calls from out side. When I tried, there is a recording going on. It says "The number you have called is not currently active or is invalid. Please check the number and dial again". The number is working number.
Seeking advice from experts. Thank you.
Looks like this is Direct Routing and using old instructions. This is the current one Enable users for Direct Routing - Microsoft Teams | Microsoft Docs.
There are some troubleshooting tips here Monitor and troubleshoot Direct Routing - Microsoft Teams | Microsoft Docs including a diag tool that checks if the user is properly configured.
Since this is Direct Routing and inbound to Teams, the audio message can come from multiple components, i.e. carrier or us or somewhere a long the way.You can check your SBC to see if the call reaches it and if it does, check what error message Direct Routing is returning. The best approach is to open a Microsoft support case and provide the tenant information, call time, phone number etc and support can check Direct Routing traces etc.
I found the answer for this after investigating with Network team. There were 2 issues.
The Telephone Number field in the user profile on AD, we need to put the number as normal. Not as E. 164 standard. As an example: The number should be 0229188884 not like +64229188884
otherPager attribute field in the user profile on AD, We need to add as "teams" (LOWERCASE). I have added as "Teams".
I made those changes and wait for sync. Then trid to call to that number. It worked.
Thank you #Sayali-MSFT for your support. I found some clues and got a clear path to investigate becasue of your guidance.
Related
For a school I implemented eduroam two years ago and from time to time we add new students in the AD.
Five days ago I added 40 more new students but I changed the CN's (or what in New-ADUser is called "-Name") format:
from "name.surname" to "SURNAME, NAME" (quotes excluded), hence
earlier it was
CN=name.surname, OU=CLASS_A, OU=STUDENTS, DC...
now it is
CN=SURNAME, NAME, OU=CLASS_A, OU=STUDENTS, DC...
an eduroam's username normally is <string with no blanks>#<yourschool>.<tld> so that the RADIUS proxies can route the auth request based on #<yourschool>.<tld> , So I must keep such a format.
Now, the new users cannot be authenticated anymore by NPS.
All the tests I ran back my thesis (i.e. that NPS uses CN to authenticate) but I cannot find any Microsoft document that states that.
Could anybody share the link to such doc?
is it a way to change the check from CN (if proved by answer of point 1)) to another user's recor like sAMAccountNAme or UPN?
I'm sure I'm touching something deep in AD but I hope somebody has tripped into this issue and has found a answer.
TIA
P.S. I guess the alternative would be to use FreeRADIUS but I would rather explore the options to still make within NPS/AD
• Please check the Windows Server event security log for more details on the issue for NPS authentication because that might shed some more light on the actual issue that you might be facing. Till then, please clear the cache and temporary files from the server and restart the whole infrastructure regarding NPS, i.e., domain controller, NPS Server, Access points and other related devices through which users can login through NPS.
• Once restarted, please try to authenticate any allowed user through NPS once again and check. Also, as you are using NPS as a radius server proxy, please check for the attribute manipulation rules for message forwarding since the CNs are changed in their order/format in your AD. Specifically, regarding the username which is provided by the access client and is included by the NAS in the Radius access-request message. The value of this attribute is a character string that typically contains a realm name and a user account name.
• To correctly replace or convert realm names in the username of a connection request, you must configure attribute manipulation rules for the User-Name attribute on the appropriate connection request policy.
Also, find the below links regarding your query whether which attribute you can use to authenticate in case of NPS. In it, it clearly stated that user principal name should be used as an attribute as a best practice: -
https://learn.microsoft.com/en-us/windows-server/networking/technologies/nps/nps-best-practices#performance-tuning-nps
https://learn.microsoft.com/en-us/windows-server/networking/technologies/nps/nps-best-practices#using-nps-in-large-organizations
Please check the below documentation link for your condition: -
https://learn.microsoft.com/en-us/windows-server/networking/technologies/nps/nps-plan-proxy#key-steps-3
For a client, we have to connect a WSO2IS 5.10.0 to an Active Directory.
For that we have created a secondary user Store with this configuration:
User store main configuration
User store optional configuration
User store advanced configuration
WSO2IS can connect to Active Directory as we can retrieve users and roles.
Before doing any claim mapping we have tried to edit and create user without any problems.
And then we have mapped some claims to retrieve more information from Active Directory.
And here come our problems:
We can't create a user in Active Directory
We can't update a user in Active Directory
This two problem gives us this error :
Caused by: javax.naming.directory.NoSuchAttributeException: [LDAP: error code 16 - 00000057: LdapErr: DSID-0C090C45,
comment: Error in attribute conversion operation, data 0, v1db1
Things that we have tried:
Check (and check a second and third time) that all our claims are mapped correctly (and they are)
Reset all claims to default mapping (on the state where we where able to create/update user)
Set User DN Pattern (as explained here)
Restart on a fresh instance of WSO2IS 5.10.0
But all things that we have tried are not helping and we are stuck.
Any help would be hugely appreciated. Thank you for any suggestions.
As asked, this is the AD attribut we have mapped :
sn
givenName
cn
displayName
name
description
mail
sAMAccountName
userPrincipalName
accountExpires
pwdLastSet
userAccountControl
scriptPath
homePhone
mobile
facsimileTelephoneNumber
title
department
company
Here the issue is LDAP_NO_SUCH_ATTRIBUTE returned from the AD.
We don't know which attribute is missing on AD side.
From the existing DEBUG logs of the server, probably you wouldn't be able to log all the attributes that WSO2 is going to update. Therefore, you have to choose an alternative option.
Manual check - Even though there are only few attributes configured (and verified) by you, there are other claims with default attribute mappings. Please check all the mapped attributes that are there in the http://wso2.org/claim dialect.
Remote debug - Remote DEBUG the server to check what are the attributes WSO2 is trying to write in to. (Smaller subset than previous approach) Then verify if those exist.
To do this remote debugging you can check out the Kernel source code from here.
To find out the correct tag to checkout, you can find the kernel version of your identity server version from this release matrix.
Once you clone and checkout the correct tag, you can use IntelliJ Idea or a capable IDE to remote debug the server as explained in the this blog.
Though it's hard to point an exact line of code, you can put DEBUG points to ActiveDirectoryUserStoreManager.doAddUser() and ActiveDirectoryUserStoreManager.doSetUserClaimValue() methods and start from there.
P.S. You can also check if the carbon log's stack trace contains any clue of the failing attribute or the respective claim, so that you can check validate it.
I work in a big company and we have just migrated to office 365 in a hybrid scenario.
Here is the "stack":
Exchange 2016 Hybrid
ADSync with AADConnect
Usermailboxes hosted on Office 365
Users use the Outlook 2016 Client (can't roll out o365 client, because we have over 50.000 users and so many custom outlook plugins 32 Bit)
We do this as followed:
Create a new ad user.
Enable-RemoteMailbox samAccountName -RemoteRoutingAddress samAccountName#tenant.mail.onmicrosoft.com -PrimarySmtpAddress address#tenant.com -shared
(This also turns of emailAddressPolicy which it should do according to our exchange admins). Our exchange admins are also stuck on that problem so that's why I created this post here)
Then I wait and have a look in the ECP Admin center. Before the sync happens the remote Routing address is: address#tenant.com
After the first sync (every 30 minutes) it's samAccountName#tenant.mail.onmicrosoft.com ==> How it should be.
After another 30 minutes (2nd sync back to AD) it's a X500 address.
When I look it up in PS like get-remotemailbox <UPN> | fl *remote* the address is samAccountName#tenant.mail.onmicrosoft.com (how it should be).
So it's displayed wrong in the ecp.
But the huge problem we face is this:
When I give any user from the company full access to this shared mailbox it won't get Automapped.
After 1 hour of waiting I manually add it. When I do this a .OST error comes.
Error:
"Microsoft Outlook cannot expand the folder. The set of folders cannot
be opened. The file
C:\Users\UserName\AppData\Local\Microsoft\Outlook{username]}.ost"
Also with outlook restart it's not working. So our guess is because something is wrong about ECP and the Remote Routing address.
Please note that this isn't a client problem. It effects almost every mailbox I create these days.
I had another post about this but with fewer details and without the knowledge of the remote routing address: https://www.reddit.com/r/exchangeserver/comments/eceqm6/automapping_doesnt_work_on_hybrid_setting/
Anyone have any ideas? I appreciate any kind of help from you guys. If you need any more informations please ask
You have an Hybrid architecture, ok. You need to use O365, because if you use older versions you will need to change a bit the computer registry in each computer. Or change the on-premise autodiscover.
But your big problem is big indeed. Right now, you can not hare mailboxes in O365 correctly. If you do that, you may have access to main mailbox, but if you use archive, you won't have access (you just have OWA access).
Regards.
I am currently working on a AD installation where there are about 45,000 accounts and about 60+ global catalogue servers, some accounts are active some are disabled. Some active accounts are service account which don't appear to login as the lastlogondate is several months old.
If I disable some of the service accounts which do not login the application stops working so I know the application is authenticating to AD somehow.
My question is how can I determine which account have been used to authenticate but have not actually 'logged in'? Is there an attribute I can query or can I set it somehow that AD writes to the event log?
Simply speaking, lastLogonTimestamp is the right attribute to find inactive accounts.
See following link for descriptions on different related attributes:
http://social.technet.microsoft.com/wiki/contents/articles/22461.understanding-the-ad-account-attributes-lastlogon-lastlogontimestamp-and-lastlogondate.aspx
Just copied from above link, using PowerShell, you can get inactive users (inactive for AROUND 90 days, note lastLogonTimestamp is only an approx value) by calling:
Search-ADAccount -AccountInactive -DateTime ((get-date).adddays(-90)) -UsersOnly
For the last logon time from Hyena, I suspect it is inaccurate.
(I never use Hyena before, so just a guess.)
From the following link:
http://www.systemtools.com/HyenaHelp/index.htm#userlogoninfo.htm
Seems by default it only get the last logon info from one DC only. If they get this info from lastLogon attribute instead of lastLogonTimestamp (very likely, otherwise the "Check All Domain Controllers" option is meaningless), it will only get the logon time on this specific DC only. So if those service account are always using DC1 in recent authentications but you connect to DC2 to get the logon time, you will only get a very old time (or none if it never use DC2 to authenticate).
I don't know what function or technique you are using in Hyena to get the 'last logon' information, but as indicated by others, the AD attribute 'lastlogontimestamp' will get you a fairly accurate date/time (~within 10-day accuracy) of the last use of an account. This attribute can be added to any query in Hyena for all of your users. You can also export out the service information on all computers and servers, to see what accounts are being used.
If you need additional assistance, contact SystemTools Support - support#systemtools.com
We are always ready to support our customers.
(I am with SystemTools (Hyena) support)
I have a Debian Squeeze system which is using libnss-ldap to bind to a 2008 Active Directory domain controller to look up users and groups. Everything works fine, except for some reason anyone who is in the Domain Admins, Enterprise Admins, or Schema Admins group does not get the correct group memberships. They get only the *Admin group, and no others (unless there are local groups that apply, which do show).
Stranger yet, a "getent group" shows all the correct group memberships for the user, but an "id " or "groups" (when running as the user) doesn't. We use a domain group for sudo access, and this user is unable to use sudo because it fails to see the group membership. As soon as the *Admin membership is removed, lookups work correctly.
I suspected maybe this was an AD security feature, but we have FreeBSD systems using nss-ldap on which these users' group memberships resolve correctly. There is nothing in the logs to indicate why these lookups don't return the normal results, and I haven't been able to find anything via Google to help shed light on the situation. Is anyone else using libnss-ldap in Debian to connect to an AD who can try to confirm this behavior?
Edit: I have confirmed using ldapsearch that the AD is returning the correct results. I also stopped nscd to make sure it wasn't interfering. Any user in Domain Admins sees only his primary group, local groups, and Domain Admins.
BTW, I think this is the issue:
http://support.microsoft.com/kb/976063
I have had this problem also.
I found it eventually about 18 months ago. It is a security feature of Microsoft. There is a service that runs once per hour and removes the admins from the LDAP search. If you do a query as anonymous, you will receive the correct answer for 1 hour. After one hour you will receive nothing. If you log in as a domain user, you will receive the correct information. That is why you get different results.
I do not at this point remember the service name but I am searching for it now. I found it originally on Microsoft tech net about 18 months ago, but by now, I don't remember it.
The point was that the only answer to it is
Disable that service and it does many other security items so that is not a good idea.
Change the LDAP searches to run under a domain user's log in (we have done that on some users)
Create a bogus duplicate contact with the same information for each of our admins. This is probably the easiest and quickest, but the most prone to developing wrong information over time.
The rational of this security feature is to hide all domain admins from random anonymous searches so their credentials can't be compromised by an encyclopedia password attack.
Calvin Thomas
My answer was deleted, but the problem was, in fact UAC as described in http://support.microsoft.com/kb/976063. The issue is that Domain Admins, when UAC is enabled on the DC, actually exist in two states. One that is a member of the domain admins group (i.e., the UAC 'shadow' user) and another that is the normal user. It appears that the DC only returns the former when queried with LDAP. By creating a new group, making that group a member of Domain Admins instead of the accounts themselves, and putting the accounts in the new group, the problem was resolved.