Active Directory not working #4074

@guillep2k commented on GitHub (Oct 7, 2019):

I guess <username> is something you replaced, not something that actually shows up in your log, isn't it?

@guillep2k commented on GitHub (Oct 7, 2019): I guess `<username>` is something you replaced, not something that actually shows up in your log, isn't it?

GiteaMirror commented

@Mr-Reca commented on GitHub (Oct 7, 2019):

Yes. I put a “placeholder” because of internal policies.

@Mr-Reca commented on GitHub (Oct 7, 2019): Yes. I put a “placeholder” because of internal policies.

GiteaMirror commented

@guillep2k commented on GitHub (Oct 7, 2019):

Anyway, you need to replace some of the values depending on your configuration. For example, for my own system ("miempresa.es"), it should be something like this:

Báse de búsqueda de usuarios: CN=Users,dc=miempresa,dc=es. Notice that it's CN= and not OU=; also in my case it's Users and not Usuarios (my server was installed in English, but I believe that this doesn't change with the server language).
DN de Usuario: same considerations.

There are other kinds of queries that can be used, including using the OU= parameter, but they must exist in your AD configuration in order to work.

You could check some tool like this (I don't know it, it just popped up on a search) to test your search parameters.

Please notice that this is not a support forum. If you're still having problems, please ask in the #Configuration channel of our Discord server, or in our forum.

@guillep2k commented on GitHub (Oct 7, 2019): Anyway, you need to replace some of the values depending on your configuration. For example, for my own system ("miempresa.es"), it should be something like this: - ***Báse de búsqueda de usuarios***: `CN=Users,dc=miempresa,dc=es`. Notice that it's `CN=` and not `OU=`; also in my case it's `Users` and not `Usuarios` (my server was installed in English, but I believe that this doesn't change with the server language). - ***DN de Usuario***: same considerations. There are other kinds of queries that can be used, including using the `OU=` parameter, but they must exist in your AD configuration in order to work. You could check some tool like [this](http://www.joeware.net/freetools/tools/adfind/index.htm) (I don't know it, it just popped up on a search) to test your search parameters. Please notice that this is not a support forum. If you're still having problems, please ask in the `#Configuration` channel of our [Discord server](https://discord.gg/NsatcWJ), or in our [forum](https://discourse.gitea.io/).

GiteaMirror commented

@Mr-Reca commented on GitHub (Oct 8, 2019):

I also tried that configuration.

I opened the issue because there are lots of links with configurations and none of them works. I think that maybe something is missing (in documentation or implementation of LDAP)

@Mr-Reca commented on GitHub (Oct 8, 2019): I also tried that configuration. I opened the issue because there are lots of links with configurations and none of them works. I think that maybe something is missing (in documentation or implementation of LDAP)

GiteaMirror commented

@Mr-Reca commented on GitHub (Oct 8, 2019):

Hi @guillep2k ,

I tried AdFind and the same query does not work in Gitea. Is it better to close this issue and talk through the forum, or do you think it can be something? Is it possible to test this feature with another AD?

Thank you so much for your time,

@Mr-Reca commented on GitHub (Oct 8, 2019): Hi @guillep2k , I tried AdFind and the same query does not work in Gitea. Is it better to close this issue and talk through the forum, or do you think it can be something? Is it possible to test this feature with another AD? Thank you so much for your time,

GiteaMirror commented

@guillep2k commented on GitHub (Oct 8, 2019):

@Mr-Reca The AD feature is not only used in many installations (it's a popular way of using Gitea) but it's also tested every time a single line of code is added to Gitea in our continuos integration tests. Everything is susceptible of having bugs and we're far from 100% test coverage, so bugs can still slip in.

Anyway, check this link and search around the forum; you might find the solution there.

Feel free to leave this issue open if you feel that it's a bug in Gitea.

@guillep2k commented on GitHub (Oct 8, 2019): @Mr-Reca The AD feature is not only used in many installations (it's a popular way of using Gitea) but it's also tested every time a single line of code is added to Gitea in our [continuos integration tests](https://drone.gitea.io/go-gitea/gitea/13546). Everything is susceptible of having bugs and we're far from 100% test coverage, so bugs *can still slip in*. Anyway, [check this link](https://discourse.gitea.io/t/using-samaccountname-for-ldap-login/860/7) and search around the forum; you might find the solution there. Feel free to leave this issue open if you feel that it's a bug in Gitea.

GiteaMirror commented

@markkrj commented on GitHub (Oct 8, 2019):

Considering Active Directory, your User DN is wrong. It must be CN=username,OU=your,OU=user,OU=organization,OU=unity,DC=your,DC=domain. But you really must consider using LDAPS and bind DN for security.

@markkrj commented on GitHub (Oct 8, 2019): Considering Active Directory, your User DN is wrong. It must be CN=username,OU=your,OU=user,OU=organization,OU=unity,DC=your,DC=domain. But you really must consider using LDAPS and bind DN for security.

GiteaMirror commented

@Mr-Reca commented on GitHub (Oct 9, 2019):

Hi @markkrj

I'm trying now without LDAPS for testing, I'll set it up later. Is it safer to user BindDN? When I check this option, Gitea says that this value will be stored in raw.

I'll try to change my user DN. @guillep2k I also realized that my DN has the following format:

CN=<my_display_fullname>,OU=Usuarios,OU=<department>,OU=<office>,DC=<domain>,DC=<local>

In my case, the users will have the same department. But the office is different (Barcelona, Madrid, London...).

The group has the same format, but department and office is always the same for everyone.

Maybe our AD is misconfigured? Or will it be a problem to use LDAP with different OU?

Thank you so much for your time,

@Mr-Reca commented on GitHub (Oct 9, 2019): Hi @markkrj I'm trying now without LDAPS for testing, I'll set it up later. Is it safer to user BindDN? When I check this option, Gitea says that this value will be stored in raw. I'll try to change my user DN. @guillep2k I also realized that my DN has the following format: `CN=<my_display_fullname>,OU=Usuarios,OU=<department>,OU=<office>,DC=<domain>,DC=<local>` In my case, the users will have the same `department`. But the `office` is different (Barcelona, Madrid, London...). The group has the same format, but `department` and `office` is always the same for everyone. Maybe our AD is misconfigured? Or will it be a problem to use LDAP with different OU? Thank you so much for your time,

GiteaMirror commented

@lafriks commented on GitHub (Oct 9, 2019):

User DN should probably be:

CN=%s,OU=Usuarios,OU=<department>,OU=<office>,DC=<domain>,DC=<local>

Does sAMAccountName is the same as CN= for users?

If it is not that it will not work and you should use something like this for user filter:

(&(objectCategory=Person)(!(UserAccountControl:1.2.840.113556.1.4.803:=2)))

@lafriks commented on GitHub (Oct 9, 2019): User DN should probably be: ``` CN=%s,OU=Usuarios,OU=<department>,OU=<office>,DC=<domain>,DC=<local> ``` Does `sAMAccountName` is the same as `CN=` for users? If it is not that it will not work and you should use something like this for user filter: ``` (&(objectCategory=Person)(!(UserAccountControl:1.2.840.113556.1.4.803:=2))) ```

GiteaMirror commented

@lafriks commented on GitHub (Oct 9, 2019):

Also for AD I would probably recommend using LDAP (via BindDN)

Of course you need to create service user in AD for this

@lafriks commented on GitHub (Oct 9, 2019): Also for AD I would probably recommend using `LDAP (via BindDN)` Of course you need to create service user in AD for this

GiteaMirror commented

@Mr-Reca commented on GitHub (Oct 9, 2019):

User DN should probably be:
CN=%s,OU=Usuarios,OU=<department>,OU=<office>,DC=<domain>,DC=<local>
Does sAMAccountName is the same as CN= for users?

If it is not that it will not work and you should use something like this for user filter:
(&(objectCategory=Person)(!(UserAccountControl:1.2.840.113556.1.4.803:=2)))

No, it's not the same. the CN in User DN is the display name. sAMAccountName is the username

Example:

CN=Lore Ipsum,OU=Usuarios,OU=<department>,OU=<office>,DC=<domain>,DC=<local>
sAMAccountName=lore.ipsum

@Mr-Reca commented on GitHub (Oct 9, 2019): > > > User DN should probably be: > > ``` > CN=%s,OU=Usuarios,OU=<department>,OU=<office>,DC=<domain>,DC=<local> > ``` > > Does `sAMAccountName` is the same as `CN=` for users? > > If it is not that it will not work and you should use something like this for user filter: > > ``` > (&(objectCategory=Person)(!(UserAccountControl:1.2.840.113556.1.4.803:=2))) > ``` No, it's not the same. the CN in User DN is the display name. sAMAccountName is the username Example: ``` CN=Lore Ipsum,OU=Usuarios,OU=<department>,OU=<office>,DC=<domain>,DC=<local> sAMAccountName=lore.ipsum ```

GiteaMirror commented

@lafriks commented on GitHub (Oct 9, 2019):

That is why it does not work as you enter user CN but user filter filters it out as it does not match

@lafriks commented on GitHub (Oct 9, 2019): That is why it does not work as you enter user CN but user filter filters it out as it does not match

GiteaMirror commented

@Mr-Reca commented on GitHub (Oct 9, 2019):

So I could configure to use displayName which matchs with DN, but I am not able to use sAMAccountName ?

@Mr-Reca commented on GitHub (Oct 9, 2019): So I could configure to use `displayName` which matchs with DN, but I am not able to use `sAMAccountName` ?

GiteaMirror commented