Sign in with
Sign up | Sign in
Your question

AD object security settings getting erased

Tags:
Last response: in Windows 2000/NT
Share
Anonymous
January 16, 2005 1:06:17 AM

Archived from groups: microsoft.public.win2000.active_directory (More info?)

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: -
Anonymous
January 16, 2005 3:46:48 AM

Archived from groups: microsoft.public.win2000.active_directory (More info?)

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: -
>
>
>
>
>
Anonymous
January 16, 2005 10:19:49 PM

Archived from groups: microsoft.public.win2000.active_directory (More info?)

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: -
>>
>>
>>
>>
Related resources
Anonymous
January 17, 2005 1:57:33 AM

Archived from groups: microsoft.public.win2000.active_directory (More info?)

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: -
>>>
>>>
>>>
>>>
>
>
Anonymous
January 17, 2005 3:35:18 PM

Archived from groups: microsoft.public.win2000.active_directory (More info?)

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: -
>>>>
>>>>
>>>>
>>>>
>>
Anonymous
January 17, 2005 4:06:00 PM

Archived from groups: microsoft.public.win2000.active_directory (More info?)

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:o h2zXrL$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: -
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>
Anonymous
January 17, 2005 4:16:57 PM

Archived from groups: microsoft.public.win2000.active_directory (More info?)

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

--
Joe Richards Microsoft MVP Windows Server Directory Services
www.joeware.net


Brian Higgins wrote:
> 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:o h2zXrL$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: -
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>
>
>
Anonymous
January 19, 2005 1:52:28 PM

Archived from groups: microsoft.public.win2000.active_directory (More info?)

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.


"Joe Richards [MVP]" <humorexpress@hotmail.com> wrote in message
news:%23MAU8CM$EHA.600@TK2MSFTNGP09.phx.gbl...
> 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
>
> --
> Joe Richards Microsoft MVP Windows Server Directory Services
> www.joeware.net
>
>
> Brian Higgins wrote:
>> 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:o h2zXrL$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: -
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>
Anonymous
January 20, 2005 2:55:54 AM

Archived from groups: microsoft.public.win2000.active_directory (More info?)

Ah, I have never looked at SBS. It is possible this group is also covered by
that that rule.

joe

--
Joe Richards Microsoft MVP Windows Server Directory Services
www.joeware.net


Brian Higgins wrote:
> 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.
>
>
> "Joe Richards [MVP]" <humorexpress@hotmail.com> wrote in message
> news:%23MAU8CM$EHA.600@TK2MSFTNGP09.phx.gbl...
>
>>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
>>
>>--
>>Joe Richards Microsoft MVP Windows Server Directory Services
>>www.joeware.net
>>
>>
>>Brian Higgins wrote:
>>
>>>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:o h2zXrL$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: -
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>
Anonymous
January 20, 2005 7:23:50 PM

Archived from groups: microsoft.public.win2000.active_directory (More info?)

how would i go about checking to see if that's the case?


"Joe Richards [MVP]" <humorexpress@hotmail.com> wrote in message
news:u91FTxq$EHA.1908@TK2MSFTNGP15.phx.gbl...
> Ah, I have never looked at SBS. It is possible this group is also covered
> by that that rule.
>
> joe
>
> --
> Joe Richards Microsoft MVP Windows Server Directory Services
> www.joeware.net
>
>
> Brian Higgins wrote:
>> 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.
>>
>>
>> "Joe Richards [MVP]" <humorexpress@hotmail.com> wrote in message
>> news:%23MAU8CM$EHA.600@TK2MSFTNGP09.phx.gbl...
>>
>>>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
>>>
>>>--
>>>Joe Richards Microsoft MVP Windows Server Directory Services
>>>www.joeware.net
>>>
>>>
>>>Brian Higgins wrote:
>>>
>>>>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:o h2zXrL$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: -
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>
Anonymous
January 23, 2005 6:10:46 PM

Archived from groups: microsoft.public.win2000.active_directory (More info?)

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

--
Joe Richards Microsoft MVP Windows Server Directory Services
www.joeware.net


Brian Higgins wrote:
> how would i go about checking to see if that's the case?
>
>
> "Joe Richards [MVP]" <humorexpress@hotmail.com> wrote in message
> news:u91FTxq$EHA.1908@TK2MSFTNGP15.phx.gbl...
>
>>Ah, I have never looked at SBS. It is possible this group is also covered
>>by that that rule.
>>
>> joe
>>
>>--
>>Joe Richards Microsoft MVP Windows Server Directory Services
>>www.joeware.net
>>
>>
>>Brian Higgins wrote:
>>
>>>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.
>>>
>>>
>>>"Joe Richards [MVP]" <humorexpress@hotmail.com> wrote in message
>>>news:%23MAU8CM$EHA.600@TK2MSFTNGP09.phx.gbl...
>>>
>>>
>>>>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
>>>>
>>>>--
>>>>Joe Richards Microsoft MVP Windows Server Directory Services
>>>>www.joeware.net
>>>>
>>>>
>>>>Brian Higgins wrote:
>>>>
>>>>
>>>>>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:o h2zXrL$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: -
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>
>
!