I want to know which user is logged in multiple Lync client in different machines.
So how should I get to know and which SDK will gives this details?
With either UCMA or Lync Client SDK you can determine if one or more clients are logged in using presence subscription. This will give you a simple "there is a endpoint running somewhere or not", but that's not what you are asking for.
As far as I know, there is no way to do what you want with UCMA or the Lync Client SDK.
You can do it with the Lync Server SDK, but it will take some work. You can do with either a MSPL script (limited) or MSPL/C# proxy application (more options) that filters for REGISTER requests/responses.
From the register request you can determine if it's a register (coming online), unregister (going offline) or re-registration (replacing existing registration) by the expires header / contact uri expires parameter (0 == unregister).
You can determine the user type by the user-agent header, mainly between Lync Client (e.g. "UCCAPI/15.0.4771.1000 OC/15.0.4771.1001 (Skype for Business)"), Lync Phone, UCMA endpoint (e.g. RTCC/5.0.0.0 Xxxx).
You also need to handle registration timeout and re-registration.
With this knowledge you have a running knowledge of what user agents are running for the users you wish to track and do with what you wish.
So if you really want to do this, I would as a prerequisite to starting:
Get familiar with sip messaging.
Play around with building / running the examples in the Lync Server SDK.
MSPL will be a solution, but that will ask you some work like "Shane Powell" said.
The most easy way will be to use Powershell...
I use for my part "Get-CsConnections" from ehloworld.
Is a powershell script who it will shows you all the details of connection about any users.
Related
Today I received an email with the above as subject and this in the body :
Dear Android developer,
To keep your access to Google APIs, review the OAuth client used by your Android application by September 30, 2019.
Google requires developers to register all Android apps that request Google Account data and interact with Google APIs. The following Android package name you maintain may require the registration of an OAuth client:
com.myappname (not my real app name)
To register an OAuth client, make sure to either:
Have an existing project on Google Cloud Platform for the app you publish.
Create a new project and configure it correctly.
For the app, make sure there’s an Android OAuth client for the package name and SHA-1 signing-certificate fingerprint. If your app uses certain sensitive or restricted scopes, you’ll also need to submit your app for verification.
Apps without a properly registered OAuth client may not get Google Account or API data after September 30, 2019.
Thanks,
Google API team
I have a GCP project that has 2 OAuth 2.0 client IDs with the package name for this Android app (one Debug, one Release) and SHA1 fingerprint. Google login has been working for years with no issue. App is also verified (though we don't use any sensitive scopes). Anybody received a similar email or know what possibly might be missing?
This is neither a misfire or a threat. It's more of a reminder than anything else. All people who interact with Google User data get this email, and the point of this is to simply tell people "Hey, if you need to, register an OAuth client, do it by September 30th.". This is explicitly clear on the wording of the email. You can see here:
The following Android package name you maintain may require the registration of an OAuth client
The keyword being "may". Since, from what you've posted, you already registered your client, you should be good to go. Everything beyond this:
com.myappname (not my real app name)
Is nothing more than instructions on how to register your client. Everything above it is warning, that if you haven't, register your client. It's saying that it's possible that you haven't registered your client, so make sure you have.
Long story short, if you registered your client, you're good to go.
Since there are a lot of APIs for Skype for Business, and the documentation isn't always very clear, and many hours have already been wasted developing for an wrong API, here I am asking you:
I am looking for an API which enables me to administrate multiple Skype for Business Online users. Required Features:
Skype for Business Online compatible
Read and Set Presence from other users
Set Call Forwarding for other users
And all that without knowing the user's passwords.
I already started developing for UCWA until I realized every user's password is needed for setting the presence.
I am aware of the capabilities of an UCMA Trusted Application, but unfortunately S4B Online compatibility is required. Maybe it's possible to make it compatible with an interface?
Every thought on this is much appreciated.
This would have been possible with on premise Skype for Business:
A trusted UCMA application to read and set presence
Automating SEFAUtil to set the call forwarding options (which relies on UCMA)
Unfortunately (as you rightly said), neither of these are supported against Online, as there is no direct replacement for UCMA. There's unlikely to be a replacement in the future as Microsoft are pushing to move customers away from SfB and on to Teams.
Depending on exactly how you need this to work, one option would be to use the Lync 2013 client SDK, which still works against the SfB client (but is now out of mainstream support). You'd need to create a "hidden" application that gets deployed to the users desktops, and sends and receives commands to/from your centralised administration app. In that way, you'd be able to send commands to the user's application, which would then automate the client into setting presence and changing call forwarding. Some obvious downsides, though:
A lot of work to build out the client/server applications and manage the connections between them
Would only work when the user is signed in to their client (as the Client SDK uses the running instance of the Skype client)
Depends on being able to deploy to a client machine
Not an ideal solution, I know, but with Teams replacing SfB Online (over time), your options are going to be limited!
I am writing an iOS app that will use data from Skype for Business, and am following the guide from Microsoft called Create an application, which must be done before being able to use the API's.
What is unclear to me is when exactly to create an application? Is it:
per client, i.e. only once ever?
per home server?
per user?
per session?
The application here is more a kind of "virtual object (the application)"
which needs to be created here, until you can start using Skype for Business (SfB) features.
So your question isn´t that easy to answer as its not clear what you wish to perform (e.g. did you wish to login, perform some task and then logoff again?). So it depends a little bit on your application and which features you are using. Therefore its no "only once ever" as the "virtual object (the application)" is destroyed at some time (e.g. your application crash and the SfB server no longer got a "yes we are still here and are listening" requests). This is controlled by the lifetime of a token which is eight (8) hours for authenticated users so you need to renew that or your application will stop working. So its more a "per taskuser & login & time" approach...
Microsoft explained the above as well in the following statement: "This is how you register your application with UCWA 2.0 as an agent of the user whose credentials you obtained in a previous step."
If you are creating an iOS application that will interact with a Skype for Business server, you can use the Skype for Business App SDK for iOS. This client library handles anonymous meeting joins for users who are not homed on a Skype for Business server. For all other Skype for Business features, you'll need to use an iOS REST library of your choice. The REST endpoint that works best for a client application is actually the Skype Web SDK. The Skype Trusted Application API is designed for server-to-server communications where your server is talking to a Skype for Business Online instance. In that case, your server obtains and processes Skype data and then it makes it available to a client such as an iOS app. Unless you intend to create a middle tier between Skype for Business Online and your iOS app, you should use the Web SDK.
I'm new to web services and am creating HTTP services using .NET Web API 2.
The consumers of the services will be other applications, but in the future I foresee web applications (browsers, mobile apps) using them. The services simply serve data to the consumers (no create/update/delete).
All applications, including the API, are located on our enterprise intranet. Nothing outward facing.
I was told to use Integrated Windows Authentication for the services. Can an API key also be used on the same services to authenticate the application that is making the calls?
I'm not even sure doing this makes sense. Can the consuming application (i.e executable run on a server) send account info? My thought is that Windows Authentication isn't necessary and token authentication will suffice. Others have told me to use both. I'm not sure that's possible and haven't found anything showing me it is.
An API key is a parameter passed to the service interface, so it can be passed with any type of auth on the backend.
But usually, and api key is used to determine whether a user is allowed to use a specific API. For example, if only a subset of users that have windows accounts are allowed to use the api, then maybe that might make sense, because, even if they could authenticate with their windows account, they could still be determined to be unauthorized by the fact that they did not pass a valid auth key.
That said, you could also do the same things with some kind of policy, for example, checking if the user has the correct role to call the api method. It makes more sense when you are giving people access to an api through the internet.
I'm working on a Windows Phone 7 application, and to go with it I will need a web service to send out live tile push notifications. I will save the clients URI channel in a database and every hour or so I will send out the correct live tile to all the subscribed clients. I will not be sending out any sensitive data to the clients, nor do the clients send any data to the service save for their channel URI, and I've made sure to protect the database against any sql-injections.
The exposed methods are for registering and unregistering a client, as well as sending the correct live tile to a client that requests it.
Given this information, does anyone have any recommendations on how I should secure the service, or is security even needed to begin with in this case?
Thanks!
EDIT:
Thanks for the answers! My peers decided to not use any security at all though, other than purging faulty requests from the database, since the scope of the application is quite limited and no sensitive data is being transmitted. Let's hope it won't bite us in our behinds later on, eh!
Unfortunately the best solution to this problem (at the moment) is to generate a hash in your app and use that to verify the data is really coming from your app. Obviously you'll need to obfuscate tyour code if doing this.
This is the best you can do without any authentication against the backend.
If you can, have the users register and authenticate with the backend and then tie this authentication token to the ANID of the device and do everything over SSL.
Unfortunately, currenlty, security of services and prevention of spoffed requests is quite tricky with WP7 without requiring a login to the backend.
Make sure you secure your channel to your backend service with SSL. This way the data you send to the server such as a the ChannelUri will be secure.
Building a hash into your application isnt security. People could get your XAP and decompile it to get the hash.
IMHO you are better to ensure your ChannelUri (unique to your app and not "stored" in your XAP anywhere) is secured when you send it.
On the backend just make sure you purge records that fail when you try and send it a tile notification. This will get rid of any records entered by non-phone parties.
Bottom line is that you need a login infrastructure with your backend to properly ensure only valid users are using your service.