AD object security settings getting erased

  • Thread starter Thread starter Brian Higgins
  • Start date Start date
B

Brian Higgins

I have an application that was wrote in-house, that stores information
pertaining to the user account in one of the 15 Exchange Extenstion
Attributes in AD (for lack of a better place in AD to store the values).
This app has been tested on 3 different domains and everything works just
fine, once SELF is granted Write Public Information permission from within
ADSI Edit for the user account.

I have installed the app on a new domain (fresh SBS2003 Network) and I have
given the 2 accounts the Write Public Information permission. The setting
works, for about 25 minutes, after which time the SELF account then shows no
security set on any of the properties that should have allow permissions
set.

I have re-set the permissions on the 2 user accounts numerous times, and
every time I do, after 25min, the user loses all permisson for their own
account. An event 642 is logged both when setting the permissions, and when
the permissions get reset to blank, and an event 684 is logged immeaditly
after the 642 when the account gets reset.

The 684 indicates that it has something to do with domain administrative
rights(being set by an anonymous logon??), but these user accounts only have
power user rights, and local admin rights on the workstations they regularly
use.

When setting the permissions, the event ID is as follows:

Event Type: Success Audit
Event Source: Security
Event Category: Account Management
Event ID: 642
Date: 1/15/2005
Time: 3:38:06 PM
User: DOMAIN\administrator
Computer: SERVER
Description:
User Account Changed:
Target Account Name: user
Target Domain: DOMAIN
Target Account ID: DOMAIN\user
Caller User Name: administrator
Caller Domain: DOMAIN
Caller Logon ID: (0x0,0x442B0)
Privileges: -
Changed Attributes:
Sam Account Name: -
Display Name: -
User Principal Name: -
Home Directory: -
Home Drive: -
Script Path: -
Profile Path: -
User Workstations: -
Password Last Set: -
Account Expires: -
Primary Group ID: -
AllowedToDelegateTo: -
Old UAC Value: -
New UAC Value: -
User Account Control: -
User Parameters: -
Sid History: -
Logon Hours: -

When the account gets reset, the Event IDs are:

Event Type: Success Audit
Event Source: Security
Event Category: Account Management
Event ID: 642
Date: 1/15/2005
Time: 4:05:07 PM
User: NT AUTHORITY\ANONYMOUS LOGON
Computer: SERVER
Description:
User Account Changed:
Target Account Name: user
Target Domain: DOMAIN
Target Account ID: DOMAIN\user
Caller User Name: SERVER$
Caller Domain: DOMAIN
Caller Logon ID: (0x0,0x3E7)
Privileges: -
Changed Attributes:
Sam Account Name: -
Display Name: -
User Principal Name: -
Home Directory: -
Home Drive: -
Script Path: -
Profile Path: -
User Workstations: -
Password Last Set: -
Account Expires: -
Primary Group ID: -
AllowedToDelegateTo: -
Old UAC Value: -
New UAC Value: -
User Account Control: -
User Parameters: -
Sid History: -
Logon Hours: -


Event Type: Success Audit
Event Source: Security
Event Category: Account Management
Event ID: 684
Date: 1/15/2005
Time: 4:05:07 PM
User: NT AUTHORITY\ANONYMOUS LOGON
Computer: SERVER
Description:
Set ACLs of members in administrators groups:
Target Account Name: user
Target Domain: DC=DOMAIN,DC=LOCAL
Target Account ID: DOMAIN\user
Caller User Name: SERVER$
Caller Domain: DOMAIN
Caller Logon ID: (0x0,0x3E7)
Privileges: -
 
Read up on adminSDHolder functionality.

Additionally, you really don't want to give normal users Write Public
Information. It is a security risk and if you are running Exchange things can be
really bad up to and including the person being able to slam your Exchange
servers to a stop. Someone who had Write Public Information has write access to:

allowedAttributes
allowedAttributesEffective
allowedChildClasses
allowedChildClassesEffective
altRecipient
altRecipientBL
altSecurityIdentities
attributeCertificate
authOrig
authOrigBL
autoReply
autoReplyMessage
cn
co
company
deletedItemFlags
delivContLength
deliverAndRedirect
deliveryMechanism
delivExtContTypes
department
description
directReports
displayNamePrintable
distinguishedName
division
dLMemberRule
dLMemDefault
dLMemRejectPerms
dLMemRejectPermsBL
dLMemSubmitPerms
dLMemSubmitPermsBL
dnQualifier
enabledProtocols
expirationTime
extensionAttribute1
extensionAttribute10
extensionAttribute11
extensionAttribute12
extensionAttribute13
extensionAttribute14
extensionAttribute15
extensionAttribute2
extensionAttribute3
extensionAttribute4
extensionAttribute5
extensionAttribute6
extensionAttribute7
extensionAttribute8
extensionAttribute9
extensionData
folderPathname
formData
forwardingAddress
givenName
heuristics
hideDLMembership
homeMDB
homeMTA
importedFrom
initials
internetEncoding
kMServer
language
languageCode
legacyExchangeDN
mail
mailNickname
manager
mAPIRecipient
mDBOverHardQuotaLimit
mDBOverQuotaLimit
mDBStorageQuota
mDBUseDefaults
msDS-AllowedToDelegateTo
msDS-Approx-Immed-Subordinates
msDS-Auxiliary-Classes
msExchADCGlobalNames
msExchALObjectVersion
msExchAssistantName
msExchConferenceMailboxBL
msExchControllingZone
msExchCustomProxyAddresses
msExchExpansionServerName
msExchFBURL
msExchHideFromAddressLists
msExchHomeServerName
msExchIMACL
msExchIMAddress
msExchIMAPOWAURLPrefixOverride
msExchIMMetaPhysicalURL
msExchIMPhysicalURL
msExchIMVirtualServer
msExchInconsistentState
msExchLabeledURI
msExchMailboxFolderSet
msExchMailboxGuid
msExchMailboxSecurityDescriptor
msExchMailboxUrl
msExchMasterAccountSid
msExchOmaAdminExtendedSettings
msExchOmaAdminWirelessEnable
msExchOriginatingForest
msExchPfRootUrl
msExchPFTreeType
msExchPoliciesExcluded
msExchPoliciesIncluded
msExchPolicyEnabled
msExchPolicyOptionList
msExchPreviousAccountSid
msExchProxyCustomProxy
msExchQueryBaseDN
msExchRecipLimit
msExchRequireAuthToSendTo
msExchResourceGUID
msExchResourceProperties
msExchTUIPassword
msExchTUISpeed
msExchTUIVolume
msExchUnmergedAttsPt
msExchUseOAB
msExchUserAccountControl
msExchVoiceMailboxID
name
notes
o
objectCategory
objectClass
objectGUID
oOFReplyToOriginator
otherMailbox
ou
pOPCharacterSet
pOPContentFormat
protocolSettings
proxyAddresses
publicDelegatesBL
replicatedObjectVersion
replicationSensitivity
replicationSignature
reportToOriginator
reportToOwner
securityProtocol
servicePrincipalName
showInAddressBook
sn
submissionContLength
supportedAlgorithms
systemFlags
targetAddress
telephoneAssistant
textEncodedORAddress
title
unauthOrig
unauthOrigBL
unmergedAtts
userPrincipalName



That is a lot of access to allow writing to one attribute. By default every user
should by default have access to right to personal information, that includes
the following attribs:

assistant
c
facsimileTelephoneNumber
homePhone
homePostalAddress
info
internationalISDNNumber
ipPhone
l
mobile
mSMQDigests
mSMQSignCertificates
otherFacsimileTelephoneNumber
otherHomePhone
otherIpPhone
otherMobile
otherPager
otherTelephone
pager
personalTitle
physicalDeliveryOfficeName
postalAddress
postalCode
postOfficeBox
preferredDeliveryMethod
primaryInternationalISDNNumber
primaryTelexNumber
publicDelegates
registeredAddress
st
street
streetAddress
telephoneNumber
teletexTerminalIdentifier
telexNumber
thumbnailPhoto
userCert
userCertificate
userSharedFolder
userSharedFolderOther
userSMIMECertificate
x121Address


You could probably use info (aka comment) for what you need to do. However, you
have several 2.5.5.12 type attributes in that set that you could probably use
that isn't already in use in your environment. Of course you could always add an
attribute as well. Anyway the other 2.5.5.12 that the user should already have
access to are:

c
facsimileTelephoneNumber
homePhone
homePostalAddress
info
ipPhone
l
mobile
otherFacsimileTelephoneNumber
otherHomePhone
otherIpPhone
otherMobile
otherPager
otherTelephone
pager
personalTitle
physicalDeliveryOfficeName
postalAddress
postalCode
postOfficeBox
primaryInternationalISDNNumber
primaryTelexNumber
st
street
streetAddress
telephoneNumber
userSharedFolder
userSharedFolderOther



Out of curiosity, what kind of info are you inserting into AD and at what frequency?

joe
 
hmm.. I'll take a look at utilizing one of the other properties tomorrow,
and then going and removing the added permissions from these accounts..

In some of our clients enviroments there are lots of roaming between
computers for some users, and the users are often as not, very computer
illiterate.

We have a small app that checks what the current default printer is set to
every time the user logs off (99% of all printers are network based in these
cases), and stores the string value in the user properties in AD, then the
logon script reads that value when they logon and sets the default printer
(as well as mapping all printers the user has print permission to in their
OU, and any downlevel OU's under them.)

I'm also looking into a way to store the html for their signature file for
outlook so that it doesn't get lost or reset when they switch computers, or
if their computer gets moved or replaced. If anyone knows where OWA 2003
stores the signature that would be great, as I will write a script to keep
them in sync...

do you have any reccomendations as to which properties would be best suited
for storing the printer information, as well as signature info?

As usefull as that info is, it still never addressed the problem I'm seeing
on this system...

Thanks,

Brian
 
Recheck the first line of my post... Your problem is almost certainly the
adminSDHolder functionality. Read up on it, there is now a ton written about it
as well as probably many many posts from me in the various groups going back a
couple of years.

Honestly I would probably throw in a new attribute(s) for this. That way you
don't worry about stomping something already there or MS coming by later and
stomping it with something.

As for where OWA puts that signature. I am not positive but I would be extremely
expectant that the signature is stored in the mailbox as a MAPI property. There
is nothing you can do with AD to get that info. You should go look into the
various MAPI viewing tools that are out there to see if you can find it and then
possibly you will find a script to grab it or update it.

joe
 
I suspect you are right with this being related to the adminSDHolder
functionality, but i don't understand how. according to the article you
pointed me towards, this only applies to users in the following
groups/accounts:

BUILTIN\Administrators
IFRPILOT\Enterprise Admins
FAA\Domain Admins
NT AUTHORITY\SYSTEM
BUILTIN\Pre-Windows 2000 Compatible Access

the user accounts that i'm having this problem with do not fall under any of
these groups. They are in the Domain Power Users security group.

also, do you have any reccomendations as to what the best way to go about
adding a new attribute in to AD? never done it before and am not quite sure
where to start...

Brian
 
while reading the Admin console on PC thread, something occured to me...

these 2 accounts that keep getting their security reset do not have the
inherrit settings option checked(I must have un-checked it on accident late
at night when setting up these accounts)... could this be a bug in the
adminSDHolder object that is causing this because the inherrit security
option is not checked, yet these 2 accounts do not belong to any of the
groups that it is designed to replicate the security settings to, so it goes
and applies a security setting policy of blank settings as a result?
 
First off, there is no Domain Power Users group. That would be some group you
established.

As for the rest, nope, if you don't inherit security it won't fire up
adminSDHolder. However, if it is unchecked, you can't get any permissions from
above, what they have is what they will always have unless you specifically
change it. Check the inherit box, if it unchecks later, again you have to look
at adminSDHolder. Also if you look at admincount and it has any value other than
0 or empty, adminSDHolder is hitting you.

There are more groups that are impacted by adminSDHolder, its functionality has
expanded to servops and accops and others. Keep digging.

joe
 
In this case it is SBS 2003 so there is a pre-defined Domain Power User
group. The adminCount value is 1 on both of these accounts. Right after
making the last post I changed the setting back to inherit from above, and
reset permissions on the user object. when I checked it a short time ago, I
noticed that the SELF security settings had been reset back to blank, save
one setting, the Change Password field.

I have checked to see if the user accounts are part of any Distribution list
that is a member of any security groups
(http://support.microsoft.com/kb/318180) and have found no reason that the
adminSDHolder object should ever be interacting with these user accounts.
 
Ah, I have never looked at SBS. It is possible this group is also covered by
that that rule.

joe
 
Test it.

Have a user who isn't in any admin group. Verify that adminSDHolder isn't
tagging them, then add the user to that group. See if adminSDHolder now starts
affecting them.

If you are asking how to verify with MS, you can try and dig through every KB
article and MSDN document that mentioned adminSDHolder or open a ticket with PSS.

joe
 
Back
Top