We have recently integrated MS teams API so that clients can directly schedule their meetings from our dashboard. The integration worked fine and everything worked when we tested internally. Now however when clients tried to use this integration, they are facing issues.
When they are taken to authorization screen and they approve the request, it says "Sorry, but we're having trouble with signing you in"
and the Troubleshooting details says:
Application with identifier was not found in the director. This can happen if the application has not been installed by the administrator of the tenant...
I've attached screenshot here. The permission/scope we are using are: OnlineMeetings.ReadWrite, offline_access
I already asked this question on MS forum but didn't get any answer there yet. Adding link here: https://learn.microsoft.com/en-us/answers/questions/339273/ms-teams-integration-tenant-administrator-permissi.html
To access the application for other organisation, you need to enable the multi tenant configuration in application registration.You need to enable the multi tenant in azure where you have registered your application. Please check this document for more info.
Is there a way to login to a web application using one's windows credentials? Note that I'm expecting to do this in a promptless way i.e if the user selects "login using your windows credentials" it won't ask for them the first time only or anything similar.
I've read some things regarding NTLM and Kerberos and Negotiate but I got confused since they seem different to me but sources say Kerberos is the successor of NTLM and should be favored over it however people still use NTLM (version 2) for some reason.
I'd like to have some basic understanding of what is expected to work and what isn't before I start getting in deep into a documentation.
In a company network there is a web page, which uses kerberos single sign on. I am connecting to this network via VPN.
When using Mac, I can just write in the console kinit username#REALM.LOCAL, I get the ticket and after this I can open the web page in a browser and it works.
The other story happens on windows. I have my PC, I don't want it to become a member of the company domain. Via MIT Kerberos Client I can get a kerberos ticket, but of course no browser is aware of its existence.
Is there a way to feed this ticket to a browser on windows?
Safari is very friendly, it will give your kerberos tickets to anybody. IE and firefox need to be configured to do this and I'm not sure if they will have access to the kerberos tickets unless your windows box is in the AD domain.
Basically, you need to configure your browser to support SPNEGO. With firefox, you need to tweak some variables in about:config See
http://www.microhowto.info/howto/configure_firefox_to_authenticate_using_spnego_and_kerberos.html
for the exact details. IE is a whole lot trickier.
I am new to tridion and trying to setup a new instance of tridion 2011. I was able to successfully publish all my requests to file system and broker db. Suddenly it stopped publishing and all requests are stuck in "Ready to transport" mode.
I have already gone through many related threads on this forum, but could not sort out the problem. I am using Widows server 2008, with Jre 1.6 (32 bit and 64 bit both installed). Any pointer to finding the issue will be appreciated.
First thing to check is if your transport service is running.
Second thing I would look at is the config files to make sure the transport service is looking in the same directory that the publisher is storing them. Then see if files are being dropped in the transactions folder on the CM machine.
In our environment this issue arose due to a change in the SSL ciphers supported on our Content Deployer server. We are using the SSHFTP transport protocol and for security reasons the RC-4 cipher suite that had been supported by the CD server was no longer supported. We logged a case with SDL support and they issued Hotfix CD_2011.1.2.2350 which adds support for the stronger ciphers.
Unfortunately, the logs gave absolutely no indication of the issue, even with TRACE level logging.
So if you face this issue and you're using SSHFTP and the other solutions don't work for you, maybe this will help.
I heard that on Windows you can login from a web browser to the web server without going through the usual login entering username and password but using instead the credentials from Windows directly, using the NTLM protocol.
How is this achieved? Does the web server need to support some additional authentication?
Update: I'm asking for a generic web server, not just IIS. How to do that on Apache for instance?
The webserver just needs to be configured to support Windows authentication (which will be NTLM, or - better - Kerberos if both client and server are W2K or later). I believe that IIS or Apache can be configured to do that.
The browser also has to support this - at least IE does so (not sure about the others, it may be possible). edit: looks like firefox has some support for this too, and safari on MacOS
edit: for details on apache, google modules for NTLM authentication. Kerberos modules also exist. as per other answers, this really only works on an Intranet - not just because the browser needs to be in an Intranet zone (only applies to IE), but because any intervening firewall will typically stop this working, and because the necessary interdomain trusts will probably not exist. It's also a bit trickier to make work if the apache server is on UNIX, and especially if you also have Kerberos servers on UNIX in the mix, but still possible.
It will only be seamless in a specific situation; namely the webserver needs to support NTLM (for example, IIS), and it needs to be in a zone that the client is configured to trust (The "Intranet Zone" in IE parlance, unless the end user has tweaked their settings)
If your webserver and client pc's are on a network secured by Active Directory or similar, you can set 'Windows Integrated Security' in IIS on the web server for the website which automatically logs in all I.E clients (That are allowed).
As stated previously, NTLM is typically used if your back end is Windows Managed (MS Active Directory). However, there are also modules available for Apache that will tie into this: mod_ntlm.
Since this is it's own protocol, it is required that the browser is able to understand this protocol and reply to the authentication challenges. I don't know which browsers support this off hand, but my assumption would be that most do.
From my experience, kerberos is more of a prefered method, but I have not worked with it much, so unfortunately, I don't have much advise as far as that goes.
On a side note, I recall reading somewhere that the JRE also has ways of tying into NTLM on your web server in order to obtain identity information for the authenticated user. As stated previously, .NET has support for this as well.
Also, Firefox does not support NTLM by default but it can be configured using the following tut: http://www.crossedconnections.org/w/?p=89
If you set the IIS settings to require authentication then your users will need to log in to access the page. They then have any rights (if not an interface) to anything on that server that they would if they logged in the normal way (from the console).
Other than this, I am not sure what you are referring to.
Yes this is possible. It is often used in intranet applications where users are. windows uses NTLM or Kerberos to authorize the user against a central service, typically Active Directory on the windows platform. On the .NET platform the current user information can be accessed through the System.Threading.Thread.CurrentPrincipal.Identity instance.
You might also want to look into Jespa. It seems a little bit more straight forward than Kerberos but provides good ntlm sso capabilities.
I was looking for more information about Kerberos (because NTLM, even v2, become deprecated with AD 2008), and I found this article, explaining how make it work with Apache (as you mentionned it).
http://blog.scottlowe.org/2006/08/10/kerberos-based-sso-with-apache/
This question is probably outdated (or at least solved), but if it can help someone ...