Yes the security mapping is 'off' by default. For the LDAP integration, we simply grab the DN that is being returned [1]. In your login-identity-providers.xml are your 'User search' properties configured with upper or lower case?
Matt [1] https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-ldap-iaa-providers-bundle/nifi-ldap-iaa-providers/src/main/java/org/apache/nifi/ldap/LdapProvider.java#L266 On Tue, Sep 6, 2016 at 11:08 AM, Andre <[email protected]> wrote: > Matt, > > This was on 1.0 > > No big deviations from standards setup as described by Admin Guide: > > <authorizer> > <identifier>file-provider</identifier> > ... > <property name="Initial Admin Identity">CN=BOFH, DC=evil, DC=com > </property> > ... > </authorizer> > > > Configuring to: > > > <authorizer> > <identifier>file-provider</identifier> > ... > <property name="Initial Admin Identity">cn=BOFH, dc=evil, dc=com > </property> > ... > </authorizer> > > solved. > > The environment I was testing on seemed quite weird, hence the reason I > asked if anyone else seen that while integrating into AD LDS (I don't have > many of those available to test). > > Also, I away from the box at the moment but I recall leaving > nifi.security.identity.mapping unchanged (IIRC the default config is a > commented line?) > > Cheers > > > > On Wed, Sep 7, 2016 at 12:56 AM, Matt Gilman <[email protected]> > wrote: > >> Andre, >> >> Which version of Apache NiFi are you using? >> >> In 0.x authorities are defined using the string that is returned from the >> authenticator so there should be no issue here. >> >> In 1.x users are entered by hand either through the UI or in the >> authorizers.xml file (for the initial admin). This value must match the >> value that the authenticator is returning or the result of >> any nifi.security.identity.mapping you may have configured. If you're >> unsure what value the authenticator has returned, the identity string will >> be printed in the logs/nifi-user.log when authorization fails. >> >> Let me know if this helps. >> >> Matt >> >> On Tue, Sep 6, 2016 at 10:46 AM, Andre <[email protected]> wrote: >> >>> All, >>> >>> just to clarify as my previous message was missing this "small" detail): >>> >>> I defined the initial admin as: >>> >>> CN=BOFH, DC=evil, DC=com >>> >>> Logged in as >>> >>> BOFH / password >>> >>> Password gets recognised but NiFi tells me I am not authorised to access >>> the Flow. >>> >>> Rewrite the config so that initial admin as: >>> >>> cn=BOFH, dc=evil, dc=com >>> >>> Logged in as >>> >>> BOFH / password >>> >>> All works >>> >>> On Wed, Sep 7, 2016 at 12:38 AM, Andre <[email protected]> wrote: >>> >>>> All, >>>> >>>> I accidentally bumped into this situation and I was wondering if anyone >>>> else seen this as well. >>>> >>>> When provisioning a LDAP authenticated NiFi instance I defined the >>>> initial admin as: >>>> >>>> CN=BOFH, DC=evil, DC=com >>>> >>>> To my surprise this did not work. Upon inspection of the authentication >>>> and authorization files, I realised that internally NiFi seems to lower >>>> case distinguished names "fields" like cn, ou, dc, etc. >>>> >>>> It happens to be that AD LDS seems to return upper case on all "fields" >>>> of the LDAP DN. >>>> >>>> https://social.technet.microsoft.com/Forums/sharepoint/en-US >>>> /d825ec95-94ad-4b0b-93cd-01214c312ef1/returning-lower-case-d >>>> istinguished-names-from-an-ad-lds-instance?forum=winserverDS >>>> >>>> Has anyone else noticed that when integrating NiFi into AD? If so, >>>> should we raise it as a bug or simply address it via documentation? >>>> >>>> Cheers >>>> >>> >>> >> >
