Currently my Mac has been successfully configured to be in Active Directory Domain. (System Preferences -> Users & Groups -> Login Options -> Network Account Server)
We are developing a Mac application that has following requirements:
It should communicate with the LDAP server in Active Directory Domain and retrieve users & their attributes from LDAP server.
While communicating (bind or search) with the LDAP server, we are not allowed to explicitly specify logged-in user's credentials. (e.g. we should not prompt username / password screen to the user)
If we explicitly specify logged-in user's credentials,
• we are able to bind to the LDAP server
• we are able to search the users & their attributes in LDAP server.
If we do not specify logged-in user's credentials,
• we are able to bind to the LDAP server
• but it does not allow us to search the users & their attributes in LDAP server.
We are currently using OpenLDAP framework for LDAP operations.
Is there a way with which we can use logged-in user's credentials implicitly while communicating with the LDAP server?
Can you please guide us how we can query LDAP server (search users & their attributes in LDAP server) without specifying logged-in user's credentials explicitly.
Any kind of help is highly appreciated.
Is there a way with which we can use logged-in user's credentials
implicitly while communicating with the LDAP server?
Maybe.
IF you CAN set up Kerberos (and SPNEGO is using a WEB browser) you might be able to obtain a "ticket" that you could then use a GSSAPI to Authenticate the user.
You would probably be more secure if you used a one of the many third-party Access Manager Products to perform these services due to the inherent security risks involved.
Related
We have an in-house OAuth2 server used by our applications. Now we want to use Windows SSO for our applications but without them to change anything: they'll still reach our OAuth2 server for an access token and the authentication part will be delegated to Kerberos (which Windows use, if I understood properly).
Is there a way to do that?
That is a standard setup and should just require configuration changes in the Authorization Server (AS) - with zero code changes in applications.
Most commonly:
The AS might be hosted in the cloud
It will redirect browsers to an on premise Identity Provider (IDP)
The IDP can connect to Active Directory
You may also need a fallback option for when users are not joined to the work domain. See this Curity guide for an example and some infrastructure factors to think about.
If the AS is in house it may even be able to make a direct Kerberos connection via an LDAP data source, though the preferred architecture is a separate IDP.
Of course you need an AS that supports the ability to make this type of connection, so would need to check the vendor docs.
REQUEST FLOW
Kerberos has always been the simplest protocol conceptually but the deepest to understand - here is a bit of a summary:
Your apps will make a standard OpenID Connect authorization redirect to the AS
The AS may then present an authentication selection screen to the user, unless there is only a single option
Alternatively an app can send the acr_values query parameter to say which authentication method to use
The AS will then redirect the browser to the next stage of processing, that uses a 'Windows SSO authenticator'
The redirect to the Windows SSO authenticator does not have to use OpenID Connect - it could be any vendor specific HTTP request
The browser will send an encrypted Kerberos ticket automatically by connecting to AD - a prerequisite for this to work might be that the domain in the URL is in the Local Intranet zone on end user computers
The Windows SSO authenticator will need to be able to decrypt this credential, which typically requires a Service Principal Name to be configured
Once the Kerberos ticket is decrypted, the authenticator will make an LDAP connection to an Active Directory data source via its standard LDAP endpoints, to verify the received ticket
so I have Windows Server 2012 which is running on my virtual machine. I want to have possibility to make anonymous query against LDAP. For example if I'm using software like Softerra LDAP Browser I need to run this program as domain user to be able browse AD groups/users etc. But my point is that I want to be able to do it also as non-domain user(anonymous), or at least using domain user credentials from machine that is not part of the domain.
I was looking for this option in user/group policies, I've grant my user with all privileges that I found - but always with the same result - I was unable to browse LDAP.
So my question is - what have to bet set/changed to be able make anonymous queries against Windows Server LDAP?
I don't know about anonymous queries, but you said that you would also be happy using a domain user from a non-domain machine.
That should work fine. Create a domain user with sufficient privileges to see what you want.
Install a certificate on your LDAP server (or use Kerberos, but that's more annoying on the non-domain machine).
Then do LDAP authentication using the username and password of that domain user.
It works well.
I am trying to set up LDAP Authentication to allow users to log in to my application using their Microsoft AD credentials. The application is on ApEx 4.2.5.
I was able to successfully enable this when specifying the DN string's domain as mydomain\%LDAP_USER%.
The main issue is that we have users from at least 3 different domains within the same directory.
Is there a way to make this string more dynamic to include multiple domains?
In my application, I use spring security, and I just want to know what's the meaning of "realm" in HTTP config.
A realm is a credential store that enables identity or role based access control.
Java Documentation
What is a realm?
For a web application, a realm is a complete database of users and groups that identify valid users of a web application (or a set of web applications) and are controlled by the same authentication policy.
The Java EE server authentication service can govern users in multiple realms. In this release of the Application Server, the file, admin-realm, and certificate realms come preconfigured for the Application Server.
In the file realm, the server stores user credentials locally in a file named keyfile. You can use the Admin Console to manage users in the file realm.
When using the file realm, the server authentication service verifies user identity by checking the file realm. This realm is used for the authentication of all clients except for web browser clients that use the HTTPS protocol and certificates.
In the certificate realm, the server stores user credentials in a certificate database. When using the certificate realm, the server uses certificates with the HTTPS protocol to authenticate web clients. To verify the identity of a user in the certificate realm, the authentication service verifies an X.509 certificate. For step-by-step instructions for creating this type of certificate, see Working with Digital Certificates. The common name field of the X.509 certificate is used as the principal name.
The admin-realm is also a FileRealm and stores administrator user credentials locally in a file named admin-keyfile. You can use the Admin Console to manage users in this realm in the same way you manage users in the file realm. For more information, see Managing Users and Groups on the Application Server.
A realm is a security policy domain defined for a web or application server. A realm contains a collection of users, who may or may not be assigned to a group.
A realm is a security policy domain defined for a web or application
server. The protected resources on a server can be partitioned into a
set of protection spaces, each with its own authentication scheme
and/or authorization database containing a collection of users and
groups. For a web application, a realm is a complete database of users
and groups identified as valid users of a web application or a set of
web applications and controlled by the same authentication policy.
The Java EE server authentication service can govern users in multiple
realms.
https://docs.oracle.com/cd/E19798-01/821-1841/bnbxk/index.html
I'm in the process of rearranging our web-based systems, so that users will be able to log on to our systems through a Sharepoint front-end. Our single sign-on server is an Oracle SSO server that authenticates against the same domain as the sharepoint server does, but these two are currently 2 separate logins.
What I'm looking for is to configure this scenario:
A user logs in to the Sharepoint site, authenticating agains Active Directory through the TMG. This gives the user access to the sharepoint site, and this is all standard OOTB functionality. Then the user should be able to navigate into our other systems without a re-login (because the SSO configured for external authentication with the same AD, and therefore uses the same userbase).
So basically the users currently have to login twice with the same domain\user + password. I would like the SSO server to be able to read the cookie that was established in the first login, and use that instead of presenting the SSO login screen all over again.
Is it possible to share such a cookie between 2 different platforms on the same domain?
I have implemented a kerberos "Zero-sign-on" approach for the Oracle SSO server, but this only works as long as the user comes from a computer inside our domain. When the user logs on from the outside world (www) he will be prompted to login to sharepoint first, and then to the Oracle SSO.
I basically need the Oracle SSO Cookie to somehow read the Sharepoint Cookie that was established. Does this make sense?