[Samba] Verify if Samba AD was provisioned with RFC2037

[Marco Shmerykowsky]

On 2021-01-03 1:33 pm, Marco Shmerykowsky via samba wrote:
> On 2021-01-03 11:38 am, Rowland penny via samba wrote:
>> On 03/01/2021 15:35, Marco Shmerykowsky wrote:
>>> 
>>> 
>>> On 2021-01-03 10:19 am, Rowland penny via samba wrote:
>>>> On 03/01/2021 15:05, Marco Shmerykowsky via samba wrote:
>>>>> 
>>>>> On 2021-01-03 9:53 am, Rowland penny via samba wrote:
>>>>>> On 03/01/2021 14:32, Marco Shmerykowsky via samba wrote:
>>>>>>> Is there a way to confirm whether a samba AD was
>>>>>>> provisioned using RFC2307?
>>>>>> 
>>>>>> All that provisioning with '--use-rfc2307' does is to put
>>>>>> 'idmap_ldb:use rfc2307' into the first DC's smb.conf (a 'join' 
>>>>>> doesn't
>>>>>> do this) and adds the 'ypServ30.ldif' to AD. The first makes DC's 
>>>>>> use
>>>>>> uidNumber & gidNumber attributes from AD instead of the xidNumber
>>>>>> attributes from idmap.ldb. The second makes the Unix attributes 
>>>>>> tabs
>>>>>> work in ADUC, only problem is, they no longer exist 🙁
>>>>>> 
>>>>>> All of the RFC2307 attributes are in the AD schema by default, 
>>>>>> even if
>>>>>> you provision without '--use-rfc2307'.
>>>>>> 
>>>>>> Rowland
>>>>> 
>>>>> I see.  The reason I ask is that I'm trying to use an extended 
>>>>> query
>>>>> in a pfsense/openvpn setup and the query seems to fail. I'm fairly
>>>>> certain I have the query correct (although I could be wrong).
>>>>> 
>>>>> In googling I came across some discussion that RFC2307 can create 
>>>>> issues
>>>>> with the extended query (https://redmine.pfsense.org/issues/9527)
>>>>> 
>>>> That link seems to refer to IPA and AD is different, For instance 
>>>> you
>>>> cannot rely on the 'posix' objectclasses being in AD (in fact 
>>>> anything
>>>> that does, is, in my opinion, broken), the 'posix objectclasses are
>>>> auxiliary objectclasses of Windows objectclasses and as such are not
>>>> required.
>>>> 
>>>> What is your search query and what do you expect the results to be ?
>>> 
>>> my query is -> 
>>> memberOf=CN=VPN-Users,CN=users,DC=internal,DC=external,DC=com
>>> 
>>> Users who will be allowed access to the VPN are assigned to a 
>>> security group
>>> named "VPN-Users".  I then used Softerra's ldapbrowser 
>>> (www.ldapadministrator.com)
>>> to look at one of the users in the group and pulled the syntax for 
>>> the "memberof"
>>> attribute that listed the VPN-User group.
>>> 
>>> I would expect the extend query to validate a user who is a member of 
>>> the VPN-Users group.
>> 
>> OK, I do not have a group called 'VPN-Users', but I do have one called
>> 'vpnusers', so try this (adapted for your setup):
>> 
>> ldbsearch -H ldap://samdom.example.com -b
>> 'dc=samdom,dc=example,dc=com' -s sub
>> '(&(memberOf=CN=vpnusers,CN=Users,DC=samdom,DC=example,DC=com)(sAMAccountName=rowland))'
>> -P
>> 
>> or using ldapsearch:
>> 
>> ldapsearch -H ldap://samdom.example.com -b
>> 'dc=samdom,dc=example,dc=com' -s sub
>> '(&(memberOf=CN=vpnusers,CN=Users,DC=samdom,DC=example,DC=com)(sAMAccountName=rowland))'
>> -D 'cn=Administrator,dc=samdom,dc=example,dc=com' -W
>> 
>> Both of them work for myself, but the first one doesn't ask for a 
>> password.
>> 
>> Rowland
> 
> Using ldbsearch I get the following:
> 
> # Referral
> ref:
> ldap://internal.external.com/CN=Configuration,DC=internal,DC=external,DC=com
> 
> # Referral
> ref:
> ldap://internal.externak.com/DC=DomainDnsZones,DC=internal,DC=external,DC=com
> 
> # Referral
> ref:
> ldap://internal.external.com/DC=ForestDnsZones,DC=nternal,DC=external,DC=com
> 
> # returned 3 records
> # 0 entries
> # 3 referrals
> 
> Just a note that my VPN with authentication via SAMBA is working 
> without
> the "extended query" option.  I can connect my computer to the domain, 
> login
> to the network, and access all my drive mappings.  Something is wrong 
> with
> how I'm trying the extended query.

ldapsearch returns:

# search result
search: 2
result: 1 Operations error
text: 00002020: Operation unavailable without authentication