AW: [ActiveDir]
Hi Chris, If you have a backup of that domain - restore. If you don't have a backup, and it was the fist domain in the forest (forest root) then create a new forest and migrate step by step every of the existing domains into the new forest (ADMT or other migration tools from 3rd party vendors will help you here). If it wasn't the forest root domain which blow up, you are able to recreate the domain (under a different name) in the same forest, then you might be able to use the domain rename tool to put the domains which were underneath your lost one underneath the new one. If domain rename will not work, you'll have to create those domains new as well and migrate the ressources of the old domains into the new ones (ADTM or some other migration tools again). The Domain rename depends on your OS and forest and domain level - if it is WS2k3 Native this might be an possibility. However I've never tried what domain rename does if a domain is missing in the forest. If you don't migratie everything into a new forest you'll also have to perform a metadata cleanup. At what time is to be considered in a test environment. If you are able to clean the old domain out of the forest right away and the downlevel domains will still work you'll have much less problems with everything else, and the domain rename tool will work for sure (if you don't have any other stuff which prevents you from using that). Good luck, and remember afterwards that 2nd DCs and Backups are your best friends ;-) Ulf B. Simon-Weidner -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Chris Jones Gesendet: Samstag, 8. Mai 2004 01:13 An: [EMAIL PROTECTED] Betreff: [ActiveDir] Hi guys, I need some help here. We have a single forest with 2 domain trees. One of the domain trees has includes domains. One parent domain and 2 child domains. All three domains have one DC. A few days ago, the DC from the parent domain stopped working because of some h/w issues. So, the whole AD environment is screwed up. Im trying to install another DC for the same domain but it fails. Guess it tries to connect to the faulty DC. I cannot remove that domain as it has 2 child domains. Would it be possible to create another domain tree and change the parent domains for those 2 child domains? Any suggestions on how I can solve this problem?? Chris _ Stop worrying about overloading your inbox - get MSN Hotmail Extra Storage! http://join.msn.com/?pgmarket=en-uspage=hotmail/es2ST=1/go/onm00200362ave/ direct/01/ List info : http://www.activedir.org/mail_list.htm List FAQ: http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/mail_list.htm List FAQ: http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
AW: [ActiveDir] Dieing forest
Hello Rens, Migrate with ADMTv2, look into the guides MS published for a migration from one forest into another. Since you are able to keep the SID in the SIDHistory you are able to retain permissions, however I'd also look to reAcl the Ressources to the new SIDs. This can be done with ADMT, SIDWalk migration suite or 3rd Party Migration Tools. Ulf Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Rens MeijerGesendet: Donnerstag, 6. Mai 2004 15:07An: [EMAIL PROTECTED]Betreff: [ActiveDir] Dieing forest Hi all, A customer of mine had a forest root domain and a child domain. By disaster the single (i know very bad) DC in the forest root domain has crashed and cannot be restored. All replication within the forest came to a hold. By creating the forest root domain on one of the DNS servers in the child domain, GC and Domain SRV records were registered again and replication between the DC's in the child domain resumed. Accept with the forest root domain DC ofcourse because it is not there anymore. Now they're in a temporarily stable situation, but the question is for how long? Even Microsoft comes with different answers. Does anyone have thoughts about how long an orphaned child domain can sustain on it own? In my opinion the real solution is to create a new forest and migrate all the AD and Exchange data to the new forest. We already installed a new forest, we could create a trust between the 2 domains. Now we want to migrate from W2K-E2K to W2K-E2K and retain all AD, NTFS, share, Exchange permissions. Does anyone know how to accomplish this? TIA, Rens Meijer
AW: [ActiveDir] Variables allowed for creating home folders
Hello Stephen, I don't think so. AFAIK the only variables which you are able to use during logon are the ones which are system variables on the clients plus the %username%. Variables defined in the context of the user are not available at this time. AFAIK2 - the variable username is filled from the logon-box, depends on what the user types in there. I'm not 100% sure if that's still the case, but a long while ago I had issues that the %username% was sometimes uppercase and sometimes lowercase, and it did not depend on the users properties in the directory. I found out that the %username% was exactly in the same spelling the user typed it into the logon-box. But this was either in the late NT4 or early 2000 days, so this behavior might have changed. HTH, Ulf Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Bell, StephenGesendet: Mittwoch, 5. Mai 2004 18:09An: [EMAIL PROTECTED]Betreff: [ActiveDir] Variables allowed for creating home folders My question is this. Is there a variable that I can use when creating user home directories that will resolve to the User Logon Name just as username resolves to the samaccount name or Pre Windows 2000 User Logon Name field? Background: Normally what I use when creating home directories (actually allowing AD to make them I should say) is (location)\username and this creates the home directory using the name shown in the Pre Windows 2000 User Logon Name field (actually the samaccount name I believe). Do to a change in naming conventions I would like to adjust that. The new naming convention is the Pre Windows 2000 User Logon Name field will be a number such as 12345 while the User Logon Name will be the users name. I would prefer to have the home directories name be a little more readable rather than have people having to remember their number. This is only an issue when going though the GUI. Ive all ready got the script that I use to make users in batch mode converted over. I just took the UPN name and stripped off everything after the @ character and used that to name the home directories. Thanks for any help! Steve
AW: [ActiveDir] Cached Domain Credential logon expiry for Win2k/X P
Hi Joe, AFIAK the passwords of the computer accounts are not set to expire, but they are automatically changed. The password change is done from the netlogon service. The default time in NT was 15 days, changed to 30 days in W2k and later. The client might decide to change after the half of the period is over, but has to change when it's over. So technically your NT4 client might change it's password after 7,5 days, the WXP client after 15 days. It like in DHCP - half time of the period is over and it's up to client and server to decide when it's convenient to change. But there's also a registry key underneath Netlogon/Parameters, which sets on the client not to change the password, or vice versa on the DCs to refuse password change requests. So if you have a client who never exchanged his password, it will still work. However, if you have a client which was imaged, backed up, or running in a virtual machine using some roll back to snapshot feature, the following might occur: 1. The state of the client is backuped / snapshotted 2. The client runs in the domain, whenever it decides it'll change his computer password (NT4 earliest 7,5 days after joining the domain/resetting the password, WXP 15 days) 3. After the client changed his password, you roll back the machine. So if there was just one change, the AD remembers the last computer account password. A NT4 Domain does not, so the client in the NT4 Domain is not able to connect to the domain. If there was more than one change of the computer account password between the client and the domain, you can not log on to the domain. You'll need to reset the computer account password first. So especially for your Virtual Machines to test stuff there might be a reason to disable the password change on the client side. If the client does not change, the DC never will. Same as your user account password - if the user never decides to change the password the DC will not send him a mail with his new password ;-). And as I mentioned earlier, I'm quite sure that the password is not set to expire in the domain. Look at KB 154501 (old KB, but AFAIK still valid) on how to disable the password change of the computer account either on the client or the server side. Thinking of it - it would be a great security enhancement to set the computer account passwords to expire after a certain time. Because with the current behavior a client which was out of the domain for ages will always be able to log back onto it - since the client didn't had a contact to the domain it didn't change the password. So the old one is still valid. I believe the computer would not be able to handle the expired passwords, but WTH - if you set the period long enough this will never happens since he's used to change it's password frequently anyways. But since we are not able to do this as of today ... OK - enough for now - just my 0.02 Ulf -Ursprngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von joe Gesendet: Donnerstag, 6. Mai 2004 14:31 An: [EMAIL PROTECTED] Betreff: RE: [ActiveDir] Cached Domain Credential logon expiry for Win2k/X P I am actually starting to wonder on this and how it actually works and now have some new theories. I recently had to troubleshoot an issue and there were machines with passwords that were greater than 600 days old. The password had never been changed from the first day the machines were added to the domain and the machines WERE working fine with the domain. The issue ended up being that NETLOGON service had been disabled on the workstation. This made it so you couldn't use any local principals but you could still logon with a domain ID. The NETLOGON service is what keeps the passwords getting updated as well as the SP level and probably some other things in AD. I am sure there were probably some other things that weren't working quite exactly as expected either but the users seemed to have no issues. As soon as the service was restarted, the password changes started occurring again. I didn't have a chance to really dig into why the accounts kept working whether it was some special flag or not, we just wanted it cleaned up. Since the passwords were that old though and the people could still use the domain, it makes me wonder if the passwords truly break for workstations, if it isn't on the workstation side versus the domain side I.E. The workstation is completely responsible for whole process and you actually have no control from the domain side. I always wondered how the regedit on the workstation could change the functionality, this would explain that. joe -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Roger Seielstad Sent: Thursday, May 06, 2004 7:43 AM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] Cached Domain Credential logon expiry for Win2k/X P Default password aging for machine accounts is 30 days in AD and 7
Re: [ActiveDir] Mac clients passwords
Ian is correct about the AD Plugin, it isn't flaw free, but if you are simply trying to provide Single Sign On access to file servers with a windows UID and password you have the alternative of using OS X's kerberos support which is quite good. AdmitMac is a comparatively expensive solution that I found to be just as buggy as the Apple implementation. So first we'll try the AD Plugin. If it doesn't work, there are some other things that we may be able to do. So, the first thing that you will want to do is upgrade the machine to 10.3.3. This can be done via software update in the System Preferences (by default you can access system preferences from the Dock). Next, provide time synchronization services to the Mac OS Client from the DC. This is so your kerberos bind to add a machine account to the network won't fail due to timestamp problems. Click the clock in the upper left corner of the toolbar and click Open Date Time ... On the Date Time screen put a check in the box for Set Date Time automatically: , Then enter the fully qualified name of a DC in the box for a time server. Close the Date Time box. Open the finder and browse to /Applications/Utilities and open Directory Access. If the lock in the lower left corner is in the locked position, click on it and enter the appropriate credentials. Click Active Directory and click Configure you should then be able to enter your forest name in the Active Directory Forest box, enter your AD domain in the Active Directory Domain box, and finally the name of the computer account you want to use in the Computer ID box. Click the Hide Advanced Options box and unless you will absolutely need to authenticate users from multiple domains, then clear the checkbox. If the machine is a laptop, You can also choose to allow AD groups administrative rights to the mac. By default this is set to Domain Enterprise admins. When finished with all your options click the Bind button. You will be prompted for an account with permissions to add computers to the domain. The default ldap computer account location is in the CN=Computers area off the root default domain NC. You can change this by adding a fully distinguished path to the Container or OU of your choice. The machine will go through 5 steps and hopefully bind successfully. Next, Go back to the Directory Access application and click the Authentication tab at the top. Under search click Custom Path and click Add. A box will pop up and display the Active Directory connector you just added click Add, click Apply. If you have a successfully bound and added the AD connector to your authentication path, then you can log off and attempt to login using the sAMAccountname of the user. Troubleshooting If you have any issues, enable remote login in the Sharing section of System Preferences and use another machine to SSH into the Mac. If you are using a windows box to SSH there is a free application called putty that you can use, just google for it. After ssh'ing into the box with an admin user account, enter the command: sudo killall -USR1 DirectoryService this command puts the lookupd daemon in debug logging mode, then type: tail -f /Library/Logs/DirectoryService/DirectoryService.debug.log | grep ADPlug this tells your shell to read the tail end of the log file and print any new entries to STDOUT. Now attempt to login to the machine, and your SSH machine will capture what is going on with the AD Plugin. Paste the results of the tail command back here and we'll work from that point. Good Luck, Brent On May 7, 2004, at 1:42 PM, Creamer, Mark wrote: x-tad-biggerHi Brent, theyre all 10.3.2. Thanks for your help on this/x-tad-bigger x-tad-bigger/x-tad-bigger mc> x-tad-bigger-Original Message-/x-tad-bigger x-tad-biggerFrom:/x-tad-biggerx-tad-bigger Brent Westmoreland [mailto:[EMAIL PROTECTED]/x-tad-bigger x-tad-bigger /x-tad-biggerx-tad-biggerSent:/x-tad-biggerx-tad-bigger Friday, May 07, 2004 12:58 PM/x-tad-bigger x-tad-biggerTo:/x-tad-biggerx-tad-bigger [EMAIL PROTECTED]/x-tad-bigger x-tad-biggerSubject:/x-tad-biggerx-tad-bigger Re: [ActiveDir] Mac clients passwords/x-tad-bigger Which version of OS X? 10.3 or above has an Active Directory client built in that can typically be configured to work with AD, if not there are options for using Kerberos for single sign on. Post back the specific version, and I can help you get it going whether it be 10.3 or back. Brent. p.s. to get the specific version of os x, 1. log in 2. click the apple button in the upper left hand corner 3. click About this Mac On May 7, 2004, at 9:07 AM, Creamer, Mark wrote: They are OSX mc> -Original Message- From: Bruce Clingaman [mailto:[EMAIL PROTECTED] Sent: Thursday, May 06, 2004 5:39 PM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] Mac clients passwords Are the Mac clients OSX or 9.earlier? From: [EMAIL PROTECTED]