Bitbucket Server LDAP integration (active directory) necessary user has admin privs?

Joe IT Daigle

New to Bitbucket server, but I think we are going to like it.  We have two stumbling blocks to going ahead with it.

1) From what I read, Bitbucket Server requires the identity of the daemon/service interacting with A/D to have administrative rights.  That just aint gonna fly with our already paranoid IT guys.  Is this true? 

Is there any way around it - I read that there are a few permissions needed, and making the user a full on admin is overkill.  Is there a guide of some kind that describes how to give a run of the mill user just these permissions?

If we dont make this user an admin, it seems the consequence is that a deleted user in A/D does not get removed in BitBucket.  Correct?  Is this the only gotcha with a non admin user for the service identity?

 

2) Conceptual question: It seems that there are two features to A/D integration.  One provides for the normal authentication with A/D but management of what users can access BitBucket left to BitBucket mechanisms.

The other option seems to be more fully functional integration - who can access BitBucket and their group membership along with authentication is handled via A/D.

 

Do I have it right (oversimplifying I'll bet)?  Im kind of at a loss as to how to manage the second of the two.  How do I tell BB which groups mean what?  Sorry so clueless on this one....

 

Thanks in advance for any help -

 

Joe

Craig Castle-Mead_20fp9z

Hey Joe,

NB: we have Crowd as in interim step between our applications and the user stores, so while the below is correct in our environment, I can only assume it will the same/close in your type of setup, but there is a chance it may just be different enough that the below won't apply.

 

The permissions required on the AD/LDAP service account you're connecting with depend on what you want to be able to control. We have a number of directories integrated but all they do is read from the AD's and LDAP's - so the accounts just need to be read only and based on the permissions set (in Crowd, we specify that directory doesn't allow user creation/etc). It pulls all the information into Crowd and changes MUST be made back at the source (AD/LDAP). 

 

In 2 of our AD's, we have a group structure in AD that represents the permissions we want in the Atlassian applications, so we pull the users/groups/memberships straight through to the apps. We then use these groups in application licensing and global permissions.

The 2 x LDAP's have no group structure that relates to how we want to grant permissions in our Atlassian applications though, so we only pull through users (our LDAP filter for groups tries to match a random string that no group will ever meet, so we never get any groups). Once the users are in Crowd, on those directories, we allow local groups to be created for that directory so the groups sit in Crowd and we then put the users into the relevant groups.

 

Hopefully the above helps you get more insight into both of your questions - if you've still got questions (or if it makes 0 sense, it is Friday afternoon...) just yell out.

 

CCM