I have the following requirement. I have many users log into my system either from within my domain (intranet and on the VPN) or from outside the domain from public internet. I would like to know from where users log in and route them separately. (bind them to specific endpoints on a WCF service)
I tried using the "Environment" variable. But there is one special case that I would like to address. People who have a laptop that is registered in the domain always show as "Being in Domain" even when logging in from an outside network. How do I go about solving this?
Any help would be appreciated.
I'm not sure if you can reliably do this. I think the best course of action would be to have an internal server and an external server (or at least two separate applications, one accessible from the local intranet and one accessible from the internet. When accessing the application internally the companies internal DNS would route to the internal version of the application. And externally would route to the external version of the application.
There are similar questions here,
How to detect if machine is joined to domain (in C#)?
and here
Detecting a users domain in asp.net
Related
So I inherited a domain for a client that has the same internal/external domain name (Server 2012r2). This caused a problem for users inside the domain trying to reach the external site.
After some research I decided to create an IIS redirect to the external website/IP, to enable people inside the domain to reach the external website. This worked just fine.
Basically did what is at this link: http://oddjobsintech.com/active-directory-tip-access-external-website-with-the-same-domain-name-as-your-internal-domain/
Basically, just created a www A record and installed IIS on domain controllers with HTTP redirect to the external site.
However, now they've acquired an SSL cert from GoDaddy, and I installed on the external webserver, which works perfectly fine outside of the domain. But once again, internally if you try to type "https:" the same issue with the page not resolving properly shows up.
Anybody know why this is and/or a possible fix (other than renaming the domain)?
An Domain Controller is the hearth from every Microsoft Active Directory environment and Microsoft did a lot to prevent the access to it like written here:
Domain controllers, by default, restrict the types of user accounts
that have the ability to log on locally. By default, only members of
the Account Operators, Administrators, Backup Operators, Print
Operators, and Server Operators groups have the Allowed logon locally
system right.
So you shouldn´t install an IIS on an domain controller. If the IIS will he hacked, the hacker has direct access to the whole domain!
According to your issue I would check the DNS environment if it is configured correctly.
I have 2 web roles in a cloud service; my API and my Web Client. Im trying to setup SSL for both. My question is, do I need two SSL certificates? Do I need 2 domain names?
The endpoint for my api is my.ip.add.ress. The endpoint for my webclient is my.ip.add.ress:8080.
Im not sure how to add the dns entrees for this as there is nowhere for me to input the port number (which I have learned is because its out of the scope of the dns system).
What am I not understanding? This seems to be a pretty standard scenario with Azure Cloud Services (it is set up this way in the example project in this tutorial, for instance http://msdn.microsoft.com/en-us/library/dn735914.aspx) but I can't find anywhere that explains explicitly how to handle this scenario.
First, you are right about DNS not handling port number. For your case, you can simply use one SSL certificate for both endpoints and make the two endpoints have the same domain name. Based on which port is used by user request, the request will be routed to the correct endpoint (API vs. Web Client). Like you said this is a relative common scenario. There is no need to complicate things.
Let's assume you have one domain www.dm.com pointing to the ip address. To access your Web API, your users need to hit https://www.dm.com, without port number which defaults to 443. To access your web client, your users need to hit https://www.dm.com:8080. If you want users to use default port 443 for both web api and web client, you need to create two cloud services instead of one, then web api on one cloud service and web client on the other cloud service. Billing wise, you will be charged the same as one cloud service.
Are there any reasons you want to make 2 different domains and in turn 2 SSL certificates? If so, it is still possible. Based on your requirements, you may have to add extra logic to block requests from the other domain.
Why Cloudbees doesn't allow wildcart domains by default? Heroku makes really easy for user to add/remove wildcart domains like *.me.com. I filed a ticket over 24 hours but still there is no one trying to resolve that ticket.
Wildcard SSL domains are supported by RUN#cloud, however it is not exposed in the user interface.
As to why it's not in the UI - it's not a common request, and as such hasn't inflicted enough pain on support to warrant implementing a user configurable interface for it as yet.
There is further information on Custom Application Domains, wildcard domains and how to raise a request with the appropriate information at https://wiki.cloudbees.com/bin/view/RUN/Custom+Application+Domains
I'm working on a project the requires me to register a domain for a user based on input. I want an API that I can call that will let me register a free domain for the user. The TLD does not matter, i'm open to things like .co.cc, .co.nr, etc. I already saw the .TK affiliate program, but it seemed a little shady. Again, both the API and the domain have to be free.
Thanks
I'm not aware of any free domain registries. You probably want to look into creating a DNS sub-domain, where if you have the domain "myapp.com", a user can create the subdomain "user1.myapp.com". Those would be free, depending on how you're hosted and who runs your DNS.
Background: Customer X is a low-budget non-profit outfit that nonetheless has a lot of activity configured on virtual hosts, and the virtual hosts multiply very frequently. Customer X also has a lot of users and is interested in getting them over to a single sign on solution. This way, all the users can use the same credentials on all the virtual hosts.
It has also pretty much been mandated that we use [Shibboleth Single-Sign-on](http://en.wikipedia.org/wiki/Shibboleth_(Internet2) to handle the authentication.
Problem: Shibboleth Single Sign On uses SSL as part of its protocol, but getting multiple virtual hosts to use SSL is not a walk in the park.
This question about virtual-hosts with SSL details some of the pitfalls.
Question: What is the best way to proceed with this scenario (summary):
multiple virtual hosts on apache
setting up a distinct IP and NIC for each virtual host is pretty much not an option
SSL pretty much requires a separate IP
they all need some kind of SSO
we are being heavily pressured to use Shibboleth as the SSO provider
Is there anything we may be missing here or some way to resolve this, short of requiring a separate IP for all vhosts?
I have a client with the exact same situation and the way that they solved it was to buy a wildcard domain *.example.com and have all the virtual hosts have a specific subdomain at example.com to get around this problem.
This was with Shibboleth and did work out, although you need the hosts domains to agree to fall under one parent domain for the SSO.
If the data itself you exchange with the given site (the Service Provider) is not security sensitive you can just turn off SSL for accessing the site.
There are two SSL channels we are talking about.
one used when the SP communicates with the IDP
the other is accessing the site
Only the latter one should be a "well-known" (what you have to pay for) certificate.
One can use HTTP artifacts to avoid POSTing data from the idp (which is SSL protected) to the SP which is not. This way the browsers security warning can be avoided.
This setup still protects user credentials. The data you exchange with the site will be not.