I am trying to build a solution using the UCMA sdk but do not have access to the config store. Is it possible to use UCMA without it? I have a username/password I can use to log into the lync network and thought perhaps I could access things like that.
Yep, you can do this with a UserEndpoint. It doesn't require any replication with the config store (as long as you have a username and password which you've said you have).
I have a comparison between application & user endpoints here: http://blog.thoughtstuff.co.uk/2014/01/ucma-endpoints-choosing-between-application-and-user-endpoints/
and a worked example of using User Endpoints to send an IM here:http://blog.thoughtstuff.co.uk/2013/03/creating-ucma-applications-with-a-userapplication-instance-example-sending-ims/
UCMA applications can run in two different modes:
Untrusted (Client) Application.
In this mode you can't create "ApplicationEndpoint"'s but you can create "UserEndpoint"'s if you have the sip address and password for the user.
Trusted (Server) Application.
In this mode you can create "ApplicationEndpoint"'s and you can create impersonate any user with "UserEndpoint" without needing the user password.
There are two types of setups for Trusted Application's.
2.1. Auto Provisioned Trusted Application
This one is very easy to setup with code but very hard to setup to run on the machine. I don't really recommend this setup as the machine setup requirements are very high.
2.2. Manual Provisioned Trusted Application
This one has a lot more "setup" code but is easier to setup a machine to run on. I would recommend this setup as I find it far easier to setup overall.
Both types of Trusted Applications require you to setup the Trusted Application details within Lync before you can run them.
Which UCMA application setup you use is based on how you configure the CollaborationPlatform instance.
Basic Untrusted (Client) Application:
var clientPlatformSettings = new ClientPlatformSettings("lync.front.end.server.address", SipTransportType.Tls)
var collaborationPlatform = new CollaborationPlatform(clientPlatformSettings);
...
await Task.Factory.FromAsync(collaborationPlatform.BeginStartup, collaborationPlatform.EndStartup, null);
Auto Provisioned Trusted Application:
var serverPlatformSettings = new ProvisionedApplicationPlatformSettings("lync.front.end.server.address", "trusted application id")
var collaborationPlatform = new CollaborationPlatform(serverPlatformSettings);
...
await Task.Factory.FromAsync(collaborationPlatform.BeginStartup, collaborationPlatform.EndStartup, null);
Manual Provisioned Trusted Application:
var certificate = CertificateHelper.GetLocalCertificate("trusted application pool qfdn");
var settings = new ServerPlatformSettings("lync.front.end.server.address", Dns.GetHostEntry("localhost").HostName, trusted_application_port, trusted_application_gruu, certificate);
...
await Task.Factory.FromAsync(collaborationPlatform.BeginStartup, collaborationPlatform.EndStartup, null);
There are a lot of missing details. Once you know what type of UCMA application you want to develop, you can search on the internet for specific examples of that type.
Related
I have a request to restrict the access (access control) to a small user community in GCP.
Let me explain the question.
This is the current set up:
A valid GCP Organization: MyOrganization.com (under which the GCP project is deployed / provisioned)
Cloud DNS (To configure domain names, A & TXT records, zones and subdomains to build the URL for the application).
Oauth client set up (tokens, authorized redirects URIs, etc.).
HTTPS load balancer (GKE -managed k8s service- with ingress service), SSL certificate and keys issued by a trusted CA.
The application was built using python + Django framework.
I have already deployed the application (GCP resources) and it is working smooth.
The thing is that, since we are working in GCP, all IAM users who has a valid userID#MyOrgnization.com can access the application (https://URL-for-my-Appl.com).
Now, I have a new request, which consists in restricting access (access control) to the application only for a small user community within that GCP organization.
For example, I need to ensure that only specific IAM users can access the application (https://URL-for-my-Appl.com), such as:
user1#MyOrganization.com
user2#MyOrganization.com
user3#MyOrganization.com
user4#MyOrganization.com
How could I do that, taking into account the info I sent earlier ?
thanks!
You can use Cloud IAP (Identity Aware Proxy) in order to do that.
Identity-Aware Proxy (IAP) lets you manage access to applications
running in App Engine standard environment, App Engine flexible
environment, Compute Engine, and GKE. IAP establishes a central
authorization layer for applications accessed by HTTPS, so you can
adopt an application-level access control model instead of using
network-level firewalls. When you turn on IAP, you must also use
signed headers or the App Engine standard environment Users API to
secure your app.
Note: you can configure it on your load balancer.
It's not clear in your question if your application uses google auth (but considering that you talk about org-restricted login I think so) - if that's the case you should be able to enable it without virtually touching anything in your application if you are using the Users API.
The best and easiest solution is to deploy IAP (Identity Aware Proxy) on your HTTPS Loadbalancer
Then, grant only the user that you want (or create a gsuite user group and grant it, it's often easier to manage)
We have an application which is hosted on the on-premises Windows server (IIS) server
now I created a windows server on azure and building a web app for it.where the application needs to authenticate the user by windows server (DC) using kerbrose protocol but I couldn't find any documentation regarding this from Microsoft's side
Is the above query possible to be implemented in the azure web app?
No, it's not possible. Windows Authentication is something for on-premise deployments. For Azure Web Sites Azure Active Directory is clearly the best option. Sync from AD to Azure Active Directory is also quite easy to setup.
If you still want to absolutely use Windows Auth and host your website on Azure, you can create Windows VM and host your website there. You then need to join the VM to your AD. To this, both VMs must be in the same network. So if your VM is on-premise you will need to create an site-to-site VPN.
For more information, follow this SO which also discussed about this.
If your intention is to join the VM hosting the website to a domain then as others have mentioned, this isn't possible.
However, doing Kerberos authentication itself within an Azure website isn't particularly difficult, but it does require manual implementation. Windows natively handles all of this for you on domain joined machines and and IIS exposes that functionality. Since you can't domain join you have to manually do all that heavy lifting and request and validate the tickets yourself.
This involves creating a service account in Active Directory and keeping the account password in sync. Once you have that you need to indicate to the browser that it needs to negotiate auth, which is done with the WWW-Authenticate: negotiate header on a 401 response. The client, if configured to send tickets, will send a ticket in the Authorization: Negotiate YII... request header on a subsequent response. At this point you need to shove that negotiate header and that original service account password into something that can validate Kerberos tickets. Windows SSPI will do this for you, but it's a pain. I built a library that'll do this for you: Kerberos.NET. YMMV with what works best for you.
All of that said, it may be more beneficial to switch over to a more modern authentication mechanism like OAuth/OpenIDConnect/SAML.
There are several ways depending on if you have to allow access to users who are associated with a on-premise Active Directory or not.
You should have a look at this service: https://learn.microsoft.com/en-us/azure/active-directory-domain-services/
It will offer an Active Directory within Azure where you can domain join your VM to and then using Kerberos as authentication protocol (should work the same way like on prem).
The other option would be to create a new Active Directory within your Virtual Network (via 1 or 2 small Windows Server VMs where you create the AD).
The good thing if you are using Active Directory Domain Services would be that you could extend it to your on-prem Active Directory by synchronizing or federating your on-prem AD.
There are more informations regarding these scenarios here:
https://learn.microsoft.com/en-us/azure/active-directory/hybrid/whatis-hybrid-identity
For a Azure App Service - Web App you would connect it to your Azure Active Directory (AAD) and use the hybrid identity model to allow users who originate from an on-prem AD access to it:
https://learn.microsoft.com/en-us/azure/app-service/configure-authentication-provider-aad
Hope this helps a bit, it is a rather complicated topic you are digging into.
There are similar questions to this one, but not quite the same...
I have a C# program that is using amqmdnet.dll (from 9.0.1.0 MQC Redist)
The code to connect is:
Hashtable mqProperties = new Hashtable();
mqProperties.Add(MQC.CHANNEL_PROPERTY, channelName);
mqProperties.Add(MQC.HOST_NAME_PROPERTY, hostname);
mqProperties.Add(MQC.PORT_PROPERTY, port);
queueManager = new MQQueueManager(strQueueManagerName, mqProperties);
It works fine and writes to the queue. I assume it picks up my current login id from Windows.
When I run the same code on IIS, it connects but fails with an auth error 2035 when trying to write to the Queue.I assume this is because IIS is running as a different user-id.
I tried adding:
mqProperties.Add(MQC.USER_ID_PROPERTY, "myuserid");
mqProperties.Add(MQC.PASSWORD_PROPERTY, "mypassword");
and it did not work. Trying "mydomain\myuserid" did not work either. Some other posts mentioned that MQ needs the Windows SID. I tried using that string, but that did not work either.
At this point, I am playing with this, so I'd prefer not to ask the admins to set up a new userid on the MQ server side. With this in mind, is there any way I can login when running under the IIS user, but pass in my userid/password or some other credential to make this work?
If the queue manager is v8.0 or later and is configured to use CONNAUTH and has ADOPTCTX(YES) set you can present an id and password. If it does not have this set then the value presented in the UserId and Password property of a .NET client will be ignored.
A IBM developerWorks MQdev blog post "MQCSP Password Protection in MQ V8 has details on how to do this in various languages."
For .NET you should be able to use what you have with the addition of the MQC.USE_MQCSP_AUTHENTICATION_PROPERTY set to true:
mqProperties.Add(MQC.USER_ID_PROPERTY, "myuserid");
mqProperties.Add(MQC.PASSWORD_PROPERTY, "mypassword");
mqProperties.Add(MQC.USE_MQCSP_AUTHENTICATION_PROPERTY, true);
The queue manager will then authenticate this ID. If the queue manager is set with ADOPTCTX(YES) then it will always use the authenticated ID for OAM checks. If it is set to ADOPTCTX(NO) it will still use the ID the process is running under to perform OAM checks. It is highly recommended that this be set to ADOPTCTX(YES).
Update 2017/02/20:
Related to the comment "I can see that it might be turned off by admins so that MQ relies on the larger organizational SSO infrastructure.". Without setting up CONNAUTH and ADOPTCTX(YES) you can assert any id you want to over the channel. If a CHLAUTH rule is not in place to block administrative users then you can obtain full MQ administrative authority without any form of authentication.
I need to be able to verify if a new siteminder web agent is already registered on the policy server. Is it possible to do this using Java?. I couldn't find the 12.5 SDK details or sample files.
Any input is welcomed.
The PolicyMgmtAPI in the Java SDK is what you are looking for. I have done this sort of thing with the Perl PolicyMgmtAPI (get trusted host, get agent, etc...)
If you want to do this from the Policy Server it is pretty easy. If you plan on implementing this type of thing in an application server you will need to also create a 4.x agent in order to communicate with the Policy Server for the PolicyMgmtAPI calls.
Assume system S owns a certificate C. The following quote suggests that if C is to be used by S's service apps to authenticate themselves to clients, then C should be stored in LCS. But if C is to be used by S's client apps to authenticate themselves to a service, then C should be stored inside CUS:
• The local computer store (LCS).
This contains the certificates
accessed by machine processes, such as
ASP.NET. Use this location to store
certificates that authenticate the
server to clients.
• The current user store (CUS). Interactive
applications typically place
certificates here for the computer's
current user. If you are creating a
client application, this is where you
typically place certificates that
authenticate a user to a service.
But next quote sort of negates the above, since it says if S's service is embedded in an application that runs under a user account, then certificate C should be stored inside CUS
Selecting where to store a certificate
depends how and when the service or
client runs. The following general
rules apply:
• If the service is a Windows service,
a service running in "server" mode
without any user interface under a
Network service account, use the local
machine store. Note that administrator
privileges are required to install
certificates into the local machine
store.
• If the service or client is embedded
in an application that runs under a
user account, then use the current
user store.
a) what is meant by service being embedded within an application? Is a WCF service running within Net. console application or within Asp.Net application considered to be embedded?
b) And why if app ( which embeds WCF service ) runs under the user account ( even if this account has admin priviliges ), should certificate be located in CUS? Does that mean if it is located within LCS, then S ( aka client app trying to send this certificate to the server ) won't be able to locate certificate?
thank you
a) A WCF service running within a .NET console application would be considered an "embedded" service according to that description. This is also referred to as a Self-hosted service.
If the service is running within an ASP.Net application, then it depends on what process is hosting the ASP.Net application, but normally that would be considered a service running in "server" mode.
b) In order for a service to authenticate itself to clients, the user under which the service process runs needs access to the private key corresponding to the certificate. The most convenient way to make this happen is to have the certificate (with private key) installed in the certificate store of the user that runs the process.
It is possible for an application running as any arbitrary user to access a certificate and private key stored in the local computer store as long as security permissions on them allow it.
It all boils down to the identity of the running process and whether it has permission to access the private key associated with the desired certificate.