1.3.0.2 Alpha posted with AD Groups fix & x64 -- please test

Topics: Developer Forum, User Forum
Coordinator
Dec 27, 2007 at 10:20 PM
Edited Dec 27, 2007 at 10:21 PM
Two minor changes -- a patch for the AD Groups issue from Culverhay and consistent versioning across assemblies. x64 bits also included in this release.

Please test and if all looks well I'll post as the official 1.3.0 bits. [release:9227]
Coordinator
Dec 27, 2007 at 11:02 PM
FYI, I'm running into versioning issues with the SCORM WebPlayer & four part version numbers. Working on that now, should have fixed 1.3.0.2 bits here in a little bit.
Coordinator
Dec 28, 2007 at 12:06 AM
Fix posted.
Coordinator
Jan 4, 2008 at 5:30 PM
FYI, still looking for a few testers for this release. I have one 'yes' vote, it's been a bit over a week.

Please download to Install\Release, run UpgradeSolution.cmd, and then run a few of the Build Validation Tests on one of your test machines.

Thanks,

- jcb
Jan 7, 2008 at 3:05 PM
Edited Jan 7, 2008 at 3:16 PM
Sorry. Please disregard. I re-checked and I am still using 1.3.0.1. I will wait patiently for 1.3.0.2 to be released and hope that it will fix my issues with AD groups!
Thanks!
Jan 7, 2008 at 8:26 PM
Jay,

I've tried out 1.3.0.2 and still am having problems enumerating my AD groups. I am logged into my computer as a domain admin and have full control on the site.

error message displayed:
An error occurred. More information may be available in the server event log.

event log error:
System.Security.Authentication.AuthenticationException: Logon failure: unknown user name or bad password.
---> System.DirectoryServices.DirectoryServicesCOMException (0x8007052E): Logon failure: unknown user name or bad password.

at System.DirectoryServices.DirectoryEntry.Bind(Boolean throwIfFail)
at System.DirectoryServices.DirectoryEntry.Bind()
at System.DirectoryServices.DirectoryEntry.get_AdsObject()
at System.DirectoryServices.PropertyValueCollection.PopulateList()
at System.DirectoryServices.PropertyValueCollection..ctor(DirectoryEntry entry, String propertyName)
at System.DirectoryServices.PropertyCollection.get_Item(String propertyName)
at System.DirectoryServices.ActiveDirectory.PropertyManager.GetPropertyValue(DirectoryContext context, DirectoryEntry directoryEntry, String propertyName)
--- End of inner exception stack trace ---
at System.DirectoryServices.ActiveDirectory.PropertyManager.GetPropertyValue(DirectoryContext context, DirectoryEntry directoryEntry, String propertyName)
at System.DirectoryServices.ActiveDirectory.Domain.GetDomain(DirectoryContext context)
at Microsoft.SharePointLearningKit.DomainGroupUtilities.EnumerateDomainGroup(String groupName, TimeSpan timeout)
at Microsoft.SharePointLearningKit.SlkStore.EnumerateDomainGroupMembers(SPWeb spWeb, SPUser domainGroup, Boolean isInstructor, Boolean isLearner, List`1 groupFailuresList, StringBuilder groupFailureDetailsBuilder, Dictionary`2 instructorsByUserKey, Dictionary`2 learnersByUserKey, Dictionary`2 users, List`1 learnerKeys, List`1 learnerGroups, DateTime startTime)
at Microsoft.SharePointLearningKit.SlkStore.<>c_DisplayClass6.<GetMemberships>b_5()
at Microsoft.SharePoint.SPSecurity.CodeToRunElevatedWrapper(Object state)
at Microsoft.SharePoint.SPSecurity.<>c_DisplayClass4.<RunWithElevatedPrivileges>b_2()
at Microsoft.SharePoint.Utilities.SecurityContext.RunAsProcess(CodeToRunElevated secureCode)
at Microsoft.SharePoint.SPSecurity.RunWithElevatedPrivileges(WaitCallback secureCode, Object param)
at Microsoft.SharePoint.SPSecurity.RunWithElevatedPrivileges(CodeToRunElevated secureCode)
at Microsoft.SharePointLearningKit.SlkStore.GetMemberships(SPWeb spWeb, IEnumerable`1 additionalInstructors, IEnumerable`1 additionalLearners, ReadOnlyCollection`1& groupFailures, String& groupFailureDetails)
at Microsoft.SharePointLearningKit.ApplicationPages.AssignmentPropertiesPage.get_SlkMembers()
at Microsoft.SharePointLearningKit.ApplicationPages.AssignmentPropertiesPage.SetAssignmentProperties()
at Microsoft.SharePointLearningKit.ApplicationPages.AssignmentPropertiesPage.OnPreRender(EventArgs e)
Coordinator
Jan 8, 2008 at 12:15 AM
Edited Jan 8, 2008 at 12:17 AM

lilmrsgowin wrote:
Sorry. Please disregard. I re-checked and I am still using 1.3.0.1. I will wait patiently for 1.3.0.2 to be released and hope that it will fix my issues with AD groups!
Thanks!


1.3.0.2 is posted to [release:9227], but it doesn't become released until people download and test it. I'd strongly suggest downloading and trying it rather than waiting.
Coordinator
Jan 8, 2008 at 12:37 AM

JaredKahlil wrote:

I've tried out 1.3.0.2 and still am having problems enumerating my AD groups. I am logged into my computer as a domain admin and have full control on the site.

event log error:
System.Security.Authentication.AuthenticationException: Logon failure: unknown user name or bad password.
---> System.DirectoryServices.DirectoryServicesCOMException (0x8007052E): Logon failure: unknown user name or bad password.


Is there anything special about your installation of SLK, SharePoint, your domain topology, or the security settings on your domain? I'm definately not seeing this error when testing group enumeration in my forest. I've done a bit of searching on the methods being called here at the failure point and there's nothing extraordinary happening.

My working hypothesis of the situation is that the account under which SLK is running (probably the default account of WSS which can be seen via looking at the AppPool Identity of the AppPool associated with the IIS Application that WSS is using) does not have permissions to open the domain you're attempting to enumerate. I suspect this is not due to a flaw in the code but rather something specific to how IIS/WSS/SLK is configured on your server and/or how your domain(s) is set up. It's failing on the point where it's attempting to open the domain, even before it searches for the group.
Jan 8, 2008 at 3:44 PM
Thanks Jay,

You were correct. My SharePoint site was running locally under a local system account. After changing the app pool identity to a domain account with the proper AD permissions and making it a member of the local IIS_WPG group everything worked perfectly.

I've noticed that adding all authenticated users still doesn't work. This isn't a big deal for me, just wanted to make sure it was a known issue.
Coordinator
Jan 8, 2008 at 7:48 PM
The bug for "all authenticated users" was closed as "won't fix" and a new work item was entered to disable/warn against attempting to do this.

Using all authenticated users, if it was fixed to work, would cause SLK to enumerate and create assignment records for every single user in the Active Directory forest. This is a bad idea :-)