nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

CIFS active directory object related

Baiju625

Hi Gurus,

We are migrating vfilers from 7-mode (CIFS only access) to CDOT. I like to destroy the 7-mode vfiler and use same name and IP details for the new SVM so that I dont have to change any user share path names. In this regard, do I need to delete the CIFS Server object in AD and recreate it by from CDOT with Vserver CIFS create or can I re-use the CIFS Server AD object (I prefer to do this way). Just wanted to understand the active directory CIFS server object has any attribute specific to 7-mode or CDOT? if not reusing the object should not be an issue correct? please advise.

Find more posts tagged with

Accepted answers

Ontapforrum

SPN is the key for CIFS authentication via Kerberos. By default, an "AD object" is configured with a SPN that matches the name of the computer object (i.e CIFS server netbios/DNS name).

Hence, if you are creating a "CIFS" server named exactly like the one in 7-mode and using the same IP (Assuming this will need a planned downtime), then you should be fine. Users will not notice any changes to the way they are accessing the shares from 7-mode. However, by not deleting the existing AD CIFS computer object, you may get into 'SPN conflict' issue, where kerb authentication may fail due to error "SPN in use by the original AD object". If a valid "SPN" exists, only then "Kerberos" authentication is used. If there is no valid SPN (SPN that matches the hostname used) then CIFS falls back to NTLM. If NTLM is not allowed in the domain, auth fails.

In any case, have a user, who is a member of Domain Admins, run this cmd to obtain the current SPNs for the computer AD object:

C:> setspn.exe -l <Cifs server netbios name>

If you would like to know more on SPN, then this is a good thread.

https://community.netapp.com/t5/ONTAP-Discussions/What-authentication-method-does-CIFS-server-use-for-CIFS-clients/m-p/158928

On the side note: Another equally important task is that - To ensure the volume to which the shares are migrated are either better but not worse as far as performance is concerned. If the end-clients complain the shares are slower then it could be pain to fire-fight those issue . I am sure you must have done read/write testing of shares/volume from the cDOT filer.

All comments

Ontapforrum

SPN is the key for CIFS authentication via Kerberos. By default, an "AD object" is configured with a SPN that matches the name of the computer object (i.e CIFS server netbios/DNS name).

In any case, have a user, who is a member of Domain Admins, run this cmd to obtain the current SPNs for the computer AD object:

C:> setspn.exe -l <Cifs server netbios name>

If you would like to know more on SPN, then this is a good thread.

https://community.netapp.com/t5/ONTAP-Discussions/What-authentication-method-does-CIFS-server-use-for-CIFS-clients/m-p/158928

Baiju625

Thanks a lot for the insight. Today I did a test by deleting the 7-mode vfiler and then created SVM with same name and used same IP for the data LIF. Then I ran vserver CIFS create with same OU path and it detected old CIFS server and asked whether you want to reuse and I said yes and CIFS services came up. I am able to create share and access from my SVM with the same \\cifs-servername\share. So I can save a lot of time by not changing the home dir and other share paths after cutover. Only thing I noticed is that if I go to AD and right click the CIFS server object in the OS filed it is still showing old 7-mode OS info not the CODT OS info. Which means reuse has not updated any information on the object it seems. I am not sure is it very significant. Am I fine just ignoring this fact? or other option is to delete the CIFS object manually first from AD and then run the cifs create from CDOT. Problem is if I delete AD object I need to wait for 30 minutes for AD changes to propagate during cutover, also there are chances of human error by clicking and deleting another prod vfiler object by mistake . To avoid this, I thought of reusing the object. It seems delete and the re-cerate during CIFS create is a cleaner option right? please advise.

Performance wise, we are migrating from old v-series with HP EVA SAN backend to a FAS8300 (ONTAP 9.11) with flashcache and flashpool, expecting performance shouldn't be worser than the old environment , but consolidating 5 HA pair to one FAS8300 2-node cluster, yes I will be observing the workload stats as we progress.

Ontapforrum

Thanks for the update. Yes, deleting and creating object is cleaner option. In Active Directory Users and Computers, if you right-click a computer object there is an option to “Reset Account”. Resetting the computer’s account essentially breaks the secure channel connection between the computer and the server. You could also do that before attempting to join the new CIFS server to AD (If you choose not delete it). As long as shares accessible and working as expected from the client's perspective, I guess you should be fine.

Coming to performance : I mentioned it b'cos I had been in that situation myself and it was close to breaking point for me. We had migrated from 7-mode 3250 to FAS8200, 6, Nodes, with flashpool etc. Initial planning was done but we failed to do the read/write test. We mapped disk to disk, headroom performance, and all the rest of it. Chunk of those shares were serving finance. It was fire-fight from day 1 after migration, and the policy was to fix-forward, so there was no going back. Issue got escalated very quickly, NetApp PS came over for 2 days, did thorough testing but there wasn't anything sticking out as red-flags, plenty of CPU headroom, disk IOs flying, so eventually case was put to research and we had to upload tons of logs. Eventually, bizarre enough but it turned out to be something related to UTA2/CNA Port. Only difference to 7-mode was that, CIFS was going out from Physical 10g Ethernet adapter. Once we switched to Independent available single Ethernet Port (to isolate the issue), issue resolved. I guess, had we tested this before the move, it would have made life easier. Lesson learnt.

Baiju625

oh that is a difficult issue to identify, excellent job!. Ok let me better plan a file up-load and read write test.