Trying to set up VPN authentication against different realms/windows domains.
I'm using OpenVPN Access Server which directs all authentication requests (username in the form of user#domain) to FreeRADIUS server (3.0.15) with required proxy.conf and realms config so that forwards (proxies) the access-request to home server. The OpenVPN is configured to use MS-CHAPv2.
The home server is also a freeRADIUS, same version. Home server is a member of windows domain (samba 4.6) and its clients.conf file includes the proxyRADIUS server as "NAS'....etc.
No issues on home server, when it comes to samba/winbind checks, etc. As a matter of facts, if I send requests from OpenVPN directly to it (without proxy), using username = sAMAccountName, authentication and group membership checks via LDAP work as expected.
However, if the request is proxied, the mschap module in home server reports:
(0) mschap: ERROR: Program returned code (1) and output 'Logon failure (0xc000006d)'
(0) mschap: External script failed
(0) mschap: ERROR: External script says: Logon failure (0xc000006d)
(0) mschap: ERROR: MS-CHAP2-Response is incorrect
(Outout above from radiusd in debug mode)
Just as a way of testing there was no issue with proxying the requests I enabled NPS on the domain controller and started proxying requests towards it and authentication worked with no issues, so, for whatever the reason, when home server tries to authenticate a proxied request the NT-Response (or at least as managed by mschap module) doesn't seem right.
I know there was a bug in an old version of samba about NT-Response, but I don't think that's the issue here, I think it got fixed a few years ago.
Has anyone come across a similar issue?
Thanks!
PS: Proxy and home RADIUS run in BSD 10.3
Fixed this. Realm definition in proxyRADIUS with "nostrip", so that user-stripped sent to home server includes user#domain. In home server, "proxy.conf" file, define the realm but with no server pool, so that the realm is treated as LOCAL but challenge is created using only the username (without #domain). That's it
Related
We have a web application which will use self signed certificates, and after installing it on the server, the browser will open at "https://localhost" (no, for argument's sake, I will state that we cannot use the actual machine name).
This will generate a browser error, because "localhost" is not the certificate's domain.
An option, is to expose the application on HTTP only on the loopback (localhost).
Our application should be encrypted whenever it is passing outside of the server, so - the question..
Are there any security concerns around allowing HTTP access to our
application on localhost (and only on localhost)? Does this expose the
application to snooping from outside of the computer?
One can assume that if someone was able to access the machine's local user sessions, then we have bigger worries, and the lack of HTTP would hence be insignificant.
There could be other process sniffing the loopback interface. It could be a service running in you PC, sniffing and sending data outside to a remote server.
You can still use https with a domain name, like https://www.myowndomain.com and in the hosts file you map this domain to 127.0.0.1
I need informations about security risks and proof of concepts to work with an local client.
In my option, a user will install two components:
The game client
The client launcher
The launcher is running as an background process all the time. The launcher provides an WebSocket server.
The user will open my website to start the game (with game-server lists and other settings). The Website connects to the game launcher to handle all actions (change configuration, start the game executable)..
Problem:
How realize the communication with the website and the game launcher? Okay, Websockets, yes. But browsers forbid to connect to localhost/127.0.0.1 by security reason.
An fake-pointer as DNS or hosts-file to an subdomain like local.game.tld is bad, because SSL-Certificates can be revoked here as bad usage.
Another idea was to provide an NPAPI-Plugin for the browser. But it seems, that the NPAPI is deprecated and useless for the future.
Whats the best practice to communicate between webpages and local installed software?
But browsers forbid to connect to localhost/127.0.0.1 by security reason
This isn't true. Browsers allow you to connect to localhost / 127.0.0.1. I do it all the time on my machine.
The issue is that TLS (wss://localhost, not ws://localhost) requires a certificate and browsers forbid mixed content (you can't have an https website load non-encrypted resources).
fake-pointer as DNS or hosts-file to an subdomain like local.game.tld is bad, because SSL-Certificates can be revoked here as bad usage.
As part of your game installer you could create a hosts file entry with a certificate for mygame.localhost (possibly using a local script) and then ask the player to authorize the installation of the certificate using their password. This way your certificate won't be revoked... but you are right that this his suboptimal.
EDIT: also, please note that the domain name must be at the end, not at the beginning (i.e., game.localhost and not localhost.game).
Whats the best practice to communicate between webpages and local installed software?
Generally speaking, if your game is installed on the local machine, there's no need to encrypt the communication between the local browser and the local machine.
You can easily write your local server to accept only connections from the local machine (or, at worst, if need be, accept connections from the local area network - though this adds security risks).
Your webpage and WebSocket data can be sent "in the clear" (ws:// and http://) between the local server and the browser since they are both on the same machine - this way you don't need a browser. The local server would initiate (as a client) any encrypted connection it needs when communicating with an external service (was:// / https://).
EDIT (from the comments):
There are the only 2 solutions I know of:
Installing a self-signed certificate; or
Using http instead of https and having the server handle outside traffic as if it were a client (so all traffic going outside is encrypted).
We have a web application which will use self signed certificates, and after installing it on the server, the browser will open at "https://localhost" (no, for argument's sake, I will state that we cannot use the actual machine name).
This will generate a browser error, because "localhost" is not the certificate's domain.
An option, is to expose the application on HTTP only on the loopback (localhost).
Our application should be encrypted whenever it is passing outside of the server, so - the question..
Are there any security concerns around allowing HTTP access to our
application on localhost (and only on localhost)? Does this expose the
application to snooping from outside of the computer?
One can assume that if someone was able to access the machine's local user sessions, then we have bigger worries, and the lack of HTTP would hence be insignificant.
There could be other process sniffing the loopback interface. It could be a service running in you PC, sniffing and sending data outside to a remote server.
You can still use https with a domain name, like https://www.myowndomain.com and in the hosts file you map this domain to 127.0.0.1
I have CCNET 1.8.5.0 installed on two build servers and I configured WebDashboard on one server to monitor both of them. But it leads to such bug: when user logs in to one of the servers, webdashboard shows him as being authorized on other server too (Logout button is showed instead of Login). But when it tries to access project on second server he gets usual error:
Request processing has failed on the remote server: Permission to execute 'ViewProject' has been denied.
How could I force webdashboard to separate authorization on every server?
this seems to be a bug :-(
there is no configuration to my knowledge that would bypass this problem for the moment.
Website started life originally under IIS 6 and the site worked great there. Now after relocating to a new server running W2K8S, everything but mail delivery from the website now works great under IIS 7.
Researched briefly on the Web to see if anybody had a good resolution, but no avail... Not even a glimmer of hope on Microsoft's own support site.
Here are the steps taken so far on the new W2K8S box:
Added the feature for SMTP under the Server Manager
Enabled SMTP e-mail for the site itself in IIS 7 Manager to deliver e-mail to SMTP server local host, unsuccessful
Enabled SMTP e-mail for the root site in IIS 7 Manager (not sure if that needs to be on to enable sites) to deliver e-mail to SMTP server local host, unsuccessful
After failing those basic setups, I wanted to be sure I can actually talk from/to the serveron port 25. And I can successfully telnet from/to the server in question to a test e-mail on port 25 get a HELO, etc. So I do not believe it is a firewall config issue.
The IIS 7 setup test was performed with both anonymous and Windows authentication - no luck either way.
Manually checked Web Config file and it reflects correct entry for the server to use the localhost.
Read the manual and no luck there either... :-/
I faced the same problem.
I came across this link http://www.frontpagewebmaster.com/m-215289/tm.htm
and I was able to solve the issue. Go to the last post of this link.
In my case I solve problem by giving rights to "NETWORK SERVICE" user to the "Pickup" folder.
Hope this might help....
OK, to the post that said "give NETWORK USER the write rights to the pickup folder" it finally works. What I did was:
You need to use a "smart host" unless you are running exchange server. I am using a Gmail account, Gmail allows SMTP forwarding.
You can use Windows authentication for security on the SMTP server and the IIS7 config setting.
First step, set the delivery method = "network" in your web page, and get your smart host configured independently of the SMTP server.
SmtpClient client = new SmtpClient("smtp.gmail.com", 587);
client.DeliveryMethod = SmtpDeliveryMethod.Network;
client.UseDefaultCredentials = false; // use your smart host login client.Credentials = new NetworkCredential("xxxxx#gmail.com", "password");
client.EnableSsl = true;
This will send the email directly and bypass your SMTP server.
Second step, once you have that working, write a sample windows app to use your SMTP server independent of your web page, and get that working.
SmtpClient client = new SmtpClient("your server ip", 25);
client.DeliveryMethod = SmtpDeliveryMethod.PickupDirectoryFromIis;
client.EnableSsl = false; // you can't use ssl with a pickup folder
client.UseDefaultCredentials = true; // use windows credentials
This will bypass your web page and make sure you have your SMTP server configured properly.
Finally, get your web page working, by setting the sharing on your pickup folder to allow write access to NETWORK_SERVICE. Transfer the login info from step 3, into your SMTP settings, set authentication to integrated security, and use the code in step 4 for your web page.
I had exactly the same problem as described in this old question. Finally I found a solution to it. In my case the operation system is W2008 R2 with IIS 7.5, but I think this doesn’t matter.
The underlying problem is that the SMTP Service in W2008 R2 seems to be a legacy part of the IIS. It is installed with the IIS 6.0 administration tools, side by side to the IIS 7.X Server. This causes two derived problems:
IIS 7.X knows nothing about the SMTP service. If you configure SMTP in ASP.NET to use the PickupDirectoryFromIis this results in an exception. Therefore you can’t use this SMTP configuration:
<smtp deliveryMethod="PickupDirectoryFromIis" />
But it is possible to configure SMTP with SpecifiedPickupDirectory, You can use this configuration:
<smtp deliveryMethod="SpecifiedPickupDirectory">
<specifiedPickupDirectory pickupDirectoryLocation="C:\inetpub\mailroot\Pickup" />
</smtp>
If you configure the pickup directory in this way, you may run into a second kind of problem: IIS6 and IIS7.X have different security systems. IIS 7.X introduces integrated security with application pool identities. IIS 6.0 and its SMTP service don’t know about this. Therefore you have to grant write permissions for IIS_IUSRS to the pickup folder. In my configuration the pickup folder is C:\inetpub\mailroot\pickup.
I noticed that the event ID 4006 was refering to the domain controller ip instead of the mail server ip.
I used the iis 6 admin tool to configure a smarthost pointing to the mail server and voila! the issue was resolved.
I am not sure if this diagnostic tool can provide more insights,
http://www.iis.net/downloads/default.aspx?tabid=34&g=6&i=1308
This tool is for x86.
Have you checked to see if the SMTP service is accepting mail for relay from localhost? To do this, telnet from the machine in question to the local SMTP server and use SMTP commands to send a test message. The SMTP service is very picky about command formatting so you'll have to be careful when entering commands (i.e. don't use backspace to correct typographical errors).
Is this, by chance, an old "classic" ASP app relying on CDONTS to send mail?
If so, perhaps one of these links would be helpful?
Edited: I had replied before noticing the note on the original post. Disregard...
I came across this post when researching getting SMTP running on my ASP.Net app we're migrating from IIS6 to IIS7. What I found was we didn't have to set up the SMTP SERVER at all - simply setting up SMTP Email was enough - with the additional benefit of NOT having the security concerns of SMTP relaying thru the web server!
so if you don't need your web server to actually do the SMTP routing, you don't have to set up the server at all in IIS7.