This documentation relates to an earlier version of FishEye.
View

Unknown macro: {spacejump}

or visit the current documentation home.

This page explains the settings for LDAP authentication and their parameters.

On this page:

Global Settings

Global LDAP settings are:

URL

The URL of the LDAP server, e.g. ldap://localhost:389.

Base DN

The base search space for users, e.g. dc=example,dc=com

User Filter

The LDAP search for locating users, e.g. uid=${USERNAME}. The ${USERNAME} variable is expanded to the username of the individual being authenticated. You can use a more complicated LDAP filter to allow only a subset of users, such as: (&(uid=${USERNAME})(group=fisheye)).

UID Attribute

The name of the username attribute in objects matching the filter.

Email attribute

Optional. The name of an attribute giving the user's email address.

Cache TTL (positive)

How long FishEye should cache permission checks. Example values are: 0 secs, 5 mins.

Auto-add

FishEye can automatically create a user it has not previously encountered if the user can successfully authenticate against LDAP.

Initial bind DN and password

Optional. If your LDAP server does not allow anonymous bind, then you need to specify a user FishEye can use to do its initial bind.

Synchronise users with Crowd

Optional. Sets whether users will be loaded from an external directory.

Per-Repository Settings

You can give FishEye an LDAP filter that will be used to check if a user has access to individual repositories.

To specify this filter for a repository, open the Permission settings of the repository, and check the Apply LDAP restriction option. Then just below the checkbox, type the filter string:

LDAP restriction

An LDAP filter used to check if a given user can access a given repository, e.g. (&(uid=${USERNAME})(group=${REP})). When an user attempts to access the repository, FishEye will perform a search in LDAP to retrieve all the entities matching the LDAP filter. This search will start at the Base DN of your LDAP's global settings.

Match Type

One of 'user' (default) or 'any'. This setting modifies how the search results are interpreted.

  • If set to 'user', then the first search result must match the exact Distinguished Name (DN) of the current user. Only if it does match, then that user is allowed to access to the repository.
  • If set to 'any', then if there is one or more search results, the current user is allowed to access to the repository.

When writing your LDAP filter, the following expressions are available:

  • ${USERNAME} will be replaced by the username of the logged user
  • ${DN} will be replaced by the Distinguished Name of the logged user
  • ${REP} will be replaced by the name of the repository the logged user is trying to access
Example

To allow an user to access a repository only if he or she is part of the group AuthorizedGroup, specify a LDAP filter such as: (&(uniqueMember=${USERNAME})(cn=AuthorizedGroup)(objectClass=groupofuniquenames)) and set the Match Type as Any.

Testing the LDAP restriction

To test the LDAP restriction, you can use Apache Directory Studio:

  • add a connection to your LDAP server (if you use Active Directory, use the following instructions)
    • in the LDAP menu, click on New Connection
    • enter the same URL and port as you did for FishEye
    • click on Next and enter the same Bind DN and password as in Global settings (see Initial bind DN and password above)
    • click on Finish
  • in the LDAP menu, and click on New Search
  • in the Search dialog,
    • select the connection to your LDAP server 
    • enter the same Base DN you configured in Global settings next to the Search Base textbox
    • enter the LDAP filter next to the Filter textbox (if the filter contains ${USERNAME} or ${REP}, replace them by the username or repository name you want to test)
    • select Subtree in the Scope section
    • click on Search

Active Directory

To have FishEye connect to an Active Directory server, use settings such as the following:

URL

ldap://HOSTNAME:389

Base DN

DC=corp,DC=example,DC=com

User Filter

(sAMAccountName=${USERNAME})

UID Attribute

sAMAccountName

Email attribute

mail

Initial bind DN

corp.example.com/Users/SomeUser

24 Comments

  1. Deleted Account

    The ability to configure LDAP referrals appears to be missing?

    1. Partha

      Dear Andy,

      If you need to follow referrals, please add "-Djava.naming.referral=follow" to your FISHEYE_OPTS environment variable.

      Example:

      FISHEYE_OPTS="-Xms128m -Xmx1024m -XX:MaxPermSize=128m -Djava.naming.referral=follow"
      
  2. Eric O'Brien

    In an Active Directory environment, is there any way to access multiple trees below the overall domain? For example: domain1.company.com, domain2.company.com and domain3.company.com. Through the web interface it appears I can only use one sub-domain.

    1. Dear Eric,

      FishEye does not support this behaviour out of the box. However, it can be achieved if you use a custom authenticator, or Atlassian Crowd.

      See this support page on custom authenticators for more information.

      I hope this helps!

      Best Regards,


      Edwin Dawson
      Technical Writer
      ATLASSIAN - http://www.atlassian.com

    2. Anonymous

      To go across multiple domains, you can try using a Global Catalog server as your hostname and port 3286, e.g.

      ldap://GlobalCatalogServer:3268

      A Global Catalog Server cache's information from other domains such as logon credentials and group memberships, whereas a normal Domain Controller does not.

  3. Anonymous

    Does this spuuort LDAPS on port 636 instead of straigh LDAP on 389?

    1. Anonymous

      Yea - but SSL support with java will rely on your JRE being able to walk the certificate chain of the AD cert (ie you need to import your LDAPS CA into your JRE)

      captcha: poofing :/

      1. Partha

        The steps to import your LDAPS CA are similar to those of confluence. See Connect to LDAP via SSL.

        Of course skip step 2 as you will specify the port and ldaps:// in the LDAP configuration.

  4. Anonymous

    The filter string:

    sAMAccountName=${USERNAME}
    
    did not work for us with active directory. It should be corrected to 
    
    (sAMAccountName=${USERNAME}) 
    
    
    1. Anonymous

      Cool! it works.

  5. Anonymous

    Do the per-repository settings take into account information from the LDAP Authentication settings section?  In other words, if I have

    | Base DN: | OU=People, O=company.com |
    | User Filter: | (uid=${USERNAME}) |
    but I want to set my per-repository settings like this: (&(uniquemember=uid=${USERNAME},ou=People,o=company.com)(cn=APPL_Altiris_SW_Portal_Test_Users,OU=Groups,O=company.com)(objectClass=groupofuniquenames))
    

    will the per-repository settings be able to see Groups because of the People restriction in the LDAP Authentication settings section?

    1. Matt Quail

      Yes, your per-repository setting will do what you want.

      The per-repository setting is an LDAP search against the whole directory. In this case it should return one User object (with uid=${USERNAME}) or no objects at all. The User object's DN should match the DN of the user in question.

  6. Anonymous

    No idea how to get Active Directory group membership restrictions working (sad)

    (&(member=${USERNAME})(CN=Intranet - Fisheye CVS repository,OU=Intranet Resource Groups,OU=Resource Groups,DC=fcs,DC=syd)(objectClass=group)) 
    

    Just won't work for me (sad)

    1. Anonymous

      Doh!

      (memberOf=CN=Intranet - Fisheye CVS repository,OU=Intranet Resource Groups,OU=Resource Groups,DC=fcs,DC=syd)
      

      Works. sheepish grin

      1. Anonymous

        To be clear, group membership restriction works with the following in the User Filter field:

        (&(sAMAccountName=${USERNAME})(memberOf=CN=Intranet - Fisheye CVS repository,OU=Intranet Resource Groups,OU=Resource Groups,DC=fcs,DC=syd))
  7. Anonymous

    Note: it would be more practical to use the query credentials to bind for the authentication attempt. since our AD environment does not allow anonymous binds, a username and password is required. this all works ok, but I have now my personal [admin] credentials stored in the fisheye configuration. once my password expires/changes, LDAP authentication will break for all users until the new password is reentered in the fisheye LDAP configuration.

    please correct me if I am wrong.

    thanks

  8. Craig Harman

    Anyone had experience setting this up using OS X's Open Directory? I keep getting an invalid DN message:

    Server: ldap://server.com:389

    cn=users, dc=compName,dc=domain,dc=com

    Filter: (uid=$USERNAME)

    UID Attribute: uid

    1. Hendry Betts

      set your filter to (uid=${USERNAME}) -- the curly braces are important.

  9. Anonymous

    I had to use the following format for "Initial bind user" for integrating to my Microsoft AD:

    CN=John Doe,OU=Users,OU=XXX,OU=YYY,DC=ZZZ,DC=dom

  10. Eric Stevens

    Our LDAP CN's are in the format:

    Surname, Givenname (Division/SiteCode)

    I believe this forward slash prevents LDAP authentication (I have a test account which does not have (Division/SiteCode), and it authenticates successfully, while my primary account does not).

    The "error" such as it is reads as follows:

    performing search: (sAMAccountName=UserName) on DC=XX,DC=YYY,DC=ZZZ (authenticated)
    LDAP: User with dn '"CN=Surname\, Givenname (Division/SiteCode),OU=Users,OU=Site Name",DC=XXX,DC=YYY,DC=ZZZ' found, but authentication failed.
    LDAP password check for UserName in 0ms
    
    1. Anonymous

      Hi

       

      You may want to try using this as a Trial. It worked for me!!

       

      Base DN :     OU="SomeOU",DC="SomeDomain",DC="co",DC="uk"

      Initial Bind DN:     CN="username",OU="SomeOU",DC="SomeDomain",DC="co",DC="uk"

       

      Regards

       

       

       

       

  11. Chris Walquist

    How do I turn off the LDAP integration's auto-create login?  It is causing us problems managing our license allocation.

    Thanks,

    -chris

  12. Alastair Bain

    Is there any way to have separate read/write permissions when using LDAP? The implementation seems very clunky, why couldn't you guys have implemented the same kind of setup that Confluence/Jira use? Would be nice to be able to use LDAP groups in the same fashion as local groups without having to write a custom query.

  13. Anonymous

    Hi, I've just installed FishEye after installing and configuring Stash, and was expecting equivalent LDAP user and group browsing / adding. ( good work on the Stash LDAP integration tools btw )

    I'd give a big thumbs up for equivalent functionality in FishEye

    • Dominic Day