I have a Java application that authenticates against Active Directory. When running the program on a machine that is part of the domain, the application is successfully able to authenticate. When executed on the server however, the authentication fails.
Is there a way from Active Directory to block LDAP authentication from non-domain machines? If there is, is it an "all or nothing" setting or can it be configured with certain exceptions?
You can try to enable the anonymous queries.See Here
PS: this wouldn't be good from a security point of view.
Related
My site is hosted on IIS but behind reverse-proxy (nginx). Hence Windows Authentication is not working (nginx does not support it by default configuration). So I want IIS to use Active Directory to check user credentials. But how to do this? I suppose to use cookie, but can't find how to force IIS to find user in Active Directory database.
I would be appreciated for any help.
UPD:
I don't want to use Windows Authentication. I only want IIS find user in Active Directory when user send credentials by simple POST-request from the login page.
It looks like there is no integrated solution and I simply should write it by myself.
I've managed to setup two virtual machines in my local windows 7 laptop. Both of them are Windows server 2008 R2. One acts as Active Directory Domain controller and also as Active Directory Federation Services, and one other as the web app server. This second one is where I've set up my claims aware asp.net mvc web application and I also plan to setup ThinkTecture Identity Server later as my way to authenticate against custom username and password outside AD.
I've successfully implemented the installation and configuration needed for connecting our ASP.NET MVC apps through ADFS. They include :
Configure first server as Domain Controller and add domain account store (add user as testing -> this user belongs to Domain Users Group).
Configure first server also as active directory federation services.
configure relying party trust identifier from federation metadata generated from FedUtil.exe in second server.
Configure group claim mapping and assign Domain Users to this group.
Configure web apps server to be claims aware agent.
The one that's always troubled me is that every time I access my apps, it successfully prompts login dialog box. Once I enter My AD account and password, it always gives me the following error message : "There was a problem accessing the site. Try to browse to the site again.
If the problem persists, contact the administrator of this site and provide the reference number to identify the problem.
Reference number: c558ed55-b203-42cc-b6bd-3d66bddb96cd".
Any idea from you guys how to get this to work?? Any suggestion and ideas will be highly appreciated.
Have you looked in the event log?
Open Event Viewer > Go to Applications and Services Logs > AD FS 2.0
You'll see an list of errors which should give you some more guidance.
If you see the ADFS login screen, you can get to ADFS so I suspect it's something to do with your RP configuration.
Just to check - you are using ADFS 2.0 which you downloaded?
Sitecore security hardening guide instructs to restrict access to /sitecore/admin folder by disabling anonymous access. However, after I do that, I get an IIS error when I try to visit pages like /sitecore/admin/cache.aspx.
HTTP Error 401.2 - Unauthorized. You are not authorized to view this page due to invalid authentication headers.
Should anonymous access only be disabled if I don't want to access admin pages?
My sitecore version is 6.6.0 (rev. 130404).
In addition to disabling anonymous access, you should make sure some sort of other authentication method is enabled. By default, IIS7+ doesn't have any other authentication methods available, so all traffic will get an "unauthorized" error. With another means of authentication enabled, IIS will let you access the /sitecore/admin path (at which point, Sitecore's authentication may kick in).
I've done this in the past by creating a local user on the machine and enabling basic auth. Keep in mind, basic auth is not too secure since credentials are passed over the wire as cleartext, but in this case we forced traffic over SSL.
Though not spelled out in the hardening guide, you could also look at limiting access to that directory by IP address. For example, on a production content delivery server, restrict access to only localhost, meaning you cannot browse that directory without being RDP'd to the server directly.
I think you should remove extranet/anonymous access, but make sure that sitecore/everybody (or other role) has access.
That way you can only access it while logged into Sitecore.
Use the Access Viewer to check that users have access to it.
And I think that those pages, have a Sitecore login now. I know /sitecore/admin/dbbrowser.aspx has one.
I would not disable the anonymous access unless it is the production environment. I am not sure how you have the environments setup but ideally cache clearance should be on your stage/uat environment.
I hope I will be clear here:
Let's a user authenticates to application A using Kerberos (the code uses the JAAS Krb5LoginModule).
The client now needs to authenticate to Application B as well.
The Kerberos ticket is still valid.
How can I use I make sure that auhtentication flow to application B will not try to create a new Kerberos ticket?
When I use JAAS I perform:
loginContext.login (I of course passed a callback handler to provider credentials and the name that is used as an index to the configuration, see javadoc here), and of course Application A and application B run as different as different processes, so the loginContext object is not shared between them.
How can I reuse the valid kerberos ticket between the two applications which run in different processes, but the user uses the same credentials (same user#realm)
Thanks
If both applications are on the same physical/logical machine, share the same SPN and both are running under the machine account, yes you can reuse the service ticket until it expires. But those is actually handled by the browser. You will never mess with them anyway. Your SPNEGO acceptor does everything for you.
We are developing a self registration app.
Our app allows users to register for web apps and is deployed on a weblogic 10.3.5 app server. The weblogic is connected to a local ldap system.
Once the user registeres with our app we call corporate servces to generate a user id. password activation, authentication is all handled by the corporate servcies. which also has a corporate ldap that contains all users in the company.
The approach works fine for 'new users' ie users that are not present in the corporate ldap or the local ldap: users enter their details and are issued a user id which we then copy into the local ldap once the user activates their account.
The use case we're grappling with at the moment is how to handle 'existing' users that wish to register. These are users that are currently in the corporate ldap and wish to 'register' with our applications. They get rejected during the normal registration process as they already exist in the coroporate ldap.
What i'd like to do is force them to login (simply so they don't register on behalf of somone else) and once they're logged in simply copy their data into the local ldap.
The problem is even if they are successfully authenticated by the corporate service, they don't (yet exist) as far as the weblogic server is concerned. is there a way to obtain the user id that comes with the authentication token ?
The authentication method is SAML 1.1
The application is a standard Java EE servlet based webapp using the struts2 framework.
Any ideas would be much appreciated.
Within WebLogic, you can define multiple authentication providers and set them up in the order you would like the system to use. Since you are copying data over, you would have to programmatically check for the existence of the account before attempting to create it on the LDAP server.
It would be a lot simpler if you use the external LDAP server directly instead of copying the data to the internal LDAP server, letting you attempt logging the user in and creating the account only while catching the appropriate exception.