Thamm, Russell
2019-Jun-25 07:22 UTC
[Samba] Error determinigng PSOs in system [SEC=UNOFFICIAL]
UNOFFICIAL Thanks Tim, I was just wondering if my mistake was raising the functional-level. This confirms it. This apparently also broke backup. I cannot create the container, because the current schema (2003) doesn't support msDS-PasswordSettingsContainer. It seems impossible (and dangerous) to update the schema. I was given a reference to a thread about updating the schema but - the thread didn't contain the actual ldf files - the thread seemed to be an upgrade from 2003 R2 and I just have 2003. Is it possible to lower the level again? I can revert to the state that existed before demoting Julius. I'm thinking that this is the best course if I can't undo raising the level. Cheers Russell -----Original Message----- From: Tim Beale [mailto:timbeale at catalyst.net.nz] Sent: Tuesday, 25 June, 2019 9:13 a.m. To: Andrew Bartlett; Thamm, Russell; sambalist Subject: Re: [Samba] Error determinigng PSOs in system [SEC=UNOFFICIAL] On 24/06/19 9:00 PM, Andrew Bartlett wrote:> On Mon, 2019-06-24 at 07:12 +0000, Thamm, Russell via samba wrote: >> The domain seems stable until I tried LDAP authentication which >> fails. >> >> The samba log says: >> >> Error 32 determining PSOs in system. >> >> I can't seem to find anything on this error. >> >> Any idea how I fix this? > sorry about that. The issue is that Samba expects a container for > PSOs, but that is a newer AD feature and your 2003 server never > created it. > > the container is: > CN=Password Settings Container,CN=System,$DOMAIN_DN > > The code should cope with 32 (no such object) as very good proof there > are no PSOs. > > This isn't an issue upgrading pure Samba domains (everything since > before 4.0.0 has this) but windows of course is older. > > Options include fixing the code (please file a bug and hopefully Tim > can look at it) and creating the missing container. The template > Samba uses is pretty simple: > > +dn: CN=Password Settings Container,CN=System,${DOMAINDN} > +objectClass: top > +objectClass: msDS-PasswordSettingsContainer > +systemFlags: -1946157056 > + > > The final option is to use a Samba version from before PSOs were > implemented, which would be 4.8 I think, but that isn't a long-term > option. > >I've raised a bug for this: https://bugzilla.samba.org/show_bug.cgi?id=14008 and I'm just working on a fix. Creating the Password Settings Container manually is probably the simplest workaround in the meantime. Just a note to others: I think this problem only occurs if the domain DB was created based on a pre-2008 schema, and then you later manually raise the functional-level to 2008 or greater.
Tim Beale
2019-Jun-26 01:42 UTC
[Samba] Error determinigng PSOs in system [SEC=UNOFFICIAL]
Hi Russell, Ah, right, of course you can't create the msDS-PasswordSettingsContainer object on a 2003 schema. The code doesn't actually care what type of object the Password Settings Container is as long as it exists. So the simplest short-term kludge to get back to a working AD would be to create the PSO container as an object that does exist in your schema, e.g. ldbadd -H /usr/local/samba/private/sam.ldb dn: CN=Password Settings Container,CN=System,DC=addom,DC=samba,DC=example,DC=com objectClass: container This is a major kludge to the DB and so please delete this object as soon as you can, otherwise it will cause major support problems going forward. The better short/medium-term solution would be to roll your functional level back. Unfortunately the 'samba-tool domain level' command doesn't support going backwards. However, the functional-level is just an integer in the database (msDS-Behavior-Version) that you can modify. The functional-level value for 2003 is '2' - you can see the possible values here: https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/d7422d35-448a-451a-8846-6a7def0044df There are several objects that have this attribute. E.g. ldbsearch -H st/ad_dc/private/sam.ldb? '(msDS-Behavior-Version=*)' msDS-Behavior-Version --cross-ncs # record 1 dn: CN=ADDOMAIN,CN=Partitions,CN=Configuration,DC=addom,DC=samba,DC=example,DC=com msDS-Behavior-Version: 3 # record 2 dn: CN=NTDS Settings,CN=ADDC,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=addom,DC=samba,DC=example,DC=com msDS-Behavior-Version: 4 # record 3 dn: CN=Partitions,CN=Configuration,DC=addom,DC=samba,DC=example,DC=com msDS-Behavior-Version: 3 # record 4 dn: DC=addom,DC=samba,DC=example,DC=com msDS-Behavior-Version: 3 The PSO code is checking the base-domain object (i.e. record 4). The 'samba-tool domain level raise --domain-level' command also updates the domain crossRef object (record 1). --forest-level updates the CN=Partitions object (record3). To edit these objects manually, you could use something like the following (and just don't alter the objects you don't want to modify). ldbedit -H /usr/local/samba/private/sam.ldb? '(msDS-Behavior-Version=*)' msDS-Behavior-Version --cross-ncs Note that after changing the functional-level, you'll need to restart samba for this to take effect on things like LDAP authentication. Finally, longer-term you'd need to find a way to upgrade your schema from 2003 to 2008R2. I don't think there's any support for this in Samba currently. I'm not sure if anyone else on the list has had experience doing this. Cheers, Tim On 25/06/19 7:22 PM, Thamm, Russell wrote:> UNOFFICIAL > > Thanks Tim, > > I was just wondering if my mistake was raising the functional-level. This confirms it. > > This apparently also broke backup. > > I cannot create the container, because the current schema (2003) doesn't support msDS-PasswordSettingsContainer. > > It seems impossible (and dangerous) to update the schema. > > I was given a reference to a thread about updating the schema but > - the thread didn't contain the actual ldf files > - the thread seemed to be an upgrade from 2003 R2 and I just have 2003. > > Is it possible to lower the level again? > > I can revert to the state that existed before demoting Julius. I'm thinking that this is the best course if I can't undo raising the level. > > Cheers > Russell > > > -----Original Message----- > From: Tim Beale [mailto:timbeale at catalyst.net.nz] > Sent: Tuesday, 25 June, 2019 9:13 a.m. > To: Andrew Bartlett; Thamm, Russell; sambalist > Subject: Re: [Samba] Error determinigng PSOs in system [SEC=UNOFFICIAL] > > On 24/06/19 9:00 PM, Andrew Bartlett wrote: >> On Mon, 2019-06-24 at 07:12 +0000, Thamm, Russell via samba wrote: >>> The domain seems stable until I tried LDAP authentication which >>> fails. >>> >>> The samba log says: >>> >>> Error 32 determining PSOs in system. >>> >>> I can't seem to find anything on this error. >>> >>> Any idea how I fix this? >> sorry about that. The issue is that Samba expects a container for >> PSOs, but that is a newer AD feature and your 2003 server never >> created it. >> >> the container is: >> CN=Password Settings Container,CN=System,$DOMAIN_DN >> >> The code should cope with 32 (no such object) as very good proof there >> are no PSOs. >> >> This isn't an issue upgrading pure Samba domains (everything since >> before 4.0.0 has this) but windows of course is older. >> >> Options include fixing the code (please file a bug and hopefully Tim >> can look at it) and creating the missing container. The template >> Samba uses is pretty simple: >> >> +dn: CN=Password Settings Container,CN=System,${DOMAINDN} >> +objectClass: top >> +objectClass: msDS-PasswordSettingsContainer >> +systemFlags: -1946157056 >> + >> >> The final option is to use a Samba version from before PSOs were >> implemented, which would be 4.8 I think, but that isn't a long-term >> option. >> >> > I've raised a bug for this: > https://bugzilla.samba.org/show_bug.cgi?id=14008 and I'm just working on a fix. > > Creating the Password Settings Container manually is probably the simplest workaround in the meantime. > > Just a note to others: I think this problem only occurs if the domain DB was created based on a pre-2008 schema, and then you later manually raise the functional-level to 2008 or greater. >
Rowland penny
2019-Jun-26 06:56 UTC
[Samba] Error determinigng PSOs in system [SEC=UNOFFICIAL]
On 26/06/2019 02:42, Tim Beale via samba wrote:> Hi Russell, > > Ah, right, of course you can't create the msDS-PasswordSettingsContainer > object on a 2003 schema. > > The code doesn't actually care what type of object the Password Settings > Container is as long as it exists. So the simplest short-term kludge to > get back to a working AD would be to create the PSO container as an > object that does exist in your schema, e.g. > > ldbadd -H /usr/local/samba/private/sam.ldb > dn: CN=Password Settings > Container,CN=System,DC=addom,DC=samba,DC=example,DC=com > objectClass: container > > This is a major kludge to the DB and so please delete this object as > soon as you can, otherwise it will cause major support problems going > forward. > > The better short/medium-term solution would be to roll your functional > level back. Unfortunately the 'samba-tool domain level' command doesn't > support going backwards. However, the functional-level is just an > integer in the database (msDS-Behavior-Version) that you can modify. The > functional-level value for 2003 is '2' - you can see the possible values > here: > https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/d7422d35-448a-451a-8846-6a7def0044df > > There are several objects that have this attribute. E.g. > ldbsearch -H st/ad_dc/private/sam.ldb? '(msDS-Behavior-Version=*)' > msDS-Behavior-Version --cross-ncs > # record 1 > dn: > CN=ADDOMAIN,CN=Partitions,CN=Configuration,DC=addom,DC=samba,DC=example,DC=com > msDS-Behavior-Version: 3 > > # record 2 > dn: CN=NTDS > Settings,CN=ADDC,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=addom,DC=samba,DC=example,DC=com > msDS-Behavior-Version: 4 > > # record 3 > dn: CN=Partitions,CN=Configuration,DC=addom,DC=samba,DC=example,DC=com > msDS-Behavior-Version: 3 > > # record 4 > dn: DC=addom,DC=samba,DC=example,DC=com > msDS-Behavior-Version: 3 > > The PSO code is checking the base-domain object (i.e. record 4). The > 'samba-tool domain level raise --domain-level' command also updates the > domain crossRef object (record 1). --forest-level updates the > CN=Partitions object (record3). To edit these objects manually, you > could use something like the following (and just don't alter the objects > you don't want to modify). > ldbedit -H /usr/local/samba/private/sam.ldb? '(msDS-Behavior-Version=*)' > msDS-Behavior-Version --cross-ncs > > Note that after changing the functional-level, you'll need to restart > samba for this to take effect on things like LDAP authentication. > > Finally, longer-term you'd need to find a way to upgrade your schema > from 2003 to 2008R2. I don't think there's any support for this in Samba > currently. I'm not sure if anyone else on the list has had experience > doing this. > > Cheers, > Tim > > On 25/06/19 7:22 PM, Thamm, Russell wrote: >> UNOFFICIAL >> >> Thanks Tim, >> >> I was just wondering if my mistake was raising the functional-level. This confirms it. >> >> This apparently also broke backup. >> >> I cannot create the container, because the current schema (2003) doesn't support msDS-PasswordSettingsContainer. >> >> It seems impossible (and dangerous) to update the schema. >> >> I was given a reference to a thread about updating the schema but >> - the thread didn't contain the actual ldf files >> - the thread seemed to be an upgrade from 2003 R2 and I just have 2003. >> >> Is it possible to lower the level again? >> >> I can revert to the state that existed before demoting Julius. I'm thinking that this is the best course if I can't undo raising the level. >> >> Cheers >> Russell >> >> >> -----Original Message----- >> From: Tim Beale [mailto:timbeale at catalyst.net.nz] >> Sent: Tuesday, 25 June, 2019 9:13 a.m. >> To: Andrew Bartlett; Thamm, Russell; sambalist >> Subject: Re: [Samba] Error determinigng PSOs in system [SEC=UNOFFICIAL] >> >> On 24/06/19 9:00 PM, Andrew Bartlett wrote: >>> On Mon, 2019-06-24 at 07:12 +0000, Thamm, Russell via samba wrote: >>>> The domain seems stable until I tried LDAP authentication which >>>> fails. >>>> >>>> The samba log says: >>>> >>>> Error 32 determining PSOs in system. >>>> >>>> I can't seem to find anything on this error. >>>> >>>> Any idea how I fix this? >>> sorry about that. The issue is that Samba expects a container for >>> PSOs, but that is a newer AD feature and your 2003 server never >>> created it. >>> >>> the container is: >>> CN=Password Settings Container,CN=System,$DOMAIN_DN >>> >>> The code should cope with 32 (no such object) as very good proof there >>> are no PSOs. >>> >>> This isn't an issue upgrading pure Samba domains (everything since >>> before 4.0.0 has this) but windows of course is older. >>> >>> Options include fixing the code (please file a bug and hopefully Tim >>> can look at it) and creating the missing container. The template >>> Samba uses is pretty simple: >>> >>> +dn: CN=Password Settings Container,CN=System,${DOMAINDN} >>> +objectClass: top >>> +objectClass: msDS-PasswordSettingsContainer >>> +systemFlags: -1946157056 >>> + >>> >>> The final option is to use a Samba version from before PSOs were >>> implemented, which would be 4.8 I think, but that isn't a long-term >>> option. >>> >>> >> I've raised a bug for this: >> https://bugzilla.samba.org/show_bug.cgi?id=14008 and I'm just working on a fix. >> >> Creating the Password Settings Container manually is probably the simplest workaround in the meantime. >> >> Just a note to others: I think this problem only occurs if the domain DB was created based on a pre-2008 schema, and then you later manually raise the functional-level to 2008 or greater. >>This has been done before: https://lists.samba.org/archive/samba/2015-December/196883.html You will need the ldf files (which I have) Rowland