I have a web server with two websites: a & b.
a is production.
b is testing/staging.
Whoever wrote these apps before me relies on
Request.ServerVariables("LOGON_USER")
which is assigned when the user authenticates against the server via Windows Authentication. On a, this works great, on b there's some weirdness:
I get my login prompt, but i can't use [domain]\myusername to login, I can do it with \\myusername though, same passwords (AD based). The IIS configs are identical as far as I can tell, the only inconsistency is a DNS CNAME pointing from a.domain.com to b.domain.com. Changing that DNS record to point at the IP fixed the problem, but I'm trying to understand what was going on.
Previous DNS record: b.domain.com > a.domain.com
Working DNS record: b.domain.com > 10.0.x.131
It should've been b > a > regular windows authentication, but for some reason I found myself using \\ , is it tacking on the domain name twice or something? And what exactly is \\ in regards to authentication?
Make sense?
A few thoughts.
Which specific version of the OS is your server running under? Microsoft in particular tends to have somewhat different behaviors across different versions, and the documentation is version-specific
It's difficult to answer "what's going on" questions because there's no way to be sure what's correct. I can toss out hypotheses (and will), and if you could phrase the question as a "how do I fix this" rather than a "what's going on" you could check if I'm right and respond, probably having acquired a bit more pertinent data along the way.
This sounds like it's more about deep system administration understanding than programming understanding - if you don't get what you need here, you might have better luck asking on serverfault.
That having been said, in the absence of other information, the "\" most likely results from one of two things.
It's possible that you have two different parts of the code that each adds a '\' on. Domain Names are in many cases valid both with and without the trailing '\'. Thus, it's quite possible that windows authentication adds one immediately after domain names and before login ids in order to ensure the separation between the two. If your DNS CNAME lookup is automatically adding one at the end of the domain name for similar reasons, the two might stack.
It's possible that somewhere in the DNS process the domain may have gone through a converter to change control characters into escape characters (as a way of avoiding certain security exploits). '\' is used as the basis of such escape characters, and thus requires an escape character of its own ('\').
Related
The scenario is - I need to send push notification to Apple push server hosted at gateway.sandbox.push.apple.com. This Apple server is load balanced and the destination IP address can be anything in 17.x.x.x block.
Now my server which will be requesting Apple server is in secure environment and is behind firewalls. I have got the IP range 17.x.x.x unblocked, but DNS resolving is not possible on that server. That server also doesn't have Internet access on it.
What I did was - I pinged the Apple server from another system and got the Apple server's IP address for the moment. Then I mapped that IP address with the DNS name in the hosts file of my Windows server. This worked, but now the IP address can change anytime at the Apple end, and this will break things.
What can I do in this scenario?
You can talk to your security people and in cooperation with them come up with a proper, internally supported, way to provide what you need. What you need is to look up an address, and then talk to that address. Currently, you are only provided half of that.
What you're asking us for is a way to circumvent your own organization's security policies (policies that admittedly appear stupid, but that's another matter entirely). Even if someone here can come up with a technical way to do what you ask that works for now, it's likely to break at any time, since you're working at odds with your own workplace. Also, what will your bosses say if they find out that you're violating security policies?
Security very often comes down to tradeoffs. As the saying goes, the only truly secure system is one that has been encased in concrete and sunk to the bottom of the sea. But such a system will also be somewhat difficult to get useful work out of, so usually we accept lesser security in order to get work done. In your case, the tradeoff currently sits in a place that prevents you from doing whatever it is you're working on. So your organization needs to make a choice: change the tradeoff so that your machine can look up names, or keep the current tradeoff and accept that your task will not be done.
I'm sorry that I can't give you a straight up "Sure, do this" kind of answer, but your problem really is not technical.
I need to determine whether a domain entered by a user is a standard domain e.g example.co.uk or just the TLD e.g co.uk.
Is there a way I can do this e.g. by querying nameservers using nslookup or dig commands?
Just for background, I'm building a tool which works with subdomains e.g. sub.domain.example.co.uk and need to be able to spilt each part of the subdomain into subdomain, domain and TLD parts.
Thanks,
Tom
The "problem" you are trying to solve isn't even well-defined.
There is no way to get this information from DNS itself. DNS makes no distinction between what you call a subdomain, a domain, and a TLD.
Browser makers and other interested parties have apparently not found any solution to this short of building and maintaining a list manually. And even that's an incomplete solution. For example, I know that in Canada you can register a domain as <your-label>.ca, <your-label>.<province>.ca, or <your-label>.<municipality>.<province>.ca, but the current version of Mozilla's list only accounts for the first two possibilities. (Listing all municipalities would be too burdensome anyway).
More importantly, the boundary between what is a "public" domain and a "private" domain isn't a technical one. You're not supposed to be able to register a domain under ac.jp unless you are a university (or similar) in Japan. You're not supposed to be able to register a domain under u-tokyo.ac.jp unless you are a department inside 東大 (or similar). Those two restrictions aren't fundamentally different on a technical level, yet one of those domains is considered "public" and the other one is not. It's a difference of politics/law.
Furthermore, if the public/private domain distinction is being used for security purposes (as it is used for example in web browsers to disallow supercookies), who says that different departments inside one university don't distrust each other just as much as different universities do? There's a well known piece of advice that applies: you shouldn't attempt to solve a political problem with a technical solution.
We have a web based client-server product. The client is expected to be used in the upwards of 1M users (a famous company is going to use it).
Our server is set up in the cloud. One of the major questions while designing is how to make the whole program future proof. Say:
Cloud provider goes down, then move automatically to backup in another cloud
Move to a different server altogether etc
The options we thought till now are:
DNS: Running a DNS name server on the cloud ourselves.
Directory server - The directory server also lives on the cloud
Have our server returning future movements and future URLs etc to the client - wherein the client is specifically designed to handle those scenarios
Since this should be a usual problem, which is the best solution for the same? Since our company is a very small one, we are looking at the least technically and financially expensive solution (say option 3 etc)?
Could someone provide some pointers for the same?
K
I would go for the directory server option. Its the most flexable and gives you the most control over what happens in a given situtaion.
To avoid the directory itself becoming a single point of failure I would have three or four of them running a different locations with different providers. Have the client app randomly choose one of the directoy urls at startup and work its way through them all until it finds one that works.
To make it really future proof you would probably need a simple protocol to dynamicly update the list of directory servers -- but be careful if this is badly implemented you will leave your clients open to all sorts of malicious spoofing attacks.
Re. DNS: requests can be cached, and it might take a while for the changes to propagate themselves (hours to days).
I'd go for a list of prioritized IPs that can be updated on the client. If one IP fails, the client would retry with 2nd, 3rd and so on.
I'm not sure I 100% understood your question, but if I did it boils down to: if my server moves, how can my clients find it?
That's exactly what DNS did in nearly the last three decades.
Every possible system you could choose would need to be bootstrapped with initial working data: address for a directory server, address of a working server to get an updated list of addresses, etc. That's what the root dns servers are for and OS vendors will do the bootstrapping part for you.
Sure DNS queries could be cached, that's how it is supposed to work and how it scales to internet size. You control the caching (read about the TTL) and you can usually keep it on sane values (doesn't make sense to keep it shorter than the absolute minimum time needed to re-deploy the server somewhere else).
When setting up a SharePoint farm, is it technically possible to use the following URL structure?
http://myfarm/webapp1
http://myfarm/webapp2
http://myfarm/webapp3
etc.
where each URL points to a different web application on the same farm/server.
MDRoz,
Generally speaking, the answer (in a vacuum) is "no." As far as SharePoint is concerned (or rather, IIS), a hostname without any qualifying port information can be mapped to one IIS website.
Now that I've said that: there are variety of creative ways you might address this, and most are going to involve URL re-writing and remapping. A couple of ideas that come to mind:
A wonderful URL rewrite module can be obtained for IIS 7 that might work for you as-is (http://www.iis.net/extensions) ... assuming you're on Windows Server 2008, of course.
You could probably leverage Microsoft ISA Server 2006 to map incoming requests to different SharePoint web applications (IIS websites) based on path information. I don't have an ISA admin console open in front of me right now to explicitly confirm that, though.
You could develop an HttpModule that rewrites incoming URLs so that they are redirected or handled by different sites/web apps. This would ensure that redirection logic is specifically what you want.
Another link that might have some helpful tidbits comes from Todd Klindt, SharePoint MVP and all-around nice guy: http://www.toddklindt.com/blog/Lists/Posts/Post.aspx?ID=48.
Regardless of the route you choose, I'll point out one potential sidenote and watchout: hierarchy and path depth. Generally speaking, any rewriting you do shouldn't alter a page's depth. For example, this would be okay:
myfarm/webapp1/testpage.aspx => app1.myfarm/webapp1/testpage.aspx
... but avoid doing something like this:
myfarm/webapp1/testpage.aspx => app1.myfarm/webapp1/newsite/testpage.aspx
These are fabricated examples, but I hope the point I'm trying to make is clear. In the first example, testpage.aspx is "2 levels" deep from the hostname -- and it stays that way on re-write/redirect. In the second example, it goes from 2 levels deep to 3 levels deep. Depth changes like this can lead to all sorts of insidious little problems during normal operations, as SharePoint depends on the path depth and ordering for some operations and determinations.
I hope this helps!
Can I ask why you would want to do this? You can separate out content databases this way for instance.. no need to create separate webapps.
I agree with Sean and Arjan. Sean is right to point out IIS does not support this and Arjan is right in saying that if you ahve the need for more web apps then actually create them as such, if it is just for URL sake create 1 webapp with multiple site collections each using their own content db.
Folks, we all know that IP blacklisting doesn't work - spammers can come in through a proxy, plus, legitimate users might get affected... That said, blacklisting seems to me to be an efficient mechanism to stop a persistent attacker, given that the actual list of IP's is determined dynamically, based on application's feedback and user behavior.
For example:
- someone trying to brute-force your login screen
- a poorly written bot issues very strange HTTP requests to your site
- a script-kiddie uses a scanner to look for vulnerabilities in your app
I'm wondering if the following mechanism would work, and if so, do you know if there are any tools that do it:
In a web application, developer has a hook to report an "offense". An offense can be minor (invalid password) and it would take dozens of such offenses to get blacklisted; or it can be major, and a couple of such offenses in a 24-hour period kicks you out.
Some form of a web-server-level block kicks in on before every page is loaded, and determines if the user comes from a "bad" IP.
There's a "forgiveness" mechanism built-in: offenses no longer count against an IP after a while.
Thanks!
Extra note: it'd be awesome if the solution worked in PHP, but I'd love to hear your thoughts about the approach in general, for any language/platform
Take a look at fail2ban. A python framework that allows you to raise IP tables blocks from tailing log files for patterns of errant behaviour.
are you on a *nix machine? this sort of thing is probably better left to the OS level, using something like iptables
edit:
in response to the comment, yes (sort of). however, the idea is that iptables can work independently. you can set a certain threshold to throttle (for example, block requests on port 80 TCP that exceed x requests/minute), and that is all handled transparently (ie, your application really doesn't need to know anything about it, to have dynamic blocking take place).
i would suggest the iptables method if you have full control of the box, and would prefer to let your firewall handle throttling (advantages are, you don't need to build this logic into your web app, and it can save resources as requests are dropped before they hit your webserver)
otherwise, if you expect blocking won't be a huge component, (or your app is portable and can't guarantee access to iptables), then it would make more sense to build that logic into your app.
I think it should be a combination of user-name plus IP block. Not just IP.
you're looking at custom lockout code. There are applications in the open source world that contain various flavors of such code. Perhaps you should look at some of those, although your requirements are pretty trivial, so mark an IP/username combo, and utilize that for blocking an IP for x amount of time. (Note I said block the IP, not the user. The user may try to get online via a valid IP/username/pw combo.)
Matter of fact, you could even keep traces of user logins, and when logging in from an unknown IP with a 3 strikes bad username/pw combo, lock that IP out for however long you like for that username. (Do note that a lot of ISPs share IPs, thus....)
You might also want to place a delay in authentication, so that an IP cannot attempt a login more than once every 'y' seconds or so.
I have developed a system for a client which kept track of hits against the web server and dynamically banned IP addresses at the operating system/firewall level for variable periods of time for certain offenses, so, yes, this is definitely possible. As Owen said, firewall rules are a much better place to do this sort of thing than in the web server. (Unfortunately, the client chose to hold a tight copyright on this code, so I am not at liberty to share it.)
I generally work in Perl rather than PHP, but, so long as you have a command-line interface to your firewall rules engine (like, say, /sbin/iptables), you should be able to do this fairly easily from any language which has the ability to execute system commands.
err this sort of system is easy and common, i can give you mine easily enough
its simply and briefly explained here http://www.alandoherty.net/info/webservers/
the scripts as written arn't downloadable {as no commentry currently added} but drop me an e-mail, from the site above, and i'll fling the code at you and gladly help with debugging/taloring it to your server