Computer Account Reset AD
Richard Smits
R.Smits at tudelft.nl
Tue Jul 13 10:07:19 EDT 2010
Richard Smits wrote:
>
> Douglas E. Engert wrote:
>>
>> Richard Smits wrote:
>>> Hello,
>>>
>>> We have a problem where we keep getting stuck when we try to find the
>>> answer. I hope someone on this list can give us tips or hints in the
>>> right direction.
>>>
>>> I will explain it below :
>>>
>>> We use Linux/Fedora clients with a nfs4/krb5 mount to a NetApp nashead.
>>> Our KDC is our Windows 2003/2008 AD.
>>>
>>> The problem i was first facing was to establish root access to this
>>> nashead. I found out that we had to create a root keytab.
>>>
>>> No problem there, but we installed a "management station" for creating
>>> users an other maintenance work. Then you are going to face the
>>> "expired ticket" problem.
>>>
>>> I solved it this way.
>>>
>>> In the crontab, every hour :
>>> /usr/kerberos/bin/kinit -l 300d -k root/hostname.domain.net at DOMAIN.NET
>>>
>>> 300 days does not work, but one week seems to work.
>>>
>>> klist
>>> Ticket cache: FILE:/tmp/krb5cc_0
>>> Default principal: root/hostname.domain.net at DOMAIN.NET
>>>
>>> Valid starting Expires Service principal
>>> 05/11/10 08:15:01 05/11/10 18:15:02 krbtgt/DOMAIN.NET at DOMAIN.NET
>>> renew until 05/18/10 08:15:01
>>> 05/11/10 08:20:01 05/11/10 18:15:02 srv005$@DOMAIN.NET
>>> renew until 05/18/10 08:15:01
>>>
>>> But now I will explain our problem.
>>>
>>> Every week (on the second) the computer object in the AD is reset.
>>> Why, we don't know. See logfile below :
>>>
>>> --------------------------------------------
>>> 27-4-2010 12:49:56 Security Success Audit Account
>>> Management 646 NT AUTHORITY\ANONYMOUS LOGON SRV005
>>> "Computer Account Changed:
>>> -
>>> Target Account Name: nasmgt$
>>> Target Domain: DASTUD
>>> Target Account ID: DOMAIN\nasmgt$
>>> Caller User Name: SRV005$
>>> Caller Domain: DASTUD
>>> 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: 4/27/2010 12:49:56 PM
>>> Account Expires: -
>>> Primary Group ID: -
>>> AllowedToDelegateTo: -
>>> Old UAC Value: -
>>> New UAC Value: -
>>> User Account Control: -
>>> User Parameters: -
>>> Sid History: -
>>> Logon Hours: -
>>> DNS Host Name: -
>>> Service Principal Names: -
>>> "
>>> 27-4-2010 12:49:56 Security Success Audit Account
>>> Management 646 NT AUTHORITY\ANONYMOUS LOGON SRV005
>>> "Computer Account Changed:
>>> -
>>> Target Account Name: nasmgt$
>>> Target Domain: DASTUD
>>> Target Account ID: DOMAIN\nasmgt$
>>> Caller User Name: SRV005$
>>> Caller Domain: DASTUD
>>> 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: 4/27/2010 12:49:56 PM
>>> Account Expires: -
>>> Primary Group ID: -
>>> AllowedToDelegateTo: -
>>> Old UAC Value: -
>>> New UAC Value: -
>>> User Account Control: -
>>> User Parameters: -
>>> Sid History: -
>>> Logon Hours: -
>>> DNS Host Name: -
>>> Service Principal Names: -
>>>
>>>
>>>
>>> Event Type: Success Audit
>>> Event Source: Security
>>> Event Category: Account Management
>>> Event ID: 646
>>> Date: 4-5-2010
>>> Time: 12:49:56
>>> User: NT AUTHORITY\ANONYMOUS LOGON
>>> Computer: SRV005
>>> Description:
>>> Computer Account Changed:
>>> -
>>> Target Account Name: nasmgt$
>>> Target Domain: DASTUD
>>> Target Account ID: DOMAIN\nasmgt$
>>> Caller User Name: SRV005$
>>> Caller Domain: DASTUD
>>> 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: 5/4/2010 12:49:56 PM
>>> Account Expires: -
>>> Primary Group ID: -
>>> AllowedToDelegateTo: -
>>> Old UAC Value: -
>>> New UAC Value: -
>>> User Account Control: -
>>> User Parameters: -
>>> Sid History: -
>>> Logon Hours: -
>>> DNS Host Name: -
>>> Service Principal Names: -
>>>
>>>
>>> For more information, see Help and Support Center at
>>> http://go.microsoft.com/fwlink/events.asp.
>>>
>>> --------------------
>>>
>>> Event Type: Success Audit
>>> Event Source: Security
>>> Event Category: Account Management
>>> Event ID: 646
>>> Date: 4-5-2010
>>> Time: 12:49:56
>>> User: NT AUTHORITY\ANONYMOUS LOGON
>>> Computer: SRV005
>>> Description:
>>> Computer Account Changed:
>>> -
>>> Target Account Name: nasmgt$
>>> Target Domain: DASTUD
>>> Target Account ID: DOMAIN\nasmgt$
>>> Caller User Name: SRV005$
>>> Caller Domain: DASTUD
>>> 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: 5/4/2010 12:49:56 PM
>>> Account Expires: -
>>> Primary Group ID: -
>>> AllowedToDelegateTo: -
>>> Old UAC Value: -
>>> New UAC Value: -
>>> User Account Control: -
>>> User Parameters: -
>>> Sid History: -
>>> Logon Hours: -
>>> DNS Host Name: -
>>> Service Principal Names: -
>>> ===================================
>>>
>>> As a result the KVNO (Key Version Number) AD attribute :
>>> msDS-KeyVersionNumber keeps changing and is getting higher and higher.
>>> We were at version 2. I rejoined the domain a few times and i am at
>>> version 6 now.
>>> See below.
>>>
>>> The problem is that I have to recreate a new keytab file because our
>>> clients are also using a nfs4/krb5 mount on another server.
>>>
>>> When the version is higher than local in the keytab, the krb5 security
>>> will not work anymore.
>>>
>>> I have talked to the Windows sysadmins and the say that the password for
>>> a computer object is changed every 30 days, but my experience is that
>>> the key is increased every seven days.
>> Looks like the SRV005 at DASTDU is changing the password.
>>
>> Are you using a single AD account for the machine and the root/host?
>>
>> What is SRV005$ is this the samAccountName of the machine's account?
>>
>> Is there a cron job or some NAS daemon that is changing it, and expecting
>> to change the host/fqdn at realm keys in the keytab at the same time?
>>
>> Did you do a setspn command to add root/hostname.domain.net at DOMAIN.NET
>> (What UPN and SPNs are on the account?)
>>
>> You may have been bit by AD using a single password per account which is
>> used to derive the keys on the fly for the UPN and all SPNs associated with
>> the account.
>>
>> Normally the /etc/krb5.keytab has host/fqdn at realm principals,and not a
>> root/fqdn at realm principals. Did you clobber the previous /etc/krb5.keytab
>> which may have had a host/fqdn at realm principal?
>>
>> You could consider separating using two the computer account one for root
>> and one for the machine. You may not need a root/fqdn at realm principal at
>> all. Look at ~.k5login and use kinit -k host/fqdn at realm
>>
>>> -----
>>> klist -k -e
>>> Keytab name: FILE:/etc/krb5.keytab
>>> KVNO Principal
>>> ----
>>> --------------------------------------------------------------------------
>>>
>>> 6 root/nasmgt.domain.net at DOMAIN.NET (DES cbc mode with CRC-32)
>>> 6 root/nasmgt.domain.net at DOMAIN.NET (DES cbc mode with RSA-MD5)
>>> 6 root/nasmgt.domain.net at DOMAIN.NET (ArcFour with HMAC/md5)
>>> 6 root/nasmgt at DOMAIN.NET (DES cbc mode with CRC-32)
>>> 6 root/nasmgt at DOMAIN.NET (DES cbc mode with RSA-MD5)
>>> 6 root/nasmgt at DOMAIN.NET (ArcFour with HMAC/md5)
>>>
>>> ----------------
>>> klist
>>> Ticket cache: FILE:/tmp/krb5cc_0
>>> Default principal: root/nasmgt.domain.net at DOMAIN.NET
>>>
>>> Valid starting Expires Service principal
>>> 04/21/10 12:15:01 04/21/10 22:15:01 krbtgt/DOMAIN.NET at DOMAIN.NET
>>> renew until 04/28/10 12:15:01
>>> 04/21/10 12:25:01 04/21/10 22:15:01 srv005$@DOMAIN.NET
>>> renew until 04/28/10 12:15:01
>>>
>>>
>>> Kerberos 4 ticket cache: /tmp/tkt0
>>> klist: You have no tickets cached
>>> ----------------------------
>>>
>>> Reminder :
>>>
>>> Because this is our maintenance / root station for our nashead, I am
>>> renewing our ticket every hour with a cronjob. So the lifetime of the
>>> ticket is extended every hour. Could this be one of the actions that
>>> causes this ?
>>>
>>> Greetings ... Richard Smits
>>>
> Hello,
>
> > Looks like the SRV005 at DASTDU is changing the password.
> Well srv005 is the Windows Domain Controller, and DASTUD the windows domain.
>
> I use a single workstation account for my server. Why would someone need
> more ?
>
> There is no cronjob on the client or server side what could be causing
> this in my knowledge.
>
> > Did you do a setspn command to add root/hostname.domain.net at DOMAIN.NET
> > (What UPN and SPNs are on the account?)
>
> Ok, here are my UPS's and SPN's of the computer object :
>
> (servicePrincipalName)
> HOST/NASMGT
> HOST/nasmgt.tudelft.net
> ROOT/nasmgt
> ROOT/nasmgt.tudelft.net
>
> (userPrincipalName)
> root/nasmgt.tudelft.net at TUDELFT.NET
>
> But in my keytab file the HOST entry's are not there.... could this be a
> problem. I am relatively a newby for krb5, and never understood where
> the HOST entry's were for.
>
> Your story about not needing a root entry in the keytab is interesting.
> I will look in to this.
>
> Greetings .. Richard
> ________________________________________________
> Kerberos mailing list Kerberos at mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
Well, I just want to say that this problem has been solved. It took a
long time, but this is the solution :
The new samba versions has a different syntax in the smb.conf file.
In the old versions of samba, there was a line that said :
use kerberos keytab = yes
But in the newer versions, they changed the syntax of this line to :
kerberos method = secrets and keytab
This line says that the AD communication will use the keytab file, AND
the sessions.tdb file.
If you do not have this line, it only uses the session.tdb, and your
keytab will be out of sync in a couple of days.
Greetings .. Richard
More information about the Kerberos
mailing list