Details

    • Type: Bug
    • Status: Resolved
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 1.0.0-M31
    • Fix Version/s: 1.0.0-RC1
    • Labels:
      None

      Description

      Hi Team,

      I have an issue in loading schema in LDAPNetworkConnection.
      I could connect to my Active Directory host, however when I call the loadSchema() method, it threw out below exception

      java.text.ParseException: ERR_04228 Parser failure on attribute type description: ( 1.2.840.113556.1.4.375 NAME 'systemFlags' SYNTAX '1.3.6.1.4.1.1466.115.121.1.27' SINGLE-VALUE NO-USER-MODIFICATION ) Antlr message: NO-USER-MODIFICATION requires an operational USAGE Antlr column: 0: ERR_04228 Parser failure on attribute type description: ( 1.2.840.113556.1.4.375 NAME 'systemFlags' SYNTAX '1.3.6.1.4.1.1466.115.121.1.27' SINGLE-VALUE NO-USER-MODIFICATION ) Antlr message: NO-USER-MODIFICATION requires an operational USAGE Antlr column: 0: NO-USER-MODIFICATION requires an operational USAGE

      Could you please advise?

      Best Regards,

      Steven Nguyen

        Activity

        Hide
        elecharny Emmanuel Lecharny added a comment -

        I think that the pb is fixed when using the loader in relaxed mode

        Show
        elecharny Emmanuel Lecharny added a comment - I think that the pb is fixed when using the loader in relaxed mode
        Hide
        elecharny Emmanuel Lecharny added a comment -

        I think the new loader is correctly handling this use case when in relaxed mode.

        Show
        elecharny Emmanuel Lecharny added a comment - I think the new loader is correctly handling this use case when in relaxed mode.
        Hide
        semancik Radovan Semancik added a comment -

        There is method how to work around it. Initialize SchemaLoader and DefaultSchemaManager explicitly. Like this:

                                DefaultSchemaLoader schemaLoader = new DefaultSchemaLoader(connection, schemaQuirksMode);
            			DefaultSchemaManager defSchemaManager = new DefaultSchemaManager(schemaLoader);
            			try {
            				if (schemaQuirksMode) {
                				defSchemaManager.setRelaxed();
                				defSchemaManager.loadAllEnabledRelaxed();
            				} else {
            					defSchemaManager.loadAllEnabled();
            				}
        				} catch (Exception e) {
        					throw new ConnectorIOException(e.getMessage(), e);
        				}
            			if ( !defSchemaManager.getErrors().isEmpty() ) {
            				if (schemaQuirksMode) {
            					LOG.ok("There are {0} schema errors, but we are in quirks mode so we are ignoring them", defSchemaManager.getErrors().size());
            				} else {
            					throw new ConnectorIOException("Errors loading schema "+defSchemaManager.getErrors());
            				}
            			}
        

        see https://github.com/Evolveum/connector-ldap/blob/master/src/main/java/com/evolveum/polygon/connector/ldap/AbstractLdapConnector.java

        The use the API in the schemaless mode. Whenever you need schema information then retrieve it from defSchemaManager explicitly. This works for me with OpenDJ, 389ds and eDirectory. Might work for you as well.

        Show
        semancik Radovan Semancik added a comment - There is method how to work around it. Initialize SchemaLoader and DefaultSchemaManager explicitly. Like this: DefaultSchemaLoader schemaLoader = new DefaultSchemaLoader(connection, schemaQuirksMode); DefaultSchemaManager defSchemaManager = new DefaultSchemaManager(schemaLoader); try { if (schemaQuirksMode) { defSchemaManager.setRelaxed(); defSchemaManager.loadAllEnabledRelaxed(); } else { defSchemaManager.loadAllEnabled(); } } catch (Exception e) { throw new ConnectorIOException(e.getMessage(), e); } if ( !defSchemaManager.getErrors().isEmpty() ) { if (schemaQuirksMode) { LOG.ok( "There are {0} schema errors, but we are in quirks mode so we are ignoring them" , defSchemaManager.getErrors().size()); } else { throw new ConnectorIOException( "Errors loading schema " +defSchemaManager.getErrors()); } } see https://github.com/Evolveum/connector-ldap/blob/master/src/main/java/com/evolveum/polygon/connector/ldap/AbstractLdapConnector.java The use the API in the schemaless mode. Whenever you need schema information then retrieve it from defSchemaManager explicitly. This works for me with OpenDJ, 389ds and eDirectory. Might work for you as well.
        Hide
        snguyen Steven Nguyen added a comment -

        Hi Emmanuel,

        Many thanks for your detailed explanation.
        I understand that M$ does not completely follow the LDAP RFC but our project requires to use AD.
        I hope that future release of Directory API will cover the case.

        Thanks for your help.

        Best Regards,

        Steven Nguyen

        Show
        snguyen Steven Nguyen added a comment - Hi Emmanuel, Many thanks for your detailed explanation. I understand that M$ does not completely follow the LDAP RFC but our project requires to use AD. I hope that future release of Directory API will cover the case. Thanks for your help. Best Regards, Steven Nguyen
        Hide
        elecharny Emmanuel Lecharny added a comment - - edited

        You are most certainly trying to load an AD schema. As usual, Microsoft made all it can to twist the RFC and make it almost impossible for tools that actually try to follow the specifications to work.

        In this very case, the AttributeType specification, as exposed in RFC 4512, makes the USAGE keyword mandatory when the NO-USER-MODIFICATION is present:

           NO-USER-MODIFICATION requires an operational usage.
        

        This make a lot of sense, because there are three kind of operational usage, and we must know which one of the three to use.

        Bottom line, I would ask you : why are you using AD, which is just a piece of crap ? Not only it does not implements the LDAP RFCs correctly (knowing Microsoft, mostly on purpose), but it's also an inferior so-called LDAP implementation, when it comes to reliability and performance (and it's a matter of orders of magnitude in this case).

        Ok, rant put aside, here, I have no quick solution. We should and we would get the API to swallow the crippled Microsoft schema in the near future (and we actually working on making the API to do that), but it will take a bit of time.

        Technically speaking, we can allow an AttributeType to have the NO-USER-MODIFICATION specifier without an USAGE, making the attributeType an operational attributeType (most certainly a directoryOperation, but I'm not sure, seems like the systemFlags AT is used for replication, and that would dive us to pick another usage. Assuming M$ accept any of those three Operational Usage).

        FTR, here is the Microsoft broken definition of an Operational Attribute : https://technet.microsoft.com/en-us/library/ee156512.aspx

        It's not even remotely close to any LDAP RFC. At all.

        Show
        elecharny Emmanuel Lecharny added a comment - - edited You are most certainly trying to load an AD schema. As usual, Microsoft made all it can to twist the RFC and make it almost impossible for tools that actually try to follow the specifications to work. In this very case, the AttributeType specification, as exposed in RFC 4512 , makes the USAGE keyword mandatory when the NO-USER-MODIFICATION is present: NO-USER-MODIFICATION requires an operational usage. This make a lot of sense, because there are three kind of operational usage, and we must know which one of the three to use. Bottom line, I would ask you : why are you using AD, which is just a piece of crap ? Not only it does not implements the LDAP RFCs correctly (knowing Microsoft, mostly on purpose), but it's also an inferior so-called LDAP implementation, when it comes to reliability and performance (and it's a matter of orders of magnitude in this case). Ok, rant put aside, here, I have no quick solution. We should and we would get the API to swallow the crippled Microsoft schema in the near future (and we actually working on making the API to do that), but it will take a bit of time. Technically speaking, we can allow an AttributeType to have the NO-USER-MODIFICATION specifier without an USAGE , making the attributeType an operational attributeType (most certainly a directoryOperation , but I'm not sure, seems like the systemFlags AT is used for replication, and that would dive us to pick another usage. Assuming M$ accept any of those three Operational Usage). FTR, here is the Microsoft broken definition of an Operational Attribute : https://technet.microsoft.com/en-us/library/ee156512.aspx It's not even remotely close to any LDAP RFC. At all.

          People

          • Assignee:
            Unassigned
            Reporter:
            snguyen Steven Nguyen
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development