Owncloud appliance LDAP setup issues

Withe the help of one of  expert btan i was able to get my 1st OwnCloud appliance off the ground but I'm having some problems with the LDAP portion. I followed this link as closely as I could:
 I have successfully registered OC with my AD but after trying just about everything I still cannot get LDAP to return usernames rather than UUIDs and I am unable to login using active directory credentials but I can definitely see the LDAP tree in the groups column which also means that I can in fact ping the domain controller by name. Thank you!
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Aaron TomoskyDirector of Solutions ConsultingCommented:
Did you fill in the username attribute as samaccountname?
Chris DentPowerShell DeveloperCommented:
What values did you supply it with for its LDAP configuration?

AmitIT ArchitectCommented:
If there is any firewall between this server and dc make sure to open port 389, rest is self explanatory from the URL you provided...
SolarWinds® VoIP and Network Quality Manager(VNQM)

WAN and VoIP monitoring tools that can help with troubleshooting via an intuitive web interface. Review quality of service data, including jitter, latency, packet loss, and MOS. Troubleshoot call performance and correlate call issues with WAN performance for Cisco and Avaya calls

btanExec ConsultantCommented:
From the oc doc, as you edit the "User Filter", it should display 'x users found' where x is in the "Users" in AD. If there is the correct no of users in AD, it means the connection for LDAP should be alright. Just to make sure also have the DNS server working w/o error, in the past I need to even put in the PTR for the domain in appliance.

Below are some to take note

For the AD attribute clarification, you can find out more in http://www.selfadsi.org/user-attributes.htm or http://www.kouti.com/tables/userattributes.htm
Specific to your AD user profile displayed configuration  (or ADUC) tab
>userPrincipalName - under "Account" as "Logon Name"
>sAMAccountName - under "Account" as "Logon Name (pre-Windows 2000)"
>mail - under "General" as "E-Mail Address"

The string 1.2.840.113556.1.4.1941 specifies LDAP_MATCHING_RULE_IN_CHAIN. This applies only to DN attributes. This is an extended match operator that walks the chain of ancestry in objects all the way to the root until it finds a match. This reveals group nesting. It is available only on domain controllers with Windows Server 2003 SP2 or Windows Server 2008 (or above).

E.g. All members of specified group, including due to group nesting
(memberOf:1.2.840.113556.1.4.1941:= cn=Test,ou=East,dc=Domain,dc=com)

Many times you can take advantage of the fact that only one class of object in Active Directory has a particular attribute. For example, only group objects have the groupType and member attributes. This allows you to filter on groupType with a clause like (groupType=2) without using a second clause restricting the query to group objects, like (objectCategory=group). However, if your query only has the one filter, it will be checked against all objects in Active Directory. It turns out that if you also use the second clause (to restrict the query to groups), it runs faster. The results will be the same, and in most cases the time difference doesn't matter much, but a filter like (&(objectCategory=group)(member=cn=Jim Smith,ou=West,dc=MyDomain,dc=com)) is much faster than simply (member=cn=Jim Smith,ou=West,dc=MyDomain,dc=com).

E.g. All groups specified user belongs to, including due to group nesting
(member:1.2.840.113556.1.4.1941:= cn=Jim Smith,ou=West,dc=Domain,dc=com)

User Search Attributes: If an attribute is not available on a user object, the user will not be listed, and will be unable to login. This also affects the display name attribute. If you override the default you must specify the display name attribute here. Example:
Internal Username:
The internal username is the identifier in ownCloud for LDAP users. By default it will be created from the UUID attribute. The UUID attribute ensures that the username is unique, and that characters do not need to be converted....You can override all of this with the Internal Username setting. Leave it empty for default behaviour. Changes will affect only newly mapped LDAP users. Example:

Override UUID detection
By default, ownCloud auto-detects the UUID attribute. The UUID attribute is used to uniquely identify LDAP users and groups. The internal username will be created based on the UUID, if not specified otherwise.

You can override the setting and pass an attribute of your choice. You must make sure that the attribute of your choice can be fetched for both users and groups and it is unique. Leave it empty for default behaviour. Changes will have effect only on newly mapped LDAP users and groups. It also will have effect when a user’s or group’s DN changes and an old UUID was cached, which will result in a new user.

Because of this, the setting should be applied before putting ownCloud in production use and clearing the bindings (see the User and Group Mapping section below). Example: cn

In case the configuration fails, you can see details in ownCloud’s log, which is in the data directory and called owncloud.log or on the bottom the Settings – Admin page. You must refresh the Admin page to see the new log entries.

User and Group Mapping
In ownCloud the user or group name is used to have all relevant information in the database assigned. To work reliably a permanent internal user name and group name is created and mapped to the LDAP DN and UUID. If the DN changes in LDAP it will be detected, and there will be no conflicts.
Also, it is stated there is a "Test Configuration" button on the bottom of the LDAP settings section.
It will always check the values as currently given in the input fields. You do not need to save before testing. By clicking on the button, ownCloud will try to bind to the ownCloud server with the settings currently given in the input fields.
A_AmericanELectricAuthor Commented:
Hey guys. Sorry for the lack of response.  I got 89% complete and  let massive file syncing go on all night and feel asleep and let one of my VHD s overfill pausing all the hyper v guests.
Being very tired I did something stupid while expanding a volume in Disk Management andi wrecked my fake raid so yes it had been a setback but I'm getting it.
Be back soon
A_AmericanELectricAuthor Commented:
I need to come back to this because I have no running copy.
Can you please have a look here at this post:
Seuss own cloud in a box configuration
btanExec ConsultantCommented:
The post ID: 40731710 has already stated the approach is to make sure the right LDAP parameter and DNS setting can be verified and retry again on the AD binding so that the user list can be checked tas per the OC setup. Suggest that this can be considered instead of deleting the post.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
btanExec ConsultantCommented:
As per last post comments (ID: 41770189).
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Cloud Computing

From novice to tech pro — start learning today.