I'm trying to use MeetEasier application to show availability of all our bookable rooms. It works for some rooms in another office of our organisation. For my office it does not work. First I thought it was because all rooms were not yet moved off premises to Office365, but now when they all are in Office365 I still get the same error: "The specified folder could not be found in the store" (errorfoldernotfound). Since it works great for some rooms where my user has not been specifically granted access to (those in other offices) I believe that the problem has to do with the rights/configuration of the rooms and not my user. What are your thoughts? What can I ask our IT guys to try? (I don't have access or knowledge of AD etc)
In my experience, this is usually a permissions issue. For O365 your access id should have impersonation access to all rooms, as opposed to delegation (all access) rights. Your IT folks should be able to confirm this. Not familiar with MeetEasier, but presumably they have an option to select impersonation?
Related
I have a websites agriculture related with info's.
The script is very limited and do not allow me to create a classified section to my website, so, i need to create another one.
For the new website (created on subdomain, but with the same script), if i use the same database, user accounts will be kept?
In fact, that's what interests me. My users from the info's site automatically keep their accounts on the classified site, without the need for another account.
I just want to keep user accounts and nothing else.
enter image description here
The database should keep all of the data in it regardless of how many sites its connected to, however all of said sites can now see and edit it.
I have a Microsoft Teams free account that I created under an earlier organization name that I now wish to change. This is because my second Teams site undesirably reveals that it exists under the original organization name of my first Teams site.
Now, inviting users to my second Teams site inadvertently discloses to them that I also run the first Teams site. It comes up during certain Microsoft authentication screens. I don't want them to see that; it's distracting. Although both are non-profits, one organization has nothing to do with the other. A new user entering my second Teams site by invitation may feel confused when, upon initial entry, they're presented with my first organization's name.
I've since learned that I can indeed change my original organization name. Creating my first MS Teams site implicitly created the organization by that name within a personal Azure account that uses my credentials. It's at https://portal.azure.com, and my first Teams site shows up in there. It appears as a group within Azure Active Directory (AAD). My personal directory itself bears that initial name of my organization. The same name was automatically applied to the group representing my first Teams site.
Now, the directory itself is identified both by
the organization name, and
a corresponding subdomain name.
Both were the same, except the subdomain had no spaces embedded in it, obviously.
While I can change the directory's organization name, I don't see how to change the URL subdomain name (e.g., MySite.onmicrosoft.com) for my Teams site.
I know Microsoft Teams users aren't ever exposed to that technical subdomain information in normal everyday use anyway. However, that original name does become revealed when a new user is invited to the new Teams site. On the Android app, for example, upon initial login and setup, the new Teams user is asked to tap on the organization name. And there was my first disappointment, because it was the name of the other unrelated organization! After tapping it, users are then led to the correct Teams site that I did intend to make available to them.
That's what prompted me to want to change my organization name.
I was successful with that by changing the organization name under Properties for my directory. THis resolved the issue for the newly authenticated Android Microsoft Teams user.
However, I cannot see how to rename the subdomain itself. And that's important, because PC users at least (or those trying to enter my Teams site from a web browser) are in fact presented with a permissions prompt where that undesired subdomain name appears!
Is there a way to rename the subdomain?
POSTSCRIPT - Guess what? I can create new directories in AAD alongside my original one! What if I move my Teams group from the unrelated directory to a new one I create? Would that be safe? Will my Teams site still be functional?
To answer your edit. a teams organization is associated with a specific azure active directory, even if you have a second directory, i don't believe there is any way to "move" things across. you would have to create everything from scratch.
to answer your general question, you would probably have to create a new directory as you described, then create a new teams, replicate the information, remove all the users from the old teams. and remove them from the original directory. then invite them to the newly created one.
The reason for this is, if you invite someone, you are essentially adding their email / login to your azure tenant. of they have been invited to multiple teams tenants. then when they log into teams there is functionality for them to switch between all the directories that they are a guest of. so they will be able to see it. the only way to remove that is to delete the guest users from azure ad.
I work for a company where we started to share the PowerBI license for users without the Office plan. They started asking us to give them access to the Outlook to be in touch with newsletters and other reports from PowerBI. Our organization is not allowing to supply an Office license to PowerBI users.
I have a few questions :
Is there a chance to forward emails to their private mailboxes without converting them to SharedMailbox?
if I add a PowerBI license with Office plan and convert it to shared the PowerBI will be disabled on that account? If not is it possible to take it off or do I need to convert it to the regular mailbox to take it off?
I know about Mail Flow rules, are they safe to use? They are global rules either way.
I am excluding here a Contact user with one reason PowerBI license cannot be added to a Contact user.
Thanks for any suggestions
Found an answer,
Create AD account synch it with O365 move it to correct OU,
go to the user created earlier -> Attribute Editor -> Attribute: targetAddress add: SMTP:youraddress#something.com
Wait to synch and test. All emails should be redirected to the target address without having the license.
We have an application where we store users login name in the format domain\username. We authenticate via windows and then get additional info from our database by matching the domain\username we get from the user to our database.
Now they want to move to the cloud. We authenticate users via apps in Azure AD. However, the user identifier we get back is first.last#domain.com.
I have fiddled around with https://graph.microsoft.com/v1.0/users/email and the select command to try and get the 'old' name. Howev,er I have not yet found out how to get it.
The reason they move to the cloud is that they are merging two ADs. So some users will be DomainA and some DomainB, but in the same tenant. So my first thought was to try and convert the mail to the other format. However, the two different ADs have different naming standards. One has DOMAINA\fila (two first letters from the first name and two first letters from the last name) and the other one has DOMAINB\firlas. Also it feels really ugly to try and solve it that way.
Is it possible to fetch the users loginname formatted as domain\username via Microsoft Graph?
Using the beta edition of Graph, you can obtain the user's domain and username from the onPremisesDomainName and onPremisesSamAccountName properties:
/beta/users?$select=userPrincipalName,onPremisesDomainName,onPremisesSamAccountName
The domain is stored as a FQDN so you'll need to do some translation. For example, domainName.ad.contoso.com might translate to domainName\).
This will give you a workaround so you can match up users with your internal databases. It is however only a temporary solution. Long-term, you really want to migrate to using the userPrincipalName. This is the primary user identifier and guaranteed to be unique within a given tenant.
Azure AD is a little different than the legacy Active Directory. Certain concepts from legacy AD such as Organizational Units (OUs), Group Policy Objects (GPOs), Kerberos Authentication, Lightweight Directory Access Protocol (LDAP), Domain trusts between multiple domains, and several others simply do not exist in the cloud.
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.