Trying to connect to my AD server and keep getting this error. Any ideas? DNS is set to the internal DNS (and an external one as secondary.)
Hi, what about logs from Win2008 Domain?
Also can be useful
Windows logs show nothing. 
The first article you posted sounds promising but it is confusing.
My AD domain is eagleairmed.local Does that go in the domain or realm?
If I browse AD directly, is shows full name of ABC.eagleairmed.local So, what goes where?
Made a little progress but still stumped: 
Is you’re DC in the same subnet as the Nethserver?
If not: Are broadcasts routed by IPHelpers?
I’m not sure what goes into domain, but for sure, your realm is going to be eagleairmed.local
For reference, have a look at this link:
https://raymii.org/s/tutorials/SAMBA_Share_with_Active_Directory_Login_on_Ubuntu_12.04.html#Join_the_domain
Specially the sections called “Configuring Kerberos”, and “Configuring Samba”. You will notice the realm fields, and also maybe domain can be same as realm if I understand the page correctly.
Hi, @chrisg
This link can shed the light on your issue:
https://technet.microsoft.com/ru-ru/library/cc794928(v=ws.10).aspx
Please show the output of set DOS command , obviously on your AD
I’d like to know USERDNSDOMAIN USERDOMAIN parameters
Can you share also your LDAP branch on AD?
eagleairmed.local
eagleairmed
OU=MyAMRG,DC=EagleAirMed,DC=local
Yep, both on the same network, subnet.
192.168.1.20 AD
192.168.1.42 Nethserver
255.255.255.0
DNS on nethserver is set to the AD server as well. Time is sync’d just fine.
Any luck figuring it out? I’m stuck in the same situation
Did you tried to put “OU=MyAMRG,DC=EagleAirMed,DC=local” in the LDAP Accounts Branch-Field?
Background:
The OU does not have to own a unique name. You can have an OU with that name in another branch too - so which one should be taken? This also applies if you only have one OU with that name.
Hi @chrisg! From what I can see from your screenshot I think you set wrong realm and domain.
Try this config:
REALM: eagleairmed.local
DOMAIN: eagleairmed
then pay attention to the ldap branch you’re using: AD Administrator profile have to be into that branch.
1 Like
Hi,
I’m stuck in the same place. I’ve used:
Realm: aoserv.local
Domain: aoserv
LDAP branch: CN=Users,DC=aoserv,DC=local
My userdnsdomain is AOSERV.LOCAL
and userdomain is AOSERV
The NS and the AD are on same subnet obviously, and DNS and NTP are set correctly.
I get the same error as shown in first post. Also, if I try the CLI route that someone linked above, when I join the AD, it gives no errors and doesn’t prompt for password. Just after some time, it gets back to the prompt.
I have no idea how, but the same settings that didn’t work the past 5/8 times even with multiple server reboots, now got accepted after the last reboot.
This was the magic! The OU did not have the Administrator profile in it. Once I changed it to OU=users, it appears to have succeeded. Thanks for the help.
1 Like
So, continuing with the AD integration, We have several OU for our different divisions. Nethserver looks to only allow one OU. Do we need to move all our OUs to under one OU and link Nethserver to that OU?
OU=Company
OU=Sales
OU=Finance
Do we need to make Sales and Finance subordinate to Company?
Also, how do the users get pushed to the server? I have AD connected but the users are not populating. I can see them if I run a wbinfo -u, I do see all the users.
The documentation is seriously lacking on the AD integration and use. It may be something I consider writing up for future users of NS. Let’s face it, AD rules the world and to not have NS tightly integrated and documented, NS will only be “one of those other quasi-mail servers.” For professional IT shops, at least here in the US, ActiveDirectory integration is paramount to buying a product.
Users are not pushed to NethServer and you will be able to see them only on specific pages (like Web Content Filter), sadly the “Users” page is not one of them.
This is because the integration is partial, since there are many problems to face and most of them are not related to CentOS but to AD itself. I know we have some internal documentation but it is Italian-only and tailored for the Enterprise support.
This was the sad part, now the the bright one! 
We are working very hard to have a full integration with AD for NS 7.
The goal is to have fully featured NS which can act as AD PDC and also can connect to a forest of existing AD.
Stay tuned!
1 Like