[Samba] Samba ADS-member-server: FQDNs in /etc/hosts

[Stefan G. Weichinger]

Am 2017-07-12 um 09:20 schrieb Rowland Penny via samba:

> Probably, but for a user to become administrator is strange, is the
> user mapped to Administrator in a user map on the samba machine ?
> What uidNumber does the user have ?
> You could try examining the users object in AD to see if anything
> looks strange.

Here the "net ads sid" for both the user and administrator:


# net ads sid  S-1-5-21-2940660672-4062535256-4144655499-1037
Got 1 replies

cn: secretuser1
instanceType: 4
whenCreated: 20170524093910.0Z
uSNCreated: 4226
name: secretuser1
objectGUID: 0e4824a0-5e00-4ef2-9b46-cc0e252e4bcd
badPwdCount: 0
codePage: 0
countryCode: 0
badPasswordTime: 0
primaryGroupID: 513
objectSid: S-1-5-21-2940660672-4062535256-4144655499-1037
sAMAccountName: secretuser1
sAMAccountType: 805306368
objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=secret,DC=at
pwdLastSet: 131030223020000000
scriptPath: secretuser1.bat
accountExpires: 137303967990000000
lastLogoff: 137303967990000000
userAccountControl: 512
uidNumber: 1078
objectClass: top
objectClass: posixAccount
objectClass: person
objectClass: organizationalPerson
objectClass: user
unixHomeDirectory: /home/secretuser1
loginShell: /bin/false
gidNumber: 1078
msSFU30NisDomain: buero
lastLogonTimestamp: 131439237943973860
whenChanged: 20170707175634.0Z
uSNChanged: 6514
memberOf: CN=Mitarbeiter,OU=secret-Benutzer,DC=secret,DC=at
lastLogon: 131443178892048320
logonCount: 83
distinguishedName: CN=secretuser1,OU=secret-Benutzer,DC=secret,DC=at


# net ads sid  S-1-5-21-2940660672-4062535256-4144655499-500
Got 1 replies

objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: user
cn: Administrator
description: Built-in account for administering the computer/domain
instanceType: 4
whenCreated: 20170524093903.0Z
uSNCreated: 3545
name: Administrator
objectGUID: e5e2f6f8-daae-486c-9f54-2ffdde54c80c
userAccountControl: 512
badPwdCount: 0
codePage: 0
countryCode: 0
badPasswordTime: 0
lastLogoff: 0
primaryGroupID: 513
objectSid: S-1-5-21-2940660672-4062535256-4144655499-500
adminCount: 1
accountExpires: 9223372036854775807
sAMAccountName: Administrator
sAMAccountType: 805306368
objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=secret,DC=at
isCriticalSystemObject: TRUE
pwdLastSet: 131249708910000000
memberOf: CN=Administrators,CN=Builtin,DC=secret,DC=at
memberOf: CN=Group Policy Creator Owners,OU=secret-Benutzer,DC=secret,DC=at
memberOf: CN=Enterprise Admins,OU=secret-Benutzer,DC=secret,DC=at
memberOf: CN=Schema Admins,OU=secret-Benutzer,DC=secret,DC=at
memberOf: CN=Domain Admins,OU=secret-Benutzer,DC=secret,DC=at
lastLogonTimestamp: 131436332965480820
whenChanged: 20170704091456.0Z
uSNChanged: 5433
lastLogon: 131443181309822480
logonCount: 181
distinguishedName: CN=Administrator,OU=secret-Benutzer,DC=secret,DC=at


>>> NOTE: old (due to rename or delete) DN string component for
>>> lastKnownParent in object
>>> CN=Machine\0ADEL:f4336c47-c82e-477e-a5b6-fe7bf24ac07e,CN=Deleted
>>> Objects,DC=secret,DC=at -
>>> <GUID=f1278d7d-87c4-47b7-adf5-663d457026db>;CN={B21C7A4C-E611-460F-BC81-1BBDEC8C9053},CN=Policies,CN=System,DC=secret,DC=at
>>> Not fixing old string component
>>> Checked 445 objects (0 errors)
>>
>> Do I have to fix that? how?
> 
> Short answer: No, cannot
> Long answer: No, because they are deleted objects and will eventually
> go away (after 180 days)

cool. understood.