AD 'home directory' versus LDAP "home directory' RRS feed

  • Question

  • LDAP shows that my user's home directory is empty, even though I believe I set it.  I am using a LDAP browser to view my ldap settings and I also check it using a simple VB script. I am having no luck setting a home directory for my user.  NOTE: I AM NOT LOOKING FOR HOW TO SET THE USER'S HOME FOLDER. I realize that you can set a user's home folder in ADU&C, but setting this value (I tried both home foler & terminal home folder) does not affect the LDAP attribute "home directory".  HOW DO I SET THIS?

    Thank you very much [in advance]!

    • Edited by KrishnasPad Friday, June 26, 2009 6:46 PM Fixing thread title bug
    • Edited by Test Guy 23 Tuesday, July 7, 2009 3:57 PM
    Tuesday, June 23, 2009 1:28 PM


All replies

  • The value of homeDirectory attribute of a user object should be consistent, whether you are viewing it via Active Directory Users and Computers or any other AD access method.
    Can you describe what exactly are the steps that don't yield the expected result - and post your sample VB Script?

    Tuesday, June 23, 2009 1:43 PM
  • Hi,

    Which LDAP browser did you use? LDP.EXE or ADSIEDIT.MSC? I cannot reproduce this issue on my test machines. More information is useful for research.


    This posting is provided "AS IS" with no warranties, and confers no rights.
    • Marked as answer by Mervyn Zhang Tuesday, June 30, 2009 3:53 AM
    • Unmarked as answer by Mervyn Zhang Monday, July 6, 2009 11:09 AM
    Wednesday, June 24, 2009 7:40 AM
  • Mervyn,

    I actually used the java-based jXplorer.  I will check out LDP.EXE.  The vbscript I used came from 'Hey, Scripting Guy!'; I modified as necessary.

    On Error Resume Next

    Set objUser = GetObject("LDAP://cn=user.t.1,DC=jc,DC=local")

    If IsEmpty(objUser.homeDirectory) Then
        wscript.echo "EMPTY"
        strUser = objUser.sAMAccountName
        strHomeDirectory = "\\DC\xcdfs\Sales\" & strUser
        objUser.homeDirectory = strHomeDirectory
        objUser.homeDrive = "H:"
    ELSEIF IsNull(objUser.homeDirectory) THEN
        wscript.echo "NULL"
        wscript.echo objUser.homeDrive
    End If

    I was told that LDAP may not show the contents of a user's home directory, as a security consideration. Is this the case?
    Thursday, June 25, 2009 4:59 PM
  • No, that is not the case. As long as the account you are using has permissions to read the target attribute, you should be able to view it via LDP (based on your original post, it appears that you can view it via ADUC, so I don't believe that attribute-level permissions are playing any role here)...

    • Marked as answer by Mervyn Zhang Tuesday, June 30, 2009 3:53 AM
    • Unmarked as answer by Mervyn Zhang Monday, July 6, 2009 11:09 AM
    Thursday, June 25, 2009 5:13 PM
  • Hi,

    Thanks for helping me with this.  I am still unable to see my user's home directory via LDAP.  I can see every other set attribute.

    Again I set the home directory via ADUC snap-in >> <User> properties >> Profile tab >> Home Folder section

    Tuesday, July 7, 2009 3:56 PM
  • This is one possible method of creating home directories - so it should yield the results you are looking for. Have you tried using any other utilities providing you with direct access to AD (e.g. LDP, ADSIEdit) to view the homeDirectory attribute for the target user?

    Tuesday, July 7, 2009 6:59 PM
  • Hello,

    I found the answer to this issue yesterday.  I was using the Global Catalog (port 3268) to browse LDAP.  Apparently, you cannot view the home directory via 3268.  When I changed the port to 389 I could view the home directory.

    Does anybody have a workaround / fix for this?

    Thank you.

    Friday, July 10, 2009 12:44 PM
  • Hi,

    Add the Home Directory attribute to GC would help:



    • Marked as answer by Test Guy 23 Friday, July 10, 2009 1:15 PM
    Friday, July 10, 2009 12:56 PM
  • You would need to include the attribute in the partial attribute set as described in http://support.microsoft.com/kb/248717
    Although the more reasonable approach would be to simply connect via port 389...

    • Marked as answer by Mervyn Zhang Monday, July 13, 2009 1:34 AM
    Friday, July 10, 2009 1:07 PM