John R. Graham
2023-Apr-25 20:40 UTC
[Samba] Configuring Linux openldap ldapsearch client-side tool to authenticate against a Samba AD server
Hi, Rowland. There is no openldap server. I'm working on achieving single sign on for both Linux and Windows machines against a new Samba AD server. I'm not against authenticating; I'm just ignorant on how to go about that. Single sign on is, I understand, provided "out of the box" for Windows clients once the AD server is properly set up. The eventual goal on the Linux side would be to use pam_ldap or SSSD to communicate with the Samba AD LDAP server to achieve the same thing. My initial thought was to do this /without/ installing the Samba client side tools on every Linux box. If that's a bad decision, please feel free to wave me off. In trying to get things working incrementally, I was trying to use the openldap-provided ldapsearch tool to query Samba AD for user information. Clearly I need to set up ldapsearch to authenticate with Samba AD. Hopefully you can just point me to some documentation now that I have (hopefully) less ambiguously explained myself. - John On 4/25/23 16:00, Rowland Penny via samba wrote:> > > On 25/04/2023 20:22, John R. Graham via samba wrote: >> Is there a guide somewhere that explains the process of getting >> openldap (the ldapsearch tool for starters) to authenticate against a >> Samba AD server? On my Linux client, I can run >> >> ???? ldapsearch -LLL -x -b '' -s base '(objectClass=*)' >> >> and get a detailed response from the server. Somewhat obfuscated, >> that response is: >> >> dn: >> configurationNamingContext: >> CN=Configuration,DC=myrealm,DC=example,DC=com >> defaultNamingContext: DC=myrealm,DC=example,DC=com >> rootDomainNamingContext: DC=myrealm,DC=example,DC=com >> schemaNamingContext: >> CN=Schema,CN=Configuration,DC=myrealm,DC=example,DC=org >> subschemaSubentry: >> CN=Aggregate,CN=Schema,CN=Configuration,DC=myrealm,DC=example, >> ??DC=com >> supportedCapabilities: 1.2.840.113556.1.4.800 >> supportedCapabilities: 1.2.840.113556.1.4.1670 >> supportedCapabilities: 1.2.840.113556.1.4.1791 >> supportedCapabilities: 1.2.840.113556.1.4.1935 >> supportedCapabilities: 1.2.840.113556.1.4.2080 >> supportedLDAPVersion: 2 >> supportedLDAPVersion: 3 >> vendorName: Samba Team (https://www.samba.org) >> isSynchronized: TRUE >> dsServiceName: CN=NTDS >> Settings,CN=DC1,CN=Servers,CN=Default-First-Site-Name >> ??,CN=Sites,CN=Configuration,DC=myrealm,DC=example,DC=com >> serverName: >> CN=DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configu >> ??ration,DC=myrealm,DC=example,DC=com >> dnsHostName: dc1.myrealm.example.com >> ldapServiceName: myrealm.example.com:dc1$@MYREALM.EXAMPLE.COM >> currentTime: 20230425172943.0Z >> supportedControl: 1.2.840.113556.1.4.1413 >> supportedControl: 1.2.840.113556.1.4.1413 >> supportedControl: 1.2.840.113556.1.4.1413 >> supportedControl: 1.2.840.113556.1.4.1413 >> supportedControl: 1.2.840.113556.1.4.1413 >> supportedControl: 1.2.840.113556.1.4.528 >> supportedControl: 1.2.840.113556.1.4.841 >> supportedControl: 1.2.840.113556.1.4.319 >> supportedControl: 2.16.840.1.113730.3.4.9 >> supportedControl: 1.2.840.113556.1.4.473 >> supportedControl: 1.2.840.113556.1.4.1504 >> supportedControl: 1.2.840.113556.1.4.801 >> supportedControl: 1.2.840.113556.1.4.801 >> supportedControl: 1.2.840.113556.1.4.805 >> supportedControl: 1.2.840.113556.1.4.1338 >> supportedControl: 1.2.840.113556.1.4.529 >> supportedControl: 1.2.840.113556.1.4.417 >> supportedControl: 1.2.840.113556.1.4.2064 >> supportedControl: 1.2.840.113556.1.4.1339 >> supportedControl: 1.2.840.113556.1.4.1340 >> supportedControl: 1.2.840.113556.1.4.1413 >> supportedControl: 1.2.840.113556.1.4.1341 >> namingContexts: DC=myrealm,DC=example,DC=com >> namingContexts: CN=Configuration,DC=myrealm,DC=example,DC=com >> namingContexts: CN=Schema,CN=Configuration,DC=myrealm,DC=example,DC=com >> namingContexts: DC=DomainDnsZones,DC=myrealm,DC=example,DC=com >> namingContexts: DC=ForestDnsZones,DC=myrealm,DC=example,DC=com >> supportedSASLMechanisms: GSS-SPNEGO >> supportedSASLMechanisms: GSSAPI >> supportedSASLMechanisms: NTLM >> highestCommittedUSN: 6034 >> domainFunctionality: 4 >> forestFunctionality: 4 >> domainControllerFunctionality: 4 >> isGlobalCatalogReady: TRUE >> >> But almost any other query results in >> >> ???? Operations error (1) >> ???? Additional information: 00002020: Operation unavailable without >> authentication >> >> Surely I'm missing a pre-existing guide somewhere. > > Yes, you are missing that, unlike openldap, AD ldap requires > authentication for most searches. Sorry but you are going to have to > authenticate. > > Can I ask just what the openldap server is used for ? You may just > find it easier to extend the AD schema instead. > > Rowland > > >
Rowland Penny
2023-Apr-25 21:10 UTC
[Samba] Configuring Linux openldap ldapsearch client-side tool to authenticate against a Samba AD server
On 25/04/2023 21:40, John R. Graham via samba wrote:> Hi, Rowland. There is no openldap server. I'm working on achieving > single sign on for both Linux and Windows machines against a new Samba > AD server. I'm not against authenticating; I'm just ignorant on how to > go about that. Single sign on is, I understand, provided "out of the > box" for Windows clients once the AD server is properly set up. The > eventual goal on the Linux side would be to use pam_ldap or SSSD to > communicate with the Samba AD LDAP server to achieve the same thing. My > initial thought was to do this /without/ installing the Samba client > side tools on every Linux box. If that's a bad decision, please feel > free to wave me off. > > In trying to get things working incrementally, I was trying to use the > openldap-provided ldapsearch tool to query Samba AD for user > information. Clearly I need to set up ldapsearch to authenticate with > Samba AD. Hopefully you can just point me to some documentation now that > I have (hopefully) less ambiguously explained myself. > > - John > >I still don't fully understand just what you are trying to achieve, to get any method to work, your Linux machine really needs to join the domain. If you don't require shares, don't run the Samba smbd daemon, just run winbind. The problem is mapping AD users as Linux users, by using winbind you make the AD users appear as Linux users without creating them on the Linux box. If you do use the Samba tools, you can install the ldb tools (ldbsearch etc), these can use the machine password for most searches. Rowland