Re: AD object security settings getting erased
From: Brian Higgins (brian_at_-NO-accentconsulting-SPAM-.com)
Date: 01/17/05
- Next message: Brian Higgins: "Re: Multiple logon scripts assigned with Active Directory"
- Previous message: Mike_68: "Re: dcpromo /forceremoval does not work"
- In reply to: Brian Higgins: "Re: AD object security settings getting erased"
- Next in thread: Joe Richards [MVP]: "Re: AD object security settings getting erased"
- Reply: Joe Richards [MVP]: "Re: AD object security settings getting erased"
- Messages sorted by: [ date ] [ thread ]
Date: Mon, 17 Jan 2005 13:06:00 -0500
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?
"Brian Higgins" <brian@-NO-accentconsulting-SPAM-.com> wrote in message
news:Oh2zXrL$EHA.3700@tk2msftngp13.phx.gbl...
>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
>
>
> "Joe Richards [MVP]" <humorexpress@hotmail.com> wrote in message
> news:e2GruiE$EHA.4004@tk2msftngp13.phx.gbl...
>> 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
>>
>> --
>> Joe Richards Microsoft MVP Windows Server Directory Services
>> www.joeware.net
>>
>>
>> Brian Higgins wrote:
>>> 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
>>>
>>> "Joe Richards [MVP]" <humorexpress@hotmail.com> wrote in message
>>> news:%23pn5$64%23EHA.2700@TK2MSFTNGP14.phx.gbl...
>>>
>>>>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
>>>>
>>>>--
>>>>Joe Richards Microsoft MVP Windows Server Directory Services
>>>>www.joeware.net
>>>>
>>>>
>>>>Brian Higgins wrote:
>>>>
>>>>>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: -
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>
- Next message: Brian Higgins: "Re: Multiple logon scripts assigned with Active Directory"
- Previous message: Mike_68: "Re: dcpromo /forceremoval does not work"
- In reply to: Brian Higgins: "Re: AD object security settings getting erased"
- Next in thread: Joe Richards [MVP]: "Re: AD object security settings getting erased"
- Reply: Joe Richards [MVP]: "Re: AD object security settings getting erased"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
