There are standard Java API's for LDAP from Sun.
now i use these to operate Active Directory.
now i can create user account、create computer with java api.
But how can I grant authorization user&group to join a computer to an AD domain when i new a computer account?
i know openLDAP can do it :Access Control
but how can i do with java api?
Granting authorization is not discrib in any LDAP RFC. This part is proprietary.
In OpenLDAP Access Control List (ACL) is established by a kind of filter.
In SUN Directory (Nowdays Oracle one) ACLs are established by attributes.
In Active Directory granting authorization is done using internal in the same proprietary maner as in the NFTS file system.
The thing you can do is to execute an external program like DSACLS.EXE see Dsacls Examples
Another solution should be to map COM ADSI objects into Java this may help you (or not).
Related
I have Kerberos and have enabled Hadoop cluster. I need to perform HDFS operations using Java code.
I have keytab file and username.
Can someone please suggest how can I authenticate Kerberos using Java code?
Thanks.
If you just want to use the HDFS Java API for a short-lived connection, then UserGroupInformation has a loginUserFromKeytab method.
If you want a durable connection (i.e. longer than the lifetime of the initial Kerberos TGT) then have a look at that post.
If you are interested in the dark side of Kerberos (well, there is no other side anyway) then have a look at the "Madness beyond the Gate" online book -- at your own risk.
~~~~~~
BTW there is an alternative to the Java API: the WebHDFS REST service. But on Windows you still need some Java code to create the Kerberos TGT (using GSSAPI i.e. the Linux way, not SSPI i.e. the Microsoft way!!!), run the SPNEGO initial authentication, and retrieve the delegation token. At this point any HTTPS library will be able to handle the file operations using that token.
I need to develop a web application for the Intranet users. I don't want them to enter the login credentials each time they visit the site. It should be automatically loaded from the System Username and Password.
I have successfully implemented functionality which prompt user name and password registered with active directory and validate against LDAP. I need some tips to login directly from intranet website without prompt username & password.
Here is my queries, please let me know your suggestion.
Is it compulsory to set SPN?
Do we need to create separate keytab file for each client? In my organization, there is around 800 people are working so should I need to add all client principal in keytab file & copy to client machine to perform autologin.
I have tried many API's like JESSO, Waffle, Spring Kerberos, SPNGO but failed to implement auto login.
If you want to use Kerberos/SPNEGO (which would be my recommendation) you do have to set up SPN. And you only need one keytab for AD domain. Are you running your Java program on some app server, like Weblogic, or as a standalone program? Servers do have security framework that you could use, while for standalone program you'd have to do a bunch of stuff manually.
I've found that the easiest way to do this is to use Atlassian's Crowd (https://www.atlassian.com/software/crowd/overview) instead of implementing it yourself. It's a commercial product, but last time I checked, it was dirt cheap, and it just works.
I have configured Kerberos for various authentication purposes. OS command line tools are working and return renewable tickets with a configurable lifetime.
I now need to obtain tickets in a custom application and store them away in a ticket cache file that I can use with any Kerberos system tool. Since the custom application is Java-based, it seems most natural to use Java means to authenticate and deal with the tickets.
I have been following the example given in JAAS Authentication Tutorial and successfully authenticated to my Kerberos KDC. Now, I would like to
Fine tune the properties of the obtained TGT ticket. What I get is a non-renewable ticket with unlimited lifetime. Instead, I would like to request a renewable ticket with configurable lifetime, renewable lifetime etc.
Store the obtained ticket into a ticket cache file for use outside the sample application (e.g. command line kerberos utilities).
I do have two open questions:
How can I configure the login context to obtain tickets with the desired settings?
How can I extract the credentials from the authenticated subject and save them into a ticket cache file?
Update: Digging into the code, it seems that sun.security.krb5.KrbAsReqBuilder is used to do the Kerberos communication. The lifetime options seem to be hardcoded in there, although sun.security.krb5.KrbAsReq allows to specify them. Seems I might need to take another route to get what I want.
Update2: After reviewing other options, I have decided to use a modified version of the original C source code for MIT Kerberos' kinit tool instead of using Java at all.
Is there an implementation of the MIT Kerberos admin protocol in Java which i can use to create an kerberos administration client written in Java?
My application should be able to:
1.) authenticate with MIT Kerberos Server
2.) add/delete user/service principals
No kadmin.local calls. JNI Bindings would work, too.
Alternative:
Since kerberos credentials are saved in ldap it is possible to change those information. This might be an easy alternative. But this would mean editing KDCs database itself. This bypasses the kadmin protocol and requires knowledge of how this database is created. This method should not be favored over a kadmin protocol interface.
Use Apache Directory Studio, a very nice tool.
I want to implement Single Sign On with Kerberos in Java and have successfully managed to create a ticket for the Service using the ticket from the Windows logon. Unfortunately, I can only create that ticket when the Registry Key "allowtgtsessionkey" is enabled. I am receiving an exception with the message "Identifier doesn't match expected value (906)" as soon as I disable it. The registry key is documented on http://java.sun.com/j2se/1.5.0/docs/guide/security/jgss/tutorials/Troubleshooting.html and http://support.microsoft.com/kb/308339.
Unfortunately I do not have access to the registry on the computers where my application will be used, so I am looking for a way to do this without having to modify it. When I do Single Sign On over SPNEGO in Internet Explorer or Mozilla Firefox, they create a Service ticket in my ticket cache, so there definitely has to be a way to do this without setting the registry key. Does anyone have an idea how to do this in Java?
Thanks for your help,
memminger
Update: I am giving up on this issue. The Windows registry key prevents the access to the Ticket (more exactly: the Subject) inside the Ticket cache. Java on Windows uses its own GSSAPI implementation, and I suppose that needs access to the Ticket to create a Service Ticket. The SSPI Windows API though has full access to the Ticket cache and can thus create Service tickets. This API is used by the web browsers, but it is not used by Java (according to http://java.sun.com/developer/technicalArticles/J2SE/security/#3). When I disable SSPI in Firefox after having accessed a web page once (so a service ticket has been created), I can still access the page, so maybe a command-line util would be sufficient that creates a service ticket using the SPPI API.
For us, this means now that we can either abandon Single Sign On (which is unacceptable for us) or that we do the authentification on the client side of our application (because we can only read out the username but not verify the ticket on the server), which is a major security risk. Another example of how stronger security constraints lead to bigger security holes because they become too complicated to use.
Forgive me if I am misunderstanding you problem, but...
The point of SSO type systems is that the client authenticates directly to the (separate) authentication server, and obtains a ticket from it. It then passes the ticket to the target server(s) it wants to use, each of which verify that the ticket is valid with the authentication server. If the ticket is validated, it can be assumed by the server that the client only obtained it by presenting the (trusted) Kerberos server with acceptable credentials.
Nowhere in the process, should any server authenticate on behalf of the client. In such a system, the only server that needs to know and validate the client's credentials is the authentication server - no other server need have access to this information. This way the client can authenticate for many servers with just one authentication exchange, and credentials are not put at risk by being stored on, or accessible to, multiple servers.
It sounds like your implementation is working just as it should - the authentication should occur on the client side of the application, and this is correct and not a security risk.
Have you tried setting sun.security.jgss.native in Java 6? Wouldn't SSPI be the "native" interface for windows?
You can access the native SSPI API via JNA. See the WindowsAuthProviderImpl in WAFFLE or WindowsNegotiateScheme from the Apache HC library for an example.
Native support for Windows SSPI was introduced into JDK 13 and later backported to JDK 11 too. You'll need to use at least Java 11.0.10. When the JDK's support for SSPI is used then there's no longer a need to fiddle with the allowtgtsessionkey registry key, nor any need to use JNA or Waffle.
You need to set
-Dsun.security.jgss.native=true
to make it work.
You can recognize if your JDK version for Windows has support for SSPI if it includes a file named sspi_bridge.dll in the bin directory.
Refs:
JDK-6722928