Re: [Kerberos Client] Works on Active Directory, question about connection pooling
On Thu, Apr 24, 2008 at 9:40 PM, Marc Boorshtein <[EMAIL PROTECTED]> wrote: > ApacheDSers, > > I just wanted to drop you guys a line to let you know that the > kerberos-client code works well with Active Directory (at least for a TGT, I > haven't tried a SGT) with one caveat. The user principal name in ad has the > domain as lowercase (ie [EMAIL PROTECTED]) but in order for the > kerberos-client code to work the domain needs to be upper case (ie > [EMAIL PROTECTED]). I don't know if this is because of the internal > code or AD. Glad to hear it. Which version of AD? Are you by any chance testing against 2008? I'll have to look into what the reasons are for the case issue. > ... > A question about the internals of the kerberos-client, does it make sense to > pool the connection objects? does it maintain an open connection or does it > open a new connection for each ticket? IIRC, the client is fully blocking and doesn't pool connections; a new connection is created each time. The intention was to use it for integration tests in JUnit, so there's nothing fancy w.r.t. scalibility or asynchronous support. Kerberos is a request-response (stateless) protocol and originally ran only over UDP (still the default) so at a protocol-level there's no point to reusing a connection. I haven't tested whether there is any benefit to reusing a TCP connection. Enrique
Re: [Kerberos] Client and server libraries?
On Thu, Apr 17, 2008 at 6:27 PM, Marc Boorshtein <[EMAIL PROTECTED]> wrote: > ApacheDSers, > > I'm looking to implement Kerberos for JLDAP (for MyVirtualDirectory). I've > got JNDI's Kerberos support working, but I don't like it all that much and > would like to integrate Kerberos into JLDAP. I know you guys have > implemented a server side library, do you guys have a client side kerberos > implementation? There is a client implementation, but the focus was on getting the minimum working to support integration tests of our own server and the JAAS Kerberos client was too rigid in it's configuration. I'm sure as soon as you tried it you'd find it was missing features you needed. But, it does do basic ticket acquisition and it allows us to test GSSAPI/Kerberos authentication to our own LDAP impl as well as integration-test our Change Password client, too. Enrique
Re: Sun and Apache will collaborate more...
On Tue, Apr 1, 2008 at 2:46 PM, Emmanuel Lecharny <[EMAIL PROTECTED]> wrote: > ... > In the next few daysn we will have to vote for 30 more committers, so be > ready to be flooded with VOTEs... > > The new product will be named Swordfish, to follow Sun's recent naming > (Glassfish and so on). A very appropriate name ! I don't like the name. Once we get those 30 committers processed, we should open a discussion thread to determine a new name. My vote is for "Brown Trout." Enrique
Re: DNS server
On Feb 8, 2008 6:52 AM, Alan D. Cabrera <[EMAIL PROTECTED]> wrote: > I'm interested in using the DNS server. Does anyone have any > information as to what kind of a load this thing can take and if it's > deployed in production anywhere? The DNS server is only capable of returning DNS answers that are stored in its local DIT. Put another way, there is no upstream support, for example forwarding queries to upstream nameservers and acting as a caching nameserver. Moreover, there is no zone transfer support. For these reasons, I doubt anyone has ever deployed it to production. I don't have any stats on load. Enrique
Re: Configuration in bigbang branch: names of SASL attributes and elements
On Dec 30, 2007 10:37 AM, Stefan Zoerner <[EMAIL PROTECTED]> wrote: > ... > But I had also to modify the value of attribute "searchBaseDn". I assume > this value is only used for user detection in SASL. I therefore propose > the name saslSearchBaseDn in order to make this consistent. Yes, this DN is only for finding users for purposes of authentication. > Another element name I wondered about was "supportedMechanisms". I > recommend to rename it to "supportedSaslMechanisms", because this is the > name used in the Root DSE for publication. In fact, it is > supportedSASLMechanisms, but this does not fit the name scheme. The issue here is that the 'supportedMechanisms' property allows you to enable/disable support for SIMPLE authentication and SIMPLE is not technically a SASL mechanism. Enrique
[jira] Resolved: (DIRSERVER-1095) [kerberos client]Kerberos Client lacks support for different encrypt types.
[
https://issues.apache.org/jira/browse/DIRSERVER-1095?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Enrique Rodriguez resolved DIRSERVER-1095.
--
Resolution: Fixed
Added support to kerberos-client for different encryption types
(DIRSERVER-1095):
o KdcControls object can now be used to customize desired encryption types.
Committed to kerberos-client module on revision 605783.
http://svn.apache.org/viewcvs.cgi?view=rev&rev=605783
> [kerberos client]Kerberos Client lacks support for different encrypt types.
> ---
>
> Key: DIRSERVER-1095
> URL: https://issues.apache.org/jira/browse/DIRSERVER-1095
> Project: Directory ApacheDS
> Issue Type: Bug
>Reporter: Leo Li
>Assignee: Enrique Rodriguez
>
> Hi, all
> The "DES-CBC-MD5" is the only encrypt type supported by current
> kerberos client and it fails to get TGT from MIT KDC server Krb5-1.5.4 since
> the KDC server does not support this encrypt type now.
>
> Below is the program:
> String hostname = "wks107904wss.cn.ibm.com";
> int port = 88;
> KdcConnection con = new KdcConnection( hostname + ":" + port );
> KerberosTicket tgt = con.getTicketGrantingTicket( clientPrincipal,
> password );
> But it fails with such stacktrace:
> Exception in thread "main"
> org.apache.directory.client.kerberos.KdcConnectionException:
> BAD_ENCRYPTION_TYPE
> at
> org.apache.directory.client.kerberos.GetTicketGrantingTicket.processError(GetTicketGrantingTicket.java:167)
> at
> org.apache.directory.client.kerberos.GetTicketGrantingTicket.execute(GetTicketGrantingTicket.java:153)
> at
> org.apache.directory.client.kerberos.KdcConnection.getTicketGrantingTicket(KdcConnection.java:118)
> at
> org.apache.directory.client.kerberos.KdcConnection.getTicketGrantingTicket(KdcConnection.java:101)
> at org.apache.directory.client.kerberos.Main.go(Main.java:62)
> at org.apache.directory.client.kerberos.Main.main(Main.java:55)
> And on the kdc side, the server has such log:
> Oct 23 16:12:28 wks107904wss.cn.ibm.com krb5kdc[2304](info) :
> AS_REQ(1 etypes{3}) 9.181.106.61:BAD_ENCRYPTION_TYPE:[EMAIL PROTECTED]
> for krbtgt/[EMAIL PROTECTED], KDC has no support for encryption
> type
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (DIRSERVER-1113) LDAP SASL GSSAPI lacks support for different Kerberos encryption types
[ https://issues.apache.org/jira/browse/DIRSERVER-1113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Enrique Rodriguez resolved DIRSERVER-1113. -- Resolution: Fixed Added support to LDAP SASL GSSAPI for different Kerberos encryption types (DIRSERVER-1113): o Call to retrieve Subject now iterates over all keys returned for the LDAP service principal and adds the keys to the private credentials. Committed to protocol-ldap module in 'bigbang' branch on revision 605767. http://svn.apache.org/viewcvs.cgi?view=rev&rev=605767 > LDAP SASL GSSAPI lacks support for different Kerberos encryption types > -- > > Key: DIRSERVER-1113 > URL: https://issues.apache.org/jira/browse/DIRSERVER-1113 > Project: Directory ApacheDS > Issue Type: Bug > Components: ldap >Affects Versions: 1.5.1 >Reporter: Enrique Rodriguez >Assignee: Enrique Rodriguez > Fix For: 1.5.2 > > > The SASL GSSAPI support in ApacheDS' LDAP protocol only supports DES-based > Kerberos encryption types. > The solution is to simply iterate over the keys for the LDAP service > principal and add them all to the Subject that is used by jGSS. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [bigbang] Internal bind problem
On Dec 19, 2007 2:33 PM, Alex Karasulu <[EMAIL PROTECTED]> wrote: > ... > I really would stay away from using the overloaded version of the method > that does not require a normalized DN , if you could please make that one > throw an exception as well. The best thing to do is to normalize the DN. > You can do this by getting a handle on the directoryService and using that > to get access to the attributeType registry. Then use this to get the > normalizer to attribute type mapping that is fed into the normalize() method > as the argument. 1) OK, these are more the steps to get this working that I was picturing. I will try this. 2) I haven't looked yet, but KdcServer fails if anonymous access is disabled. I suspect this is due to a similar issue, that KdcServer is not yet wired properly to access the directory service using a proper admin principal. 3) I will add the check to throw an IllegalStateException to the other form of the LdapPrincipal constructor. 4) I noticed SaslGssapiBindITest got moved to 'protocol-kerberos'. I suspect this was to get it out of the way and you guys were going to revisit it. Anyway, I have it working again, but this time with the kerberos-client, so I expect it should be in 'server-unit', alongside the other integration tests, so I will check in what I have and move it there. Can you ACK this change? Enrique
Re: [bigbang] Internal bind problem
On Dec 19, 2007 12:14 AM, Emmanuel Lecharny <[EMAIL PROTECTED]> wrote: > Hi Enrique, > > you can use the ServerDNConstants.ADMIN_SYSTEM_DN_NORMALIZED constant. > It's a normalized form of the admin principal. I saw this constant, but the problem is that the LdapPrincipal constructor calls LdapDN#isNormalized() and throws the IllegalStateException. I would need to create the LdapDN with the above normalized constant AND somehow set isNormalized to return 'true'. Anyway, I got around this (for now) by noticing that an alternate form of the LdapPrincipal constructor won't evaluate the LdapDN#isNormalized and thus won't ever throw the IllegalStateException. I just have to pass in a null userPassword. This doesn't feel like a real solution, but it does allow me to have SASL GSSAPI integration tests working again. Enrique
[bigbang] Internal bind problem
Hi, Directory developers, I'm trying to get the kerbero-client working, to replace JAAS and to get some integration tests live for SASL GSSAPI. I found the following problem trying to get SASL GSSAPI working in 'bigbang'. The problem is that in the findPrincipal# method of DefaultBindHandler, an LdapPrincipal is created to do an internal bind to the backend. However, this bind is rejected because the name must be normalized (see exception). FWIW, I noticed ServerDNConstants has a String constant for the normalized name. Can this be used to "shotgun" create a normalized admin principal? What is the recommended way to bind to the directory service internally? The code where the bind is attempted (in DefaultBindHandler): ... LdapPrincipal principal = new LdapPrincipal( new LdapDN( ServerDNConstants.ADMIN_SYSTEM_DN ), AuthenticationLevel.SIMPLE ); ctx = ldapServer.getDirectoryService().getJndiContext( principal, ldapServer.getSearchBaseDn() ); ... The resulting exception (which is swallowed, BTW): java.lang.IllegalStateException: Names used for principals must be normalized! at org.apache.directory.server.core.authn.LdapPrincipal.(LdapPrincipal.java:72) at org.apache.directory.server.ldap.support.DefaultBindHandler.findPrincipal(DefaultBindHandler.java:514) at org.apache.directory.server.ldap.support.DefaultBindHandler.getSubject(DefaultBindHandler.java:469) at org.apache.directory.server.ldap.support.DefaultBindHandler.handleSaslAuth(DefaultBindHandler.java:317) at org.apache.directory.server.ldap.support.DefaultBindHandler.bindMessageReceived(DefaultBindHandler.java:727) at org.apache.directory.server.ldap.support.BindHandler.messageReceived(BindHandler.java:48) at org.apache.mina.handler.demux.DemuxingIoHandler.messageReceived(DemuxingIoHandler.java:141) ... Enrique
Re: [kerberos] How to add client/server information into kerberos database
On Nov 29, 2007 1:23 PM, Enrique Rodriguez <[EMAIL PROTECTED]> wrote: > On Nov 28, 2007 11:29 PM, Spark Shen <[EMAIL PROTECTED]> wrote: > > I did not find document about how to add client/server information to kdc > > server , > > would any one give me a hand? Thanks in advance. > > ... > > I think the best doc we currently have is for configuring SASL GSSAPI, > since a subset of configuring SASL GSSAPI is configuring Kerberos > principals, so the docs are pretty good here: > ... FWIW, I started a new draft of doco for configuring just Kerberos principals. This is basically a quick extraction of Kerberos principal configuration from the aforementioned SASL GSSAPI doc. http://cwiki.apache.org/confluence/display/DIRxSBOX/Draft+-+ApacheDS+Kerberos+principal+configuration HTH, Enrique
[jira] Created: (DIRSERVER-1113) LDAP SASL GSSAPI lacks support for different Kerberos encryption types
LDAP SASL GSSAPI lacks support for different Kerberos encryption types -- Key: DIRSERVER-1113 URL: https://issues.apache.org/jira/browse/DIRSERVER-1113 Project: Directory ApacheDS Issue Type: Bug Components: ldap Affects Versions: 1.5.1 Reporter: Enrique Rodriguez Assignee: Enrique Rodriguez Fix For: 1.5.2 The SASL GSSAPI support in ApacheDS' LDAP protocol only supports DES-based Kerberos encryption types. The solution is to simply iterate over the keys for the LDAP service principal and add them all to the Subject that is used by jGSS. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Created: (DIRSERVER-1108) [kerberos]org.apache.directory.server.kerberos.shared.crypto.encryption.ArcFourHmacMd5Encryption decryption function is not complete
FYI, I marked this issue as duplicating the much-earlier DIRSERVER-156, which we had been using to track RC4-HMAC encryption support. https://issues.apache.org/jira/browse/DIRSERVER-156 "ArcFour" is aka RC4. Enrique On Dec 6, 2007 9:38 PM, spark shen (JIRA) <[EMAIL PROTECTED]> wrote: > [kerberos]org.apache.directory.server.kerberos.shared.crypto.encryption.ArcFourHmacMd5Encryption > decryption function is not complete > > > Key: DIRSERVER-1108 > URL: https://issues.apache.org/jira/browse/DIRSERVER-1108 > Project: Directory ApacheDS > Issue Type: Bug > Components: kerberos >Reporter: spark shen >
Re: [bigbang] Bug fixes to trunk or bigbang?
On Dec 13, 2007 4:42 PM, Emmanuel Lecharny <[EMAIL PROTECTED]> wrote: > ... > Hope those explainations are clear enough :) OK, so I'll continue to fix bugs against bigbang. Enrique
[bigbang] Bug fixes to trunk or bigbang?
Hi, Directory developers, I have email access from work now, but still no IM. I noticed bigbang was merged? I take it this means new fixes to apacheds should go against trunk now? If so, then bigbang is no longer used and then why does the branch still exist? Enrique
Re: [kerberos] How to add client/server information into kerberos database
On Nov 28, 2007 11:29 PM, Spark Shen <[EMAIL PROTECTED]> wrote: > I did not find document about how to add client/server information to kdc > server , > would any one give me a hand? Thanks in advance. > ... I think the best doc we currently have is for configuring SASL GSSAPI, since a subset of configuring SASL GSSAPI is configuring Kerberos principals, so the docs are pretty good here: http://directory.apache.org/apacheds/1.5/howto-do-sasl-gssapi-authentication-to-apacheds.html You can skip ahead to steps 12-14, in which you (#12) enable the Kerberos protocol, (#13) enable the Key Derivation interceptor, and then (#14) load an LDIF file. You load principals using standard LDAP means, so you can also use the LDAP protocol. Though, for getting started, an LDIF file is pretty straightforward. In that doc is a link to an LDIF showing how to format an LDIF file: http://directory.apache.org/apacheds/1.5/howto-do-sasl-gssapi-authentication-to-apacheds.data/sasl-gssapi-example.ldif The rest of your config looks OK. Enrique
Re: Building DS Trunk From SVN
On Nov 27, 2007 12:31 PM, Enrique Rodriguez <[EMAIL PROTECTED]> wrote: > On Nov 27, 2007 3:11 AM, <[EMAIL PROTECTED]> wrote: > > ... > > Failed tests: > > > > testServerNotFound(org.apache.directory.server.kerberos.protocol.TicketGrantingServiceTest) > > > > --- > > > > Have I missed something in my configuration/environment? > > > > This is building SVN trunk today using Sun JDK 1.5.0_11 on Windows 2003 > > Server. > > I am unable to verify this, but I'm on a Mac. I'll try on Linux in a > bit ... I couldn't duplicate on Linux, either. Enrique
Re: Building DS Trunk From SVN
On Nov 27, 2007 3:11 AM, <[EMAIL PROTECTED]> wrote: > ... > Failed tests: > > testServerNotFound(org.apache.directory.server.kerberos.protocol.TicketGrantingServiceTest) > > --- > > Have I missed something in my configuration/environment? > > This is building SVN trunk today using Sun JDK 1.5.0_11 on Windows 2003 > Server. I am unable to verify this, but I'm on a Mac. I'll try on Linux in a bit. However, to my knowledge nothing has changed in trunk lately, especially not with Kerberos. Have you built either of the branches, either apacheds-kerberos or bigbang? I ask because they use the same version number so they collide in the local Maven repo. Whenever I switch branches/trunk I have to 'mvn install' shared and apacheds to make sure snapshots installed pertain to the correct branch or trunk. I'm not sure if there is a best practice for having 3 lines of code with the same version number, since I'm having the same problem working in kerberos-clients, where I have to make sure I'm working against the trunk's installed artifacts. Having more of the logs for this failure would help, too. Enrique
[jira] Closed: (DIRSERVER-1100) [kerberos]org.apache.directory.server.kerberos.shared.crypto.encryption.DesCbcCrcEncryption cannot decrypt the encryptiondata it generated.
[
https://issues.apache.org/jira/browse/DIRSERVER-1100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Enrique Rodriguez closed DIRSERVER-1100.
Resolution: Fixed
Fix Version/s: bigbang
Corrected padding algorithm error in DES encryption types (DIRSERVER-1100):
o Corrected padding algorithm error in DesCbcCrcEncryption.
o Also corrected padding algorithm error in DesCbcMd5Encryption, however
algorithm error had no effect.
o Added new test cases for above encryption types.
Committed to kerberos-shared module in 'bigbang' branch on revision 597792.
http://svn.apache.org/viewcvs.cgi?view=rev&rev=597792
> [kerberos]org.apache.directory.server.kerberos.shared.crypto.encryption.DesCbcCrcEncryption
> cannot decrypt the encryptiondata it generated.
> ---
>
> Key: DIRSERVER-1100
> URL: https://issues.apache.org/jira/browse/DIRSERVER-1100
> Project: Directory ApacheDS
> Issue Type: Bug
> Components: kerberos
>Reporter: Leo Li
>Assignee: Enrique Rodriguez
> Fix For: bigbang
>
> Attachments: Directory_100.diff
>
>
> Here is an example:
> import javax.security.auth.kerberos.KerberosKey;
> import javax.security.auth.kerberos.KerberosPrincipal;
> import
> org.apache.directory.server.kerberos.shared.messages.value.EncryptedData;
> import
> org.apache.directory.server.kerberos.shared.messages.value.EncryptionKey;
> import org.apache.directory.server.kerberos.shared.crypto.encryption.*;
> public static void main(String[] args) throws Exception{
>final char[] PASSWORD = "PASSWORD".toCharArray();
>KerberosKey key = new KerberosKey(new KerberosPrincipal("[EMAIL
> PROTECTED]"),PASSWORD, "DES");
>byte[] keyBytes = key.getEncoded();
>EncryptionKey encryptionKey = new
> EncryptionKey(EncryptionType.DES_CBC_CRC, keyBytes);
>byte[] plainText = {1,2,3,4,5,6,7};
>DesCbcCrcEncryption encryption = new DesCbcCrcEncryption();
>EncryptedData encryptionData =
> encryption.getEncryptedData(encryptionKey, plainText, KeyUsage.NUMBER1); // I
> am not sure of which KeyUsage should use here, but it is not referenced in
> source code. So I think any will work.
>encryption.getDecryptedData(encryptionKey, encryptionData,
> KeyUsage.NUMBER1);
>System.out.println("Succeed!");
> }
> But it fails with such complain:
> Exception in thread "main"
> org.apache.directory.server.kerberos.shared.exceptions.KerberosException:
> Integrity check on decrypted field failed
> at
> org.apache.directory.server.kerberos.shared.crypto.encryption.DesCbcCrcEncryption.getDecryptedData(DesCbcCrcEncryption.java:113)
> at TestDESCBCCRC.main(TestDESCBCCRC.java:21)
> After I look a further into it, it is due to current implementation
> (r595192) there is two paddings in DesCbcCrcEncryption.getEncryptedData:
> LINE 126:
>byte[] paddedPlainText = padString( plainText );
> byte[] dataBytes = concatenateBytes( conFounder, concatenateBytes(
> zeroedChecksum, paddedPlainText ) );
> byte[] checksumBytes = calculateIntegrity( dataBytes, null, usage );
> byte[] paddedDataBytes = padString( dataBytes );
> But RFC 3961
> "One generates a random confounder of one block, placing it in
>'confounder'; zeros out the 'checksum' field (of length appropriate
>to exactly hold the checksum to be computed); adds the necessary
>padding; calculates the appropriate checksum over the whole sequence,
>placing the result in 'checksum'; and then encrypts using the
>specified encryption type and the appropriate key."
> So the checksum should be calculated after all padding for encryption has
> finished.
> It seems that the same problem occurs in other Encryption classes.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [bigbang] Branch compilation failure, 2 of 2
On Nov 22, 2007 2:02 PM, Enrique Rodriguez <[EMAIL PROTECTED]> wrote: > ... > I was able to get the 'bigbang' branch to build on a Mac by > downloading and installing an updated JDK from the Apple Developer > Connection. If you login and go to Downloads, there is a developer > preview release that updates the JDK for Mac ... This may be hard to find, since it's not on the main Downloads page. You have to: 1) Go to http://connect.apple.com/ 2) Login or create account. 3) Go to Downloads. 4) Download the "Java for Mac OS X 10.4, Release 6 Developer Preview 1" "This release updates J2SE 5.0 to version 1.5.0_13 and Java 1.4 to version 1.4.2_16." HTH, Enrique
[bigbang] Branch compilation failure, 2 of 2
Hi, Directory developers, I was able to get the 'bigbang' branch to build on a Mac by downloading and installing an updated JDK from the Apple Developer Connection. If you login and go to Downloads, there is a developer preview release that updates the JDK for Mac to: $ java -version java version "1.5.0_13" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_13-b05-241) Java HotSpot(TM) Client VM (build 1.5.0_13-120, mixed mode, sharing) BTW, I also had to update the MINA version to 1.1.6-SNAPSHOT (micro revision update) because 1.1.4-SNAPSHOT isn't deployed and I didn't feel like digging it out of SVN. Enrique
Re: [ApacheDS] Questions about the server.xml file of Apache DS 1.5.1 ?
On Nov 16, 2007 1:44 AM, Pierre-Arnaud Marcelot <[EMAIL PROTECTED]> wrote:
> ...
> Earlier in the file we can see this property in the environment bean:
> > simple
> >
>
> Can this "java.naming.security.authentication" property be set to something
> else than 'simple' ? If yes, I suppose the value has to chosen between one
> of the supported mechanisms right ?
The property is for internal binding, so it is set to simple and I
don't believe any other value has an effect, since SASL binds only
take place via the LDAP (wire) protocol. This is mostly a side-effect
from using JNDI as the internal interface, since it doesn't really
make sense to have SASL ("strong") bind types internal to the server.
The list of SASL supported mechanisms is what you want to "turn on" to
allow clients to use with the LDAP (wire) protocol.
So, this property is unrelated to our SASL support. For a developer
using Sun's JNDI client, you would be able to use this property in
client-side code to choose the simple or SASL mechanism you want to
use. You can see this in action in the SASL bind and SASL GSSAPI
tests in 'server-unit'.
The other guys can comment more but I think this property is going
away with the removal of JNDI in 'bigbang'.
Enrique
[Kerberos] Bug fix commit location
Hi, Directory developers, I have a bug fix and new tests for DIRSERVER-1100, which is a bug in DES-CBC-CRC encryption. I'm looking for guidance on where to commit it, since we have 2 open branches. Sorry, for all the clarifying questions about commits and branches, but I'm under work lockdown w.r.t. email access so I want to check before making commits since I can't follow-up very quickly with commit messages, dev list traffic, or continuous integration feedback in case I mess something up. Enrique
[jira] Commented: (DIRSERVER-1100) [kerberos]org.apache.directory.server.kerberos.shared.crypto.encryption.DesCbcCrcEncryption cannot decrypt the encryptiondata it generated.
[
https://issues.apache.org/jira/browse/DIRSERVER-1100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12542938
]
Enrique Rodriguez commented on DIRSERVER-1100:
--
I have this verified and fixed, with new test cases. I just need to get to
email to double-check where to commit it and to verify commit messages and CI.
> [kerberos]org.apache.directory.server.kerberos.shared.crypto.encryption.DesCbcCrcEncryption
> cannot decrypt the encryptiondata it generated.
> ---
>
> Key: DIRSERVER-1100
> URL: https://issues.apache.org/jira/browse/DIRSERVER-1100
> Project: Directory ApacheDS
> Issue Type: Bug
> Components: kerberos
>Reporter: Leo Li
> Assignee: Enrique Rodriguez
> Attachments: Directory_100.diff
>
>
> Here is an example:
> import javax.security.auth.kerberos.KerberosKey;
> import javax.security.auth.kerberos.KerberosPrincipal;
> import
> org.apache.directory.server.kerberos.shared.messages.value.EncryptedData;
> import
> org.apache.directory.server.kerberos.shared.messages.value.EncryptionKey;
> import org.apache.directory.server.kerberos.shared.crypto.encryption.*;
> public static void main(String[] args) throws Exception{
>final char[] PASSWORD = "PASSWORD".toCharArray();
>KerberosKey key = new KerberosKey(new KerberosPrincipal("[EMAIL
> PROTECTED]"),PASSWORD, "DES");
>byte[] keyBytes = key.getEncoded();
>EncryptionKey encryptionKey = new
> EncryptionKey(EncryptionType.DES_CBC_CRC, keyBytes);
>byte[] plainText = {1,2,3,4,5,6,7};
>DesCbcCrcEncryption encryption = new DesCbcCrcEncryption();
>EncryptedData encryptionData =
> encryption.getEncryptedData(encryptionKey, plainText, KeyUsage.NUMBER1); // I
> am not sure of which KeyUsage should use here, but it is not referenced in
> source code. So I think any will work.
>encryption.getDecryptedData(encryptionKey, encryptionData,
> KeyUsage.NUMBER1);
>System.out.println("Succeed!");
> }
> But it fails with such complain:
> Exception in thread "main"
> org.apache.directory.server.kerberos.shared.exceptions.KerberosException:
> Integrity check on decrypted field failed
> at
> org.apache.directory.server.kerberos.shared.crypto.encryption.DesCbcCrcEncryption.getDecryptedData(DesCbcCrcEncryption.java:113)
> at TestDESCBCCRC.main(TestDESCBCCRC.java:21)
> After I look a further into it, it is due to current implementation
> (r595192) there is two paddings in DesCbcCrcEncryption.getEncryptedData:
> LINE 126:
>byte[] paddedPlainText = padString( plainText );
> byte[] dataBytes = concatenateBytes( conFounder, concatenateBytes(
> zeroedChecksum, paddedPlainText ) );
> byte[] checksumBytes = calculateIntegrity( dataBytes, null, usage );
> byte[] paddedDataBytes = padString( dataBytes );
> But RFC 3961
> "One generates a random confounder of one block, placing it in
>'confounder'; zeros out the 'checksum' field (of length appropriate
>to exactly hold the checksum to be computed); adds the necessary
>padding; calculates the appropriate checksum over the whole sequence,
>placing the result in 'checksum'; and then encrypts using the
>specified encryption type and the appropriate key."
> So the checksum should be calculated after all padding for encryption has
> finished.
> It seems that the same problem occurs in other Encryption classes.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (DIRSERVER-1100) [kerberos]org.apache.directory.server.kerberos.shared.crypto.encryption.DesCbcCrcEncryption cannot decrypt the encryptiondata it generated.
[
https://issues.apache.org/jira/browse/DIRSERVER-1100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Enrique Rodriguez reassigned DIRSERVER-1100:
Assignee: Enrique Rodriguez
> [kerberos]org.apache.directory.server.kerberos.shared.crypto.encryption.DesCbcCrcEncryption
> cannot decrypt the encryptiondata it generated.
> ---
>
> Key: DIRSERVER-1100
> URL: https://issues.apache.org/jira/browse/DIRSERVER-1100
> Project: Directory ApacheDS
> Issue Type: Bug
> Components: kerberos
>Reporter: Leo Li
> Assignee: Enrique Rodriguez
> Attachments: Directory_100.diff
>
>
> Here is an example:
> import javax.security.auth.kerberos.KerberosKey;
> import javax.security.auth.kerberos.KerberosPrincipal;
> import
> org.apache.directory.server.kerberos.shared.messages.value.EncryptedData;
> import
> org.apache.directory.server.kerberos.shared.messages.value.EncryptionKey;
> import org.apache.directory.server.kerberos.shared.crypto.encryption.*;
> public static void main(String[] args) throws Exception{
>final char[] PASSWORD = "PASSWORD".toCharArray();
>KerberosKey key = new KerberosKey(new KerberosPrincipal("[EMAIL
> PROTECTED]"),PASSWORD, "DES");
>byte[] keyBytes = key.getEncoded();
>EncryptionKey encryptionKey = new
> EncryptionKey(EncryptionType.DES_CBC_CRC, keyBytes);
>byte[] plainText = {1,2,3,4,5,6,7};
>DesCbcCrcEncryption encryption = new DesCbcCrcEncryption();
>EncryptedData encryptionData =
> encryption.getEncryptedData(encryptionKey, plainText, KeyUsage.NUMBER1); // I
> am not sure of which KeyUsage should use here, but it is not referenced in
> source code. So I think any will work.
>encryption.getDecryptedData(encryptionKey, encryptionData,
> KeyUsage.NUMBER1);
>System.out.println("Succeed!");
> }
> But it fails with such complain:
> Exception in thread "main"
> org.apache.directory.server.kerberos.shared.exceptions.KerberosException:
> Integrity check on decrypted field failed
> at
> org.apache.directory.server.kerberos.shared.crypto.encryption.DesCbcCrcEncryption.getDecryptedData(DesCbcCrcEncryption.java:113)
> at TestDESCBCCRC.main(TestDESCBCCRC.java:21)
> After I look a further into it, it is due to current implementation
> (r595192) there is two paddings in DesCbcCrcEncryption.getEncryptedData:
> LINE 126:
>byte[] paddedPlainText = padString( plainText );
> byte[] dataBytes = concatenateBytes( conFounder, concatenateBytes(
> zeroedChecksum, paddedPlainText ) );
> byte[] checksumBytes = calculateIntegrity( dataBytes, null, usage );
> byte[] paddedDataBytes = padString( dataBytes );
> But RFC 3961
> "One generates a random confounder of one block, placing it in
>'confounder'; zeros out the 'checksum' field (of length appropriate
>to exactly hold the checksum to be computed); adds the necessary
>padding; calculates the appropriate checksum over the whole sequence,
>placing the result in 'checksum'; and then encrypts using the
>specified encryption type and the appropriate key."
> So the checksum should be calculated after all padding for encryption has
> finished.
> It seems that the same problem occurs in other Encryption classes.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [DNS] Trunk or branch for DNS work?
On Nov 13, 2007 11:47 PM, Alex Karasulu <[EMAIL PROTECTED]> wrote: > ... > You are being overly cautious on the wrong front here. If this client > code is just used for tests (with test scope) then the clients will > not be > packaged with the product. > > I don't know if I expressed myself well enough but do you see what I mean? Of course I understand the clients will not be packaged with the product. What I'm trying to avoid is breaking the build by having integration tests using kerberos-client fail, because the kerberos-client is unstable. > ... > bugs if your tests flush them out. You are doing great by adding > tests for existing features. You are not adding new features without > tests, so there is no reason to keep your effort in a sandbox. Tests > are good things which should be given more leeway in the review > process. I agree tests should be given more leeway. Enrique
Re: [DNS] Trunk or branch for DNS work?
On Nov 12, 2007 12:36 PM, Alex Karasulu <[EMAIL PROTECTED]> wrote: > ... > One reason to keep them together for now is due to the changelog > effort which will speed up all the tests. When I start doing this > it's nice to have all the networked integration tests in one place. > Then if you want to open discussions on messing with this convention > that's up to you. OK, I'll put stable tests into 'server-unit'. However, I would like to *only temporarily* add integration tests to the kerberos-client. These integration tests would test the alpha-quality kerberos-client against the full ApacheDS backend. The reason I wouldn't put them directly into server-unit is that the kerberos-client should be considered unstable so I wouldn't want to put it near trunk. Of course, once I've tested it more and it appears stable, then we can use it to replace the JAAS Kerberos client in server-unit and get both test coverage for the Kerberos protocol and its interactions via SASL GSSAPI. Also, I would like to pass integration tests through my personal sandbox since I need to test on multiple machines and VMs and to simply back-up work, but, again, you can expect them to work their way into server-unit shortly. Enrique
Re: [DNS] Trunk or branch for DNS work?
On Nov 12, 2007 7:10 AM, Emmanuel Lecharny <[EMAIL PROTECTED]> wrote: > ... > Yes. But these tests should be kept into some dns-unit project (which > does not currently exists). The base idea is to be able to run those > tests without modifying the core server (which protocol-dns is part of). > Having some comparison between what the server is doing and what dnsjava > provides is an excellent idea. We have done that with the ASN.1 codec at > the beginning. But dnsjava should not be used _inside_ protocol_dns. > ... > There is nothing bad about dnsjava. It's just that we need it to be used > in some kind of specific place where it does not impact the core server. > A protocol-dns-unit project would be the perfect place to do that. I agree with Emmanuel w.r.t. creating protocol-[XYZ]-unit modules for integration tests specific to a given protocol. For integration tests that test the collaboration of multiple protocols, such as SASL GSSAPI/Kerberos and DNS TSIG GSSAPI Kerberos that we would continue to place them in server-unit. If this is OK, I'll create the modules as I add tests. FYI, you may see me commit some tests initially to my sandbox so I can pass them between my laptop and main development machines to test various platforms and VMs. Enrique
Re: [DNS] Trunk or branch for DNS work?
On Nov 11, 2007 3:35 PM, Alex Karasulu <[EMAIL PROTECTED]> wrote: > The dependency is OK in server-unit but not in protocol-dns. If you > want to do over the wire tests do it in server-unit. This is the > point to the module: it's there specifically for over the wire > integration tests. I'm confused because it seems both you and Emm approved the addition of the commons NTP client to the protocol-ntp module, which is used in exactly the same way I was intending to use 'dnsjava', namely with over-the-wire NTP tests. So then, the NTP client and test(s) should be moved to 'server-unit'? In which case we're back to a scalability problem w.r.t. deps in server-unit. Or is it the case that the dep in protocol-ntp is acceptable because NTP doesn't use the backend DIT? Be assured, my intention here has nothing to with creating a "standalone product" but rather the generally-accepted principle of loose-coupling. Enrique
Re: [bigbang] Branch compilation failure, 2 of 2
On Nov 11, 2007 2:01 PM, Emmanuel Lecharny <[EMAIL PROTECTED]> wrote: > ... > Strange. May be you should doom your maven repo. I was afraid of that ... I'm roaming on a Mac w/wireless. But, I deleted my entire repo and it made no difference ... same error. I think I may have to wait until 'bigbang' is merged to address the DNS-related JIRA issues. Enrique
Re: [DNS] Trunk or branch for DNS work?
On Nov 10, 2007 8:51 PM, Alex Karasulu <[EMAIL PROTECTED]> wrote:
> ...
> I agree but dnsjava is a client library. Are you using it to go
> through the wire via
> the protocol?
'dnsjava' has some functions that would be useful for doing PDU-level
comparisions, to test our codecs in isolation. It also has some
routines for working with domain names. However, I *would* like to
also use it to test the DnsServer over-the-wire with a stub backend.
The unit testing cycle and overall development is much faster without
involving the backend. Ideally we would package the same tests with
'dnsjava' that both run against a stub store as well as the full
ApacheDS in 'server-unit', using some technique like the Maven 2
"tests" classifier that David Jencks detailed a bit ago.
I would also like to point out that in DIRSERVER-1091 the backend is
custom ("MyRecordStore"), so I think it makes sense to provide these
tests such that they don't require the full DIT. As we can see from
DIRSERVER-1091, DIRSERVER-1092, and DIRSERVER-1093, there is a benefit
to making the protocol providers function without requiring the DIT
backend since it opens our user base to a wider community.
Enrique
[bigbang] Branch compilation failure, 2 of 2
Hi, Directory developers, The 'bigbang' branch fails to compile with the following error: ... core-entry/src/main/java/org/apache/directory/server/core/entry/BasicServerAttribute.java:[108,22] inconvertible types found : org.apache.directory.server.core.entry.ServerValue required: org.apache.directory.server.core.entry.ServerStringValue core-entry/src/main/java/org/apache/directory/server/core/entry/BasicServerAttribute.java:[112,22] inconvertible types found : org.apache.directory.server.core.entry.ServerValue required: org.apache.directory.server.core.entry.ServerBinaryValue core-entry/src/main/java/org/apache/directory/server/core/entry/ObjectClassAttribute.java:[109,22] inconvertible types found : org.apache.directory.server.core.entry.ServerValue required: org.apache.directory.server.core.entry.ServerStringValue ... I'm not sure what's up here. I'm building the bigbang versions of project, shared, and apacheds. Also, I'm on a Mac with 'java -version': java version "1.5.0_07" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_07-164) Java HotSpot(TM) Client VM (build 1.5.0_07-87, mixed mode, sharing) HTH, Enrique
[bigbang] Branch compilation failure, 1 of 2
Hi, Directory developers, The 'bigbang' branch fails to compile for me, with: ... core/src/main/java/org/apache/directory/server/core/changelog/MemoryChangeLogStoreTest.java:[22,23] package junit.framework does not exist core/src/main/java/org/apache/directory/server/core/changelog/MemoryChangeLogStoreTest.java:[40,46] cannot find symbol symbol: class TestCase public class MemoryChangeLogStoreTest extends TestCase core/src/main/java/org/apache/directory/server/core/changelog/MemoryChangeLogStoreTest.java:[47,8] cannot find symbol symbol : variable super location: class org.apache.directory.server.core.changelog.MemoryChangeLogStoreTest ... Should this Test class be moved to the 'src/test/java' directory? Enrique
[DNS] Trunk or branch for DNS work?
On Nov 10, 2007 7:16 PM, Alex Karasulu <[EMAIL PROTECTED]> wrote: > Yes the bigbang branch is probably best. Also do you need to have dnsjava dep > in the protocol-dns side if the integration tests that test the DNS > protocol over the > wire are going to be in server-unit? 'dnsjava' would be used for non-integration tests in 'protocol-dns'. I think it makes sense to have both integration tests to make sure the backend is fully functional but also to have regular unit tests to test finer-grained functionality. This would also have the benefit of making sure protocol workflow is tested during normal builds, ie 'mvn install' w/o integration profile. Enrique
[DNS] Trunk or branch for DNS work?
Hi, Directory developers, Just wanted to check if you have a preference for where to put DNS work, given the changes you've made in branches. IIRC, I saw a commit where the DNS chain was removed. I have 3 JIRA issues and a 4th bug I found tonight with DNS, plus tests for protocol-dns and integration tests for server-unit. FYI, I'd like to add the 'dnsjava' dependency to both protocol-dns and server-unit since it is useful for regular tests and integration tests. Hope that's OK. Enrique
[jira] Assigned: (DIRSERVER-1095) [kerberos client]Kerberos Client lacks support for different encrypt types.
[
https://issues.apache.org/jira/browse/DIRSERVER-1095?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Enrique Rodriguez reassigned DIRSERVER-1095:
Assignee: Enrique Rodriguez
> [kerberos client]Kerberos Client lacks support for different encrypt types.
> ---
>
> Key: DIRSERVER-1095
> URL: https://issues.apache.org/jira/browse/DIRSERVER-1095
> Project: Directory ApacheDS
> Issue Type: Bug
>Reporter: Leo Li
> Assignee: Enrique Rodriguez
>
> Hi, all
> The "DES-CBC-MD5" is the only encrypt type supported by current
> kerberos client and it fails to get TGT from MIT KDC server Krb5-1.5.4 since
> the KDC server does not support this encrypt type now.
>
> Below is the program:
> String hostname = "wks107904wss.cn.ibm.com";
> int port = 88;
> KdcConnection con = new KdcConnection( hostname + ":" + port );
> KerberosTicket tgt = con.getTicketGrantingTicket( clientPrincipal,
> password );
> But it fails with such stacktrace:
> Exception in thread "main"
> org.apache.directory.client.kerberos.KdcConnectionException:
> BAD_ENCRYPTION_TYPE
> at
> org.apache.directory.client.kerberos.GetTicketGrantingTicket.processError(GetTicketGrantingTicket.java:167)
> at
> org.apache.directory.client.kerberos.GetTicketGrantingTicket.execute(GetTicketGrantingTicket.java:153)
> at
> org.apache.directory.client.kerberos.KdcConnection.getTicketGrantingTicket(KdcConnection.java:118)
> at
> org.apache.directory.client.kerberos.KdcConnection.getTicketGrantingTicket(KdcConnection.java:101)
> at org.apache.directory.client.kerberos.Main.go(Main.java:62)
> at org.apache.directory.client.kerberos.Main.main(Main.java:55)
> And on the kdc side, the server has such log:
> Oct 23 16:12:28 wks107904wss.cn.ibm.com krb5kdc[2304](info) :
> AS_REQ(1 etypes{3}) 9.181.106.61:BAD_ENCRYPTION_TYPE:[EMAIL PROTECTED]
> for krbtgt/[EMAIL PROTECTED], KDC has no support for encryption
> type
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [kerberos] Potential problem in AuthenticationServiceChain
On 10/31/07, Emmanuel Lecharny <[EMAIL PROTECTED]> wrote:
> ...
> I'm looking again in the AuthenticationServiceChain (which has been
> removed in bigbang branch), and I see this code :
> ...
> As one can see, the next.execute() method is called twice if the
> authContext.getClientKey() is not null.
>
> Should I presume that the method should return immediatly in tis case
> instead of going through all the following code ? Something like :
> ...
> if ( authContext.getClientKey() != null )
> {
> next.execute( session, message );
> return;
> }
> ...
Yes, definitely.
Enrique
Re: [Kerberos] Ticket structure
On 10/29/07, Emmanuel Lecharny <[EMAIL PROTECTED]> wrote: > ... > Now, I'm wondering if it's a good thing to also provide the accessors to > this unsealed value in the Ticket class. I would favor this kind of access : > > ticket.getDecryptedTicket().getClientAddresses() > > instead of : > > ticket.getClientAddresses() > > At first sight, it seems that the second form is lighter, but it has the > big inconvenient to duplicate the accessors : you already have a > getClientAddesses() method in the EncTicketpart class. > ... I think the delegate methods are a better API. Certainly the methods are duplicated, but you can auto-generate these methods in an IDE (assuming logical names) and also you can make the methods on the EncTicketPart package-scoped. Developers would work only with the Ticket class and we'd throw IllegalStateException on methods when the Ticket is not yet decrypted. > I like to have basic structure being as close as possible to the ASN.1 > names, because it helps people who read the RFCs to get a quick > understanding of the code. But I also have some concerns when it comes > to implement, say, 'sname'. Ticket.getSName() is really not the best > method call I ever saw, compared to Ticket.getServerName(). I totally agree and it gets worse. 'sname' at least follows a bit of a convention with 'cname', 'srealm', and 'crealm'. Contrast this with 'from', 'till', 'rtime', 'authtime', 'starttime', 'endtime', and 'renew-till'. I understand your reasoning, and it's noble, but I recall my early days with Kerberos when, for the longest time, I misinterpreted 'rtime' on a regular basis. > I don't know. The idea is to discuss all those kind of questions in > order to share the ideas and have the best solution, as a community. > > If you tell me that getSName() is far from being perfect, I will just > switch back to the previous name :) (anyway, I don't like this name > either... ) 'getSName()' is far from perfect. Enrique
Re: [kerberos client]Problem to obtain TGT from KDC.
On 10/30/07, Leo Li <[EMAIL PROTECTED]> wrote: > ... >Thanks, Enrique. >I found it is not the problem with apache ds's kerberos client but > in fact the KDC I used: all other encrypt types can work except > des-cbc-md5. :) >So could you tell me what is the "long form of the ApacheDS Kerberos > client component" which can specify the encrypt type? Long form is described here: http://cwiki.apache.org/confluence/display/DIRxSBOX/Draft+-+Kerberos+client+components There is a controls object (modeled after JNDI controls) that allows you to set less commonly used parameters. I thought this might help keep the API simple for the common cases. Feedback about API appreciated. Enrique
[DNS] Test commit plan
Hi, Directory developers, I have tests to commit for DNS and just wanted to double-check a few things before I commit. 1) I want to add 'dnsjava' as a dep to 'protocol-dns'. This is our best bet for cross-platform tests, since the DNS JNDI provider is only Sun JDK, AFAICT. 2) I would add these tests to 'protocol-dns'. I have a HashMap-backed implementation of the RecordStore interface. This avoids the need to start-up the ApacheDS backend and so it doesn't make sense to put these tests anywhere but 'protocol-dns', as opposed to 'server-unit'. If this sounds good, I'll can start to commit this week. Enrique
Re: [kerberos client]Problem to obtain TGT from KDC.
On 10/25/07, Leo Li <[EMAIL PROTECTED]> wrote:
> ...
> Besides, the successful kinit has such log for REQ:
> AS_REQ (7 etypes {18 17 16 23 1 3 2}). It has the "7" type
> for REQ than "1" type. Does it make some difference?
> Can somebody help?
Hi, Leo,
I need to fire up MIT Kerberos to try to reproduce this. The ApacheDS
Kerberos client component has only been tested against ApacheDS
itself, so it's entirely possible we have an interop problem. Our
client is pre-alpha. Let me get back to you.
Enrique
Re: [Kerberos] Ticket structure
On 10/26/07, Emmanuel Lecharny <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I'm currently reviewing the Ticket structure, and I'm wondering why we
> do store the encrypted data _and_ the encrypted ticket part,
> considering that the first structure is a sealed version of the second
> one ? I understand that it is an optimization as we will manipulate a
> lot the data from the second structure, but why can't we simply extend
> the Ticket class to add a new field (this encTicketpart) in the
> inherited part?
I think of the Ticket as existing in 2 states: sealed and unsealed.
Therefore, it makes sense to have one Ticket but have it handle the 2
states better, such as returning an IllegalStateException instead of
the current NPE if an attempt is made to access the EncTicketPart
without decrypting it first.
>
> Something like :
>
> Ticket
> {
> int versionNumber;
> KerberosPrincipal serverPrincipal;
> EncryptedData encPart;
> }
>
> and
>
> TicketWithTicketPart extends Ticket
> {
> EncTicketpart encTicketPart;
> }
>
> I don't know... wdyt ?
>
This might work. I can see how the API would return the 2nd form
after a decrypt. Though, it might be better named as "Ticket" and
"DecryptedTicket." With both the names your are suggesting here and
the other renames you have made I believe you are coming at an
understanding of Kerberos from the ASN.1 structures, when the
higher-level (and less literal) naming will be better with the
protocol workflow in mind.
Enrique
Re: Apache DS latest code from the trunks 1.5.1x
On 10/25/07, Abdullah Zahur <[EMAIL PROTECTED]> wrote: > Thanks for the help. Yes that was the problem and I will use the users list > to post questions too. Basically what I am tring to do is modify ApacheDS, > in such a way that it uses some other directory... other than the datastore > of apacheDs to lookup users and their information. > Can you give me some pointers. > I was thinking that would it be easier, if I use referrals, to look up users > then I might not have to modfiy anything in apacheDs what are you thoughts There is an interface called PrincipalStore that you could easily implement with an alternate backend. We re-implement it with a HashMap to do full-protocol tests without having to fire-up the ApacheDS backend. As for referrals, I haven't tried this and I'm not sure what the current state of ApacheDS is w.r.t. referral support. I doubt the current PrincipalStore implementation we use would know what to do if it finds a referral instead of the expected Kerberos principal. BTW, prior to ApacheDS 1.5.1 the LDIF loader was "Kerberos aware," which is why your old way of loading principals no longer worked. The drawback to that mechanism was you could only load principals via LDIF. Now LDIF loads, LDAP changes, and the Change Password protocol all use the interceptor. Enrique
Re: KeyTab and EncryptionKey
On 10/24/07, Emmanuel Lecharny <[EMAIL PROTECTED]> wrote: > Hi, > > while looking into the kerberos code, I found a KeyTab class, which is > used to read a KeyTab file. I have some questions related to this > class : Module 'kerberos-shared' in the trunk has a keytab package. That package has as its entry point the Keytab class. It sounds a bit like you are talking about something older, IIRC, possibly in another module. If you find keytab code, apart from the keytab package in 'kerberos-shared', you can delete it. > - do we have any tests which shows that this class works ? Yes, the aforementioned package is covered by the KeytabTest class which uses package-scoped methods to test the reading and writing of keytab bytes, avoiding the need for test files on disk. Moreover, I have used this in interop scenarios. > - do we have a Keytab generator? The Keytab class can both read and write to a File. > - do we use this class - or intend to use it - into the kerberos server ? I don't believe the server currently uses this class. I originally intended this component to be used in conjunction with the LDAP protocol to import/export Kerberos keys to/from a keytab file. However, a "version 2" update to the Change Password protocol is working its way through the IETF and I believe this will be the better solution. I wouldn't delete it since it is useful for interop. > - The EncryptionKey class contains a kvno which is not present in the > ASN.1 definition of this structure : do we need this field ? kvno needs to be somewhere. We may not be strict about the kvno in use and IMO most implementations aren't strict but they do check the kvno to give the user the hint that they may not be using the correct kvno w.r.t. the error returned to the user. I would review in light of your refactoring to a strict interpretation of the ASN.1 structures. Enrique
Re: [kerberos client]Problem to obtain TGT from KDC.
Hi, Leo,
This looks like an MIT Kerberos configuration issue. The MIT KDC is
responding that it is not configured to use encryption type 3
(DES-CBC-MD5). The client is simply reporting the error returned by
the KDC. I recommend reviewing MIT Kerberos server documentation.
Alternatively, you can use the "long form" of the ApacheDS Kerberos
client component to try to use an enc type that is supported by
default by MIT Kerberos KDC.
Enrique
On 10/23/07, Leo Li <[EMAIL PROTECTED]> wrote:
> Hi, all
>
>I am trying to connect to KDC to get a TGT by:
>String hostname = "wks107904wss.cn.ibm.com";
>int port = 88;
>KdcConnection con = new KdcConnection( hostname + ":" + port );
>KerberosTicket tgt = con.getTicketGrantingTicket( clientPrincipal,
> password );
>
>But it fails with such stacktrace:
>Exception in thread "main"
> org.apache.directory.client.kerberos.KdcConnectionException:
> BAD_ENCRYPTION_TYPE
> at
> org.apache.directory.client.kerberos.GetTicketGrantingTicket.processError(GetTicketGrantingTicket.java:167)
> at
> org.apache.directory.client.kerberos.GetTicketGrantingTicket.execute(GetTicketGrantingTicket.java:153)
> at
> org.apache.directory.client.kerberos.KdcConnection.getTicketGrantingTicket(KdcConnection.java:118)
> at
> org.apache.directory.client.kerberos.KdcConnection.getTicketGrantingTicket(KdcConnection.java:101)
> at org.apache.directory.client.kerberos.Main.go(Main.java:62)
> at org.apache.directory.client.kerberos.Main.main(Main.java:55)
>
>
> And on the kdc side, the server has such log:
> Oct 23 16:12:28 wks107904wss.cn.ibm.com krb5kdc[2304](info) :
> AS_REQ(1 etypes{3}) 9.181.106.61:BAD_ENCRYPTION_TYPE:[EMAIL PROTECTED]
> for krbtgt/[EMAIL PROTECTED], KDC has no support for encryption
> type
>
> The KDC is provided by redhat enterprise 5 with default setup configuration.
>
> And if I try the same program in the machine where KDC resides and
> run it with "localhost" as host parameter, it will get null TGT and
> from the KDC log there seems no further log as if no Kerberos Request
> had been sent to KDC.
>
> Can somebody help?
>
> Thanks,
>
> --
> Leo Li
> China Software Development Lab, IBM
>
Re: Apache DS latest code from the trunks 1.5.1x
On 10/20/07, Abdullah Zahur <[EMAIL PROTECTED]> wrote: > Hi all. > I have been trying to set the Apache DS with Kerberos enabled. I am using > the original server.xml that comes with apacheds code with out any changes > and am using the Kerberos-example.ldif that also comes with the code > without modifications. > ... It sounds like you need to un-comment the XML stanza that enables the KeyDerivationService in the server.xml. This service (interceptor) intercepts writes of the user password to automatically derive the keys required for Kerberos operation. With the interceptor enabled, you can either re-write the passwords using the LDAP protocol or you can delete your database and reload the principals via LDIF import. BTW, we have a users@ mailing list for user questions. Enrique
Re: [ApacheDS] [Kerberos] Where are the full integration tests for Kerberos backed by the DIT
On 10/11/07, Alex Karasulu <[EMAIL PROTECTED]> wrote: > > Do you have any integration tests for Kerberos where it's backed by the DIT? > As I refactor I wanted > to make sure I don't break the store integration in the Kerberos server. The short answer is no. The longer answer is that we discussed this and the problem is that we only have the JAAS Kerberos client available for full ITests tests and, since it is fixed to use port 88 (requires external config to override), we can't use it for tests since that requires a root bind. So, I launched into the Kerberos client component initiative. That is pretty well along, and it is great for ITests, but it is not stable enough to use, just yet, in the trunk. If you really want to test, you can use the SaslGssapiITest in server-unit. This is commented out for the aforementioned root bind issue with the Kerberos LoginModule. Also, of course, it is testing LDAP GSSAPI but it does first use Kerberos, so you could use it in a pinch. Enrique
Re: [ApacheDS] Configuration of protocols
On 10/9/07, Alex Karasulu <[EMAIL PROTECTED]> wrote: > On 10/9/07, David Jencks <[EMAIL PROTECTED]> wrote: > > NTP is pretty darn simple and I'm going to code up a couple of > > examples using it so we can better see what we are talking about. > > NTP is simple and one of the reasons why I picked it for the example. Also > as you > say it can be used for a simple experiment to see the impact of what we want > to do > without a massive investment in time. On 10/9/07, Alex Karasulu <[EMAIL PROTECTED]> wrote: > On 10/9/07, David Jencks <[EMAIL PROTECTED]> wrote: > > NTP is pretty darn simple and I'm going to code up a couple of > > examples using it so we can better see what we are talking about. > > NTP is simple and one of the reasons why I picked it for the example. Also > as you > say it can be used for a simple experiment to see the impact of what we want > to do > without a massive investment in time. I agree that the issue isn't just NTP, but coming up with a way to do this so that grokking all the protocols is easier. UDP vs.TCP is more of an issue with DNS and Kerberos (including Change Password). For some history, these protocols were written with OSGi's Configuration Admin in mind, with config in the DIT. This worked with the old Oscar/Maven 1 build. A Config Admin ManagedServiceFactory could produce listeners between any IP endpoint and any subtree in the DIT (for DNS records or Kerberos principals), a bit like Jetty allows you to have multiple listeners. Whether it is UDP vs. TCP is handled in the MINA codec factory, which can switch based on UDP vs. TCP. Incidentally, this is why the XxxServer classes have lifecycle, like destroy# and isDifferent#, because it was meant to handle dynamic config changes propagating out of the DIT. To Emm's question, the main consideration of UDP vs. TCP is whether the size of the message is pre-pended to the message when using TCP. DNS has a truncation bit to set but I can't recall any of the protocols having any other different processing with UDP vs. TCP. IMO, it's just simpler to have one configuration and whether its UDP or TCP depends on what you connect it to with MINA and the codec factory handles the pre-pended size. Of course, with the fixed nature of the config XML, there may be little difference between two configs or one with a property to switch UDP vs. TCP. I'm glad David committed something since it may makes things clearer w.r.t. how to proceed. Also, I was happy to read, after seeing the commits, that "DirectoryService" and "ApacheDS" deps were to come out of the protocols. There shouldn't be any reason these protocols couldn't run on alternate backends. I see this as mostly good programming practice but it also could aid in attracting committers, if there were more ways to use these protocols then only with ApacheDS. No one should be prevented from, say, backing them with OpenDS, again because its good decoupling, but also since it would be better overall for attracting committers/users. Not to mention that it's nice to be able to test against an in-memory HashMap-based store, since you can test the entire protocol workflow much faster than even with FastXxxITest. Also, Kerberos was originally written backed by JNDI to OpenLDAP and, who knows, that could be a config someone is interested in. HTH, Enrique
Re: What about Kerberos becoming a separate project ?
On 10/9/07, Emmanuel Lecharny <[EMAIL PROTECTED]> wrote: > I would add something to what Alex just said : we didn't anted to make > Kerberos a separate Apache project, but a separate sub-project, from > Maven point of view. This was just about an internal refactoring. > > Kerberos and Apache Directory Project are tighly coupled right now, > and will remain coupled for a while. They are only coupled from a build point-of-view. The entire directory store is behind an interface. For example, for tests there is a HashMap-based store implementation. Enrique
Re: What about Kerberos becoming a separate project ?
On 10/9/07, Emmanuel Lecharny <[EMAIL PROTECTED]> wrote: > I would add something to what Alex just said : we didn't anted to make > Kerberos a separate Apache project, but a separate sub-project, from > Maven point of view. This was just about an internal refactoring. > > Kerberos and Apache Directory Project are tighly coupled right now, > and will remain coupled for a while. They are only coupled from a build point-of-view. The entire directory store is behind an interface. For example, for tests there is a HashMap-based store implementation. A separate sub-project could help attract committers. A common complaint I hear from people is that apacheds sub-sub-projects pull in the dependencies and build overhead of the whole apacheds server. Enrique
Re: [ApacheDS] Things to consider for big bang refactoring
On 10/4/07, Alex Karasulu <[EMAIL PROTECTED]> wrote: > Excellent thanks. > > Alex I was waiting somewhere so I updated the Confluence doc with some notes I had already done and the contents of this thread, for you to look at whenever. http://cwiki.apache.org/confluence/display/DIRxSBOX/Draft+-+CatalogService+Interceptor Enrique > On 10/4/07, Enrique Rodriguez <[EMAIL PROTECTED]> wrote: > > On 10/1/07, Alex Karasulu <[EMAIL PROTECTED]> wrote: > > > ... I'd like to > > > talk about this > > > on this or another thread but I'm presently preoccupied with work, > bigbang > > > branch and other > > > things. I'll try to get back to you on this right after the JNDI > cleanup. > > > > np. In the meantime I went ahead and checked-in a proof-of-concept to > > my sandbox on r581763: > > > http://svn.apache.org/viewvc/directory/sandbox/erodriguez/core-catalog/ > > > > We can use it to continue the discussion when you're ready. You may > > want to look at the TestCase to get an idea of typical regex's used > > for Kerberos principal to LDAP URL mappings. > > > > Enrique
[jira] Closed: (DIRSERVER-145) Make NTP configurable
[ https://issues.apache.org/jira/browse/DIRSERVER-145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Enrique Rodriguez closed DIRSERVER-145. --- Issue was resolved some time ago, merged, and has been shipping since 1.5.1. > Make NTP configurable > - > > Key: DIRSERVER-145 > URL: https://issues.apache.org/jira/browse/DIRSERVER-145 > Project: Directory ApacheDS > Issue Type: New Feature > Components: kerberos > Reporter: Enrique Rodriguez > Assignee: Enrique Rodriguez > Fix For: 1.5.1 > > > The NTP protocol provider is not configurable. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Issues with tests
On 10/5/07, Alex Karasulu <[EMAIL PROTECTED]> wrote: > There were a slew of copy and paste problems that I had to fix all the tests > created recently: > ... Thanks for doing this. The clean-up has been much needed. > ... > Furthermore they don't seem to follow the pattern of using the > AbstractTestCase and AbstractServerTestCase > classes. It would help a lot if you tried to use these instead of > duplicating the setUp() code. Eventually > switching to the FastXXXITest that Emmanuel setup should be the best. > ... IIRC, the base classes you mention cannot currently be reused for the non-LDAP protocol providers. The setUp() method in question does not allow modification to the configuration prior to the startup of the server. Once the server is started up, there is no way to dynamically reconfigure. Thus the "cut & paste" code you see is simply the minimum boilerplate for starting a server instance when custom config is required. The non-LDAP protocol providers must make changes to the: 1) enabled protocols (all PP besides LDAP are disabled by default) 2) enabled schema (eg Kerberos) 3) enabled interceptors (eg key derivation interceptor) 4) advanced tests (multi-realm) may require additional partitions. In short, the test base classes are highly LDAP-centric. This includes the SASL GSSAPI test, which uses Kerberos. Perhaps as the tests are migrated to the FastXXXITest test we can figure out to allow subclasses to make these changes in a clean manner. Could be as simple as some template methods called by the setUp() method. Enrique
Method signatures in JUnit4 primer
Hi, Directory developers, I tried out Emm's JUnit4 primer. It looks like the per-class methods need to be static. If others verify this, I can update the primer. Correct method signatures: @BeforeClass public static void globalSetUp() @AfterClass public static void globalTearDown() This is in the "giant leap for testers" section. Primer: http://cwiki.apache.org/confluence/display/DIRxDEV/JUnit4+primer Enrique
Re: [ApacheDS] Things to consider for big bang refactoring
On 10/1/07, Alex Karasulu <[EMAIL PROTECTED]> wrote: > ... I'd like to > talk about this > on this or another thread but I'm presently preoccupied with work, bigbang > branch and other > things. I'll try to get back to you on this right after the JNDI cleanup. np. In the meantime I went ahead and checked-in a proof-of-concept to my sandbox on r581763: http://svn.apache.org/viewvc/directory/sandbox/erodriguez/core-catalog/ We can use it to continue the discussion when you're ready. You may want to look at the TestCase to get an idea of typical regex's used for Kerberos principal to LDAP URL mappings. Enrique
[Kerberos] apacheds-kerberos branch, prototypical ASN.1 codec
Hi, Directory developers, I checked out Emm's branch and I'd like to start getting my head around the new ASN.1 codec style. I was wondering if you (Emm) could recommend a good message object to start with, one you think best exemplifies the new codecs you are writing. Thanks, Enrique
Re: [ApacheDS] Things to consider for big bang refactoring
On 10/1/07, Emmanuel Lecharny <[EMAIL PROTECTED]> wrote: > ... > I suggest that we feed the Roadmap with any other issues. We can then > trigger the roadmap to make it reasonable given the timeframe and > workforce we have. Biggest problem I can think of for possible short-term inclusion is that in a number of places, we limit principal lookup to a single "search base DN." We have the single vs. multi-base search mechanism for Kerberos and Change Password, and this could work for SASL GSSAPI, but it definitely doesn't handle the other SASL mechanisms (they don't use Kerberos principals). Also, the Kerberos and Change Password single vs. multi-base search mechanism is insufficiently flexible. Other directory servers, like AD and OpenLDAP, allow principals to occur in any container, even if they are in the same realm. OpenLDAP uses regex's to allow this. In the real world, eg Quanah/Stanford, you want to segregate principals that are in the same realm but that are different principal types (such as users vs. services). You can do this with regex's that segregate principals with "host/" in their names vs. users, just as a simple example. This issue comes up periodically as a 2nd-order problem, ie multi-realm support for Kerberos, CP, and SASL GSSAPI and, looking now, quite possibly this is the issue behind DIRSERVER-1068. A good, cross-ApacheDS solution would fix a number of usability issues and clean-up the legacy mess of single vs. multi-base search. As an interceptor, it could be seriously elegant and powerful. Alex asked me back in July to come up with a proposal. The best solution, IMO, would be a component that used regex's to map between an entity, like a Kerberos principal or SASL realm/user, and a DN, either the DN of the desired entity or a base DN for a subsequent search. Of course, this is exactly what OpenLDAP does and I can't think of anything better. We could either re-use this proposed component in LDAP, Kerberos, and Change Password or we could install it as an interceptor. As an interceptor, we could have a system container, perhaps "ou=catalog,ou=system," under which there were regex's. Our internal JNDI clients could execute lookups for "([EMAIL PROTECTED])" against "virtual base DN" "ou=kerberos,ou=catalog,ou=system." That node would be populated with regex's from config XML (or LDIF) that would be processed and result either in (a) the "real base DN" to perform the search at or (b) as an interceptor, simply redirect the query in the interceptor service chain to the "real base DN." This is possible because the OperationContext's passing through the interceptor service chain are mutable and this would optimize the redirect since the query wouldn't need to be executed twice. In other words, to a JNDI client, a query against one search base results in an answer in a totally different search base. If any of this makes sense, I could code up a prototype and commit to my sandbox. Also, I did at one point, start a draft doc in the cwiki sandbox. Enrique
Re: Is org.apache.directory.server.kerberos.shared.store.MultiBaseSearch thread safe?
On 9/30/07, David Jencks <[EMAIL PROTECTED]> wrote: > ... > Unless something is going on to synchronize access to this class > elsewhere 2 threads are going to be installing different > PROVIDER_URLS at the same time... > ... I agree this is problematic and that your recommended fix makes sense. Glad to hear you're taking a look at the protocols. Enrique
Re: [ApacheDS] Mini-roadmap for protocol work
On 9/30/07, Stefan Zoerner <[EMAIL PROTECTED]> wrote:
> Emmanuel Lecharny wrote:
>
> > for ( project in {DNS, NTP, DHCP, ChangePW, Kerberos} do
> > 1) Add some doco on confluence
> > 2) Clean the chain
> > 3) Add some tests
> > done
OK, I'll get going with DNS. I was in the middle of Kerberos tests so
I'll wrap-up some pre-auth tests then get on with DNS.
One note for Kerberos and Changepw: we'll need to have our own client
libraries. These are mostly done, I would say in an alpha quality.
NTP and DNS have client libraries we can use for tests. So, after
DNS, we should revisit our client-side support for Kerberos and
Changepw.
Enrique
Re: NTP integraion test added (was Re: [ApacheDS] Mini-roadmap for protocol work)
On 9/30/07, Stefan Zoerner <[EMAIL PROTECTED]> wrote: > Emmanuel Lecharny wrote: > >> * Should I create the tests in Big Bang or the 1.5 trunk? > > > > Add them in trunk, because we need them in trunk, but as we will merge > > them with bigbang and the way out, at the end of the day, it makes no > > difference... > > Thanks Emmanuel! > > I have added a simple integration test for the NTP server here > http://svn.apache.org/viewvc?view=rev&revision=580746 This is a really nice test. In particular, it fills a gap between unit tests and the integration tests in server-unit, providing full server tests, including codecs. The tests I added for Kerberos tested at the IoHandler level and thus did not test the codecs. I will start to use something more like what Stefan worked out for the other protocols. One issue, because this came up earlier this summer, is that when you get the loopback address, the best practice is to use 'null' as the hostname. 'null' will explicitly return the loopback address and avoid any issues with misconfigured hosts files that could cause the tests to fail. I've tested this on Sun and IBM and it should work given a read of Harmony source. >From the javadocs: "If the host is null then an InetAddress representing an address of the loopback interface is returned. " Enrique
[jira] Created: (DIRSERVER-1076) Add support for the Kerberos PKINIT pre-authentication type
Add support for the Kerberos PKINIT pre-authentication type --- Key: DIRSERVER-1076 URL: https://issues.apache.org/jira/browse/DIRSERVER-1076 Project: Directory ApacheDS Issue Type: New Feature Components: kerberos Affects Versions: 1.5.0 Reporter: Enrique Rodriguez Assignee: Enrique Rodriguez Priority: Minor Fix For: 1.5.2 Add support for the Kerberos PKINIT pre-authentication type. PKINIT allows users to replace usernames/passwords with PKI credentials, typically using hardware devices, eg smart cards. Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) http://www.ietf.org/rfc/rfc4556.txt -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [ApacheDS] Mini-roadmap for protocol work
On 9/29/07, Alex Karasulu <[EMAIL PROTECTED]> wrote: > On 9/29/07, Enrique Rodriguez <[EMAIL PROTECTED]> wrote: > > (CES 2008). > > What's CES stand for? I'm just ignorant. Consumer Electronics Show Enrique
Re: [ApacheDS] Mini-roadmap for protocol work
On 9/29/07, Emmanuel Lecharny <[EMAIL PROTECTED]> wrote:
> ...
> May I suggest that you just do it in a slightly different order ?
Unfortunately you not only changed the order but you introduced
substantial scope creep. While all the changes you suggest are valid,
I have to package them such that I can actually complete them in OCT.
> for ( project in {DNS, NTP, DHCP, ChangePW, Kerberos} do
I specifically left out NTP and DHCP, mostly due to time limitations,
though secondarily since they don't have IoHandlerChain's and because
they seem to be lower priority given the queries we get. Certainly
they are valid concerns, though.
> 1) Add some doco on confluence
Everyone of these protocols (except DHCP, IIRC) has docs in the AUG.
Any thoughts on what else you'd like to see?
> 2) Clean the chain
Removing the chains is an orthogonal concern. By this, I mean I can
remove all the chains at once, since it is a similar operation,
independent of protocol behavior. I can probably remove the SASL one,
but I left it out since it is more in the midst of "bigbang" changes.
> 3) Add some tests
> done
> ...
> The idea is to clean the simplest protocols first, and to get me into
> the last loop when starting with Kerberos. I have still a hell loyt of
> work to do on the kerberos branch, and I really want to do it with
> you.
OK. I am shooting for next month. Something to consider is that if
you want to better support users, digging into the code may not be the
most effective use of time. Most user questions will be at a higher
level, pertaining to configuration of the provider and how to
integrate Kerberos with Linux, Windows, and various services. I'm
looking forward to the ASN.1 boost, but, to be perfectly honest, its
not going to be as valuable to users as getting interop scenarios
working.
> - you can add your mini-roadmap into the main roadmap
> (http://cwiki.apache.org/confluence/display/DIRxPMGT/2.0+Roadmap), so
> that everyone will have a clear visibility about your progression
> (it's a matter of when we will be able to release : as you can see, we
> are now 11 working on the project, and we must be much more 'serious')
Will do, once I get some sense as to whether it's "approved."
> - We will also clean the chain into SASL, because we have clear
> problems with it (not sure it's already in the roadmap, but we will
> add it).
Valid concern but scope creep.
> Btw, if you have to work on a new external project, it would be cool
> to tell us so we can define a deadline for some of you assigned tasks,
> to be able to define the 2.0 release content.
I'd like to wrap-up any work up by the end of October. I have a new
deadline of early JAN (CES 2008). I don't exactly have downtime right
now; I am simply taking away from any room for error I have later in
the year.
Enrique
Re: [ApacheDS] Mini-roadmap for protocol work
On 9/29/07, Alex Karasulu <[EMAIL PROTECTED]> wrote: > What are your motives for these changes? My motivation is that I still believe in the idea of a combined "realm controller" and, since a number of issues have been raised over the last couple months, each of which I agree with, I would like to address them in an effort to make the protocols easier for people to work with. > What are the benefits? The benefit of test cases is that it should make it easier for people to get into working with the protocols. It also makes it easier for changes to not cause regression. The benefit to removing the chains, as succinctly noted previously by you and Emm, is that reading the code and using a debugger is improved. The benefit of making the pre-auth verifiers pluggable is flexibility. We can currently only add one verifier at the class-loading point, and Kerberos (the specs) supports numerous pre-auth types. Enrique > On 9/29/07, Enrique Rodriguez < [EMAIL PROTECTED]> wrote: > > Hi, Directory developers, > > > > I'd like to continue addressing some "unfinished business" with the > > various protocols. This is in an effort to address some issues raised > > in the past (and recently). So, I put together a "mini-roadmap," > > below, of items I think I can get to in OCT. Much of this is internal > > refactoring, with only 1-2 touchpoints that we'll need to coordinate. > > > > The changes fall into roughly three categories: chains, tests, and > > Kerberos pre-authentication. > > > > 1) Regarding chains, I would like to remove the use of the > > IoHandlerChain's in DNS, Change Password, and Kerberos, in that order. > > DNS and Change Password should go easily. Kerberos will go easily > > too, with the only consideration being any conflict with changes Emm > > has made and needs to merge in his Kerberos branch. > > > > 2) Regarding tests, I've added a ton for Kerberos but I haven't gone > > and done the similar effort for DNS and Change Password. Also, > > pre-auth coverage for Kerberos isn't very good. Adding tests won't > > effect anybody's work, but I wanted to mention this because the tests > > will go hand-in-hand with removing the chains in #1. Furthermore, I > > expect the tests for Kerberos pre-auth to occur (TDD) while I'm > > revamping pre-auth in #3. > > > > 3) Regarding Kerberos pre-auth, I see this combining (a) tests with > > (b) the removal of the pre-auth, AS, and TGS IoHandlerChain's, (c) the > > refactoring of the class loader mechanism with a Spring configuration > > mechanism a la David's recent work, and (d) the addition of PKINIT as > > a new pre-auth mechanism. Of course, PKINIT work will continue in my > > sandbox, but it makes sense to me to work on pre-auth all at once so > > I'll have my head around it all. The only "end user" consideration > > here is that pre-auth configuration will be exposed, but since we can > > ship defaults that are unchanged from how it currently works no one > > should notice. > > > > I don't think any of this affects the current plans around the > > "bigbang" effort, but please give your thoughts on the above and I can > > get going with it pretty much immediately. > > > > Enrique > > > >
Testing issue, need pointers
Hi, Directory developers, I'm looking for pointers for an issue I recall coming up before, namely that reusable test classes that are in "src/test/java" don't get packaged into artifact jars, so they can't be reused by other Maven2 modules. When I asked before someone (David?) had a best practice here and I don't recall enough to find the answer or thread. There are base classes in server-unit and in local work I have for Kerberos that are only used by tests but that would be nice to reuse. Of course, the simple solution is to move these classes to "src/main/java," but that was shutdown before in favor of this other solution I'm alluding to. TIA, Enrique
[ApacheDS] Mini-roadmap for protocol work
Hi, Directory developers, I'd like to continue addressing some "unfinished business" with the various protocols. This is in an effort to address some issues raised in the past (and recently). So, I put together a "mini-roadmap," below, of items I think I can get to in OCT. Much of this is internal refactoring, with only 1-2 touchpoints that we'll need to coordinate. The changes fall into roughly three categories: chains, tests, and Kerberos pre-authentication. 1) Regarding chains, I would like to remove the use of the IoHandlerChain's in DNS, Change Password, and Kerberos, in that order. DNS and Change Password should go easily. Kerberos will go easily too, with the only consideration being any conflict with changes Emm has made and needs to merge in his Kerberos branch. 2) Regarding tests, I've added a ton for Kerberos but I haven't gone and done the similar effort for DNS and Change Password. Also, pre-auth coverage for Kerberos isn't very good. Adding tests won't effect anybody's work, but I wanted to mention this because the tests will go hand-in-hand with removing the chains in #1. Furthermore, I expect the tests for Kerberos pre-auth to occur (TDD) while I'm revamping pre-auth in #3. 3) Regarding Kerberos pre-auth, I see this combining (a) tests with (b) the removal of the pre-auth, AS, and TGS IoHandlerChain's, (c) the refactoring of the class loader mechanism with a Spring configuration mechanism a la David's recent work, and (d) the addition of PKINIT as a new pre-auth mechanism. Of course, PKINIT work will continue in my sandbox, but it makes sense to me to work on pre-auth all at once so I'll have my head around it all. The only "end user" consideration here is that pre-auth configuration will be exposed, but since we can ship defaults that are unchanged from how it currently works no one should notice. I don't think any of this affects the current plans around the "bigbang" effort, but please give your thoughts on the above and I can get going with it pretty much immediately. Enrique
Re: [Kerberos] PKINIT support
On 9/24/07, Emmanuel Lecharny <[EMAIL PROTECTED]> wrote: > ... > Feel free to have a look at it, it's far from being perfect nor > finished. It's just a work in progress I wanted to share. Would you > have any question or suggestion about it, please do so. I will be > please to answer. I looked it over. The first thing is a nitpick of the change you made from "cipher text" to "cipher." A cipher is an algorithm, while cipher text is the output. Why the ASN.1 for EncryptedData calls this "cipher" I don't know, but they clarify in the ASN.1 notes (RFC 4120 5.2.9) that this field contains "ciphertext." Enrique
Re: [ApacheDS] StartTLS Control
On 9/21/07, Enrique Rodriguez <[EMAIL PROTECTED]> wrote: > I will review StartTLS again this weekend and come back with a > timeframe. I could get it in, in the next week or so. > ... I took a look at StartTLS. I won't be able to get to it until later this year. I will instead focus on some of the protocols that people are more concerned I shore up, such as DNS and Kerberos. Enrique > Enrique > > > On 9/19/07, Alex Karasulu <[EMAIL PROTECTED]> wrote: > > Hi once again, > > > > We have some StartTLS Control code already written here: > > > > > > https://svn.safehaus.org/repos/apacheds/shds-extension-starttls/trunk/ > > > > I have signed and committed the scanned grant documents for this minor grant > > and placed them > > here in the PMC private repository. > > > > > > https://svn.apache.org/repos/private/pmc/directory/grants/start_tls.tgz > > > > Anyone interested in migrating this code over to the ASF repository and > > applying it to the server > > so we can release 1.5.2 with the additional StartTLS control? > > > > Anyone? > > > > Alex > > >
Re: [Kerberos] PKINIT support
On 9/22/07, Alex Karasulu <[EMAIL PROTECTED]> wrote: > IMO if you have some time you might want to start work on some developer > documentation > on DNS as well as a user's guide so we can attract more committers while > answering user > questions around DNS. > ... Point taken. I will prioritize this higher than new features, such as PKINIT or StartTLS. > ... > Secondly with respect to technical matters how does this impact what we have > in Triplesec > with HOTP? Is this another SAM type for the kerberos server which uses the > class loading > scheme we already have in place for verifiers? My plan is to make pre-auth verifiers "pluggable" in the same way that core Authenticators can be configured via Spring XML. I am committed to supporting Triplesec such that the HOTP verifier works after this configuration change. Though, since last I checked, Triplesec builds against a 1.0, this is moot until Triplesec moves to the next stable branch. The class loading scheme only allows one plug-in. This configuration/plugin change is separate from PKINIT, which would use this "plugin point" just like HOTP will. PKINIT is not another SAM type. PKINIT has its own base RFC with its own pre-auth type. Enrique
Re: [Kerberos] PKINIT support
On 9/23/07, Emmanuel Lecharny <[EMAIL PROTECTED]> wrote: > ... > Sandbox can be used to push this kind of new code, I see no problem. > When it reaches a level of tests which allow any other committer to > anter into it, and do some modification without breaking the tests, > then it can be added to the project. > After clarifying this point with Emm via IM, I understand I can make PKINIT commits to a new module in my personal sandbox and that, at such time as the team is comfortable with the level of tests and doco, that a further decision can be made to move it to the trunk. Enrique
[Kerberos] PKINIT support
Hi, Directory developers, I have a window with no major deadlines for the next few weeks, so I looked into adding 1 new Kerberos feature for the next release. After doing some "due diligence," ie reading the relevant specs and reviewing what support I need from the JDK and various libraries, I am highly confident I can add PKINIT support for 1.5.2. PKINIT is a pre-authentication type for Kerberos (detailed in RFC 4556). For those not familiar, PKINIT can be quickly summarized as "smartcard authentication for Kerberos, replacing the username/password." PKINIT can also work with a local keypair, so there isn't a requirement for hardware like an actual smartcard, though that is the intended deployment scenario. Since this is only a new pre-authentication verifier, I would rather not branch and instead develop this, at first, in my sandbox. I have time starting this weekend, so I'd like to start to get code committed, to back the code up. Enrique
Re: What about Kerberos becoming a separate project ?
I've always wanted to see all the non-LDAP/directory code move to Triplesec. The name "Apache Directory" would make more sense and it would clear things up for people who just want a directory/LDAP/embedded JNDI provider. It would also put the Kerberos code together with the HOTP code already in Triplesec. Enrique
Re: [ApacheDS] StartTLS Control
I will review StartTLS again this weekend and come back with a timeframe. I could get it in, in the next week or so. Enrique On 9/19/07, Alex Karasulu <[EMAIL PROTECTED]> wrote: > Hi once again, > > We have some StartTLS Control code already written here: > > > https://svn.safehaus.org/repos/apacheds/shds-extension-starttls/trunk/ > > I have signed and committed the scanned grant documents for this minor grant > and placed them > here in the PMC private repository. > > > https://svn.apache.org/repos/private/pmc/directory/grants/start_tls.tgz > > Anyone interested in migrating this code over to the ASF repository and > applying it to the server > so we can release 1.5.2 with the additional StartTLS control? > > Anyone? > > Alex >
Re: [OT] Is there a Java client to interact with directory server?
On 8/29/07, Leo Li <[EMAIL PROTECTED]> wrote: > ... > Does apache Directory project has an implementation for kerberos client? > Although there might exist some gap from the code to the JGSS provider > harmony needs, it is nice to avoid re-inventing wheels.:) Good idea and we are also quite active with the Kerberos code so we will be available to add missing features, fix bugs, and hone the client-side API to meet your needs. Enrique
Re: [OT]Where is the source code for kerberos client?
On 8/30/07, Leo Li <[EMAIL PROTECTED]> wrote: > ... > So does directory project has such an java implementation of kerberos > client? If so, it can save us from rewriting such feature and wrap it as a > JGSS provider. Hi, Leo, The links from Emmanuel are the shared (kerberos-shared) and server-side (protocol-kerberos) components for Kerberos that are in the Directory trunk. What you are looking for is the kerberos client (not in the trunk, but which uses kerberos-shared) at: http://svn.apache.org/repos/asf/directory/clients/trunk/kerberos/ There is draft doco at: http://cwiki.apache.org/confluence/display/DIRxSBOX/Draft+-+Kerberos+client+components Please note this is a client-side *component* for Kerberos, meaning it is not a CLI or GUI client. But, that is likely what you want for JGSS, anyway. We use this for integration tests for the Kerberos server running in ApacheDS, in JUnit tests. We need to complete support for client-side handling during pre-authentication, but most everything works. I am planning to re-engage pre-authentication when our current trunk code freeze is over so we should have this client pretty well cleaned up in the next month or so. Enrique
Re: [OSGi] Sandboxing ?
On 8/28/07, Emmanuel Lecharny <[EMAIL PROTECTED]> wrote: > Hi guys, > > while watching at the 'rat' output pam just sent me, I see that there > are a bunch of OSGi subprojects we are not using at all. > > Question : should we sandbox them ? This makes sense. Also, I thought we voted or otherwise unanimously decided to sandbox DHCP, since it wasn't as "live" as the other protocols. Enrique
[jira] Commented: (DIRSERVER-869) Add Start TLS support
[ https://issues.apache.org/jira/browse/DIRSERVER-869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12521209 ] Enrique Rodriguez commented on DIRSERVER-869: - I no longer have my implementation of StartTLS. As the assignee, description, and comments from March in this issue mention, I was waiting for you to process grant paperwork. If you get around to processing a grant, there is still the Safehaus StartTLS implementation, still at the above URL, that could be moved over: Safehaus Start TLS implementation to grant is here: https://svn.safehaus.org/repos/apacheds/shds-extension-starttls > Add Start TLS support > - > > Key: DIRSERVER-869 > URL: https://issues.apache.org/jira/browse/DIRSERVER-869 > Project: Directory ApacheDS > Issue Type: New Feature > Components: ldap > Reporter: Enrique Rodriguez >Assignee: Alex Karasulu > Fix For: 1.5.1 > > > This is assigned to Alex to process the grant paperwork. The actual move and > integration can be handled during the SASL branch work. > JNDI Tutorial: The Start TLS Extension > http://java.sun.com/products/jndi/tutorial/ldap/ext/starttls.html > Lightweight Directory Access Protocol (v3): Extension for Transport Layer > Security > http://www.rfc-editor.org/rfc/rfc2830.txt -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [ApacheDS] If you have JIRA issues for 1.5.1 we need your help to release
On 8/17/07, Alex Karasulu <[EMAIL PROTECTED]> wrote: > ... > Emmanuel and I are spending time sifting through this stuff so you don't > have to but > a few minutes of your time could save us a lot of JIRA greif. So please > take a minute > to query the JIRA issues for 1.5.1 to see which ones have your names on them > as > either the reporter or the person assigned to fix them. See if you can give > us a hint > as to what remains. E and I already cleaned up a bunch of stuff so this > should not > take much time. > ... I know quite a few of these are mine (both Major and others). I'll have a chance this weekend (hopefully tomorrow (Saturday)) to go through them. Enrique
Re: [Kerberos] Flags rewrite
On 8/15/07, Emmanuel Lecharny <[EMAIL PROTECTED]> wrote: > Hi Enrique > ... Thanks for responding with detailed reasons. This will be great clean-up. You have obviously taken time to read up on Kerberos. I am looking forward to these changes. Enrique
Re: [ApacheDS] Build Failures: protocol-kerberos 3 tests fail
On 8/15/07, Alex Karasulu <[EMAIL PROTECTED]> wrote: > If a host's network name is not properly configured properly the following > tests fail > since they try to bind to the name of the host instead of localhost. Both Kerberos TGS tests (and the NTP integration test) were using InetAddress.getLocalHost(), which would fail if your host/IP wasn't properly configured. I updated this to use the better practice of InetAddress.getByName( null ). Enrique
Re: [ApacheDS] [NTP] Failing NTP test case
On 8/15/07, Alex Karasulu <[EMAIL PROTECTED]> wrote: > ... > Attached you'll find the surefire generated output file for the the failing > test. Looks like some timeout problem which can easily be fixed. Both Kerberos TGS tests and the NTP integration test were using InetAddress.getLocalHost(), which would fail if your host/IP wasn't properly configured. I updated this to use InetAddress.getByName( null ), which will more reliably return the loopback address. Could you 'svn up' and retest? I couldn't see any other reason for the timeout and it appeared to be the same issue for your host as the Kerberos TGS tests that failed. If it works for you I will re-enable the test. Enrique
Re: [Kerberos] Flags rewrite
On 8/14/07, Emmanuel Lecharny <[EMAIL PROTECTED]> wrote: > ... > - an interface KerberoFlags > - an abstract class AbstractKerberosFlags implementing the base > operations, and extending the asn1 BitString object > - 3 classes extending AbstractKerberosFlags, containing the > combinaison of flags (TicketFlags, KdcOptions and ApOptions) > - 3 enum containing the different individual flags (TicketFlag, > KdcOption and ApOption) > > It will ease a lot flags manipulation in the code, and be coherent > with our current ASN.1 codec. > > thoughts ? In general I like the clean-up, but we do have enumeration using the older Java-style int's and we do have these classes and they already extend the common base class Options. KerberosFlags is a new name from RFC 4120 (as opposed to RFC 1510) and I agree the rename is in order. Regarding easing flag manipulation, I haven't found flag setting to be a problem and I'm not sure how what you propose helps. So, what's the major benefit of this work? Is this part of the "make codecs 6x faster" and "remove BC deps" initiative? What happens with the concept of making Kerberos ASN.1 classes implement common codec interfaces, such as "Encodable" and "Decodable." I thought one of the ideas you were working to make uniform was that the classes would know how to encode themselves, which to me ment something like a getEncoded() method that returned a byte array containing the DER or wrote to a ByteBuffer. Also, if I found the right BitString you're talking about, extending BitString would expose a public API that has nothing to do with flags, such as isStreamed(). These classes really should be immutable, even though they aren't today. After decoding off the wire, they should be immutable. The client side needs to set flags during request building, though. Do you have examples yet of how you've updated Kerberos message objects to use the newer ASN.1 codecs? I thought you checked in a class or two, but I couldn't find them. Enrique
Re: Apache Directory T-Shirts for LDAPCon
On 8/12/07, Chris Custine <[EMAIL PROTECTED]> wrote: > ... From a > branding perspective, you do not want variations of the logo, so we need to > pick one style or the other and use it everywhere because layout and > location is part of the logo and these two options are technically > different. > ... Along the same lines, is the 'S' in TripleSec (vs. Triplesec) upper- or lower-case? Again this isn't "Chris' fault" but it is inconsistent across the website, the T-shirt has it lowercase, and then I noticed Emmanuel used "TripleSec" in his email. IMO, I think it should be capitalized. I hadn't really noticed, but the centered tree does look better. Enrique
Re: Apache Directory T-Shirts for LDAPCon
On 8/11/07, Chris Custine <[EMAIL PROTECTED]> wrote: > Hi Everyone, > I updated the shirts with some of the suggestions that were made so here are > the URL's if you want to take a look. > ... Looks great! Directory URL positioning came out great. Enrique
[TripleSec] [Kerberos] Making pre-auth verifiers pluggable
Hi, Directory developers, I'd like to make pre-auth verifiers "pluggable." We currently ship a fixed set of pre-auth verifiers in the Kerberos protocol and we have a static setter hack in place to allow TripleSec to set its HotpVerifier. I believe this predates how we currently do such configuration. I'd like to update this to follow the convention of how Authenticators are configured in the core, namely how the core AuthenticationService allows a developer or admin to register and unregister Authenticators, in code or by (today) Spring XML. I think this would be handy for writing integration tests and I think it would make it easier to maintain TripleSec. If this makes sense I'd like to update it this month and I'd keep an eye on things to make sure this doesn't break TripleSec. This would also allow me to begin dismantling the chains in protocol-kerberos, starting with the pre-authentication verifier chain. I currently have good test coverage of protocol-kerberos and I have a couple more tests specifically for pre-auth that I would commit before starting this work. Enrique
Re: Apache Directory T-Shirts for LDAPCon
On 8/6/07, Chris Custine <[EMAIL PROTECTED]> wrote: > ... > For the time being I decided to stick with a basic design with the ASF logo > and the Directory logo, but if you guys want to see more detail or something > specific we still have plenty of time to figure it out and have some printed > before LDAPCon. ... Very nice! My only comment for an improvement would be to adjust the URL to directly reference http://directory.apache.org (instead of the 'www'). Enrique
Re: [m2-snapshot-repo] Permissions need to be massaged to allow group read write access
On 7/25/07, David Jencks <[EMAIL PROTECTED]> wrote: we did a couple of experiments here and we think you need to: set umask 2 in .bashrc. For non-interactive remote shell access such as through scp this is the file executed, not .bash_profile in ~/.m2/settings.xml set 775 664 for each repository you are deploying to. We're not so sure about the 2nd point, but this works for me and we found that the source file permissions do have an effect on the target file permissions together with the umask, and these settings affect what maven presents as the source file permissions. The combination of both of these settings (.bashrc && settings.xml) worked for me. Nice! With just umask it didn't work. Enrique
Re: [BUILD] [FAILED] Build Apache Directory Server::CI Build #142 failed
On 7/26/07, Chris Custine <[EMAIL PROTECTED]> wrote: Sorry about the build server, these things are all fickle and require a certain amount of care and feeding. In this case the SVN checkout was getting truncated so it was never getting half the project, but it is all working now apparently. Something like this keeps happening every couple of weeks, but it is totally a coincidence that the last couple of times were from Enrique's checkins and they had nothing to do with it. I don't mind the failures as long as I can check the status. Now that I know to use the guest account, that should work fine. As far as seeing more detail, the problem is that this build server only has two named logins licensed to it... I have secured an Open Source license for unlimited users, but I need to re-install and upgrade the server. At that point I will get everyone logins and such. I also have another build server that I have an OS license for called Zutubi Pulse and I want to try that out soon too. All fairly low on the priority list though, so it may be a few weeks. Again, guest access is fine. I can't picture needing any personalized functionality. Enrique
Re: [BUILD] [FAILED] Build Apache Directory Server::CI Build #142 failed
On 7/26/07, Alex Karasulu <[EMAIL PROTECTED]> wrote: Looks like these were just a build server hickup. Nothing major the server seemed to correct itself. How can I log in to see what the deal is/was, in case it's something I did? Enrique
Re: [m2-snapshot-repo] Permissions need to be massaged to allow group read write access
OK, done. I'm aware of the issue and (usually) remember to 'chmod' after each deploy. Enrique On 7/25/07, Alex Karasulu <[EMAIL PROTECTED]> wrote: Enrique, You have files in the m2 snapshot repo from a deploy which need to have the group rw permissions added to them here on people.apache.org: /www/people.apache.org/repo/m2-snapshot-repository Please fix this. Make sure you massage permissions on each deployment. We need to either fix maven's deploy plugin or make sure we massage permissions after each deploy. I think Trustin had a fix for it at some point but I don't think the maven guys incorporated it. Alex
Re: [Kerberos] Are the current refactoring changes going to break Triplesec?
On 7/21/07, Emmanuel Lecharny <[EMAIL PROTECTED]> wrote: ... yes, I wish that refactoring are done only on parts we now have tests cases. The major issue we currently have with kerberos is the lack of tests case. As soon as the tests case are written, it's ok, to refactor the code, but tests case should cover the current server and TSec too, as it's now a part of the project. I have been exclusively focused on providing test coverage. The latest series of changes was fully "test driven." In the last week I added ~70 new tests (~4 kloc). The changes I made last night were improvements to spec compliance found while writing the tests and reviewing the latest Kerberos RFC. The AS and TGS are now pretty well covered in protocol-kerberos. I will now move on to protocol-changepw and then move back to the integration tests for Kerberos, Change Password, and SASL GSSAPI. Enrique
Re: [Kerberos] Are the current refactoring changes going to break Triplesec?
These changes were all to protocol workflow behavior in the ticket-granting service (TGS). As such, they didn't touch the pre-authentication verifiers at all, which are in the authentication service (AS). I tried checking T-Sec to make sure but the build fails since org.apache.directory.server 1.0.3-SNAPSHOT artifacts don't appear to be deployed. If you have them checked out, could you please deploy them? Then I'll get into double-checking T-Sec is OK. Enrique On 7/21/07, Alex Karasulu <[EMAIL PROTECTED]> wrote: Enrique, I'm just curious if the current refactoring changes you're making are going to break Triplesec. Are you tracking if these changes break the way the verifiers are used so the HOTP verifier is not broken in Triplesec? Alex
Re: [BUILD] [FAILED] Build Apache Directory Server::CI Build #126 failed (1739 tests passed, 1 test failed (1 new))
I believe this simply triggered in the middle of about 20 commits. The offending line is now in a comment block. I'm all in and these changes build and tests pass on 2 machines. Let's see if it happens again. Enrique On 7/21/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: Build Apache Directory Server::CI Build #126 failed (1739 tests passed, 1 test failed (1 new)) Agent: Default agent Build results: http://builds.organicelement.com/viewLog.html?buildId=278&buildTypeId=bt1 Newly failed tests (1 test) == testRenewableTicket = junit.framework.AssertionFailedError: Requested renew-till time at junit.framework.Assert.fail(Assert.java:47) at junit.framework.Assert.assertTrue(Assert.java:20) at org.apache.directory.server.kerberos.protocol.KerberosProtocolHandlerTest.testRenewableTicket(KerberosProtocolHandlerTest.java:1059) at org.apache.directory.server.kerberos.protocol.KerberosProtocolHandlerTest.testRenewableTicket(KerberosProtocolHandlerTest.java:1059) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at junit.framework.TestCase.runTest(TestCase.java:154) at junit.framework.TestCase.runBare(TestCase.java:127) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.maven.surefire.junit.JUnitTestSet.execute(JUnitTestSet.java:213) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:138) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:125) at org.apache.maven.surefire.Surefire.run(Surefire.java:132) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:290) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:818) Changes included (17 changes, only 10 changes shown) Change 558312 by erodriguez (1 file): Minor API tweak to auth header verification to handle non-TGT ticket validation. Change 558310 by erodriguez (1 file): Minor refactoring of TGT verification to break abstract ticket verification. Also added some new checks for when the wrong tickets are presented to the TGS. Change 558309 by erodriguez (1 file): Minor improvement to error handling when a request is made to TGS without an auth header present. Change 558308 by erodriguez (1 file): Added some additional ticket validity checks and POSTDATED error handling to TGS ticket generation. Change 558307 by erodriguez (1 file): Fixed a minor bug where renew-till time as requested by client was not honored. Change 558305 by erodriguez (1 file): Enabled body checksum to be disabled by configuration, in TGS. Change 558304 by erodriguez (1 file): Added protocol version number check to TGS. Change 558303 by erodriguez (1 file): Made body checksum verification configurable (boolean) so it can be turned off during testing. Change 558302 by erodriguez (1 file): Minor API tweak to auth header verification to support ticket validation. Change 558301 by erodriguez (1 file): Broke ticket verification hierarchy. see more information about changed files: http://builds.organicelement.com/viewLog.html?tab=buildChangesDiv&buildId=278&buildTypeId=bt1 Configure email notifications: http://builds.organicelement.com/profile.html?init=1#notifications
Re: Is Dynamic DNS possible with Apache DS?
On 7/13/07, satish viswanatham <[EMAIL PROTECTED]> wrote: Hi I see that Apache DS works as a DNS server http://directory.apache.org/apacheds/1.0/dns-protocol-provider.html. Can this be extended to serve dynamic resolution of names for example call back or interceptor is called for each naming lookup. I am looking for something similar what pdns has http://doc.powerdns.com/pipebackend-dynamic-resolution.html , but in Java. Any thoughts? Does Apache DS or any other Java Server does this? ApacheDS could be extended to support DDNS, but this is not a currently supported feature. Enrique
[NTP] New integration test
Hi, Directory developers, After the configuration for NTP was revamped, Alex asked for an integration test for checking NTP when enabled in the server. I just added an NTP integration test to server-unit. I used commons-net for the NTP client. Enrique
Re: Kerberos implementation questions
On 7/9/07, Alex Karasulu <[EMAIL PROTECTED]> wrote: Right now the organization is setup to have two kinds of integration tests in two separate modules: core-unit => which IMO should be called core-integration :) server-unit => which IMO should be called server-integration :) I agree with these module names. ... If we add a kerberos-unit then to follow the same scheme we would have to rename server-unit to ldap-unit. Then we would create a changepw-unit and so on. I don't know how many tests we're adding but if not that many keeping them in the same project may be less overhead both in terms of maven build time and in terms of managing the project. I can only picture 1, maybe 2, test classes for each SASL GSSAPI, Kerberos, and CP. I don't see the point of separate modules with 1-2 classes. Emmanuel makes the point that "you should always write separate tests for separate elements" but then goes on to equate this with separate modules (!?). IMO, we do have separate tests already and there is nothing confusing about having them in the same module. ... I'd recommend (for now) just putting the kerberos tests and other protocol tests into a special package to differentiate them from the LDAP integration tests in server-unit. We eventually need to better organize them but a package level separation should give new comers enough of a cue as to the nature of the test. I was fine with separating by test class, but package works better if we do get above just a single test class for each protocol. We could even name the packages so they correspond to the module being tested, such as: o.a.d.server.core o.a.d.server.protocol.kerberos o.a.d.server.protocol.ldap o.a.d.server.protocol.changepw The difference between 'core' and 'protocol.ldap' would be the intent of the integration test, ie even though you are firing up the server and using the LDAP protocol in both cases, the target of the test may be the core or something in the protocol workflow. Enrique
Re: Kerberos implementation questions
On 7/9/07, Emmanuel Lecharny <[EMAIL PROTECTED]> wrote: Guys, I did a simple test on my laptop writing a kerberos-unity project, mimicing the server-unit project. I think that this should be a good approach, as you don't have anymore dependency to deal with. wdyt ? What would you do in the case of SASL GSSAPI bind tests, which use both Kerberos and LDAP? I am in favor of a single integration test module. Similarly, integration tests for Change Password would use Change Password and Kerberos. kerberos-unit would make sense if you were only testing the Kerberos protocol, but then why not just put the tests in protocol-kerberos. Enrique
Re: Kerberos implementation questions
On 7/9/07, Alex Karasulu <[EMAIL PROTECTED]> wrote: First of all this presumes the clients mirror the version of the server. I don't think you want that right? Nope. I just now looked at how shared-ldap is set up so I'll follow the way that's done. Unfortunately, the ldap clients are on Maven 1 so I couldn't use them as an example. Also the client is an external (to apacheds) project to ApacheDS so I would put the correct version of the client into the dependencyManagement section. Then you don't need to specify the version of the artifact in the dependencies section for these clients. OK, I take it you mean the dependencyManagement section of the apacheds trunk's POM, not server-unit. Secondly you want test in there for these dependencies if in fact you intend their scope to be test scope. OK, I see how the server-unit POM does this for ldapsdk. Enrique
Re: Kerberos implementation questions
On 7/9/07, Alex Karasulu <[EMAIL PROTECTED]> wrote:
...
The dep is just fine especially if you make the dep have test scope.
OK, one last question, can you review the following group/artifact
id's and make changes/suggestions before I deploy and add this to
server-unit:
org.apache.directory.client.kerberos
apacheds-kerberos-client
${pom.version}
org.apache.directory.client.kerberos
apacheds-password-client
${pom.version}
Enrique
Re: Kerberos implementation questions
On 7/2/07, Emmanuel Lecharny <[EMAIL PROTECTED]> wrote: On 7/2/07, Enrique Rodriguez <[EMAIL PROTECTED]> wrote: > On 7/1/07, Emmanuel Lecharny <[EMAIL PROTECTED]> wrote: > > Hi, > > > > I have some questions regarding the kerberos implementation : > > > > 1) We have a TicketModifier class. Is it really usefull ? > > The Ticket has no attribute setters, so the intention is that you use > the modifier to create immutable Ticket's. Do we need to create immutable Tickets ? We just produce Tickets in the server, then send them to the client. What's the point to have Immutable Tickets ? I may miss something ... I think it is good programming practice, both for security implications and for the resulting API, even if it is internal to ApacheDS on the server-side. You can web search on "security immutable" or here is a direct reference from Sun: http://java.sun.com/security/seccodeguide.html#gcg6 ... Ok, I gonna have a look at it. From the client side, we obviously must work with Sun classes, but from server side, having our own classes will help a lot (debug, logs, etc.). It can be done step by step, but first we need to build integration tests to be sure that moving from Sun to our own classes don't break everything. This is what I find difficult atm : changing the code is risky, because of the lack of tests. ... I have integration tests I would like to add to server-unit. But it requires adding a dep for kerberos-clients to server-unit, since the tests use the new client. If this is acceptable, I will add the dep and commit a new test class. This dep will also set us up for a new SASL GSSAPI bind integration test and some tests for Change Password, as well. Enrique
