createTrustedClientPassword web service call failing

MediaBin 4.5.3

I am trying to connect to MediaBin via web service with a simple Java application. The eventual execution location will be inside of the TeamSite content center application. I will already know the currently logged in TeamSite user, which uses an LDAP server to authenticate. Our MediaBin server leverages an Active Directory server to do its authentication.

We currently have not changed anything on the LDAP tab on the enterprise manager screen. Do we need to set this up for it to work?

Code snippet:


((Stub) service).setUsername("domain\\user");
((Stub) service).setPassword(service.createTrustedClientPassword("myhint"));

The error I am getting is the following:


Exception: Server was unable to process request. --> MBException:  User:  domain\user.  The user logon failed.  The user name or password may be invalid for the specified domain

Is there something else that needs to be done for this to work?

Find more posts tagged with

Comments

msnider

Bill,

There are several things that must be done in order to support Trusted LDAP logins. Consult the webservice's readme for details.

It is important to note that before you try to connect via your sample Java app, that you try connecting via one of the MediaBin native clients using an LDAP based user just to verify that the MediaBin server has been correctly configured. This will save time when trying to figure out why you can't log in.

Once you have verified that the MediaBin server has been configured for LDAP authentication, your code will look something like this:


 public static String UploadForm = null;
 public static String UploadFTPSite = null;
 public static String UploadUNCPath = null;
 public static MediaBinServerSoap MediaBinService = null;


 //A MediaBinServerSoap proxy object only has to be created once
 public static void ConnectToMediaBin( String strURL, String strAuthType, String strDomain, String strUsername, String strPassword ) throws Exception
 {
  //This creates the service proxy object
  MediaBinServer myService = new MediaBinServerLocator();

  //The WSDL contains the URL but since we referenced it dynamically we need to specifies the service's URL
  java.net.URL serviceURL = new java.net.URL( strURL );   
  MediaBinService = myService.getMediaBinServerSoap( serviceURL );

  //Specify the type of authentication and the logon credentials
  CreateCredentials( strAuthType, strDomain, strUsername, strPassword);

  //Persist the MediaBin connection between calls
  MediaBinService.beginPersistentConnection(false);

  UploadUNCPath = MediaBinService.getUploadUNC();
  UploadFTPSite = MediaBinService.getUploadURL_FTP();
  UploadForm = MediaBinService.getUploadURL_HTTP();

  //Now we can make calls into the web service using the Java stub   
 }
 public static void CreateCredentials( String strAuthType, String strDomain, String strUsername, String strPassword ) throws Exception
 {
  if( strAuthType.equals("BASIC") )
  {  
   String strUser = "";

   if( strDomain.equals("") )
    strUser = strUsername;
   else
    strUser = strDomain + "\\" + strUsername;

   ((org.apache.axis.client.Stub) MediaBinService).setUsername( strUser );
   ((org.apache.axis.client.Stub) MediaBinService).setPassword( strPassword );
  }
  else if( strAuthType.equals("LDAP") || strAuthType.equals("T_LDAP") )
  {
   strDomain = "ldap";  //domain must always be "ldap"
   ((org.apache.axis.client.Stub) MediaBinService).setMaintainSession(true);  //auth ticket will be held in a cookie

   if( strAuthType.equals( "T_LDAP" ) )
   {    
    String strHint = "s0m3$";  //Get the trusted LDAP password using a hint word
    strPassword = MediaBinService.createTrustedClientPassword( strHint );  //Could remove this call all together and just store the trusted password
   }

   //Pass an HTTP_AUTHORIZATION header as the parameter...clear text or Base64 encoded
   MediaBinService.createAuthenticationTicket( "Basic " + strDomain +"\\"+ strUsername + ":" + strPassword );
  } 

  //NOTE:  may need to increase timeout value....default is 60 sec.
  //((org.apache.axis.client.Stub) MediaBinService).setTimeout( );
 }

Mark

Bill Klish

Mark,

If I hard code my username and password in my java code it works without a problem.

If I replace the password with the trusted client call, it does not and fails with that message.

I am confused about a few things in your code snippet:

1. Why does the domain have to be LDAP. Seems like a strange requirement, especially if customers don't currently have things setup that way. Is this some sort of internal dependency in the MediaBin connection code that is used to flag it to leverage LDAP? Does this effect logins on the desktop or web clients?

2. The authentication through the current MediaBin web client is going through our Active Directory domain (called HQ). It works fine. If I need to specify information on the LDAP tab of the MB enterprise manager can I specify my Active Directory server in there, or will this only work with non-AD LDAP?

3. We have unix LDAP servers and Active Directory sharing the same exact data. In an effort to not use the unix LDAP and have users with the same unique ids and not rework the entire MediaBin repository, I am not sure what you mean by login as an LDAP user. I do that already, and did that with my hard coded domain\\user and password.

So, the underlying confusion here is can my Active Directory server serve as the LDAP server, or do we need to setup our unix servers instead? If we have to use unix, does that change all of the thousands of objects in the current repository and force us to write some sort of migration script to map the old object owners to the new object owners? Leveraging our AD as the LDAP would hopefully eliminate this issue.

Thanks,
-Bill

msnider

Bill,

From the MediaBin server perspective, if you do not have an LDAP server configured via the MEM and you are not specifying "ldap" as the domain when you login then you are not authenticating using an LDAP lookup but rather you are authenticating via a Windows Domain controller (which may be attached to an ActiveDirectory on the backend). You must configure the LDAP tab in the MEM before you can login via an LDAP lookup.

The LDAP server can be an ActiveDirectory server or it can be a unix server....the MediaBin server doesn't require a specific type of server just as long as it supports the LDAP schema. It sounds like you would use your ActiveDirectory server when configuring the MEM.

Yes, the domain "ldap" is a special moniker that flags the MediaBin server to do an LDAP lookup. This moniker is used by all client access to MediaBin when logging in via an LDAP lookup....it's not something unique to the web service and the sample code snippet hardcodes it so as to avoid confusion. This is why I said to try to login via the MediaBin native client or web client using "ldap\username" password....if you can't login that way then the MediaBin server's LDAP function is not configured yet or not configured correctly. However, using "ldap" doesn't preclude logging in via another client using a true domain user. By default, the MediaBin server does authentication via a Windows domain controller. Once the LDAP tab is configured ,then the MediaBin server can do both...which one to try is determined by the domain specified as part of the user's credentials.

Sometimes the transparency of using a "LDAP" user that maps to a true "DOMAIN" user can cause confusion as to which authentication method is being used. But suffice it to say that without configuring the MEM and without specifying "ldap" as the domain, the MediaBin server is not using LDAP authentication.

Mark

Bill Klish

Perfect. Exactly the level of detail that I needed. I will get this setup once I find out the Active Directory server information.

My confusion stemmed from the Interwoven support engineer telling me that we needed to change our domain to be called LDAP, which made no sense to me. Should have just posted out here in the first place.

Thanks for the detailed response.