I was looking a long time for a good sso solution for my company's web
apps and esoe seems to be good at all my needs.
I have downloaded esoe and run the esoe startup project. I filled in
any information wanted and the config files and DB was created
successfully. Then i made the changes described to the documentation
to handle Active Directory (yes, unfortunately i need to play with m$
directory system). An esoe user and his keytab file created and
changes was done in the ${esoe.data}/config/esoe.config file. ROOT
changed and then all 4 .war files (ROOT, esoemanager, spep, web) was
copied into tomcat's webapps folder. It is tomcat 6.0.18 and all
endorsed and shared libraries are in ${tomcatroot}/endorsed and $
{tomcatroot}/lib directories because these are the locations for
tomcat 6.x (common and shared are not used).
And then nothing at all. I don't know how to describe the problem so i
put here a summary of my log files (everything seems useful).
PS: i want to try it at home, there is a full linux network there with
an openldap server, to check esoe in another environment.
${tomcatroot}/logs/localhost.log
15 Σεπ 2008 12:38:06 μμ org.apache.catalina.core.ApplicationContext
log
INFO: Initializing Spring root WebApplicationContext
15 Σεπ 2008 12:38:42 μμ org.apache.catalina.core.StandardContext
listenerStart
SEVERE: Exception sending context initialized event to listener
instance of class
org.springframework.web.context.ContextLoaderListener
org.springframework.beans.factory.BeanInitializationException: Could
not load properties; nested exception is
java.net.UnknownHostException: C
Caused by: java.net.UnknownHostException: C
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:177)
at java.net.Socket.connect(Socket.java:519)
at java.net.Socket.connect(Socket.java:469)
at sun.net.NetworkClient.doConnect(NetworkClient.java:157)
at sun.net.NetworkClient.openServer(NetworkClient.java:118)
at sun.net.ftp.FtpClient.openServer(FtpClient.java:488)
... [CUTTED OUT]
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:
39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImp l.java:
25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:288)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:413)
15 Σεπ 2008 12:38:42 μμ org.apache.catalina.core.ApplicationContext
log
INFO: Closing Spring root WebApplicationContext
15 Σεπ 2008 12:38:44 μμ org.apache.catalina.core.ApplicationContext
log
INFO: Initializing Spring root WebApplicationContext
15 Σεπ 2008 12:39:07 μμ org.apache.catalina.core.StandardContext
listenerStart
SEVERE: Exception sending context initialized event to listener
instance of class
org.springframework.web.context.ContextLoaderListener
org.springframework.beans.factory.BeanInitializationException: Could
not load properties; nested exception is
java.net.UnknownHostException: C
Caused by: java.net.UnknownHostException: C
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:177)
at java.net.Socket.connect(Socket.java:519)
at java.net.Socket.connect(Socket.java:469)
at sun.net.NetworkClient.doConnect(NetworkClient.java:157)
at sun.net.NetworkClient.openServer(NetworkClient.java:118)
... [CUTTED OUT]
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImp l.java:
25)
From reading your logs I think you may have one of two problems:
#1 - esoe.data, esoemanager.data and spep.data have not
been specified as JAVA_OPTS values when you started Tomcat. The
underlying spring architecture then is getting quite confused and trying
to connect to some non existent FTP source.
#2 - The metadata source located at http://tech11.pds.piraeusgroup.gr:8080/esoemanager/metadata/retrieve.htm is unable to be accessed. If you navigate to this URL in your browser you should have an XML document returned which is the metadata that controls the ESOE system. Without this document the various subsystems can't operate. This not being available would probably indicate some issue with esoemanager that we'd need to pin point.
regards,
Bradley
-- Bradley Beddoes
Lead Software Architect
Intient Pty Ltd
> I was looking a long time for a good sso solution for my company's web
> apps and esoe seems to be good at all my needs.
> I have downloaded esoe and run the esoe startup project. I filled in
> any information wanted and the config files and DB was created
> successfully. Then i made the changes described to the documentation
> to handle Active Directory (yes, unfortunately i need to play with m$
> directory system). An esoe user and his keytab file created and
> changes was done in the ${esoe.data}/config/esoe.config file. ROOT
> changed and then all 4 .war files (ROOT, esoemanager, spep, web) was
> copied into tomcat's webapps folder. It is tomcat 6.0.18 and all
> endorsed and shared libraries are in ${tomcatroot}/endorsed and $
> {tomcatroot}/lib directories because these are the locations for
> tomcat 6.x (common and shared are not used).
> And then nothing at all. I don't know how to describe the problem so i
> put here a summary of my log files (everything seems useful).
> PS: i want to try it at home, there is a full linux network there with
> an openldap server, to check esoe in another environment.
#1 - The fact is that i am starting Tomcat as a service and environment variable JAVA_OPTS is not recognized there BUT i set all esoe.data, esoemanager.data, spep.data as java options from"tomcat6w //ES//Tomcat6" dialog and it seems to work as well as the bin/startup script. For example in the esoestartup project in the form with these three files the values was completed automatically so i think that i am OK. However, i will try again with env. variable JAVA_OPTS and the startup script.
#2 - Nope i browsed the URL and it is null. Nothing into it just a 404 error. But this is right, isn't it. Because esoemanager context failed to start. Maybe an incorrect configuration of the #1 causes the application to fail starting and the metadata to be null. I don't know..
I 'll try more tomorrow and if i have found anything i'll post it.
> From reading your logs I think you may have one of two problems:
> #1 - esoe.data, esoemanager.data and spep.data have not > been specified as JAVA_OPTS values when you started Tomcat. The > underlying spring architecture then is getting quite confused and trying > to connect to some non existent FTP source.
> #2 - The metadata source located at > http://tech11.pds.piraeusgroup.gr:8080/esoemanager/metadata/retrieve.htm > is unable to be accessed. If you navigate to this URL in your browser > you should have an XML document returned which is the metadata that > controls the ESOE system. Without this document the various subsystems > can't operate. This not being available would probably indicate some > issue with esoemanager that we'd need to pin point.
> > I was looking a long time for a good sso solution for my company's web > > apps and esoe seems to be good at all my needs.
> > I have downloaded esoe and run the esoe startup project. I filled in > > any information wanted and the config files and DB was created > > successfully. Then i made the changes described to the documentation > > to handle Active Directory (yes, unfortunately i need to play with m$ > > directory system). An esoe user and his keytab file created and > > changes was done in the ${esoe.data}/config/esoe.config file. ROOT > > changed and then all 4 .war files (ROOT, esoemanager, spep, web) was > > copied into tomcat's webapps folder. It is tomcat 6.0.18 and all > > endorsed and shared libraries are in ${tomcatroot}/endorsed and $ > > {tomcatroot}/lib directories because these are the locations for > > tomcat 6.x (common and shared are not used).
> > And then nothing at all. I don't know how to describe the problem so i > > put here a summary of my log files (everything seems useful).
> > PS: i want to try it at home, there is a full linux network there with > > an openldap server, to check esoe in another environment.
I've managed to reproduce this in my windows environment, so this is definitely a platform problem. The problem is that the esoe.data, etc paths are being interpreted as relative URIs to the base file:// URL. When there is no leading / on the esoe.data location, the URL file://C:\esoe\... is parsed.
What this means, for windows platforms, is that the *.data parameters need to be set as (for example): -Desoe.data=/c:/esoe/core -Dspep.data=/c:/esoe/spep -Desoemanager.data=/c:/esoe/manager
Obviously this would differ depending where the config is stored. The important aspects of the URL here are the leading slash, and the fact that they are forward slashes as used in URLs normally, rather than the backslashes that windows uses for directory locations.
Thanks for reporting this, we haven't come across this one yet. We'll update the wiki documentation shortly to reflect this detail of configuration.
> #1 - The fact is that i am starting Tomcat as a service and environment > variable JAVA_OPTS is not recognized there BUT i set all esoe.data, > esoemanager.data, spep.data as java options from"tomcat6w //ES//Tomcat6" > dialog and it seems to work as well as the bin/startup script. For example > in the esoestartup project in the form with these three files the values was > completed automatically so i think that i am OK. However, i will try again > with env. variable JAVA_OPTS and the startup script.
> #2 - Nope i browsed the URL and it is null. Nothing into it just a 404 > error. But this is right, isn't it. Because esoemanager context failed to > start. Maybe an incorrect configuration of the #1 causes the application to > fail starting and the metadata to be null. I don't know..
> I 'll try more tomorrow and if i have found anything i'll post it.
>> From reading your logs I think you may have one of two problems:
>> #1 - esoe.data, esoemanager.data and spep.data have not >> been specified as JAVA_OPTS values when you started Tomcat. The >> underlying spring architecture then is getting quite confused and trying >> to connect to some non existent FTP source.
>> #2 - The metadata source located at >> http://tech11.pds.piraeusgroup.gr:8080/esoemanager/metadata/retrieve.htm >> is unable to be accessed. If you navigate to this URL in your browser >> you should have an XML document returned which is the metadata that >> controls the ESOE system. Without this document the various subsystems >> can't operate. This not being available would probably indicate some >> issue with esoemanager that we'd need to pin point.
>> > I was looking a long time for a good sso solution for my company's web >> > apps and esoe seems to be good at all my needs.
>> > I have downloaded esoe and run the esoe startup project. I filled in >> > any information wanted and the config files and DB was created >> > successfully. Then i made the changes described to the documentation >> > to handle Active Directory (yes, unfortunately i need to play with m$ >> > directory system). An esoe user and his keytab file created and >> > changes was done in the ${esoe.data}/config/esoe.config file. ROOT >> > changed and then all 4 .war files (ROOT, esoemanager, spep, web) was >> > copied into tomcat's webapps folder. It is tomcat 6.0.18 and all >> > endorsed and shared libraries are in ${tomcatroot}/endorsed and $ >> > {tomcatroot}/lib directories because these are the locations for >> > tomcat 6.x (common and shared are not used).
>> > And then nothing at all. I don't know how to describe the problem so i >> > put here a summary of my log files (everything seems useful).
>> > PS: i want to try it at home, there is a full linux network there with >> > an openldap server, to check esoe in another environment.
Nice.. Thanks.. I am not sure if i could imagine that..
Now i am one step forward and your help about path's syntax was the solution. ESOE is up and running and when i am trying to open esoemanager it redirects me to the magic login screen.
But user's credentials cannot be authenticated against Active Directory. In ${esoe.data}/logging/esoe.log i am getting some WARNs, see the log result below.
I think that it makes the (network) connection to the AD and it then it is not allowed to search for the user because of misconfiguration of the userdn or the keytab file. In my home network (linux - openldap) it works perfect.
If can anyone help me or make a suggestion on this i would be grateful.
PS: Happy to help, even with this accidentally bug report.
*${esoe.data}/logging/esoe.log:* 2008-09-16 12:48:10,045 INFO com.qut.middleware.esoe.spep.impl.StartupImpl - Successfully registered SPEP http://tech11.pds.piraeusgroup.gr:8080/esoemanager. 2008-09-16 12:48:10,232 INFO com.qut.middleware.esoe.pdp.cache.impl.PolicyCacheProcessorImpl - Sending AuthzClearCacheRequest to http://tech11.pds.piraeusgroup.gr:8080/spep/services/spep/authzCacheC... 2008-09-16 12:48:10,420 INFO com.qut.middleware.esoe.pdp.cache.impl.PolicyCacheProcessorImpl - Recieved Success Status from AuthzClearCacheResponse. 2008-09-16 12:50:37,895 INFO com.qut.middleware.esoe.sso.impl.AuthenticationAuthorityProcessorBase - Detected incoming AuthnRequest encoding of UTF-16 will respond in same encoding 2008-09-16 12:50:37,957 INFO com.qut.middleware.esoe.sso.impl.AuthenticationAuthorityProcessorBase - Session not established, forcing authentication operation on principal 2008-09-16 12:50:46,255 WARN com.qut.middleware.esoe.authn.pipeline.authenticator.LdapBasicAuthenticator - LDAP exception while attempting LDAP search: Invalid Credentials 2008-09-16 12:50:56,708 WARN com.qut.middleware.esoe.authn.pipeline.authenticator.LdapBasicAuthenticator - LDAP exception while attempting LDAP search: Invalid Credentials 2008-09-16 12:51:14,475 INFO com.qut.middleware.esoe.sso.impl.AuthenticationAuthorityProcessorBase - Detected incoming AuthnRequest encoding of UTF-16 will respond in same encoding 2008-09-16 12:51:14,506 INFO com.qut.middleware.esoe.sso.impl.AuthenticationAuthorityProcessorBase - Session not established, forcing authentication operation on principal 2008-09-16 12:51:14,865 WARN com.qut.middleware.esoe.authn.pipeline.authenticator.KerberosV5Authenticato r - Server Login failed. Unable to process SPNEGO authentication requests. 2008-09-16 12:58:08,649 INFO com.qut.middleware.esoe.metadata.impl.MetadataUpdateMonitor - Rebuilding metadata cache from new revision 88203ceee5df874e5a32436fd5c9ef814c09bad2. =========================================================================== ===
Στις 16 Σεπτέμβριος 2008 2:49 πμ, ο χρήστης Shaun Mangelsdorf < s.mangelsd...@gmail.com> έγραψε:
> I've managed to reproduce this in my windows environment, so this is > definitely a platform problem. The problem is that the esoe.data, etc paths > are being interpreted as relative URIs to the base file:// URL. When there > is no leading / on the esoe.data location, the URL file://C:\esoe\... is > parsed.
> What this means, for windows platforms, is that the *.data parameters need > to be set as (for example): > -Desoe.data=/c:/esoe/core > -Dspep.data=/c:/esoe/spep > -Desoemanager.data=/c:/esoe/manager
> Obviously this would differ depending where the config is stored. The > important aspects of the URL here are the leading slash, and the fact that > they are forward slashes as used in URLs normally, rather than the > backslashes that windows uses for directory locations.
> Thanks for reporting this, we haven't come across this one yet. We'll > update the wiki documentation shortly to reflect this detail of > configuration.
Hi,
Lets start by disabling SPNEGO and just getting the plain LDAP authentication against your AD instance working.
To do this remove spengo as a value of activeAuthnPlugins in esoe.config (requires a restart).
Secondly specify an admin user DN and password for binding to AD and set recursive searching to be true. I would then manually test accessing AD via LDAP with this account using a tool like Apache DS Studio ( http://directory.apache.org/studio/ ) to ensure it connects correctly and is able to see all users you expect it to.
Restart ESOE and try auth with these settings and we'll see how your going at that point.
Aggelos Karalias wrote:
> Nice.. Thanks.. I am not sure if i could imagine that..
> Now i am one step forward and your help about path's syntax was the > solution. ESOE is up and running and when i am trying to open > esoemanager it redirects me to the magic login screen.
> But user's credentials cannot be authenticated against Active Directory.
> In ${esoe.data}/logging/esoe.log i am getting some WARNs, see the log > result below.
> I think that it makes the (network) connection to the AD and it then it > is not allowed to search for the user because of misconfiguration of the > userdn or the keytab file. In my home network (linux - openldap) it > works perfect.
> If can anyone help me or make a suggestion on this i would be grateful.
> PS: Happy to help, even with this accidentally bug report.
> *${esoe.data}/logging/esoe.log:*
> 2008-09-16 12:48:10,045 INFO
> com.qut.middleware.esoe.spep.impl.StartupImpl - Successfully registered > SPEP http://tech11.pds.piraeusgroup.gr:8080/esoemanager.
> 2008-09-16 12:48:10,232 INFO
> com.qut.middleware.esoe.pdp.cache.impl.PolicyCacheProcessorImpl - > Sending AuthzClearCacheRequest to > http://tech11.pds.piraeusgroup.gr:8080/spep/services/spep/authzCacheC... > 2008-09-16 12:48:10,420 INFO
> com.qut.middleware.esoe.pdp.cache.impl.PolicyCacheProcessorImpl - > Recieved Success Status from AuthzClearCacheResponse.
> 2008-09-16 12:50:37,895 INFO
> com.qut.middleware.esoe.sso.impl.AuthenticationAuthorityProcessorBase - > Detected incoming AuthnRequest encoding of UTF-16 will respond in same > encoding
> 2008-09-16 12:50:37,957 INFO
> com.qut.middleware.esoe.sso.impl.AuthenticationAuthorityProcessorBase - > Session not established, forcing authentication operation on principal
> 2008-09-16 12:50:46,255 WARN
> com.qut.middleware.esoe.authn.pipeline.authenticator.LdapBasicAuthenticator > - LDAP exception while attempting LDAP search: Invalid Credentials
> 2008-09-16 12:50:56,708 WARN
> com.qut.middleware.esoe.authn.pipeline.authenticator.LdapBasicAuthenticator > - LDAP exception while attempting LDAP search: Invalid Credentials
> 2008-09-16 12:51:14,475 INFO
> com.qut.middleware.esoe.sso.impl.AuthenticationAuthorityProcessorBase - > Detected incoming AuthnRequest encoding of UTF-16 will respond in same > encoding
> 2008-09-16 12:51:14,506 INFO
> com.qut.middleware.esoe.sso.impl.AuthenticationAuthorityProcessorBase - > Session not established, forcing authentication operation on principal
> 2008-09-16 12:51:14,865 WARN
> com.qut.middleware.esoe.authn.pipeline.authenticator.KerberosV5Authenticato r > - Server Login failed. Unable to process SPNEGO authentication requests.
> 2008-09-16 12:58:08,649 INFO
> com.qut.middleware.esoe.metadata.impl.MetadataUpdateMonitor - Rebuilding > metadata cache from new revision 88203ceee5df874e5a32436fd5c9ef814c09bad2.
> =========================================================================== ===
> Στις 16 Σεπτέμβριος 2008 2:49 πμ, ο χρήστης Shaun Mangelsdorf > <s.mangelsd...@gmail.com <mailto:s.mangelsd...@gmail.com>> έγραψε:
> Hi,
> I've managed to reproduce this in my windows environment, so this is
> definitely a platform problem. The problem is that the esoe.data,
> etc paths are being interpreted as relative URIs to the base file://
> URL. When there is no leading / on the esoe.data location, the URL
> file://C:\esoe\... is parsed.
> What this means, for windows platforms, is that the *.data
> parameters need to be set as (for example):
> -Desoe.data=/c:/esoe/core
> -Dspep.data=/c:/esoe/spep
> -Desoemanager.data=/c:/esoe/manager
> Obviously this would differ depending where the config is stored.
> The important aspects of the URL here are the leading slash, and the
> fact that they are forward slashes as used in URLs normally, rather
> than the backslashes that windows uses for directory locations.
> Thanks for reporting this, we haven't come across this one yet.
> We'll update the wiki documentation shortly to reflect this detail
> of configuration.
> Thanks,
> Shaun Mangelsdorf
-- Bradley Beddoes
Lead Software Architect
Intient Pty Ltd
I did test the user dn and the password with ldp.exe of Microsoft tools and it can search correctly.
The strange thing is that i have the user in AD and when i am running the ktpass then i cannot bind the user (from the ldp.exe for example) and it can only be bound if i reset his password. I cannot get this.
Anyway thanks for your help, i will try to disable SPNEGO and i will tell you.
On Wed, 2008-09-17 at 10:35 +1000, Bradley Beddoes wrote: > Hi, > Lets start by disabling SPNEGO and just getting the plain LDAP > authentication against your AD instance working.
> To do this remove spengo as a value of activeAuthnPlugins in esoe.config > (requires a restart).
> Secondly specify an admin user DN and password for binding to AD and set > recursive searching to be true. I would then manually test accessing AD > via LDAP with this account using a tool like Apache DS Studio ( > http://directory.apache.org/studio/ ) to ensure it connects correctly > and is able to see all users you expect it to.
> Restart ESOE and try auth with these settings and we'll see how your > going at that point.
> regards, > Bradley
> Aggelos Karalias wrote: > > Nice.. Thanks.. I am not sure if i could imagine that..
> > Now i am one step forward and your help about path's syntax was the > > solution. ESOE is up and running and when i am trying to open > > esoemanager it redirects me to the magic login screen.
> > But user's credentials cannot be authenticated against Active Directory. > > In ${esoe.data}/logging/esoe.log i am getting some WARNs, see the log > > result below.
> > I think that it makes the (network) connection to the AD and it then it > > is not allowed to search for the user because of misconfiguration of the > > userdn or the keytab file. In my home network (linux - openldap) it > > works perfect.
> > If can anyone help me or make a suggestion on this i would be grateful.
> > PS: Happy to help, even with this accidentally bug report.
> > *${esoe.data}/logging/esoe.log:* > > 2008-09-16 12:48:10,045 INFO > > com.qut.middleware.esoe.spep.impl.StartupImpl - Successfully registered > > SPEP http://tech11.pds.piraeusgroup.gr:8080/esoemanager. > > 2008-09-16 12:48:10,232 INFO > > com.qut.middleware.esoe.pdp.cache.impl.PolicyCacheProcessorImpl - > > Sending AuthzClearCacheRequest to > > http://tech11.pds.piraeusgroup.gr:8080/spep/services/spep/authzCacheC... > > 2008-09-16 12:48:10,420 INFO > > com.qut.middleware.esoe.pdp.cache.impl.PolicyCacheProcessorImpl - > > Recieved Success Status from AuthzClearCacheResponse. > > 2008-09-16 12:50:37,895 INFO > > com.qut.middleware.esoe.sso.impl.AuthenticationAuthorityProcessorBase - > > Detected incoming AuthnRequest encoding of UTF-16 will respond in same > > encoding > > 2008-09-16 12:50:37,957 INFO > > com.qut.middleware.esoe.sso.impl.AuthenticationAuthorityProcessorBase - > > Session not established, forcing authentication operation on principal > > 2008-09-16 12:50:46,255 WARN > > com.qut.middleware.esoe.authn.pipeline.authenticator.LdapBasicAuthenticator > > - LDAP exception while attempting LDAP search: Invalid Credentials > > 2008-09-16 12:50:56,708 WARN > > com.qut.middleware.esoe.authn.pipeline.authenticator.LdapBasicAuthenticator > > - LDAP exception while attempting LDAP search: Invalid Credentials > > 2008-09-16 12:51:14,475 INFO > > com.qut.middleware.esoe.sso.impl.AuthenticationAuthorityProcessorBase - > > Detected incoming AuthnRequest encoding of UTF-16 will respond in same > > encoding > > 2008-09-16 12:51:14,506 INFO > > com.qut.middleware.esoe.sso.impl.AuthenticationAuthorityProcessorBase - > > Session not established, forcing authentication operation on principal > > 2008-09-16 12:51:14,865 WARN > > com.qut.middleware.esoe.authn.pipeline.authenticator.KerberosV5Authenticato r > > - Server Login failed. Unable to process SPNEGO authentication requests. > > 2008-09-16 12:58:08,649 INFO > > com.qut.middleware.esoe.metadata.impl.MetadataUpdateMonitor - Rebuilding > > metadata cache from new revision 88203ceee5df874e5a32436fd5c9ef814c09bad2. > > =========================================================================== ===
> > Στις 16 Σεπτέμβριος 2008 2:49 πμ, ο χρήστης Shaun Mangelsdorf > > <s.mangelsd...@gmail.com <mailto:s.mangelsd...@gmail.com>> έγραψε:
> > Hi,
> > I've managed to reproduce this in my windows environment, so this is > > definitely a platform problem. The problem is that the esoe.data, > > etc paths are being interpreted as relative URIs to the base file:// > > URL. When there is no leading / on the esoe.data location, the URL > > file://C:\esoe\... is parsed.
> > What this means, for windows platforms, is that the *.data > > parameters need to be set as (for example): > > -Desoe.data=/c:/esoe/core > > -Dspep.data=/c:/esoe/spep > > -Desoemanager.data=/c:/esoe/manager
> > Obviously this would differ depending where the config is stored. > > The important aspects of the URL here are the leading slash, and the > > fact that they are forward slashes as used in URLs normally, rather > > than the backslashes that windows uses for directory locations.
> > Thanks for reporting this, we haven't come across this one yet. > > We'll update the wiki documentation shortly to reflect this detail > > of configuration.
> I was looking a long time for a good sso solution for my company's web
> apps and esoe seems to be good at all my needs.
> I have downloaded esoe and run the esoe startup project. I filled in
> any information wanted and the config files and DB was created
> successfully. Then i made the changes described to the documentation
> to handle Active Directory (yes, unfortunately i need to play with m$
> directory system). An esoe user and his keytab file created and
> changes was done in the ${esoe.data}/config/esoe.config file. ROOT
> changed and then all 4 .war files (ROOT, esoemanager, spep, web) was
> copied into tomcat's webapps folder. It is tomcat 6.0.18 and all
> endorsed and shared libraries are in ${tomcatroot}/endorsed and $
> {tomcatroot}/lib directories because these are the locations for
> tomcat 6.x (common and shared are not used).
> And then nothing at all. I don't know how to describe the problem so i
> put here a summary of my log files (everything seems useful).
> PS: i want to try it at home, there is a full linux network there with
> an openldap server, to check esoe in another environment.
|
